Direct C2 authorization

Abstract

A method for an SMF to perform communications is disclosed. The method may comprise the steps of: receiving authorization request information for direct C2 communication from a UE; sending an authorization request message to the USS; receiving an application layer ID of the UAV-C from the USS; and sending the application layer ID of the UAV-C to the UE.

Description

Technical Field

[0001] This specification relates to mobile communications. Background Art

[0002] The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is a technology for implementing high-speed packet communications. Many solutions have been proposed for LTE objectives, including those aimed at reducing user and provider costs, improving service quality, and expanding and enhancing coverage and system capacity. 3GPP LTE requires reduced cost per bit, increased service availability, flexible use of frequency bands, simple structure, open interfaces, and sufficient power consumption of terminals as upper layer requirements.

[0003] In the International Telecommunication Union (ITU) and 3GPP, requirements and specifications for a New Radio (NR) system have been started. 3GPP must identify and develop technical components that will successfully standardize a new RAT that will meet both the urgent market needs in a timely manner and the longer-term requirements set forth in the ITU Radiocommunication Sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. In addition, NR should be able to use any spectrum band in the range of at least up to 100 GHz that will also be available for wireless communications even in the more distant future.

[0004] The goal of NR is a single technical framework that addresses all usage scenarios, requirements, and deployment scenarios, including enhanced mobile broadband (eMBB), massive machine type communication (mMTC), ultra-reliable and low-latency communication (URLLC), etc. NR should be inherently forward compatible.

[0005] Unmanned Aerial Systems (UAS) have been discussed in 5G. Command and control (C2) communication can be performed between an Unmanned Aerial Vehicle (UAV) and a UAV Controller (UAV-C) based on the PC5 interface. However, in the prior art, a specific method for performing authorization to perform such C2 communication has not been discussed. Summary of the Invention

[0006] Technical Solution

[0007] In one aspect, a method for an SMF to perform communication is provided. The method may include the following steps: directly receiving authorization request information for C2 communication from a UE; sending an authorization request message to a USS; receiving an application layer ID of a UAV-C from the USS; and sending the application layer ID of the UAV-C to the UE.

[0008] In another aspect, a device for implementing the method is provided.

[0009] In one aspect, a method for a UE to perform communication is provided. The method may include the steps of: sending authorization request information for direct C2 communication to the SMF; and receiving the application layer ID of UAV-C from the SMF.

[0010] In another aspect, a device for implementing the method is provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 An example of a communication system implementing the present disclosure is shown.

[0012] Figure 2 An example of a wireless device implementing the present disclosure is shown.

[0013] Figure 3 An example of a UE implementing the present disclosure is shown.

[0014] Figure 4 An example of a 5G system architecture implementing the present disclosure is shown.

[0015] Figure 5 and Figure 6 An example of a PDU session establishment process implementing the present disclosure is shown.

[0016] Figure 7 An example architecture of logical 5GS and EPS for UAVs is illustrated.

[0017] Figure 8a and Figure 8b The process of the first example in the first example according to the present disclosure is illustrated.

[0018] Figure 9a and Figure 9b The process of the second example in the first example according to the present disclosure is illustrated.

[0019] Figure 10 The process of the third example in the first example according to the present disclosure is illustrated.

[0020] Figure 11 The process of the fourth example in the first example according to the present disclosure is illustrated.

[0021] Figure 12 The process of establishing a layer-2 link at the PC5 reference point according to an embodiment of the present disclosure is illustrated.

[0022] Figure 13 An example process of establishing a PDU session for C2 communication according to an embodiment of the present disclosure is illustrated.

[0023] Figure 14An example of a PDN connection for C2 authorization according to an embodiment of the present disclosure.

[0024] Figure 15 An example of a process according to an embodiment of the present disclosure is illustrated. Detailed implementation

[0025] The following technologies, devices, and systems can be applied to various wireless multi-access systems. Examples of multi-access systems include code division multiple access (CDMA) systems, frequency division multiple access (FDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and multi-carrier frequency division multiple access (MC-FDMA) systems. CDMA can be implemented by radio technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented by radio technologies such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data Rates for GSM Evolution (EDGE). OFDMA can be implemented by radio technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). The 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) is part of the Evolved UMTS (E-UMTS) that uses E-UTRA. 3GPP LTE employs OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). The evolution of 3GPP LTE includes LTE-Advanced (LTE-A), LTE-A Pro, and / or 5G New Radio (NR).

[0026] For ease of description, implementations of the present disclosure are mainly described with respect to 3GPP-based wireless communication systems. However, the technical features of the present disclosure are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP-based wireless communication system, aspects of the present disclosure that are not limited to 3GPP-based wireless communication systems are applicable to other mobile communication systems.

[0027] For terms and technologies not specifically described among the terms and technologies adopted in the present disclosure, reference can be made to wireless communication standard documents published prior to the present disclosure.

[0028] In the present disclosure, "A or B" may mean "only A", "only B", or "both A and B". In other words, "A or B" in the present disclosure may be interpreted as "A and / or B". For example, "A, B, or C" in the present disclosure may represent "only A", "only B", "only C", or "any combination of A, B, and C".

[0029] In the present disclosure, a slash ( / ) or a comma (,) may mean "and / or". For example, "A / B" may mean "A and / or B". Thus, "A / B" may mean "only A", "only B", or "both A and B". For example, "A, B, C" may represent "A, B, or C".

[0030] In the present disclosure, "at least one of A and B" may represent "only A", "only B", or "both A and B". Additionally, the expressions "at least one of A or B" or "at least one of A and / or B" in the present disclosure may be interpreted the same as "at least one of A and B".

[0031] Furthermore, in the present disclosure, "at least one of A, B, and C" may mean "only A", "only B", "only C", or "any combination of A, B, and C". Additionally, "at least one of A, B, or C" or "at least one of A, B, and / or C" may represent "at least one of A, B, and C".

[0032] In addition, parentheses used in the present disclosure may mean "for example". Specifically, when it is shown as "control information (PDCCH)", "PDCCH" may be presented as an example of "control information". In other words, "control information" in the present disclosure is not limited to "PDCCH", and "PDCCH" may be presented as an example of "control information". Additionally, even when shown as "control information (i.e., PDCCH)", "PDCCH" may be presented as an example of "control information".

[0033] Technical features described separately in one of the drawings of the present disclosure may be implemented separately or simultaneously.

[0034] Although not limited thereto, the various descriptions, functions, processes, suggestions, methods, and / or operation flowcharts of the present disclosure disclosed herein may be applied to various fields that require wireless communication and / or connection (e.g., 5G) between devices.

[0035] Hereinafter, the present disclosure will be described in more detail with reference to the drawings. Unless otherwise specified, the same reference numerals in the following drawings and / or descriptions may refer to the same and / or corresponding hardware blocks, software blocks, and / or functional blocks.

[0036] Figure 1 An example of a communication system to which an implementation of the present disclosure is applied is shown.

[0037] Figure 1 The 5G usage scenarios shown are merely exemplary, and the technical features of the present disclosure can be applied to Figure 1 other 5G usage scenarios not shown herein.

[0038] The three main requirement categories of 5G include (1) the enhanced mobile broadband (eMBB) category, (2) the massive machine type communication (mMTC) category, and (3) the ultra-reliable and low-latency communication (URLLC) category.

[0039] Referring to Figure 1 , communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200, and a network 300. Although Figure 1 a 5G network is shown as an example of the network of communication system 1, the implementations of the present disclosure are not limited to 5G systems and can be applied to future communication systems other than 5G systems.

[0040] BS 200 and network 300 can be implemented as wireless devices, and a particular wireless device can operate as a BS / network node relative to other wireless devices.

[0041] Wireless devices 100a to 100f represent devices that perform communication using a radio access technology (RAT) (e.g., 5G NR or LTE) and can be referred to as communication / radio / 5G devices. The wireless devices can include (but are not limited to) robot 100a, vehicles 100b-1 and 100b-2, extended reality (XR) device 100c, handheld device 100d, home appliance 100e, Internet of Things (IoT) device 100f, and artificial intelligence (AI) device / server 400. For example, the vehicle can include a vehicle with wireless communication capabilities, an autonomous driving vehicle, and a vehicle capable of performing communication between vehicles. The vehicle can include an unmanned aerial vehicle (UAV) (e.g., a drone). The XR device can include an augmented reality (AR) / virtual reality (VR) / mixed reality (MR) device and can be implemented in the form of a head-mounted device (HMD), a head-up display (HUD) mounted in a vehicle, a TV, a smart phone, a computer, a wearable device, a home appliance device, a digital sign, a vehicle, a robot, etc. The handheld device can include a smart phone, a smart board, a wearable device (e.g., a smart watch or smart glasses), and a computer (e.g., a notebook). The home appliance can include a TV, a refrigerator, and a washing machine. The IoT device can include sensors and smart meters.

[0042] In the present disclosure, wireless devices 100a to 100f may be referred to as user equipment (UE). The UE may include, for example, a cellular phone, a smartphone, a laptop computer, a digital broadcast terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a tablet personal computer (PC), a tablet PC, a superbook, a vehicle, a vehicle with autonomous driving function, a connected car, a UAV, an AI module, a robot, an AR device, a VR device, an MR device, a holographic device, a public safety device, an MTC device, an IoT device, a medical device, a FinTech device (or financial device), a security device, a weather / environment device, a device related to 5G services, or a device related to the fourth industrial revolution field.

[0043] Wireless devices 100a to 100f may be connected to the network 300 via the BS200. AI technology may be applied to wireless devices 100a to 100f, and wireless devices 100a to 100f may be connected to the AI server 400 via the network 300. The network 300 may be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a super 5G network. Although wireless devices 100a to 100f may communicate with each other through the BS200 / network 300, wireless devices 100a to 100f may perform direct communication (e.g., sidelink communication) with each other without going through the BS200 / network 300. For example, vehicles 100b-1 and 100b-2 may perform direct communication (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). IoT devices (e.g., sensors) may perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

[0044] Wireless communications / connections 150a, 150b, and 150c can be established between wireless devices 100a to 100f and / or between wireless devices 100a to 100f and BS 200 and / or between BS 200s. Herein, the wireless communications / connections can be established via various RATs (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication (or device-to-device (D2D) communication) 150b, inter-base-station communication 150c (e.g., relay, integrated access and backhaul (IAB)). The wireless devices 100a to 100f and BS 200 / wireless devices 100a to 100f can send / receive radio signals to / from each other via the wireless communications / connections 150a, 150b, and 150c. For example, the wireless communications / connections 150a, 150b, and 150c can send / receive signals via various physical channels. To this end, at least a part of various configuration information configuration processes, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, and resource mapping / demapping), and resource allocation processes for sending / receiving radio signals can be performed based on various proposals of the present disclosure.

[0045] NR supports multiple parameter sets (and / or multiple subcarrier spacings (SCSs)) to support various 5G services. For example, if the SCS is 15 kHz, wide area can be supported in a traditional cellular band, and if the SCS is 30 kHz / 60 kHz, dense urban areas, lower latency, and wider carrier bandwidth can be supported. If the SCS is 60 kHz or higher, a bandwidth greater than 24.25 GHz can be supported to overcome phase noise.

[0046] NR frequency bands can be defined as two types of frequency ranges, namely, frequency range 1 (FR1) and frequency range 2 (FR2). The numerical values of the frequency ranges can vary. For example, the two types (FR1 and FR2) of frequency ranges can be as shown in Table 1. For ease of explanation, in the frequency ranges used in the NR system, FR1 can represent the "below 6 GHz range", FR2 can represent the "above 6 GHz range", and can be referred to as millimeter wave (mmW).

[0047] [Table 1]

[0048] Frequency range specification Corresponding frequency range Subcarrier spacing FR1 450 MHz – 6000 MHz 15 kHz, 30 kHz, 60 kHz FR2 24250 MHz – 52600 MHz 60 kHz, 120 kHz, 240 kHz

[0049] As described above, the numerical value of the frequency range of the NR system can be changed. For example, FR1 can include a frequency band of 410 MHz to 7125 MHz as shown in Table 2 below. That is to say, FR1 can include a frequency band of 6 GHz (or 5850 MHz, 5900 MHz, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850 MHz, 5900 MHz, 5925 MHz, etc.) or higher included in FR1 can include an unlicensed frequency band. The unlicensed frequency band can be used for various purposes (e.g., for vehicle communication (e.g., autonomous driving)).

[0050] [Table 2]

[0051] Frequency range specification Corresponding frequency range Subcarrier spacing FR1 410 MHz – 7125 MHz 15 kHz, 30 kHz, 60 kHz FR2 24250 MHz – 52600 MHz 60 kHz, 120 kHz, 240 kHz

[0052] Here, the radio communication technologies implemented in the wireless devices in the present disclosure can include narrowband IoT (NB-IoT) technology for low-power communication, as well as LTE, NR, and 6G. For example, NB-IoT technology can be an example of low-power wide area network (LPWAN) technology, can be implemented in specifications such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the said name. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices in the present disclosure can communicate based on LTE-M technology. For example, LTE-M technology can be an example of LPWAN technology and can be called various names such as enhanced MTC (eMTC). For example, LTE-M technology can be implemented in at least one of various specifications such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-bandwidth limited (non-BL), 5) LTE-MTC, 6) LTE machine type communication, and / or 7) LTE M, and is not limited to the said name. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices in the present disclosure can include at least one of ZigBee, Bluetooth, and / or LPWAN considering low-power communication, and is not limited to the said name. For example, ZigBee technology can generate a personal area network (PAN) associated with low-power / low-power digital communication based on various specifications such as IEEE 802.15.4 and can be called various names.

[0053] Figure 2 An example of a wireless device applying an implementation manner of the present disclosure is shown.

[0054] In Figure 2 the first wireless device 100 and / or the second wireless device 200 can be implemented in various forms according to use cases / services. For example, {the first wireless device 100 and the second wireless device 200} can correspond to Figure 1at least one of {wireless devices 100a to 100f and BS 200}, {wireless devices 100a to 100f and wireless devices 100a to 100f}, and / or {BS 200 and BS 200}. The first wireless device 100 and / or the second wireless device 200 may be configured by various elements, devices / components, and / or modules.

[0055] The first wireless device 100 may include at least one transceiver (e.g., transceiver 106), at least one processing chip (e.g., processing chip 101), and / or one or more antennas 108.

[0056] The processing chip 101 may include at least one processor (such as processor 102) and at least one memory (such as memory 104). Additionally and / or alternatively, the memory 104 may be placed outside the processing chip 101.

[0057] The processor 102 may control the memory 104 and / or the transceiver 106, and may be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in the present disclosure. For example, the processor 102 may process the information within the memory 104 to generate first information / signals, and then transmit radio signals including the first information / signals through the transceiver 106. The processor 102 may receive radio signals including second information / signals through the transceiver 106, and then store the information obtained by processing the second information / signals in the memory 104.

[0058] The memory 104 may be operatively connected to the processor 102. The memory 104 may store various types of information and / or instructions. The memory 104 may store firmware and / or software code 105, which implements codes, commands, and / or command sets that, when executed by the processor 102, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. For example, the firmware and / or software code 105 may implement instructions that, when executed by the processor 102, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. For example, the firmware and / or software code 105 may control the processor 102 to execute one or more protocols. For example, the firmware and / or software code 105 may control the processor 102 to execute one or more layers of a radio interface protocol.

[0059] In this document, the processor 102 and the memory 104 can be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). The transceiver 106 can be connected to the processor 102 and send and / or receive radio signals via one or more antennas 108. Each of the transceivers 106 can include a transmitter and / or a receiver. The transceiver 106 can be used interchangeably with the radio frequency (RF) unit. In the present disclosure, the first wireless device 100 can represent a communication modem / circuit / chip.

[0060] The second wireless device 200 can include at least one transceiver (such as the transceiver 206), at least one processing chip (such as the processing chip 201), and / or one or more antennas 208.

[0061] The processing chip 201 can include at least one processor (such as the processor 202) and at least one memory (such as the memory 204). Additionally and / or alternatively, the memory 204 can be placed outside the processing chip 201.

[0062] The processor 202 can control the memory 204 and / or the transceiver 206, and can be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in the present disclosure. For example, the processor 202 can process the information within the memory 204 to generate a third information / signal, and then send a radio signal including the third information / signal via the transceiver 206. The processor 202 can receive a radio signal including a fourth information / signal via the transceiver 106, and then store the information obtained by processing the fourth information / signal in the memory 204.

[0063] The memory 204 can be operatively connected to the processor 202. The memory 204 can store various types of information and / or instructions. The memory 204 can store firmware and / or software code 205, which implements codes, commands, and / or command sets that, when executed by the processor 202, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. For example, the firmware and / or software code 205 can implement instructions that, when executed by the processor 202, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. For example, the firmware and / or software code 205 can control the processor 202 to execute one or more protocols. For example, the firmware and / or software code 205 can control the processor 202 to execute one or more layers of a radio interface protocol.

[0064] In this document, the processor 202 and the memory 204 can be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). The transceiver 206 can be connected to the processor 202 and send and / or receive radio signals via one or more antennas 208. Each transceiver 206 can include a transmitter and / or a receiver. The transceiver 206 can be used interchangeably with the RF unit. In this disclosure, the second wireless device 200 can represent a communication modem / circuit / chip.

[0065] Hereinafter, the hardware elements of the wireless devices 100 and 200 will be described in more detail. One or more protocol layers can be implemented by (but are not limited to) one or more processors 102 and 202. For example, one or more processors 102 and 202 can implement one or more layers (e.g., functional layers such as the physical (PHY) layer, the media access control (MAC) layer, the radio link control (RLC) layer, the packet data convergence protocol (PDCP) layer, the radio resource control (RRC) layer, and the service data adaptation protocol (SDAP) layer). One or more processors 102 and 202 can generate one or more protocol data units (PDUs), one or more service data units (SDUs), messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 can generate a signal (e.g., a baseband signal) including PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure, and provide the generated signal to one or more transceivers 106 and 206. One or more processors 102 and 202 can receive a signal (e.g., a baseband signal) from one or more transceivers 106 and 206 according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure, and obtain PDUs, SDUs, messages, control information, data, or information.

[0066] One or more processors 102 and 202 may be referred to as a controller, microcontroller, microprocessor, or microcomputer. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. As an example, one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processor devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field programmable gate arrays (FPGAs) may be included in one or more processors 102 and 202. For example, one or more processors 102 and 202 may be configured by a group of communication control processors, application processors (APs), electronic control units (ECUs), central processing units (CPUs), graphics processing units (GPUs), and memory control processors. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, code, instructions, and / or commands. One or more memories 104 and 204 may be configured by random access memory (RAM), dynamic RAM (DRAM), read only memory (ROM), electrically erasable programmable read only memory (EPROM), flash memory, volatile memory, non-volatile memory, hard disk drives, registers, cache memory, computer readable storage media, and / or a combination thereof. One or more memories 104 and 204 may be located inside and / or outside of one or more processors 102 and 202. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 by various techniques such as a wired connection or a wireless connection.

[0067] One or more transceivers 106 and 206 may transmit user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure to one or more other devices. One or more transceivers 106 and 206 may receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure from one or more other devices. For example, one or more transceivers 106 and 206 may be connected to one or more processors 102 and 202 and transmit and receive radio signals. For example, one or more processors 102 and 202 may execute control such that one or more transceivers 106 and 206 may send user data, control information, or radio signals to one or more other devices. One or more processors 102 and 202 may execute control such that one or more transceivers 106 and 206 may receive user data, control information, or radio signals from one or more other devices.

[0068] One or more transceivers 106 and 206 may be connected to one or more antennas 108 and 208. Additionally and / or alternatively, one or more transceivers 106 and 206 may include one or more antennas 108 and 208. One or more transceivers 106 and 206 may be adapted to transmit and receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure via one or more antennas 108 and 208. In this disclosure, one or more antennas 108 and 208 may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

[0069] One or more transceivers 106 and 206 may convert received user data, control information, radio signals / channels, etc. from RF band signals into baseband signals in order to process the received user data, control information, radio signals / channels, etc. using one or more processors 102 and 202. One or more transceivers 106 and 206 may convert user data, control information, radio signals / channels, etc. processed using one or more processors 102 and 202 from baseband signals into RF band signals. To this end, one or more transceivers 106 and 206 may include (analog) oscillators and / or filters. For example, one or more transceivers 106 and 206 may up-convert an OFDM baseband signal into an OFDM signal via its (analog) oscillator and / or filter under the control of one or more processors 102 and 202, and transmit the up-converted OFDM signal at a carrier frequency. One or more transceivers 106 and 206 may receive an OFDM signal at a carrier frequency and down-convert the OFDM signal into an OFDM baseband signal via its (analog) oscillator and / or filter under the control of one or more processors 102 and 202.

[0070] Although not shown in Figure 2 the wireless devices 100 and 200 may also include additional components. The additional components 140 may be configured differently according to the types of the wireless devices 100 and 200. For example, the additional components 140 may include at least one of a power supply unit / battery, an input / output (I / O) device (e.g., an audio I / O port, a video I / O port), a driving device, and a computing device. The additional components 140 may be coupled to one or more processors 102 and 202 via various techniques such as a wired connection or a wireless connection.

[0071] In an implementation of the present disclosure, the UE may operate as a transmitting device on the uplink (UL) and as a receiving device on the downlink (DL). Within an implementation of the present disclosure, the BS may operate as a receiving device on the UL and as a transmitting device on the DL. Hereinafter, for ease of description, it is mainly assumed that the first wireless device 100 acts as the UE and the second wireless device 200 acts as the BS. For example, a processor 102 connected to, installed on, or initiated in the first wireless device 100 may be adapted to perform UE behavior according to an implementation of the present disclosure, or control a transceiver 106 to perform UE behavior according to an implementation of the present disclosure. A processor 202 connected to, installed on, or initiated in the second wireless device 200 may be adapted to perform BS behavior according to an implementation of the present disclosure, or control a transceiver 206 to perform BS behavior according to an implementation of the present disclosure.

[0072] In the present disclosure, the BS is also referred to as a Node B (NB), an eNode B (eNB), or a gNB.

[0073] Figure 3 An example of a UE to which an implementation of the present disclosure is applied is shown.

[0074] Referring to Figure 3 , the UE 100 may correspond to Figure 2 the first wireless device 100.

[0075] The UE 100 includes a processor 102, a memory 104, a transceiver 106, one or more antennas 108, a power management module 141, a battery 142, a display 143, a keypad 144, a subscriber identity module (SIM) card 145, a speaker 146, and a microphone 147.

[0076] The processor 102 may be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. The processor 102 may be adapted to control one or more other components of the UE 100 to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. Layers of the radio interface protocol may be implemented in the processor 102. The processor 102 may include an ASIC, other chip sets, logic circuits, and / or data processing devices. The processor 102 may be an application processor. The processor 102 may include at least one of a DSP, a CPU, a GPU, and a modem (modulator and demodulator). It may be in a manufactured SNAPDRAGON TM series processor, a manufactured EXYNOS TMExamples of Processor 102 can be found in Series processors, A series processors manufactured by , HELIO series processors manufactured by , ATOM series processors manufactured by TM , or corresponding next-generation processors. TM

[0077] Memory 104 can be operatively coupled to Processor 102 and store various information for operating Processor 102. Memory 104 may include ROM, RAM, flash memory, memory cards, storage media, and / or other storage devices. When the implementation is realized in software, the techniques described herein can be implemented using modules (e.g., procedures, functions, etc.) that execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. The modules can be stored in Memory 104 and executed by Processor 102. Memory 104 can be implemented within Processor 102 or outside Processor 102 (in which case, these memories can be communicatively coupled to Processor 102 via various devices known in the art).

[0078] Transceiver 106 can be operatively coupled to Processor 102 and send and / or receive radio signals. Transceiver 106 includes a transmitter and a receiver. Transceiver 106 may include baseband circuitry to process radio frequency signals. Transceiver 106 controls one or more antennas 108 to send and / or receive radio signals.

[0079] Power management module 141 manages the power for Processor 102 and / or Transceiver 106. Battery 142 supplies power to power management module 141.

[0080] Display 143 outputs the results processed by Processor 102. Keypad 144 receives inputs to be used by Processor 102. Keypad 144 can be displayed on Display 143.

[0081] SIM card 145 is an integrated circuit designed to securely store the International Mobile Subscriber Identity (IMSI) number and its associated keys for identifying and authenticating subscribers on mobile phone devices such as mobile phones and computers. Contact information related to many SIM cards can also be stored.

[0082] Speaker 146 outputs sound-related results processed by Processor 102. Microphone 147 receives sound-related inputs to be used by Processor 102.

[0083] Figure 4 An example of a 5G system architecture implementing the present disclosure is shown.

[0084] The 5G System (5GS) architecture consists of the following Network Functions (NFs).

[0085] - AUSF (Authentication Server Function)

[0086] - AMF (Access and Mobility Management Function)

[0087] - DN (Data Network), e.g., operator services, Internet access, or third-party services

[0088] - UDSF (Unstructured Data Storage Function)

[0089] - NEF (Network Exposure Function)

[0090] - I-NEF (Intermediate NEF)

[0091] - NRF (Network Repository Function)

[0092] - NSSF (Network Slice Selection Function)

[0093] - PCF (Policy Control Function)

[0094] - SMF (Session Management Function)

[0095] - UDM (Unified Data Management)

[0096] - UDR (Unified Data Repository)

[0097] - UPF (User Plane Function)

[0098] - UCMF (UE Radio Capability Management Function)

[0099] - AF (Application Function)

[0100] - UE (User Equipment)

[0101] - (R)AN ((Radio) Access Network)

[0102] - 5G-EIR (5G Equipment Identity Register)

[0103] - NWDAF (Network Data Analytics Function)

[0104] - CHF (Charging Function)

[0105] In addition, the following network functions may be considered.

[0106] - N3IWF (Non-3GPP Interworking Function)

[0107] - TNGF (Trusted Non-3GPP Gateway Function)

[0108] -W-AGF (Wired Access Gateway Function)

[0109] Figure 4 The 5G system architecture in the non - roaming case is depicted using reference point representations showing how various network functions interact with each other.

[0110] In Figure 4 For the sake of clarity of the point - to - point diagram, UDSF, NEF, and NRF are not depicted. However, all the depicted network functions can interact with UDSF, UDR, NEF, and NRF as needed.

[0111] For clarity Figure 4 UDR and its connections to other NFs (e.g., PCF) are not depicted in Figure 4 For clarity, NWDAF and its connections to other NFs (e.g., PCF) are not depicted in

[0112] The 5G system architecture includes the following reference points:

[0113] - N1: The reference point between the UE and the AMF.

[0114] - N2: The reference point between the (R)AN and the AMF.

[0115] - N3: The reference point between the (R)AN and the UPF.

[0116] - N4: The reference point between the SMF and the UPF.

[0117] - N6: The reference point between the UPF and the data network.

[0118] - N9: The reference point between two UPFs.

[0119] The following reference points show the interactions that exist between NF services in the NFs.

[0120] - N5: The reference point between the PCF and the AF.

[0121] - N7: The reference point between the SMF and the PCF.

[0122] - N8: The reference point between the UDM and the AMF.

[0123] - N10: The reference point between the UDM and the SMF.

[0124] - N11: The reference point between the AMF and the SMF.

[0125] - N12: The reference point between the AMF and the AUSF.

[0126] - N13: The reference point between the UDM and the AUSF.

[0127] - N14: Reference point between two AMFs.

[0128] - N15: Reference point between the PCF and the AMF in a non-roaming scenario, and between the PCF in the visited network and the AMF in a roaming scenario.

[0129] - N16: Reference point between two SMFs (in the case of roaming, between the SMF in the visited network and the SMF in the home network).

[0130] - N22: Reference point between the AMF and the NSSF.

[0131] In some cases, it may be necessary to associate a pair of NFs with each other to serve the UE.

[0132] The PDU session establishment procedure is described. Reference can be made to Section 4.3.2 of 3GPP TS23.502 V16.3.0 (2019-12).

[0133] Figure 5 and Figure 6 shows an example of the PDU session establishment procedure implementing the present disclosure.

[0134] The PDU session establishment can correspond to:

[0135] - UE-initiated PDU session establishment procedure.

[0136] - UE-initiated PDU session handover between 3GPP and non-3GPP.

[0137] - UE-initiated PDU session handover from EPS to 5GS.

[0138] - Network-triggered PDU session establishment procedure.

[0139] The PDU session can be (a) associated with a single access type (i.e., 3GPP access or non-3GPP access) at a given time, or (b) associated with multiple access types (i.e., one 3GPP access and one non-3GPP access) simultaneously. A PDU session associated with multiple access types is called a multi-access PDU (MAPDU) session, and it can be requested by a UE with access traffic steering, switching, splitting (ATSSS) capabilities.

[0140] Figure 5 and Figure 6 specifies the procedure for establishing a PDU session associated with a single access type at a given time.

[0141] Figure 5 and Figure 6The process shown assumes that the UE has been registered with the AMF. Therefore, unless the UE is an emergency registration, the AMF has retrieved the user subscription data from the UDM.

[0142] First, the process Figure 5 described

[0143] (1) Step 1: To establish a new PDU session, the UE generates a new PDU session ID.

[0144] The UE initiates the UE-requested PDU session establishment process by sending a NAS message including a PDU session establishment request message within the N1 SM container. The PDU session establishment request message includes the PDU session ID, the requested PDU session type, the requested session and service continuity (SSC) mode, 5GSM capabilities, protocol configuration options (PCO), SM PDU DN request container, UE integrity protection maximum data rate, etc.

[0145] If the PDU session establishment is a request to establish a new PDU session, the request type indicates "initial request", and if the request involves a handover of an existing PDU session between 3GPP access and non-3GPP access or a handover of a PDU session from an existing packet data network (PDN) connection in the EPC, the request type indicates "existing PDU session". If the PDU session establishment is a request to establish a PDU session for an emergency service, the request type indicates "emergency request". If the request involves a handover of an existing PDU session for an emergency service between 3GPP access and non-3GPP access or a handover of a PDU session from an existing PDN connection for an emergency service in the EPC, the request type indicates "existing emergency PDU session".

[0146] The UE includes the S-NSSAI of the allowed NSSAI from the current access type. If a mapping of the allowed NSSAI is provided to the UE, the UE shall provide the S-NSSAI of the visited public land mobile network (VPLMN) from the allowed NSSAI and the corresponding S-NSSAI of the home public land mobile network (HPLMN) from the mapping of the allowed NSSAI.

[0147] (2) Step 2: The AMF selects an SMF. If the request type indicates "initial request" or the request is due to a handover from EPS or from non-3GPP access served by a different AMF, the AMF stores the association of the S-NSSAI, data network name (DNN), PDU session ID, SMF ID, and access type of the PDU session.

[0148] If the request type is "Initial Request" and if the old PDU session ID indicating an existing PDU session is also included in the message, the AMF selects the SMF and stores the association of the new PDU session ID, S-NSSAI, the selected SMF ID, and the access type of the PDU session.

[0149] If the request type indicates "Existing PDU Session", the AMF selects the SMF based on the SMF-ID received from the UDM. The AMF updates the access type stored for the PDU session.

[0150] If the request type indicates "Existing PDU Session" for an existing PDU session involving a move between 3GPP access and non-3GPP access, then the PDU session establishment procedure can be performed in the following cases if the serving PLMN S-NSSAI of the PDU session is present in the allowed NSSAI of the target access type:

[0151] - The SMF ID corresponding to the PDU session ID and the AMF belong to the same PLMN;

[0152] - The SMF ID corresponding to the PDU session ID belongs to the HPLMN;

[0153] Otherwise, the AMF shall reject the PDU session establishment request with an appropriate rejection cause.

[0154] The AMF shall reject requests from an emergency registered UE where the request type does not indicate either "Emergency Request" or "Existing Emergency PDU Session".

[0155] (3) Step 3: If the AMF does not have an association with the SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Initial Request"), the AMF invokes the Create SM Context Request procedure (e.g., Nsmf_PDUSession_CreateSMContext request). If the AMF already has an association with the SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Existing PDU Session"), the AMF invokes the Update SM Context Request procedure (e.g., Nsmf_PDUSession_UpdateSMContext request).

[0156] The AMF sends the S-NSSAI of the serving PLMN from the allowed NSSAI to the SMF. For a roaming scenario in local breakout (LBO), the AMF also sends the corresponding S-NSSAI of the mapped HPLMN from the allowed NSSAI to the SMF.

[0157] The AMF ID is the GUAMI of the UE, which uniquely identifies the AMF serving the UE. The AMF forwards the PDU session ID together with the N1 SM container including the PDU session establishment request message received from the UE. If available at the AMF, the Generic Public Subscription Identifier (GPSI) shall be included.

[0158] When a UE in a limited service state registers for emergency services without providing the SUPI, the AMF provides the PEI instead of the SUPI. In the case where a UE in a limited service state registers for emergency services with a SUPI but has not yet been authenticated, the AMF indicates that the SUPI has not been authenticated. When the SMF does not receive the SUPI for the UE or when the AMF indicates that the SUPI has not been authenticated, the SMF determines that the UE has not been authenticated.

[0159] The AMF may include the PCF ID in the Nsmf_PDUSession_CreateSMContext request. This PCF ID identifies the Home PCF (H-PCF) in the non-roaming case and the Visited PCF (V-PCF) in the LBO roaming case.

[0160] (4) Step 4: If the session management subscription data for the corresponding SUPI, DNN, and S-NSSAI of the HPLMN is not available, the SMF may retrieve the session management subscription data from the UDM and subscribe to notifications when modifying the subscription data.

[0161] (5) Step 5: The SMF sends a Create SM context response message (e.g., Nsmf_PDUSession_CreateSMContext response) or an Update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext response) to the AMF according to the request received in Step 3.

[0162] If the SMF receives an Nsmf_PDUSession_CreateSMContext request in Step 3 and the SMF is able to handle the PDU session establishment request, the SMF creates an SM context and responds to the AMF by providing the SM context ID.

[0163] When the SMF decides not to accept the establishment of a PDU session, the SMF responds to the AMF by using the Nsmf_PDUSession_CreateSMContext response to reject the UE request via NAS SM signaling including the relevant SM rejection reason. The SMF also indicates to the AMF that the PDU session ID will be considered released, the SMF proceeds to the following Step 20 and the PDU session establishment process is stopped.

[0164] (6) Step 6: Optional secondary authentication / authorization can be performed.

[0165] (7a) Step 7a: If dynamic policy and charging control (PCC) is to be used for the PDU session, the SMF can perform PCF selection.

[0166] (7b) Step 7b: The SMF can perform an SM policy association establishment procedure to establish an SM policy association with the PCF and obtain the default PCC rules for the PDU session.

[0167] (8) Step 8: The SMF selects one or more UPFs.

[0168] (9) Step 9: The SMF can perform an SMF-initiated SM policy association modification procedure to provide information related to the triggered conditions of the policy control requests that have been satisfied.

[0169] (10) Step 10: If the request type indicates "initial request", the SMF can initiate an N4 session establishment procedure with the selected UPF. Otherwise, the SMF can initiate an N4 session modification procedure with the selected UPF.

[0170] In step 10a, the SMF can send an N4 session establishment / modification request to the UPF and provide the packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU session. In step 10b, the UPF can confirm by sending an N4 session establishment / modification response.

[0171] (11) Step 11: The SMF sends an N1N2Message Transfer message (e.g., Namf_Communication_N1N2MessageTransfer) to the AMF.

[0172] The N1N2Message Transfer message can include N2 SM information. The N2 SM information carries the information that the AMF should forward to the (R)AN, which can include:

[0173] - CN Tunnel Info: The core network address of the N3 tunnel corresponding to the PDU session;

[0174] - One or more quality of service (QoS) profiles and corresponding QoS flow IDs (QFIs);

[0175] - PDU session ID: Indicates the association between the (R)AN resources and the PDU session for the UE.

[0176] - An S-NSSAI with a value for the serving PLMN (i.e., the HPLMN S-NSSAI, or in the case of LBO roaming, the VPLMN S-NSSAI).

[0177] - User plane security enforcement information determined by the SMF.

[0178] - If the user plane security enforcement information indicates that integrity protection is "preferred" or "required (or mandatory)", the SMF also includes the UE integrity protection maximum data rate received in the PDU session establishment request message.

[0179] - Redundant Sequence Number (RSN) parameter

[0180] The N1N2Message Transfer message may include an N1 SM container. The N1 SM container contains the PDU session establishment accept message that the AMF should provide to the UE. The PDU session establishment accept message includes an S-NSSAI from the allowed NSSAI. For the LBO roaming scenario, the PDU session establishment accept message includes an S-NSSAI from the allowed NSSAI for the VPLMN, and it also includes the corresponding S-NSSAI of the mapped HPLMN from the allowed NSSAI received by the SMF in step 3.

[0181] Multiple QoS rules, QoS flow levels, and QoS parameters (if required for the QoS flows associated with those QoS rules and QoS profiles) may be included in the PDU session establishment accept message within the N1 SM container and in the N2 SM information.

[0182] If the PDU session fails anywhere between steps 5 and 11, the N1N2MessageTransfer message shall include an N1 SM container with a PDU session establishment reject message and shall not include any N2 SM information. The (R)AN sends a NAS message to the UE that includes the PDU session establishment reject message. In this case, steps 12 to 17 are skipped.

[0183] (12) Step 12: The AMF sends a NAS message to the (R)AN that includes the PDU session ID for the UE and the PDU session establishment accept message and the N2 SM information received from the SMF within the N2 PDU session request message.

[0184] (13) Step 13: The (R)AN can send AN-specific signaling exchanges related to the information received by the UE from the SMF. For example, in the case of NG-RAN, an RRC connection reconfiguration can occur, where the UE establishes the necessary NG-RAN resources related to the QoS rules of the PDU session request received in Step 12.

[0185] (R)AN forwards the NAS messages provided in Step 12 (PDU session ID, N1 SM container (PDU session establishment acceptance message)) to the UE. If the AN-specific signaling exchange with the UE includes (R)AN resource addition associated with the received N2 command, the (R)AN will provide only the NAS message to the UE.

[0186] If Step 11 does not include N2 SM information, the following Steps 14 to 16b and Step 17 are omitted.

[0187] Now, describe the Figure 5 process after Figure 6 the process.

[0188] (14) Step 14: The (R)AN sends an N2 PDU session response message to the AMF. The N2 PDU session response message can include the PDU session ID, cause, N2 SM information (PDU session ID, AN Tunnel Info, list of accepted / rejected QFIs, user plane enforcement policy notification), etc.

[0189] (15) Step 15: The AMF sends an Update SM Context request message to the SMF (e.g., Nsmf_PDUSession_UpdateSMContext request). The AMF forwards the N2 SM information received from the (R)AN to the SMF.

[0190] (16a) Step S16a: The SMF initiates an N4 session modification process with the UPF. The SMF provides the AN Tunnel Info and the corresponding forwarding rules to the UPF.

[0191] (16b) Step S16b: The UPF provides an N4 session modification response to the SMF.

[0192] After this step, the UPF can deliver any DL packets that may have been buffered for this PDU session to the UE.

[0193] (16c) Step 16c: If the SMF has not registered this PDU session, the SMF can register with the UDM for the given PDU session.

[0194] (17) Step 17: The SMF sends an Update SM Context Response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to the AMF.

[0195] After this step, the AMF forwards the relevant events subscribed by the SMF.

[0196] (18) Step 18: If during the procedure, at any time after step 5, the PDU session establishment is not successful, the SMF can notify the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (Release). The SMF can also release any N4 sessions created, any PDU session addresses (if allocated) (e.g., IP addresses), and release the association with the PCF (if any). In this case, step 19 is skipped.

[0197] (19) Step 19: In the case of PDU session type IPv6 or IPv4v6, the SMF can generate an IPv6 Router Advertisement and send it to the UE.

[0198] (20) Step 20: The SMF can perform SMF-initiated SM policy association modification.

[0199] (21) Step 21: If the PDU session establishment fails after step 4, the SMF can unsubscribe from the modification of the session management subscription data if the SMF no longer processes the UE's PDU session.

[0200] <UAS (Unmanned Aerial System)>

[0201] In 5G, the support for Unmanned Aerial System (UAS) is discussed. A UAS can consist of one or more Unmanned Aerial Vehicles (UAVs) and an Unmanned Aerial Controller (UAV-C). The UAV can be controlled by the UAV controller via a Command and Control (C2) link in a 3GPP mobile network or a non-3GPP mobile network.

[0202] In the present disclosure, C2 communication can refer to Command and Control (C2) communication. C2 communication can refer to the following user plane link: from the UAV controller or Unmanned Aerial System Traffic Management (UTM) to the UAV to deliver a message including command and control information for UAV operation, or from the UAV to report telemetry data to the UAV controller or UTM.

[0203] For the management of UAS, the UAS Service Provider (USS) / UAS Traffic Management (UTM) and the UAV can exchange application data services via a 3GPP mobile network. The UAV can be considered as a UE. For example, the followingFigure 7 The example in illustrates the logical 5GS and EPS architectures for UAVs. Further details can be found in TS23.256 V17.0.0.

[0204] The following figures are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the figures or the designation of specific signals / messages / fields are for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following figures.

[0205] Figure 7 An example architecture for logical 5GS and EPS for UAVs is illustrated.

[0206] To receive connectivity services from the network, the UAV must perform an authorization process through the UAV USS authentication and authorization process (UUAA). For example, depending on the network operator's policy, the authorization can be performed in the following ways:

[0207] 1) UUAA can be performed during the process of the UAV registering to the network: For example, the UAV can have an airborne UE subscription in its access and mobility subscription data. If the registration request message sent by the UAV includes a CAA-level UAV ID, UUAA can be performed (this can be referred to as UUAA-MM). If UUAA-MM is not performed, the UAV can perform UUAA during the PDU session creation process.

[0208] 2) The UAV can perform UUAA during the PDU session generation process for the DNN of the UAV service (PDN connection in the case of EPS) (this can be referred to as UUAA-SM): For 5GS, UUAA-SM can be initiated by the SMF when the UAV provides a CAA-level UAV ID in the PDU session creation request message. For EPS, it can be initiated by the SMF + PGW-C when the UAV provides a CAA-level UAV ID to the ESM message container.

[0209] UAV communication can be divided into USS communication and C2 communication between the UAV and the USS. USS communication can be user plane data transmission in addition to C2 communication. The PDU session / PDN connection for C2 communication and the PDU session / PDN connection for USS communication can be used jointly or separately. For example, the PDU session / PDN connection for C2 communication and the PDU session / PDN connection for USS communication can be the same or different.

[0210] The UAS network functions are supported by the Network Exposure Function (NEF) or the Service Capability Exposure Function (SCEF) + NEF (which can be used for external exposure of services to the USS). The UAV-NF can utilize the existing exposure services of the NEF / SCEF for operations such as authentication / authorization of UAVs, flight authorization, UAV-UAVC pairing authorization and revocation of related operations, location reporting, and control of QoS / traffic filtering for C2 communication. The UAS NF can store the results of the UUAA-MM process and the UUAA-SM process. Additionally, to support re-authentication requested by the USS, the UAS NF can store whether re-authentication should be requested from the AMF or the SMF / SMF+PGW-C, and can store the address of the AMF or the SMF / SMF+PGW-C currently providing the service.

[0211] The USS can initiate a re-authentication process through the UAS NF at any time after the end of the UUAA process. Depending on the network settings, the UUAA re-authentication can be performed via the SMF (UUAA-SM) or the AMF (UUAA-MM). The result of the re-authentication can be transmitted from the USS to the UE via the SMF (UUAA-SM) or the AMF (UUAA-MM) through the UAS NF.

[0212] Additional measures to support Unmanned Aerial System (UAS) services on 5GS are under discussion. 3GPP TR23.700-58v1.0.0 covers the following issues:

[0213] For example, there are issues with the transmission of C2 communication on the PC5 interface.

[0214] The issue focuses on the transmission of C2 communication via PC5 in the 3GPP system. This includes research on how to achieve direct C2 communication between the UAV and the UAV controller. The following aspects should be considered:

[0215] - Whether the PC5 can support C2 communication between the UAV and the UAV controller (UAV-C);

[0216] - Regarding the current solutions using the PC5 (e.g., Proximity-based Services (ProSe), Cellular Vehicle-to-Everything (C-V2X)), whether architecture modifications are needed and what kind of modifications:

[0217] - This includes research on scenarios where both the drone and the UAV controller (UAV-C) are registered to 5GS and scenarios where the UAV controller (UAV-C) may not be registered to 5GS or may not have Uu capabilities;

[0218] - This includes scenarios where the radio resources used by PC5 are set and scheduled by the Mobile Network Operator (MNO) (during coverage operation) and scenarios where the radio resources used by PC5 are "non-operator managed";

[0219] - Whether and how to reuse and / or extend existing PC5-based unicast communication to carry C2 communication;

[0220] - How to establish C2 communication on PC5 between the UAV and the UAV controller;

[0221] - How to authorize the UAV and how to revoke the authorization to establish C2 communication directly with the UAV controller via PC5 in in-coverage and out-of-coverage scenarios;

[0222] - Whether the UAV needs to discover the UAV controller or vice versa, and if so, how to discover.

[0223] TR 23.700-58 v1.0.0 contains the following conclusions regarding questions such as the above examples.

[0224] A UAV participating in C2 communication via PC5 may or may not be able to communicate with the network over Uu.

[0225] Only unicast mode C2 communication on PC5 is supported.

[0226] For C2 communication on PC5, the UAV-C can be pre-paired or dynamically paired.

[0227] For C2 communication on PC5, two types of authorization are supported:

[0228] - Authorization based on the UAV's prescribed policy, similar to clause 5.1.3 of TS 23.304 V17.4.0

[0229] - If the UAV is able to communicate with the network over Uu, authorization is based on the C2 communication authorization procedure defined in AUTHORIZATION.

[0230] Based on the following enhancements and adaptations, the procedure defined for unicast mode 5G ProSe direct communication in clause 6.4.3 of TS 23.304 V17.4.0 shall be used as the basis for establishing C2 communication via PC5.

[0231] - ProSe service information replaced by "C2 communication service"

[0232] - The C2 communication service identifier can be pre-set or derived from the CAA-level UAV ID.

[0233] Support for UE - oriented and service - oriented unicast link establishment, as defined in clause 6.4.3.1 of TS23.304 V17.4.0.

[0234] The following additional elaboration can be applied to the above conclusion: The C2 communication authorization procedure via Uu, as defined in TS23.256 V17.4.0, can be used to establish C2 communication between the UAV and the UAV - C via PC5 (e.g., authorization with the USS / network). In this case, it can be clarified that the C2 communication via the Uu authorization procedure must be performed before the C2 communication on PC5. For example, the following additional elaboration can be applied.

[0235] For C2 communication on PC5, two types of authorization are supported

[0236] - Authorization based on the UAV - specified policy, similar to clause 5.1.3 of TS23.304 V17.4.0.

[0237] - If the UAV is capable of Uu communication with the network, authorization is based on the C2 communication authorization procedure defined in TS23.256 V17.4.0. In this case, the UAV UE will perform the C2 communication authorization according to the procedure defined in TS23.256 V17.4.0 before initiating direct UAV - to - UAV - C communication via PC5.

[0238] The C2 communication authorization procedure via Uu defined in TS23.256 V17.4.0 may fail. In this case, it is not clear whether the UAV UE should be allowed to perform C2 communication via the UAV - C and PC5. Additionally, if the UAV UE should not perform C2 communication via the UAV - C and PC5, it is not clear how to handle this (e.g., authorization or C2 communication).

[0239] The C2 connection via Uu may also be withdrawn by the USS or the network. In this case, it is not clear whether the UAV UE should be allowed to perform C2 communication via the UAV - C and PC5. Additionally, if the UAV UE should not be allowed to perform C2 communication via the UAV - C and PC5, it is not clear how to handle this (e.g., authorization or C2 communication).

[0240] Therefore, a solution to this problem is needed.

[0241] Additionally, it may be necessary to provide the UE with the option to perform C2 communication via PC5 using the Uu connection, or to set the UE to the option of performing C2 communication via PC5.

[0242] Regarding C2 communication, the following is defined in TS23.256 V17.4.0.

[0243] C2 communication may mean command and control (C2) communication. C2 communication may mean a user plane link from a UAV controller or unmanned aerial system traffic management (UTM) to a UAV to deliver a message including command and control information for UAV operation or report telemetry data from the UAV to the UAV controller or UTM.

[0244] The procedure for authorization of C2 communication over Uu can be found in clause 5.2.5 (Authorization for C2) of TS23.256 V17.4.0. And the procedure for withdrawing a C2 connection via Uu can be found in clause 5.2.9 (Withdrawal of C2 connectivity) of TS23.256 V17.4.0.

[0245] The approach of using the PC5 interface to support C2 communication proposed in the disclosure herein may include a combination of one or more of the following various examples of actions / configurations / steps.

[0246] In this specification, the terms C2 communication, C2 connection, C2 connectivity, and C2 may be used interchangeably, i.e., C2 communication, C2 connection, C2 connectivity, and C2 may all be used interchangeably.

[0247] In this disclosure, "performing C2 communication" may be interpreted as performing C2 connection establishment, or may be interpreted as an operation including performing C2 connection establishment. Establishing a C2 connection via the PC5 interface may refer to layer-2 link establishment, e.g., the unicast link establishment operation in TS23.287 V17.4.0, TS23.304 V17.4.0.

[0248] The terms user equipment (UE) and terminal may be used interchangeably in this specification.

[0249] The terms PC5, PC5 interface, PC5 reference point, and "PC5-based" may be used interchangeably in this specification.

[0250] In this disclosure, the terms Uu, Uu interface, Uu reference point, and Uu reference may be used interchangeably.

[0251] In this disclosure, SMF may refer to SMF + PGW-C in EPS.

[0252] In the following, the disclosure of this specification describes what is proposed in this disclosure, and the description of configurations identical to the prior art may be omitted. For UAS-related operations and procedures, TS23.256 V17.4.0 is the default reference. Additionally, for PC5-related operations and procedures, the default references are TS23.287 V17.4.0, TS24.587, TS23.304 V17.4.0, TS24.554, etc.

[0253] The examples described in this specification for supporting C2 communication using the PC5 interface can be extended / changed and applied to other services (e.g., ProSe service, V2X service, etc.) and UAS services. In this case, the C2 communication / C2 connection disclosed herein can be interchangeably interpreted as the communication / connection between two UEs.

[0254] If the C2 communication authorization via Uu (or authorization with the USS / network) fails, or if the C2 communication authorization (or authorization with the USS / network) is withdrawn, the following example actions can be performed. For example, it can be provided or set to the UE whether to allow the SMF or USS to perform C2 communication via PC5. Alternatively, it can be notified or set to the UE whether the SMF or USS can perform C2 communication on PC5 using the Uu connection. If the USS performs these actions, the information or configuration provided by the USS can be passed to the UE via the SMF.

[0255] For example, if the C2 communication authorization via Uu (or authorization with the USS / network) fails or the C2 communication authorization (or authorization with the USS / network) is withdrawn, the following example actions can be performed. For example, the network can indicate or configure whether to allow the UE to perform C2 communication via PC5. Alternatively, the network can provide or set to the UE whether to allow the UE to perform C2 communication via PC5 using the Uu connection. Here, it can be assumed that the UE is a UAV. However, this is only for illustrative purposes, and the UE can be a UAV-C, or the UE can be both a UAV and a UAV-C.

[0256] In this disclosure, the operation of providing or setting to the UE whether C2 communication on PC5 can be performed using the Uu connection can also be interpreted as the operation of providing or setting to the UE whether C2 communication on PC5 can be performed by the network.

[0257] 1. First example of this disclosure

[0258] The first example of this disclosure describes an example of setting authorization policies / parameters on the UE.

[0259] One or more of the following authorization policies / parameters can be set on the UE. These authorization policies / parameters can be set in various forms, including combinations, explicit, implicit, etc.

[0260] (a) Information indicating / commanding the following: In order for the UE to perform C2 communication on the PC5 interface (or before the UE performs C2 communication on the PC5 interface), the UE shall perform / conduct C2 communication authorization (or authorization with the USS / network) via Uu.

[0261] (b) Information indicating / commanding that the authorization of C2 communication via Uu (or authorization with the USS / network) has failed (i.e., has not been successful), or information indicating / commanding that C2 communication should not be performed via the PC5 interface. This can be interpreted to mean that if the authorization of C2 communication via Uu (or authorization with the USS / network) fails (i.e., is not successful), C2 communication via the PC5 interface is not allowed / authorized.

[0262] (c) Information indicating / commanding that C2 communication can be performed on the PC5 interface, or information indicating / commanding that C2 communication can be performed on the PC5 interface if the authorization for C2 communication via Uu (or authorization with the USS / network) is successful. This can be interpreted to mean that if the authorization of C2 communication via Uu (or authorization with the USS / network) is successful, C2 communication via the PC5 interface is allowed / authorized.

[0263] (d) Information indicating / commanding the following: that C2 communication can be performed on the PC5 interface even if the authorization for C2 communication via Uu (or authorization with the USS / network) has failed (i.e., has not been successful). This can be interpreted to mean that even if the authorization of C2 communication via Uu (or authorization with the USS / network) fails (i.e., is not successful), C2 communication on the PC5 interface is allowed / authorized.

[0264] (e) Information indicating / commanding that C2 communication should not be performed on the PC5 interface once the Uu-based C2 connection is withdrawn. This can be interpreted to mean that if the authorization of C2 communication via Uu (or authorization with the USS / network) is withdrawn, C2 communication via the PC5 interface is not allowed / authorized.

[0265] (f) Information indicating / commanding that C2 communication can be performed on the PC5 interface even if the Uu-based C2 connection is withdrawn. This can be interpreted to mean that even if the authorization of C2 communication via Uu (or authorization with the USS / network) is withdrawn, C2 communication via the PC5 interface is allowed / authorized.

[0266] (g) Information indicating / commanding that C2 communication should not be performed on the PC5 interface when the Uu-based C2 connection (or the PDU (Packet Data Unit or Protocol Data Unit) session / PDN (Packet Data Network) connection for Uu-based C2 communication) is terminated. This can be interpreted to mean that if the C2 communication on Uu (or the PDU session / PDN connection for this purpose) has terminated, C2 communication on the PC5 interface is not allowed / authorized.

[0267] (h) Information indicating / commanding that C2 communication can be performed on the PC5 interface even if the Uu-based C2 connection (or the PDU session / PDN connection for Uu-based C2 communication) is terminated. This can be interpreted as allowing / authorizing C2 communication on the PC5 interface even if the C2 communication (or the PDU session / PDN connection for it) on Uu is terminated.

[0268] It should be noted that in various examples of the present disclosure, the above (a) to (h) can also be referred to as (a) information (or information (a)) and (h) information (or information (h)), respectively.

[0269] In the above example, the action of disconnecting the PDU session / PDN connection for Uu-based C2 communication can be interpreted as including disconnecting the QoS flow / bearer for Uu-based C2 communication.

[0270] The above authorization policy / parameter setting can be set by one or more of the following methods: set in the UICC, set in the ME, set in the UE by the PCF, or set in the UE by the AF. Examples of the actions for making these settings can be found in clauses 5.1.1 and 6.2 of TS23.287 V17.4.0.

[0271] Hereinafter, with reference to Figure 8a and Figure 8b examples, the first example in the first example of the present disclosure will be described.

[0272] The following example is based on the content of clause 5.2.5.2.1 (C2 authorization request during the UUAA-SM process in 5GS) of TS23.256 V17.4.0, and the following discussion focuses on the content proposed in the present disclosure. Note that clause 5.2.5.2.1 of the above TS23.256 V17.4.0 describes an addition to clause 5.2.3.2 of TS23.256 V17.4.0.

[0273] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields is for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0274] Figure 8a and Figure 8b illustrate the process according to the first example in the first example of the present disclosure.

[0275] Figure 8a and Figure 8b The examples in illustrate examples of performing UUAA when executing the PDU session establishment process.

[0276] The description of the behavior described in clause 5.2.5.2.1 of TS23.256 V17.4.0 is omitted.

[0277] Step 0. If the information in (a) above is configured in the UE, the UE may decide to perform C2 communication authorization via Uu.

[0278] Step 7. Based on one or more of the information in (b), (c), and / or (d) above and the result (success or failure) of the C2 authorization, the UE may decide whether to perform C2 communication on the PC5 interface. For example, the following example behaviors may be performed:

[0279] - If the C2 authorization is successful, the UE may determine that it can perform C2 communication on the PC5 interface. The UE may make this decision even if the information (c) above is set or not set.

[0280] - In the case of a C2 authorization failure, if the information (b) above is set, the UE may determine that it cannot perform C2 communication on the PC5 interface. Even if the information (b) above is not set, if the information (a) above is set, then if the C2 authorization fails, the UE may determine that it is not permitted to perform C2 communication on the PC5 interface.

[0281] - If the C2 authorization fails, then if the information (d) is configured, the UE may determine that it can perform C2 communication on the PC5 interface.

[0282] Depending on the UE implementation, the UE may perform the determination according to the above examples instead of using the information (b), (c), or (d) above.

[0283] The UE may receive SM NAS messages (e.g., PDU session establishment accept, PDU session establishment reject, etc.) from the SMF. Based on the received SM NAS messages (e.g., PDU session establishment accept, PDU session establishment reject, etc.) and / or the information included in the message (e.g., 5GSM cause value, information contained in the service level - AA container, etc.). The specific description of the 5GSM cause value and service level - AA container information can be found in TS24.501 V17.8.0. For example, if the C2 authorization fails, the 5GSM cause value included in the SM NAS message may contain or be set to #29 "User authentication or authorization failed". For example, when the C2 authorization fails, the service level - AA response information contained in the service level - AA container may contain or be set to "C2 authorization not successful or C2 authorization withdrawn".

[0284] [Table 3]

[0285]

[0286] Table 3 is an example of the service level - AA response information element defined in Table 9.11.2.14.1 of 3GPP TS24.501 V17.8.0.

[0287] In the following, with reference to Figure 9a and Figure 9b as examples, a second example of the first example of the present disclosure will be described.

[0288] The following example is based on the content of clause 5.2.5.3.0 (C2 authorization request during the UUAA - SM procedure in EPS) of TS23.256 V17.4.0, and the following discussion focuses on what is presented in the present disclosure. Note that clause 5.2.5.3.0 of TS23.256 V17.4.0 described an addition to clause 5.2.3.3 of TS23.256 V17.4.0.

[0289] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields are for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0290] Figure 9a and Figure 9b illustrate the process of the second example in the first example according to the present disclosure.

[0291] Figure 9a and Figure 9b The examples in show examples of performing UUAA when executing the PDN connection establishment procedure in EPS.

[0292] The description of the behavior described in clause 5.2.5.3.0 of TS23.256 V17.4.0 is omitted.

[0293] Step 0. If information (a) is set in the UE, the UE can determine to perform C2 communication authorization via Uu.

[0294] Step 8 (or after step 5). Based on one or more of the above information (b), (c), and / or (d) and the result (success or failure) of the C2 authorization, the UE can decide whether to perform C2 communication on the PC5 interface. For example, the following example behaviors can be performed:

[0295] - If the C2 authorization is successful, the UE can determine that it can perform C2 communication on the PC5 interface. The UE can make this determination whether information (c) is configured or not.

[0296] - In the case of C2 authorization failure, if the above information (b) is set, the UE can determine that C2 communication cannot be performed on the PC5 interface. Even if the information (b) is not configured, if the information (a) is configured, the UE can determine that C2 authorization has failed, and the UE is not allowed to perform C2 communication on the PC5 interface.

[0297] - If C2 authorization fails, then if the information in the above (d) is set, the UE can determine that it can perform C2 communication on the PC5 interface.

[0298] Instead of using the information in the above (b), (c), and (d), the UE can make a decision according to the above example based on the UE's implementation.

[0299] The UE can receive SM-related NAS messages (e.g., modify EPS bearer context request, deactivate EPS bearer context request, bearer modification request, etc.) from the network (MME / SMF + PGW-C). Based on the received SM-related NAS messages (e.g., modify EPS bearer context request, deactivate EPS bearer context request, bearer modification request, etc.) and / or the information contained in the NAS message (e.g., ESM cause value, information contained in the service level - AA container, etc.). The specific description of the ESM cause value and the service level - AA container information can be found in TS24.301 V17.8.0. For example, if C2 authorization fails, the ESM cause value can include or be set to #29 "User authentication or authorization failed". For example, when C2 authorization fails, the service level - AA response information contained in the service level - AA container can include / set "C2 authorization is not successful or C2 authorization is withdrawn".

[0300] In reference to Figure 8a and Figure 8b 's example and in reference to Figure 9a and Figure 9b 's example, if the UE determines to perform C2 communication via the PC5 interface, the UE can perform the operation of establishing a C2 connection using the PC5 interface. In addition, if the UE decides not to perform C2 communication on the PC5 interface, the UE can reject a request from another UE (i.e., UAV-C for the UAV and UAV-C for the UAV) to establish a C2 connection using the PC5 interface. If the UE rejects, the UE can send a rejection message to the other UE. The rejection message can include the reason for the rejection (e.g., C2 communication authorization failure based on Uu, C2 communication not authorized based on Uu, C2 communication not authorized based on PC5, etc.).

[0301] In the following, the third example in the first example of the present disclosure will be described with reference to Figure 10 's example.

[0302] The following example is based on the content of Clause 5.2.9.1 (Withdrawal of C2 Connectivity in 5GS) of TS 23.256 V17.4.0, and the following discussion focuses on what is presented in this disclosure.

[0303] The following figures are intended to illustrate specific embodiments of this disclosure. The designation of a specific device shown in the figures or the designation of a specific signal / message / field is for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following figures.

[0304] Figure 10 The process of the third example in the first example according to this disclosure is illustrated.

[0305] Figure 10 The example in shows an example of withdrawing the C2 connection on 5GS.

[0306] Step 3 or Step 6. Based on one or more of the above information (e), (f), (g), and / or (h) and the C2 connection withdrawal (or termination of the PDU session for the C2 connection or termination of the QoS flow for the C2 connection), the UE can decide whether to perform C2 communication on the PC5 interface. For example, the following example behaviors can be performed:

[0307] - In the case of C2 connection withdrawal (or release of the PDU session / QoS flow for the C2 connection), if one or more of the information (e), (g) are configured, the UE can determine that C2 communication on the PC5 interface cannot be performed. Even if the above information (e) and (g) are not configured, if the above information (a) is configured and the C2 connection withdrawal (or release of the PDU session / QoS flow for the C2 connection) has occurred, the UE can determine that it cannot perform C2 communication on the PC5 interface.

[0308] - In the case of C2 connection withdrawal (or release of the PDU session / QoS flow for the C2 connection), the UE can decide that it can perform C2 communication on the PC5 interface. The UE can make this decision even if one or more of the information (f) or (h) are configured or not configured.

[0309] The UE can receive an SM NAS message from the SMF. Based on the received SM NAS message (e.g., PDU session release command, PDU session modification command, etc.) and / or the information contained therein (e.g., 5GSM cause value, information contained in the service level - AA container, etc.), the UE can know the withdrawal of the C2 connection (or release of the PDU session / QoS flow for the C2 connection). A detailed description of the 5GSM cause value and the service level - AA container information can be found in TS 24.501 V17.8.0.

[0310] For example, when the C2 connection is withdrawn, the 5GSM cause value may include or be set to #29 "User authentication or authorization failed". For example, when the C2 connection is withdrawn, the service level-AA response information included in the service level-AA container may include or be set to "C2 authorization unsuccessful or C2 authorization withdrawn".

[0311] In the following, a fourth example of the first example of the present disclosure is described with reference to Figure 11 the examples.

[0312] The following examples are based on the content of clause 5.2.9.2 (Withdrawal of C2 connectivity in EPS) of TS23.256 V17.4.0 and are described in the context of the content presented in the introduction of this specification below.

[0313] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields are for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0314] Figure 11 The process of the fourth example in the first example according to the present disclosure is illustrated.

[0315] Figure 11 The examples in

[0316] Step 2 or step 4. Based on one or more of the information (e), (f), (g), and / or (h) and the C2 connection withdrawal (or termination of the PDN connection for the C2 connection or termination of the bearer for the C2 connection), the UE may decide whether to perform C2 communication on the PC5 interface.

[0317] - In the case of C2 connection withdrawal (or termination of the PDN connection / bearer for the C2 connection), if at least one of the above information (e) or (g) is configured, the UE may determine that it cannot perform C2 communication on the PC5 interface. Even if the information (e) and (g) are not configured, if the above information (a) is configured and the C2 connection withdrawal (or termination of the PDN connection / bearer for the C2 connection) has occurred, the UE may determine that it cannot perform C2 communication on the PC5 interface.

[0318] - In the case of C2 connection withdrawal (or termination of the PDN connection / bearer for the C2 connection), the UE may decide that it can perform C2 communication on the PC5 interface. The UE may make this decision even if one or more of the above information (f), (h) are configured or not configured.

[0319] The UE can receive SM-related NAS messages from the network (MME / SMF + PGW-C). Based on the received SM-related NAS messages (e.g., Modify EPS Bearer Context Request, Deactivate EPS Bearer Context Request, Bearer Modification Request, etc.) and / or the information contained in the NAS messages (e.g., ESM cause value, information contained in the Service Level - AA container, etc.), the UE can be notified of the C2 connection withdrawal (or the termination of the PDN connection / bearer for the C2 connection). For the specific descriptions of the ESM cause value and the Service Level - AA container information, refer to TS24.301 V17.8.0. For example, for the C2 connection withdrawal, the ESM cause value can include or be set to #29 "User authentication or authorization failed". For example, for the C2 connection withdrawal, the Service Level - AA response information included in the Service Level - AA container can include or be configured as "C2 authorization unsuccessful or C2 authorization withdrawn".

[0320] In the example according to Figure 10 and the example according to Figure 11 where the UE performing C2 communication on the PC5 interface can decide not to perform C2 communication on the PC5 interface. When the UE makes such a decision, the UE can perform an operation to disconnect the C2 connection on the PC5 interface. The PC5 message for the disconnection operation can include the reason for the disconnection (e.g., C2 communication based on Uu is withdrawn, C2 communication based on Uu is not authorized, C2 communication based on PC5 is not authorized, etc.). For the detailed description of the behavior of releasing the C2 connection on the PC5 interface, refer to the L2 link release procedure defined in TS23.287 V17.4.0 and TS23.304 V17.4.0.

[0321] 2. The second example of the present disclosure

[0322] describes how to notify the UE during the C2 communication authorization process via Uu or using the Uu connection.

[0323] For example, during the C2 communication authorization process via Uu or using the Uu connection, the network notifies the UE whether it is allowed to perform C2 communication on the PC5.

[0324] If the C2 communication authorization via Uu fails (i.e., is unsuccessful), or if the C2 connection based on Uu is withdrawn, or if the PDU session / QoS flow for the C2 communication based on Uu is released, or if the PDN connection / bearer for the C2 communication based on Uu is released, or if the C2 communication authorization via PC5 fails (i.e., is unsuccessful), or if the C2 connection based on PC5 is withdrawn, the following actions can be performed. For example, the network can provide the UE with information indicating not to perform C2 communication on the PC5 (or not allowing C2 communication on the PC5 or C2 communication on the PC5 is not authorized).

[0325] In the case contrary to the above example, for example, if the C2 communication authorization via Uu is successful or the C2 communication authorization via PC5 is successful, the following example behaviors can be performed. The network can provide the UE with information indicating to perform C2 communication on PC5 (or allowing C2 communication on PC5 or C2 communication on PC5 is authorized).

[0326] Referring to Figure 12 , which illustrates an example of establishing a PC5 unicast link. For the description of establishing or forming a PC5 unicast link in the second example of the present disclosure, reference can be made to the example of Figure 12 .

[0327] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of a specific device shown in the drawings or the designation of a specific signal / message / field is for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0328] Figure 12 Illustrates the process of establishing a layer-2 link at the PC5 reference point according to an embodiment of the present disclosure.

[0329] Describes an example of unicast mode V2X communication at the PC5 reference point.

[0330] Referring to Figure 12 , illustrates an example of establishing a layer-2 link through the PC5 reference point.

[0331] To perform V2X communication in unicast mode via the PC5 reference point, relevant information can be configured in the UE.

[0332] Figure 12 Shows the process of establishing a layer 2 link for the unicast mode of V2X communication at the PC5 reference point.

[0333] 1. The UE determines the destination layer-2 ID for receiving the signaling for PC5 unicast link establishment. The destination layer-2 ID is configured for the UE.

[0334] 1. The UE determines the destination layer-2 ID for receiving the signaling for PC5 unicast link establishment. The destination layer-2 ID is configured by the UE.

[0335] 2. The V2X application layer of UE-1 provides application information for PC5 unicast communication. The application information includes the type of V2X service and the application layer ID of the originating UE. The application layer ID of the target UE may be included in the application information.

[0336] The V2X application layer in UE-1 can provide V2X application requirements for this unicast communication. UE-1 can determine PC5 QoS parameters and PC5 QoS flow ID (PFI).

[0337] If UE-1 decides to reuse an existing PC5 unicast link, the UE can trigger a layer 2 link modification process.

[0338] 3. UE-1 initiates a unicast layer 2 link establishment process by sending a direct communication request message. The direct communication request message can include the following information:

[0339] - Source User Info: The application layer ID of the initiating UE (i.e., the application layer ID of UE-1).

[0340] - If the V2X application layer provided the application layer ID of the target UE in step 2, it includes the following information:

[0341] - Target User Info: The application layer ID of the target UE (i.e., the application layer ID of UE-2).

[0342] - V2X Service Info: Information about the type of V2X service for which the layer 2 link establishment is requested.

[0343] - Security information: Information for establishing security.

[0344] Determine the source layer-2 ID and destination layer-2 ID for sending the direct communication request message. The destination layer-2 ID can be a broadcast or unicast layer-2 ID. If a unicast layer-2 ID is used, the direct communication request message must include Target User Info.

[0345] UE-1 directly sends the communication request message via PC5 broadcast or unicast using the source layer-2 ID and destination layer-2 ID.

[0346] If, for example, based on the NR Tx profile, the sending and receiving of the direct communication request message requires PC5 DRX behavior, the default PC5 DRX settings are used.

[0347] 4. The security of UE-1 is established as follows:

[0348] 4a. If the charging user information is included in the direct communication request message, the target UE (i.e., UE-2) can respond by establishing security with UE-1.

[0349] 4b. The Target User Info may not be included in the direct communication request message. In this case, the UE that wishes to use the advertised V2X service type on the PC5 unicast link with UE-1 shall respond by establishing security with UE-1.

[0350] When security protection is enabled (or activated), UE-1 sends the following information to the target UE:

[0351] - When using IP communication, the following information may be sent:

[0352] - IP address configuration: For IP communication, IP address configuration is required for this link, indicating one of the following values:

[0353] - "IPv6 Router", if the initiating UE supports the IPv6 address allocation mechanism (i.e., it acts as an IPv6 router); or

[0354] - "Does not support IPv6 address allocation", if the initiating UE does not support the IPv6 address allocation mechanism.

[0355] - Link-local IPv6 address: When UE-1 does not support the IPv6 IP address allocation mechanism, i.e., when "Does not support IPv6 address allocation" is indicated in the IP address setting, the locally formed link-local IPv6 address.

[0356] - QoS Info: Information about the PC5 QoS flows to be added. For each PC5 QoS flow, the PFI, the corresponding PC5 QoS parameters (i.e., PQI and conditional other parameters (e.g., MFBR / GFBR, etc.)) and the associated V2X service type.

[0357] Determine the source layer 2 identifier used during the security establishment process. The destination layer 2 ID is set to the source layer 2 ID of the received direct communication request message.

[0358] After receiving a message related to the security establishment process, UE-1 obtains the layer 2 identifier of the peer UE for future signaling and data traffic communication on this unicast link.

[0359] 5. The target UE that has successfully established security with UE-1 sends a direct communication acceptance message to UE-1:

[0360] 5a. (UE-directed layer-2 link establishment) If the target user information is included in the direct communication request message and if the application layer ID of the target UE (i.e., UE-2) matches, UE-2 shall respond with a direct communication acceptance message.

[0361] 5b. (V2X Service - Oriented Layer 2 Link Establishment) If the target user information is not included in the direct communication request message, the UE that wishes to use the advertised V2X service shall respond to the request by sending a direct communication acceptance message ( Figure 12 UE - 2 and UE - 4 in

[0362] The direct communication acceptance message includes the following items:

[0363] - Source User Info: The application layer ID of the UE that sends the direct communication acceptance message.

[0364] - QoS Info: Information about the PC5 QoS flow requested by UE - 1. For each PC5 QoS flow, it includes PFI, corresponding PC5 QoS parameters (i.e., PQI and conditional other parameters (e.g., MFBR / GFBR, etc.)) and related V2X service type information.

[0365] - If IP communication is used, it includes the following information:

[0366] - IP address configuration: For IP communication, IP address configuration is required for this link. It indicates one of the following values:

[0367] - "IPv6 Router", if the initiating UE supports the IPv6 address allocation mechanism (i.e., it acts as an IPv6 router); or

[0368] - "Does not support IPv6 address allocation", if the target UE does not support the IPv6 address allocation mechanism.

[0369] - Link - local IPv6 address: When the target UE does not support the IPv6 IP address allocation mechanism (i.e., "Does not support IPv6 address allocation"), the locally formed link - local IPv6 address is indicated in the IP address setting, and UE - 1 includes the link - local IPv6 address in the direct communication request message. The target UE shall include a non - conflicting link - local IPv6 address.

[0370] If two UEs (i.e., the initiating UE and the target UE) choose to use the link - local IPv6 address, the duplicate address detection must be disabled.

[0371] If the initiating UE or the target UE indicates that it supports an IPv6 router, the addressing process is performed after the layer 2 link establishment, and the link - local IPv6 address can be ignored.

[0372] The V2X layer of the UE that establishes a PC5 unicast link forwards the PC5 link identifier assigned to the unicast link and the PC5 unicast link related information to the AS layer. The PC5 unicast link related information includes layer-2 identification information (e.g., source layer-2 identification and destination layer-2 identification) and corresponding PC5 QoS parameters. This allows the AS layer to maintain the PC5 link identifier and the PC5 unicast link related information.

[0373] 6. Transmit V2X service data via the unicast link established as follows:

[0374] The PC5 link identifier and PFI are provided to the AS layer together with the V2X service data.

[0375] Optionally, additional layer 2 identification information (e.g., source layer 2 ID and destination layer 2 ID) is provided to the AS layer.

[0376] Depending on the UE implementation, the layer 2 identification information may also be provided to the AS layer.

[0377] UE-1 uses the source layer-2 ID (i.e., the layer-2 ID of UE-1 for this unicast link) and the destination layer-2 ID (i.e., the layer-2 ID of the peer UE for this unicast link) to transmit V2X service data.

[0378] Since the PC5 unicast link is bidirectional, the peer UE of UE-1 can send V2X service data to UE-1 on the unicast link with UE-1.

[0379] Hereinafter, with reference to Figure 8a and Figure 8b , a first example of a second example of the present disclosure is described. It should be noted that although the first example of the first embodiment of the present disclosure was previously illustrated with reference to Figure 8a and Figure 8b , hereinafter, what is proposed in the first example of the second embodiment of the present disclosure will be described based on Figure 8a and Figure 8b .

[0380] USS UAV authorization / authentication (UUAA) can be triggered by the SMF during PDU session establishment. UUAA can also be triggered based on the SM subscription data obtained from the UDM and the service level device ID provided by the UE in the PDU session establishment request or the PDN connection establishment request.

[0381] Step 0. The steps 1 to 5 of the example of Figure 5 can be executed.

[0382] The UAV may include the following information in the PDU session establishment request message, as shown in the following example. For example, the UAV may include a service level device identifier (e.g., the CAA level UAV ID of the UVA), an authentication server address (e.g., the USS address), and optional authorization data (e.g., the UUAA airborne payload) in the PDU session establishment request message.

[0383] Step 1. The SMF may send an authorization-related message to the UAS NF / NEF. For example, the SMF may send an authorization-related message to the USS through the UAS NF / NEF. For example, the SMF may invoke the Nnef_Authentication_AuthenticateAuthorize service operation. This service operation may include the service level device ID (including the CAA level UAV ID of the UAV), DNN, S-NSSAI, and may include the authorization server address (i.e., the USS address) and the UUAA aviation payload (if provided by the UE), GPSI, optional UAV location, PEI (if available), and UE IP address (if available). The UAV location is the user location information provided by the AMF (e.g., cell ID). The UAS NF / NEF selects the USS based on the service level device ID (e.g., the CAA level UAV ID of the UAV) or the authorization server address (e.g., the USS address).

[0384] Step 2. The UAS NF / NEF may send an authorization-related message to the USS. For example, the UAS NF / NEF may invoke the Naf_Authentication_AuthenticateAuthorize service operation to forward the authorization request information received from the SMF to the USS. For example, the UAS NF may convert the cell ID received as part of the UAV location in the Nnef_Authentication_AuthenticateAuthorize request in Step 1 to the corresponding geographical area, and / or the UAS NF may use the location service procedure to further obtain the UE location information and include it in the Naf_Ahentication_AuthenticateAuthorize message to the USS to support the geolocation function.

[0385] Step 3. [Conditional operation] Depending on the authorization method used by the USS, multiple necessary round-trip messages may be sent or received. The response message of the USS (e.g., Naf_Authentication_AuthenticateAuthorize response message) includes the GPSI, and the authorization message according to the authorization method used is transparently transmitted to the UE via the NAS SM transport message. If not provided by the UE previously, the authorization message in Step 3 may include the UUAA airworthiness payload required by the USS.

[0386] Step 4. The USS may send an authorization response message (e.g., Naf_Authentication_AuthenticateAuthorize response) to the UAS NF / NEF. The authorization response message may include the result of authentication / authorization. The authentication / authorization result may include the UUAA result for the UAS NF and information related to whether the UAS service associated with the network resources can be released for re-authentication or re-authorization in case of UUAA failure. Optionally, the authorization / authentication result may include the authenticated CAA-level UAV ID, the requested policy information, and the service-level device ID including the UUAA authorization payload. The policy information requested by the USS may include the DN authentication profile index and / or the DN authentication session AMBR. The USS may include the new CAA-level UAV ID as the authorized CAA-level UAV ID.

[0387] Step 6. The SMF may receive the authorization response message from the UAS NF / NEF. For example, the SMF may receive a response message from the UAS NF / NEF including information / results of C2 authorization failure or success. In this embodiment, the C2 authorization may be the authorization for C2 communication via Uu and / or the authorization for C2 communication via PC5. The authorization response message may be a message sent by the USS to the SMF via the UAS NF / NEF.

[0388] Step 7. After successful authentication / authorization, the USS subscribes to the PDU session status event. For example, the behavior of Steps 1 to 5 of Figure 4 .15.3.2.3-1 according to TS23.502 V17.6.0 may be performed. Step 7 may be executed in parallel with Step 4. The UAS NF / NEF will determine which DNN, S-NSSAI will subscribe to the PDU session status event notification.

[0389] Step 7. The SMF may send an SM NAS message to the UE. For example, when the SMF sends an SM NAS message (e.g., PDU session establishment accept, PDU session establishment reject, PDU session modification command, etc.) to the UE, the SMF may include the following information in the SM NAS message:

[0390] i) In the case of C2 authorization failure (i.e., when the SMF receives a response message from the UAS NF / NEF that includes information / results indicating that C2 authorization has failed), the SMF may include in the SM NAS message information indicating / commanding not to perform C2 communication on the PC5 interface. This can be interpreted as not allowing / authorizing C2 communication on the PC5 interface.

[0391] ii) In the case of successful C2 authorization (i.e., when the SMF receives a response message from the UAS NF / NEF that includes information / results indicating successful C2 authorization), the SMF may include in the SM NAS message information contrary to that in case i) (e.g., information indicating that C2 communication can be performed via the PC5 interface. This information can be interpreted as allowing / authorizing C2 communication on the PC5 interface). The SMF may also provide the UE with UAV-C specific information (e.g., the application layer ID of UAV-C (which can be interpreted as user information or pilot information), layer-2 ID, etc.). For example, the SMF may send to the UE via the AMF an SM NAS message including UAV-C related information (e.g., the application layer ID of UAV-C (which can be interpreted as user information or pilot information), layer-2 ID, etc.). The SMF may provide or obtain UAV-C related information from one or more of the following entities: USS, UAS NF / NEF, UDM, UDR, PCF, UAV-C, application server / function. Alternatively, UAV-C related information may be configured in the SMF. All UAV-C related information may be provided or obtained from a single entity or from multiple entities. For example, the SMF may receive UAV-C related information (e.g., the application layer ID of UAV-C) from the USS, and the SMF may send UAV-C related information (e.g., the application layer ID of UAV-C) to the UE (e.g., UAV). The UAV may use the UAV-C related information provided above to establish a PC5 unicast link for C2 communication with UAV-C (or, alternatively, the UAV may use the UAV-C related information provided above to form a PC5 unicast link for C2 communication with UAV-C). For example, based on Figure 12 the example, the UE (e.g., UAV) may perform a procedure for establishing a PC5 unicast link for C2 communication with UAV-C. For example, in Figure 12In step 3, the UE (e.g., UAV) can set the Target User Info to the application layer ID of UAV-C. The reason that the SMF includes information related to UAV-C may be that the UE has requested such information (in step 1). The information related to UAV-C can also be information related to a Third Party Authorization Entity (TPAE). In this case, the TPAE can be considered as a UE with PC5 capabilities or a UE with V2X capabilities or a UE with ProSe capabilities.

[0392] The UAV can establish a PC5 unicast link for C2 communication with UAV-C or the Third Party Authorization Entity (TPAE). In this case, if the UAV has an application layer ID provided by the network, the UAV can set the application layer ID as the Target User Info. Additionally, if the UAV has a layer-2 ID provided by the network, the UAV can set the layer-2 ID as the destination layer-2 ID, and the UAV can use the layer-2 ID to the destination layer-2 ID to establish a PC5 unicast link (e.g., the UAV uses the destination layer-2 ID to send a direct communication request message). If the network also provides the UAV's layer-2 ID, the UAV can set the UAV's layer-2 ID as the source layer-2 ID, and use the source layer-2 ID to establish a PC5 unicast link (e.g., the UAV uses the source layer-2 ID to send a direct communication request message). The operation for the UAV to obtain the UAV's layer-2 ID from the network can be performed in a manner similar to the operation for the UAV to obtain the above-mentioned UAV-C related information from the network. This description of PC5 unicast link formation can be applied throughout this disclosure.

[0393] The UAV-C related information or the TPAE related information can also be inferred / determined based on the identification information of the UAV (e.g., the identification information of one or more of the CAA level UAV ID (or the service level device identification of the UAV), GPSI, PEI, IP address information). This can be applied throughout the specification.

[0394] Among the UAV-C related information and the TPAE related information, the application layer related information (e.g., application layer ID) can also be considered as direct C2 pairing information or C2 pairing information. For example, the application layer related information (e.g., application layer ID) can be provided to the UE as direct C2 pairing information or C2 pairing information. This can be applied throughout the specification.

[0395] For example, in Figure 8a and 8bFor step 0 of the example, the following example description can be applied. The UAV may need to establish a direct PC5 link to connect to UAV-C (i.e., direct C2 communication). In this case, the C2 aerial payload sent by the UAV may include an indication that it is also an authorization for direct C2 communication. The UAV may also include direct C2 pairing information (if available) in the C2 aerial payload.

[0396] For example, in Figure 8a and 8b For step 4 of the example, the following illustrative description can be applied. If an authorization request for direct C2 communication is included in step 0 and C2 authorization is successful, the USS may include direct C2 pairing information in the C2 authorization payload that includes the application layer ID of UAV-C. The C2 authorization payload that includes the application layer ID of UAV-C may be included in the Naf_Ahentication_AuthenticateAuthorize response, which may be further forwarded to the UE.

[0397] For example, in the following Figure 13 For step 1 of the example, the following description can be applied. The UAV may need to establish a direct PC5 link to connect to UAV-C (i.e., direct C2 communication). In this case, the C2 aerial payload sent by the UAV may include an indication that it is also an authorization for direct C2 communication. The UAV may also include direct C2 pairing information (if available) in the C2 aerial payload.

[0398] For example, in the following Figure 13 For step 4 of the example, the following illustrative description can be applied. If an authorization request for direct C2 communication is included in step 0 and C2 authorization is successful, the USS may include direct C2 pairing information in the C2 authorization payload that includes the application layer ID of UAV-C. The C2 authorization payload that includes the application layer ID of UAV-C should be included in the Naf_Ahentication_AuthenticateAuthorize response, which may be further forwarded to the UE.

[0399] The above information related to UAV-C or information related to TPAE may be provided. In this case, such information can be interpreted as in the following examples. For example, such information can be interpreted as the following: UAV-C or TPAE is authorized to control the UAV, or UAV-C or TPAE is authorized to perform C2 communication with the UAV, or UAV-C or TPAE is authorized to perform C2 communication with the UAV via PC5, or UAV-C or TPAE is authorized to pair with the UAV, authorized to pair with the UAV, etc. This can be applied throughout the specification.

[0400] The UAV can establish a C2 connection with the recently established or network-provided C2 connection opponent (e.g., UAV-C or TPAE) via PC5. This can be applied throughout the specification.

[0401] For the reasons described in the following examples, the SMF can include information related to the above i) or ii) in the SM NAS message. For example, at step 0, since the UE has requested authorization information for PC5-based C2 communication, the SMF can include this information in the SM NAS message. For example, since the AMF has requested the UE to provide authorization information for PC5-based C2 communication (at step 1), the SMF can include this information in the SM NAS message based on subscriber information (e.g., when performing Uu-based C2 communication authorization, the authorization information for PC5-based C2 communication needs to be provided to the UE, and the UE can perform PC5-based C2 communication, etc.). If the USS has requested the UE to provide authorization information for PC5-based C2 communication (at step 4), the SMF can include the above information in the SM NAS message. The UAS NF / NEF has requested the UE to provide authorization information for PC5-based C2 communication (at step 5), and the SMF can include this information in the SM NAS message. Based on the SMF's local policy / operator policy / local configuration, the SMF can include the above information in the SM NAS message. Based on one or more of the various information in these examples, the SMF can include information in the SM NAS message.

[0402] The UE can receive the SMF NAS message from the SMF. The SM NAS message can include information based on i) or information based on ii). The UE can determine whether C2 communication can be performed on the PC5 interface based on the SM NAS message received from the SMF and / or based on the information of the above i) or ii).

[0403] Hereinafter, with reference to Figure 9a and Figure 9b , a second example of the second aspect of the present disclosure will be described. It should be noted that although the second example of the first example of the present disclosure was previously described with reference to Figure 9a and Figure 9b , the following will be based on Figure 9a and Figure 9b describe what is proposed in the second example of the second example of the present disclosure.

[0404] Step 5. The SMF + PGW-C receives a response message from the UAS NF / NEF including information / results of C2 authorization failure or success. In this embodiment, the C2 authorization can be authorization for C2 communication via Uu and / or authorization for C2 communication via PC5.

[0405] Step 8 (or after Step 5). The SMF+PGW-C may send SM-related NAS messages to the UE via the MME. The SMF+PGW-C may include the following information in the SM-related NAS messages (e.g., Modify EPS Bearer Context Request, Deactivate EPS Bearer Context Request, etc.):

[0406] I) In the case of C2 authorization failure (i.e., when receiving a response message including information / result of C2 authorization failure from the UAS NF / NEF), the SMF+PGW-C may include in the SM-related NAS message information indicating / commanding not to perform C2 communication on the PC5 interface. This may be interpreted as not allowing / authorizing C2 communication on the PC5 interface.

[0407] II) When C2 authorization is successful (i.e., when the SMF+PGW-C receives a response message including information / result of C2 authorization success from the UAS NF / NEF), the SMF+PGW-C may include in the SM-related NAS message information contrary to the above case I) (e.g., information indicating that C2 communication may be performed via the PC5 interface. This information may be interpreted as allowing / authorizing C2 communication on the PC5 interface). In this case, the SMF+PGW-C may also provide the UE with UAV-C related information (e.g., application layer ID of UAV-C (which may be interpreted as user information or pilot information), layer-2 ID, etc.). For example, the SMF+PGW-C may provide the UE with an SM NAS message including UAV-C related information (e.g., application layer ID of UAV-C (which may be interpreted as user information or pilot information), layer-2 ID, etc.). The SMF+PGW-C may provide or obtain UAV-C related information from one or more of the following entities: USS, UAS NF / NEF, UDM / HSS, UDR, PCF, UAV-C, application server / function. Alternatively, the above UAV-C related information may be configured in the SMF+PGW-C. All UAV-C related information may be provided or obtained from one entity, or may be provided or obtained from multiple entities. The UAV may use the UAV-C related information provided above to form a PC5 unicast link for UAV-C and C2 communication (or the UAV may use the UAV-C related information provided above to form a PC5 unicast link for UAV-C and C2 communication). The reason for the SMF+PGW-C to include the above UAV-C related information may be that the UE has requested such information (e.g., it may be requested by the UE in Step 0). The above UAV-C related information may also be third-party authorization entity (TPAE) related information. In this case, the TPAE may be considered as a UE with PC5 capabilities or a UE with V2X capabilities or a UE with ProSe capabilities.

[0408] For the reasons given in the following examples, the SMF+PGW-C may include information related to the above I) or II) in the SM NAS message. For example, if the UE has requested authorization information for PC5-based C2 communication (at step 0), the SMF+PGW-C may include this information in the SM NAS message. For example, if the MME has requested the UE to provide authorization information for PC5-based C2 communication (at step 1), the SMF+PGW-C may include this information in the SM NAS message. For example, based on subscriber information (e.g., information such as the UE should provide authorization information for PC5-based C2 communication when performing Uu-based C2 communication authorization, the UE is capable of performing PC5-based C2 communication, etc.), the SMF+PGW-C may include the above information in the SM NAS message. For example, if the USS has requested the UE to provide authorization information for PC5-based C2 communication (at step 5), the SMF+PGW-C may include the above information in the SM NAS message. For example, if the UAS NF / NEF has requested the UE to provide authorization information for PC5-based C2 communication (at step 5), the SMF+PGW-C may include the above information in the SM NAS message. Based on the local policy / operator policy / local configuration of the SMF+PGW-C, the SMF+PGW-C may include the above information in the SM NAS message. Based on one or more of various information such as these examples, the SMF+PGW-C may include the above information in the SM NAS message.

[0409] Based on the SM-related NAS message received from the network to the UE and / or the information in the above I) or II), the UE may determine whether it can perform C2 communication on the PC5 interface.

[0410] In the following, a third example in the second example of the disclosure of the present disclosure is described.

[0411] As a reference, the third example in the second example of the present disclosure is an implementation manner based on the first example and / or the second example in the second example of the present disclosure above. For example, the third example in the second example of the disclosure of the present disclosure is an example applying the description of the second example of the disclosure of the present disclosure.

[0412] C2 communication and direct C2 communication can be defined as follows.

[0413] Command and Control (C2) Communication: The user plane link used to transfer messages including command and control information for UAV operations from a UAV controller or UTM to a UAV. Or the user plane link used to report telemetry data from the UAV to a UAV controller or UTM. C2 communication can be established via the Uu reference point or the PC5 reference point.

[0414] Direct C2 Communication: For communication with each other, a UAV controller and a UAV can establish a direct C2 link via the PC5 reference point.

[0415] C2 Aerial Payload: Includes application layer information sent by the UAS to the USS, including UAV pairing information and / or flight authorization information that is transparent to the 3GPP system.

[0416] C2 Authorization Payload: Includes application layer information sent by the USS to the UAV, such as C2 pairing information and / or C2 security information that is transparent to the 3GPP system.

[0417] C2 Pairing Information: Includes UAV-C addressing information (e.g., UAV-C IP address).

[0418] Authorization for C2 via Uu is described.

[0419] When a UAV establishes a user plane connection for C2 operations (i.e., transfers messages including command and control information about UAV operations from the UAV-C or USS to the UAV, or reports telemetry data from the UAV to the UAV-C), authorization for C2 is required. Both sides of the C2 communication (the UAV and the UAV-C) can belong to the same UAS.

[0420] The UAV can be authorized by the USS to use a PDU session or a PDN connection for C2. Authorization for C2 includes the following items:

[0421] - UAV-to-UAV-C Pairing Authorization: This can be used to pair with a networked UAV-C or a UAV-C connected to the UAV via an Internet connection before the UAV and the UAV-C exchange C2 communication. The UAV can be paired with only one UAV-C at any given time. The UAV-C can be paired with one or more UAVs simultaneously.

[0422] - Flight Authorization: If the UAV also provides flight certification information, this can be flight authorization.

[0423] C2 authorization can be performed in the following examples:

[0424] - During the UUAA procedure (when UUAA is performed on the establishment of a PDU session / PDN connection): When the UAV requests to establish a PDU session / PDN connection for connectivity.

[0425] - During the PDU session modification procedure or the bearer resource modification procedure requested by the UE: When the UAV needs to use an existing PDU session / PDN connection to exchange C2 communication-related messages.

[0426] - During the establishment of a new PDU session / PDN connection: When the UAV needs to use a separate PDU session / PDN connection for C2 communication.

[0427] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields are for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0428] Figure 13 An example process for establishing a PDU session for C2 communication according to an embodiment of the present disclosure is illustrated.

[0429] Figure 13 The process of establishing a PDU session for UE-initiated C2 communication is shown. Figure 13 The example in is an example when a separate PDU session is used for UAS services.

[0430] If C2 authorization is requested during the establishment process of a PDU session dedicated to C2 communication with UAV-C, the UAV shall request C2 authorization as follows.

[0431] 0. The UAV has performed a successful UUAA with the USS (UUAA-SM or UUAA-MM), and the USS can subscribe to PDU session status events for this GPSI from the NEF.

[0432] 1. If the UAV needs to establish C2 communication, the UAV can determine that a new dedicated PDU session or a direct PC5 link is required to connect to UAV-C. The UE can initiate the PDU session establishment process for the DNN / S-NSSAI to connect to UAV-C. The PDU session establishment request shall include the C2 aviation payload and the CAA-level UAV ID to be used for C2 authorization, and the PDU session establishment request shall be forwarded to the SMF. The pairing information includes the CAA-level UAV ID of the requesting UAV, and the identification of the UAV-C to be paired can be included in the C2 aviation payload. If the authorization request is for direct C2 communication, the C2 aviation payload includes an indication that the authorization is for direct C2 communication. The UAV can also include other information, such as flight certification information, in the aviation payload. The USS can also use locally configured pairing information to authenticate the UAV-UAV-C pairing, which takes precedence over the pairing information provided by the UAV.

[0433] 2. Based on the fact that the requested DNN / S-NSSAI combination is only for air services (the air service indicator is set) and the request includes the service level device identifier (CAA level UAV ID), the SMF can determine whether authorization is required. Then, the SMF can send an Nnef_Authentication_AuthenticateAuthorize request message to the UAS NF / NEF, which is used to request authorization to pair the UAV-C with the UAV. This request message includes the GPSI, the CAA level UAV ID, and the C2 air payload, the optional UAV location (e.g., cell ID) (if provided by the AMF), and the DNN and S-NSSAI of the PDU session.

[0434] If the requested DNN / S-NSSAI is only for air services, but the request does not provide the service level device ID (CAA level UAV ID), the SMF can reject the PDU session establishment request due to the need for USS authorization. For example, the SMF can send a PDU session establishment rejection message including the reason for the need for USS authorization.

[0435] The SMF also provides a notification endpoint to the UAS NF / NEF. By providing the notification endpoint, if the C2 authorization result in step 5 is successful, the SMF can implicitly subscribe to receive notifications about the reauthorization, authorization data update, or revocation of the C2 connection of the UAS NF / NEF.

[0436] 3. The UAS NF / NEF checks if a valid UUAA is stored for the GPSI and forwards the Naf_Authentication_AuthenticateAuthorize request message including the received authorization request to the USS. Otherwise, the request is not forwarded to the USS and the PDU session is rejected.

[0437] The UAS NF / NEF also provides a notification endpoint to the USS. By providing the notification endpoint, if the UUAA result in step 5 is successful, the UAS NF / NEF can implicitly subscribe to receive authorization, authorization data update, or C2 disconnection notifications from the USS.

[0438] The USS can trigger UAV re-authentication / re-authorization in response to a query from the UAS NF / NEF.

[0439] 4. The USS can perform C2 authorization based on the received information and send a Naf_Authentication_AuthenticateAuthorize response message to the UAS NF / NEF. The Naf_Authentication_AuthenticateAuthorize response message can include a service level device identifier (e.g., CAA level UAV-ID) (which may be new), a C2 authorization result, and a C2 authorization payload (e.g., C2 pairing information and C2 security information, direct C2 pairing information).

[0440] In step 1, an authorization request for direct C2 communication is included, and the C2 authorization can be successful. In this case, the USS can include the direct C2 pairing information, which includes the application layer ID of UAV-C, in the Naf_Ahentication_AuthenticateAuthorize response message.

[0441] 5. The UAV-NF / NEF can send a Nnef_Authentication_AuthenticateAuthorize response message including the information received from the USS to the SMF.

[0442] 6. The SMF can send a PDU session establishment accept message to the UE. To notify the UE of the C2 authorization result, the SMF can include the authorization result, an optional authorization payload (e.g., C2 pairing information and C2 security information, direct C2 pairing information), and the new CAA level UAV ID (if received from the USS) in the PDU session establishment accept message. Then, the SMF can continue until the PDU session establishment process is completed.

[0443] If a failed C2 authorization result is received from the USS, the SMF can reject the PDU establishment and send a PDU session establishment reject message including a cause code indicating that the PDU was not authenticated.

[0444] 7. [Conditional] If the C2 authorization is successful, the USS subscribes to the PDU session status event for the PDU session used for C2 by sending a request message including the GPSI of the UAV via the UAV-NF. The UAS NF determines the DNN and S-NSSAI corresponding to the PDU session used for C2 communication and subscribes to the PDU session status event with the SMF using the DNN and S-NSSAI. The SMF can detect that the PDU session has been established as described in TS23.502 V17.6.0 Figure 4As described in steps 6-7 of 0.15.3.2.3-1, and send a PDU session status event report to the UAS NF / NEF via the Nsmf_EventExposure_Notify message including the GPSI and the UE IP address. Then, the UAS NF / NEF forwards the event message to the USS.

[0445] 8. [Conditional] The USS stores the received UE IP address, and with the received PDU session IP address and the IP address of the authenticated paired UAV-C as inputs, the USS can invoke the pairing policy setting process. Therefore, the USS requests the UPF to permit the corresponding traffic in the PDU session.

[0446] Unless a dedicated QoS is requested for the C2 flow, this process does not invoke interactions with the UE, the AMF, or the RAN.

[0447] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields is for illustrative purposes only, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0448] Figure 14 is an example of a C2-authorized PDN connection according to an embodiment of the present disclosure.

[0449] Figure 14 is an example of a process for establishing a C2-authorized PDN connection requested by the UE.

[0450] When the UAV requests to establish a connection to an additional PDN via E-UTRAN for C2, the following modifications to the process in clause 5.10.2 of TS23.401 can be applied, as shown in the following example.

[0451] 0. The UAV has performed a successful UUAA with the USS (UUAA-SM), and the USS may have subscribed to the PDN connection status event report for this GPSI from the NEF.

[0452] 1. Steps 1 to 3 described in Figure 5 .10.2-1 of TS23.401 can be executed.

[0453] If the UAV needs to establish C2 communication, the UAV can determine that a new PDN connection or a direct PC5 link is required to connect to the UAV-C. The UE shall initiate the UE-requested PDN connection procedure to connect to the UAV-C. The PCO included in the PDN connection request message includes the service level device identifier to be used for C2 authorization (e.g., CAA-level UAV ID) and the C2 air payload, and the PCO is forwarded to the MME. The pairing information includes the service level device identifier of the requesting UAV (e.g., CAA-level UAV ID), and the identifier of the UAV-C to be paired can be included in the C2 air payload. If the authorization request is an authorization request for direct C2 communication, the C2 air payload includes an indication that it is an authorization for direct C2 communication. The UAV may also include other information, such as flight authorization information. Additionally, the USS may use locally configured pairing information for UAV-UAV-C pairing authorization, which takes precedence over the pairing information provided by the UAV.

[0454] If the service level device ID (CAA-level UAV ID) is provided with the request message, the SMF+PGW-C can use the Nudm_SDM_Get service operation to retrieve the UE's session management subscription data from the UDM+HSS (if not already available).

[0455] 2. Based on the requested APN / DNN being only for air services (the air service indicator is set) and the request message including the service level device identifier (CAA-level UAV ID), the SMF+PGW-C can determine that authorization is required. The SMF+PGW-C then sends an Nnef_Authentication_AuthenticateAuthorize request message to the UAS NF / NEF, which is used to request authorization to pair the UAV-C with the UAV. This request message includes the GPSI, the service level device identifier (e.g., CAA-level UAV ID), and the C2 air payload, as well as the optional UAV location (e.g., cell ID) (if provided by the MME) and the APN / DNN of the PDN connection.

[0456] If the SMF+PGW-C determines that an authorization procedure with the USS is required, but the UAV has not provided the service level device ID (e.g., CAA-level UAV ID), the SMF+PGW-C shall send a PDN connection request rejection message with the cause being USS authorization required.

[0457] 3. The UAS NF / NEF checks whether a valid UUAA is stored for the GPSI and forwards the received authorization request as a Naf_Authentication_AuthenticateAuthorize request to the USS. Otherwise, the request is not forwarded to the USS and the PDN connection is rejected.

[0458] 4. The USS performs C2 authorization based on the received information and sends a Naf_Authentication_AuthenticateAuthorize response to the UAS NF / NEF, which includes a service level device ID (e.g., CAA level UAV-ID) (which may be new), a C2 authorization result, and a C2 authorization payload (e.g., C2 pairing information and C2 security information, direct C2 pairing information).

[0459] If step 1 includes an authorization request for direct C2 communication and the C2 authorization is successful, the USS may include direct C2 pairing information in the Naf_Ahentication_AuthenticateAuthorize response that includes the application layer ID of the UAV-C.

[0460] 5. The UAS NF / NEF forwards the information received from the USS in the Nnef_Authentication_AuthenticateAuthorize response to the SMF+PGW C.

[0461] 6. To notify the UE of the C2 authorization result, the SMF+PGW-C may include the C2 authorization result, as well as optional authorization payloads (e.g., C2 pairing information and C2 security information, direct C2 pairing information) and the new service level device ID (e.g., CAA level UAV ID) (if received from the USS) in the PCO of the PDN connectivity acceptance to be sent to the UE, and the SMF+PGW-C shall include it and continue until the PDN connection request process is completed.

[0462] If a failed C2 authorization result is received from the USS, the SMF+PGW-C instead rejects the PDN connection request and sends a rejection message with a cause code indicating that it is not authorized.

[0463] 7. Upon successful C2 authorization, the USS includes the GPSI of the UAV in the request for subscribing to the PDN connection status event report for C2 via the UAS NF / NEF. The UAS NF / NEF determines the APN / DNN and uses that APN / DNN to subscribe to the PDN connection status event with the SMF+PGW-C. The SMF+PGW-C detects when the PDN connection is established, as in TS23.502Figure 4 As described in steps 6-7 of 15.3.2.3-1. Then, SMF+PGW-C will send a PDN connection status event report including GPSI and UE IP address to UAS NF / NEF via the Nsmf_EventExposure_Notify message. Then, UAS NF / NEF will forward the event message to USS.

[0464] 8. To request permission for such traffic on the PDN connection by PGW-U, USS may store the received UE IP address and invoke the USS-initiated C2 pairing policy setting procedure during the EPS procedure (see Figure 5 .2.5.4.2-1), with the received PDN connection IP address and the IP address of the authenticated paired UAV-C as inputs.

[0465] Unless dedicated QoS is requested for the C2 flow, this procedure does not invoke any interaction with the UE, MME, or RAN.

[0466] Describe direct C2 communication.

[0467] A UAV that supports direct C2 communication may establish a direct PC5 link with UAV-C. A UAV using direct C2 communication may or may not be connected to the 3GPP network. The UAV may be authenticated by USS to establish direct C2 communication with UAV-C. As shown in the example with reference to Figure 13 and the example with reference to Figure 14 information related to UAV-C that establishes direct C2 communication with the UAV may be pre-set in the UAV or provided by the network. The UAV may be pre-set with vehicle-to-everything (A2X) service types for direct C2 communication, direct C2 pairing information (e.g., application layer ID of UAV-C), layer-2 ID of UAV-C, default destination layer-2 ID for initial signaling to establish a unicast connection, and an authorization policy for direct C2 communication.

[0468] Describe the authorization for direct C2 communication.

[0469] The following authorization policies may be provided to a UAV that supports direct C2 communication:

[0470] - When the UAV is "served by NG-RAN":

[0471] - When the UAV is "served by NG-RAN", the PLMN authorized to perform direct C2 communication via the PC5 reference point.

[0472] - If the UAV is not "served by NG-RAN":

[0473] - Information indicating whether the UE is authorized to perform C2 communication via the PC5 reference point when it is "not served by the NG-RAN".

[0474] If the UAV can connect to the 3GPP network, the UAV performs C2 authorization as previously described for "Authorization of C2 via Uu". If the UAV supports direct C2 communication and there is no authorization policy for direct C2, the UAV may include an indication of direct C2 communication authorization in the authorization request.

[0475] Describe the procedure established for direct C2 communication.

[0476] The unicast mode 5G ProSe direct communication procedure defined in clause 6.4.3.1 of TS 23.304 V17.4.0 shall be used for the establishment of C2 communication via PC5, with the following enhancements. The following enhancements can also be applied to Figure 12 the examples referred to in

[0477] - In step 3 (or Figure 12 ) of clause 6.4.3.1 of TS 23.304 V17.4.0, the following description can be applied:

[0478] - Prose Service Info can be configured to the A2X service type for C2 communication. The A2X service type for C2 communication can be pre-set on the UAV.

[0479] - Source user information can be configured to the service level device ID (e.g., CAA level UAV ID).

[0480] - Destination user information can be configured to the application layer ID of UAV-C. As shown in the examples of Figure 13 and Figure 14 's examples, the application layer ID of UAV-C can be pre-set on the UAV or provided by the network.

[0481] - The destination layer-2 ID is set to the layer-2 ID of UAV-C (if the UAV has a pre-set layer-2 ID of UAV-C). Otherwise, the destination layer-2 ID is set to the default destination layer-2 ID for the initial signaling to establish a unicast connection as pre-set in the UAV.

[0482] For direct C2 communication, the unicast mode 5G direct communication procedure can be supported.

[0483] 3. The third example of this disclosure

[0484] An example is described where the network uses the Uu connection to inform the UE when it wants to change the destination for PC5-based C2 communication with the UAV.

[0485] For example, as long as the network has a PC5-based C2 connection with the UAV (i.e., performs PC5-based C2 communication), the network can use the Uu connection to inform the UE when it wants to change from UAV-C to TPAE or from TPAE to UAV-C or from UAV-C to TPAE.

[0486] When the UAV-C with a PC5-based C2 connection (i.e., performs PC5-based C2 communication) with the UAV changes, or when the UAV-C becomes TPAE, or when TPAE becomes UAV-C, one or more of the following operations can be performed:

[0487] a) The UAV controller replacement procedure can be used (see clause 5.2.8 of TS23.256 V17.4.0). For example, the USS can provide the UAS NF / NEF with information about the change or indication that the (re)authorization is for the information about the change. The UAS NF / NEF can provide the above information to the SMF (for 5GS) or SMF+PGW-C (for EPS). When the SMF (in the case of 5GS) sends an SM NAS message to the UE, or when the SMF+PGW-C (in the case of EPS) sends an SM-related NAS message to the UE via the MME, the SMF can include the above information.

[0488] b) The C2 connectivity withdrawal procedure can be utilized (see the examples in Figure 10 and the examples in Figure 11 ). For example, the USS can provide the UAS NF / NEF with information about the above change or indication that the withdrawal is for the above change. The UAS NF / NEF can provide the information to the SMF (in the case of 5GS) or SMF+PGW-C (in the case of EPS). The SMF (for 5GS) can include the information when it sends an SM NAS message to the UE, or the SMF+PGW-C (for EPS) includes the information when it sends an SM-related NAS message to the UE via the MME.

[0489] When changing from UAV-C to another UAV-C or from TPAE to UAV-C, the USS can also provide the UE with information about the new UAV-C, including the application layer ID of the UAV-C (which can be interpreted as user information or pilot information), layer-2 ID, etc. When changing to TPAE, information about the TPAE can be provided to the UE, such as including the application layer ID of the TPAE (which can be interpreted as user information or pilot information or official information), layer-2 ID, etc.

[0490] The UE can form a PC5 unicast link for the C2 connection with the new UAV-C or TPAE based on the information included in the SM NAS message received from the SMF or the SM-related NAS message from the network / MME to the UE. It can also release the PC5 unicast link for the existing C2 connection.

[0491] In the above operations a) and b), if the procedures / actions related to C2 communication via Uu are not required, the procedures / actions can be skipped.

[0492] 4. Fourth example of the present disclosure

[0493] An example is described where the core network provides the base station with information on whether C2 communication via PC5 is authorized in case of failure or revocation of authorization for C2 communication via Uu (or authorization with the USS / network).

[0494] When the authorization for C2 communication on Uu fails (i.e., is unsuccessful), or when the C2 connection based on Uu is revoked, or when the PDU session / QoS flow for C2 communication based on Uu is released, or when the PDN connection / bearer for C2 communication based on Uu is released, the core network can provide one or more of the following information to the base station. This information can be provided in various forms, including combination, explicit, implicit, etc.:

[0495] (A) Information related to non-authorization of C2 communication based on PC5

[0496] (B) Information related to non-permission of C2 communication based on PC5

[0497] (C) Information requesting that resources are not allocated for C2 communication based on PC5. The resource can be radio resources.

[0498] Assume that the UE associated with the above information is a UAV. However, this is only for illustrative purposes, and the UE associated with the above information can be a UAV-C or both a UAV and a UAV-C.

[0499] The method by which the core network provides the base station with the above information (e.g., one or more of (A) to (C)) can be based on one or more of the following:

[0500] - The SMF can include the above information in the N2 message / information (or in the form of an N2 message / information) and send it to the base station via the AMF.

[0501] - The SMF provides information to the AMF, and the AMF sends it to the base station. The SMF providing the above information to the AMF can also be in the form of an event notification.

[0502] - The SMF + PGW-C provides the above information to the MME, and the MME can send it to the base station.

[0503] - The SMF requests the UDM to provide the above information or notifies the AMF of the above information. The UDM then provides / notifies the AMF with the above information that the AMF can send to the base station. In this case, the UDM can also provide / notify the AMF with information about the corresponding UE of the UE (i.e., if the UE is a UAV, it is the UAV-C, or if the UE is a UAV, it is the UAV), so that the AMF can send it to the base station. Information about the neighboring UEs of the UE can be based on subscriber information.

[0504] When the base station receives the above information from the core network, the base station can decide not to allocate / provide the radio resources required for PC5-based C2 communication (or PC5 communication, direct communication) to the UE under discussion.

[0505] In the first to fourth examples of the present disclosure described above based on various examples, a method for supporting C2 communication using the PC5 interface is described in combination with the execution of Uu-based C2 communication authorization. The description of the present disclosure regarding C2 communication using the PC5 interface can also be applied to the case of performing Uu-based C2 communication reauthorization.

[0506] In Examples 1 to 4 of the present disclosure previously described with reference to various examples, the operations associated with PC5-based C2 communication can also be interpreted as including PC5 operations for performing such operations or other PC5 operations associated therewith (e.g., direct discovery).

[0507] The following drawings are intended to illustrate specific embodiments of the present disclosure. The designation of specific devices shown in the drawings or the designation of specific signals / messages / fields are only for illustrative purposes, and the technical features of this specification are not limited to the specific designations used in the following drawings.

[0508] Figure 15 An example of a process according to an embodiment of the present disclosure is illustrated.

[0509] Note that Figure 15 the process shown is only illustrative, and the scope of the present disclosure is not limited to Figure 15 the examples in. For example, Figure 15 the UE, SMF, and USS shown in can perform Figure 1 the operations described in the examples of or Figure 14 the examples described in. It is worth noting that Figure 15Examples of AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc. are not shown, but this is for illustrative purposes only. That is, even in an embodiment based on Figure 15 AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc. can also perform the operations described in various examples of the present disclosure.

[0510] For example, for the example of Figure 15 the operations described in the example of Figures 1 to 14 can also be applied. For example, even if behaviors, content, etc. are not directly illustrated in the example of Figure 15 the behaviors, content, etc. illustrated in various examples of the present disclosure can still be applied.

[0511] In step S1501, the UE (e.g., UAV) may send a request message to the SMF. For example, the UE may request authorization for direct C2 communication from the UAV-C. For example, the request message sent by the UE may include information that it is requesting authorization for direct C2 communication. For example, the authorization request message may include C2 aviation payload information, which may include information that the information is for authorization of direct C2 communication.

[0512] In step S1502, the SMF may send an authorization request message to the USS. For example, the SMF may send an authorization-related message to the USS via the UAS NF / NEF. The authorization request message sent by the SMF may be, for example, the Nnef_Authentication_AuthenticateAuthorize message. The SMF sends this request message to the UAS NF / NEF, and the UAS NF / NEF may generate this request message into a Naf_Authentication_AuthenticateAuthorize request message and send it to the USS.

[0513] Step S1503: The USS sends an authorization response message to the SMF. Here, the authorization response message can be, for example, a Naf_Authentication_AuthenticateAuthorize response message. If the USS has successfully performed direct C2 authorization, the USS can send an authorization response message to the SMF, and the authorization response message includes the application layer ID of UAV-C. The application layer ID of UAV-C can be passed to the UE. For example, the Naf_Authentication_AuthenticateAuthorize response message sent by the USS can include a C2 authorization payload, which can include direct C2 pairing information. The C2 pairing information can include the application layer identifier of UAV-C.

[0514] The SMF can send the application layer ID of the UAV to the UE.

[0515] If the USS fails to perform direct C2 authorization, the USS can send a response message including information that the direct C2 authorization has failed to the SMF. In this case, the SMF can send information to the UE notifying the UE not to perform C2 communication based on PC5.

[0516] In step S1504, the SMF can send information to the UE. For example, the SMF can send the application layer ID of UAV-C to the UE. The UE can configure the application layer ID of UAV-C as target user information. For example, the UE can configure the application layer ID of UAV-C as target user information and send a direct communication request message including the target user information to another UE (for example, UAV-C). This enables the UE to establish C2 communication with UAV-C via the PC5 reference point regarding UAV-C.

[0517] According to an embodiment of the present disclosure, in combination with setting whether to allow C2 communication based on PC5 according to the result of Uu-based C2 communication authorization, the following example behaviors can be performed. For example, according to the result of Uu-based C2 communication authorization (or authorization with the USS / network), it can be indicated and / or set whether the UE is allowed to perform C2 communication based on PC5. For example, the UE can perform Uu-based C2 communication authorization (or authorization with the USS / network) before performing C2 communication based on PC5. For example, according to the result of Uu-based C2 communication authorization (i.e., success or failure) and the instruction / setting information on whether the UE is allowed to perform C2 communication based on PC5, the UE can determine whether it is allowed to perform C2 communication based on PC5.

[0518] According to an embodiment of the present disclosure, in combination with setting whether to allow PC5-based C2 communication in response to performing the withdrawal of Uu-based C2 communication, the following example behaviors may be performed. For example, when performing the withdrawal of Uu-based C2 communication, it may be indicated or set whether the UE is allowed to perform PC5-based C2 communication. For example, the withdrawal of Uu-based C2 communication may be performed. For example, based on the indication / setting information regarding whether PC5-based C2 communication can be performed, the UE may determine whether it can perform / continue PC5-based C2 communication.

[0519] According to various examples of the present disclosure, the present disclosure may have various effects. For example, the authorization for performing C2 communication between a UAV and a UAV-C can be effectively performed. For example, the UAV may perform direct C2 communication by receiving information for direct C2 communication (i.e., information for forming a PC5 unicast link with the UAV-C) from the network via the C2 communication authorization process through Uu. For example, if the C2 communication via PC5 is authorized through the C2 communication authorization process via Uu (i.e., by performing authorization with the USS / network), the C2 communication via PC5 can be prevented from being performed if the C2 communication authorization process via Uu fails.

[0520] The effects that can be derived from specific examples of the present disclosure are not limited to the effects listed above. For example, there may be various technical effects that those of ordinary skill in the relevant art can understand or infer from the present disclosure. Therefore, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or inferred from the technical features of the present disclosure.

[0521] For reference, the operations of the terminals (e.g., UE, UAV, UAV-C, etc.) described in this specification may be implemented by the devices described above Figures 1 to 4 . For example, the terminal (e.g., UE) may be Figure 2 the first device 100 or the second device 200. For example, the operations of the terminals (e.g., UE) described herein may be processed by one or more processors 102 or 202. The operations of the terminals described herein may be stored in one or more memories 104 or 204 in the form of instructions / programs (e.g., instructions, executable code) executable by one or more processors 102 or 202. One or more processors 102 or 202 control one or more memories 104 or 204 and one or more transceivers 105 or 206, and may perform the operations of the terminals (e.g., UE) described herein by executing the instructions / programs stored in one or more memories 104 or 204.

[0522] In addition, instructions for performing operations of a terminal (e.g., UE) described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium in which they are recorded. The storage medium may be included in one or more memories 104 or 204. In addition, the instructions recorded in the storage medium may be executed by one or more processors 102 or 202 to perform operations of the terminal (e.g., UE) described in the disclosure of this specification.

[0523] For reference, operations of network nodes (e.g., AMF, SMF, UPF, PCF, USS, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc.) or base stations (e.g., (R)AN, NG-RAN, gNB, etc.) described herein may be implemented by the Figures 1 to 3 devices to be described below. For example, a network node or a base station may be Figure 2 the first device 100 or Figure 2 the second device 200. For example, operations of network nodes or base stations described herein may be processed by one or more processors 102 or 202. Operations of the terminal described herein may be stored in one or more memories 104 or 204 in the form of instructions / programs (e.g., instructions, executable code) executable by one or more processors 102 or 202. One or more processors 102 or 202 may perform operations of network nodes or base stations described herein by controlling one or more memories 104 or 204 and one or more transceivers 106 or 206 and executing the instructions / programs stored in one or more memories 104 or 204.

[0524] In addition, instructions for performing operations of network nodes or base stations described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium. The storage medium may be included in one or more memories 104 or 204. In addition, the instructions recorded in the storage medium are executed by one or more processors 102 or 202 to perform operations of network nodes or base stations.

[0525] Preferred embodiments have been described by way of example, but the disclosure of this specification is not limited to such specific embodiments, and thus may be modified, changed or improved.

[0526] In the above exemplary system, the method is described as a series of steps or blocks based on a flowchart, but is not limited to the order of the described steps. Some steps may occur in a different order or simultaneously with other steps described above. Additionally, those skilled in the art will understand that the steps shown in the flowchart are not exclusive and may include other steps, or one or more steps of the flowchart may be deleted without affecting the scope of the claims.

[0527] The claims described herein may be combined in various ways. For example, the technical features of the method claims of this specification may be combined and implemented as a device, and the technical features of the device claims of this specification may be combined and implemented as a method. Additionally, the technical features of the method claims of this specification and the technical features of the device claims of this specification may be combined and implemented as a device, and the technical features of the method claims of this specification and the technical features of the device claims of this specification may be combined and implemented as a method.

Claims

1. A method for performing communication, the method being performed by a Session Management Function (SMF) and comprising the following steps: Receiving, from a User Equipment (UE), information for requesting authorization for direct Command and Control (C2) communication; Sending an authorization request message to an Unmanned Aerial System (UAS) Service Supplier (USS); Based on the authorization for direct C2 communication being successful, receiving, from the USS, the application layer ID of an Unmanned Aerial Vehicle (UAV) Controller (UAV-C); and Sending the application layer ID of the UAV-C to the UE.

2. The method according to claim 1, wherein, the application layer ID of the UAV-C is used by the UE to establish a PC5-based unicast link.

3. The method according to claim 2, wherein, the application layer ID of the UAV-C is set as Target User Info.

4. The method according to claim 3, wherein, the UE sends a direct communication request message including the Target User Info.

5. The method according to any one of claims 1 to 4, wherein, the application layer ID of the UAV-C is included in direct C2 pairing information.

6. The method according to claim 5, wherein, the direct C2 pairing information is included in a Naf_Authentication_AuthenticateAuthorize response message sent by the USS.

7. The method according to any one of claims 1 to 6, wherein, the direct C2 communication refers to a direct C2 link established between the UAV Controller and the UAV via the PC5 reference point.

8. The method according to any one of claims 1 to 7, Based on the authorization for the direct C2 communication failing, sending, to the UE, information related to notifying that the direct C2 communication is not to be performed.

9. A Session Management Function (SMF) configured to operate in a wireless communication system, the SMF comprising: One or more transmitters and receivers; One or more processors; and One or more memories that are operably connectable to the one or more processors and store instructions, the instructions performing operations based on being executed by the one or more processors, the operations including the method according to any one of claims 1 to 8.

10. A method for performing communication, the method being performed by a User Equipment (UE) and comprising the following steps: Sending, to a Session Management Function (SMF), authorization request information for direct Command and Control (C2) communication, wherein the authorization request information is used by the SMF to send an authorization request message to an Unmanned Aerial System (UAS) Service Supplier (USS); and Receiving, from the SMF, the application layer ID of an Unmanned Aerial Vehicle (UAV) Controller (UAV-C), wherein the application layer ID of the UAV-C is sent to the UE by the USS via the SMF based on the authorization for the direct C2 communication being successful.

11. The method according to claim 10, the method further comprises the following steps: Establish a unicast link based on PC5 based on the application layer ID of the UAV-C.

12. The method according to claim 11, the method further comprises the following steps: Send a direct communication request message to the UAV-C including target user information set to the application layer ID of the UAV-C.

13. The method according to any one of claims 10 to 12, wherein, The direct C2 communication refers to a direct C2 link established between the UAV controller and the UAV via the PC5 reference point.

14. The method according to any one of claims 10 to 13, the method further comprises the following steps: Receive information related to notifying non-execution of the direct C2 communication from the SMF.

15. A user equipment UE configured to operate in a wireless communication system, the UE comprises: One or more transceivers; One or more processors; and One or more memories, the one or more memories being operably connectable to the one or more processors and storing instructions, the instructions performing operations based on being executed by the one or more processors, the operations including the method according to any one of claims 10 to 14.

16. A device in mobile communication, At least one processor; and At least one memory, the at least one memory being operably connectable to the at least one processor and storing instructions, the instructions performing operations based on being executed by the at least one processor, the operations comprise: Send authorization request information for direct command and control C2 communication to a session management function SMF, wherein, the authorization request information is used by the SMF to send an authorization request message to an unmanned aerial system UAS service provider USS; and Receive the application layer ID of a UAV controller UAV-C from the SMF, wherein, the application layer ID of the UAV-C is sent to the UE by the USS via the SMF based on the authorization for the direct C2 communication being successful.

17. A non-transitory computer-readable medium storing instructions, The instructions, when executed by one or more processors, cause the one or more processors to: Send authorization request information for direct command and control C2 communication to a session management function SMF, wherein, The authorization request information is used by the SMF to send an authorization request message to an unmanned aerial system UAS service provider USS; and Receive the application layer ID of a UAV controller UAV-C from the SMF, wherein, the application layer ID of the UAV-C is sent to the UE by the USS via the SMF based on the authorization for the direct C2 communication being successful.

Images