Direct C2 Authentication

Abstract

One disclosure in the present specification includes a method for an SMF to perform communication, the method including the steps of receiving authentication request information for C2 communication directly from a UE, sending an authentication request message to a USS, receiving an application hierarchical ID of a UAV-C from the USS, and sending the application hierarchical ID of the UAV-C to the UE.

Description

[Technical Field]

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

[0002] The 3rd Generation Partnership Project (3GPP®) Long-Term Evolution (LTE) is a technology that enables high-speed packet communications. Many plans have been proposed for LTE, including those aimed at reducing user and provider costs, improving service quality, and expanding and improving coverage and system capacity. 3GPP LTE requires lower cost per bit, increased service availability, flexible use of frequency bands, simple architecture, open interfaces, and reasonable terminal power consumption as upper-level requirements.

[0003] The International Telecommunication Union (ITU) and 3GPP have initiated a task to develop requirements and specifications for a New Radio (NR) system. 3GPP must identify and develop the technical building blocks necessary to timely and successfully standardize a new Radio Access Technology (RAT) that meets all urgent market needs and the long-term requirements established in the ITU-R (International Mobile Telecommunications) International Mobile Telecommunications (IMT)-2020 process. NR must also use spectrum bands in the minimum and maximum 100 GHz range that can be used for wireless communications well into the distant future.

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

[0005] Uncrewed Aerial Systems (UAS) are being discussed in 5G. Command and Control (C2) communication can be performed between an Uncrewed Aerial Vehicle (UAV) and a UAV-Controller (UAV-C) based on the PC5 interface. However, no specific method for performing authorization for such C2 communication has been discussed so far. Summary of the Invention [Means for solving the problem]

[0006] In one aspect, a method for an SMF to perform communication is provided, the method including the steps of receiving authentication request information for C2 communication directly from a UE, sending an authentication request message to a USS, receiving an application hierarchical ID of a UAV-C from the USS, and sending the application hierarchical ID of the UAV-C to the UE.

[0007] In another aspect, an apparatus is provided that embodies the method.

[0008] In one aspect, a method for a UE to perform communication is provided, the method including: sending authentication request information for direct C2 communication to an SMF; and receiving an application layer ID of a UAV-C from the SMF.

[0009] In another aspect, an apparatus is provided that embodies the method. [Brief explanation of the drawings]

[0010] [Figure 1] 1 illustrates an example of a communication system in which implementations of the present disclosure may be applied. [Figure 2] 1 illustrates an example of a wireless device to which the implementations of this specification may be applied. [Figure 3] 1 illustrates an example of a UE to which the implementation of this specification applies. [Figure 4] 1 shows an example of a 5G system architecture to which the implementation of this specification is applied. [Figure 5] 1 shows an example of a PDU session establishment procedure to which the implementation of this specification applies. [Figure 6] 1 shows an example of a PDU session establishment procedure to which the implementation of this specification applies. [Figure 7] An example of a logical 5GS and EPS architecture for UAVs is shown. [Figure 8a] A procedure according to a first example of the first embodiment of the present disclosure will now be described. [Figure 8b] A procedure according to a first example of the first embodiment of the present disclosure will now be described. [Figure 9a] A procedure according to a second example of the first example of the disclosure of this specification will now be described. [Figure 9b] A procedure according to a second example of the first example of the disclosure of this specification will now be described. [Figure 10] A procedure according to a third example of the first example of the disclosure of this specification will now be described. [Figure 11] A fourth illustrative procedure of the first example of the present disclosure will now be described. [Figure 12] 1 illustrates a procedure for establishing a layer-2 link via a PC5 reference point according to one embodiment of the present disclosure. [Figure 13] 1 illustrates an example of a PDU session establishment procedure for C2 communication according to one embodiment of the present disclosure. [Figure 14]10 is an example of a PDN connection for C2 authentication according to one embodiment of the present disclosure. [Figure 15] 1 illustrates an example procedure according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following techniques, devices, and systems apply to various wireless multiple access systems. Examples of multiple access systems include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and multi-carrier frequency division multiple access (MC-FDMA) systems. CDMA is implemented over radio technologies such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA is implemented over radio technologies such as global system for mobile communications (GSM), general packet radio service (GPRS), or enhanced data rates for GSM evolution (EDGE). OFDMA is implemented over radio technologies such as IEEE (Institute of Electrical and Electronics Engineers) 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). 3GPP (3rd generation partnership project) LTE (long-term evolution) is part of evolved UMTS (E-UMTS) that uses E-UTRA. 3GPP LTE uses OFDMA on the downlink (DL) and SC-FDMA on the uplink (UL).Evolution of 3GPP LTE includes LTE-A (advanced), LTE-A Pro, and / or 5G NR (New Radio).

[0012] For convenience of explanation, the implementation of this specification will be mainly described in relation to a 3GPP-based wireless communication system. However, the technical characteristics of this specification are not limited thereto. For example, the following detailed description will be provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of this specification that are not limited to a 3GPP-based wireless communication system can be applied to other mobile communication systems.

[0013] For terms and technologies used in this specification that are not specifically described, reference may be made to wireless communication standard documents published prior to this specification.

[0014] As used herein, "A or B" can mean "only A," "only B," or "both A and B." Also, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B, and C."

[0015] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Thus, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0016] As used herein, "at least one of A and B" can mean "only A," "only B," or "both A and B." Additionally, as used herein, the expressions "at least one of A or B" and "at least one of A and / or B" can be interpreted as "at least one of A and B."

[0017] Furthermore, in this specification, "at least one of A, B and C" can mean "only A," "only B," "only C," or "any combination of A, B and C." Furthermore, "at least one of A, B or C" or "at least one of A, B and / or C" can mean "at least one of A, B and C."

[0018] Furthermore, parentheses used in this specification may mean "for example." Specifically, when "control information (PDCCH)" is used, "PDCCH" is proposed as an example of "control information." Furthermore, "control information" in this specification is not limited to "PDCCH," and "PDDCH" is proposed as an example of "control information." Furthermore, when "control information (i.e., PDCCH)" is used, "PDCCH" is proposed as an example of "control information."

[0019] In this specification, technical features individually described in one drawing may be embodied individually or simultaneously.

[0020] Without limitation, the various descriptions, functions, procedures, suggestions, methods and / or operational flow diagrams disclosed herein may be applied to various fields where device-to-device wireless communication and / or connectivity (e.g., 5G) is required.

[0021] The present specification will now be described in more detail with reference to the drawings, in which like reference numerals in the following drawings and / or description may refer to like or corresponding hardware, software and / or functional blocks unless otherwise indicated.

[0022] FIG. 1 shows an example of a communication system in which the implementation of this specification may be applied.

[0023] The 5G usage scenarios shown in FIG. 1 are merely examples, and the technical features of this specification apply to other 5G usage scenarios not shown in FIG. 1.

[0024] The three main requirement categories for 5G are (1) enhanced mobile broadband (eMBB), (2) massive machine type communication (mMTC), and (3) ultra-reliable and low latency communications (URLLC).

[0025] 1, a communication system (1) includes wireless devices 100a to 100f, a base station (BS; 200), and a network 300. While FIG. 1 illustrates a 5G network as an example of the network of the communication system (1), implementation in this specification is not limited to the 5G system and is also applicable to future communication systems beyond the 5G system.

[0026] The base station 200 and network 300 are implemented with wireless devices, and a particular wireless device can act as a base station / network node in relation to other wireless devices.

[0027] The wireless devices 100a to 100f are devices that communicate using a radio access technology (RAT) (e.g., 5G NR or LTE) and may also be referred to as communication / wireless / 5G devices. The wireless devices 100a to 100f may include, but are not limited to, a robot 100a, vehicles 100b-1 and 100b-2, an extended reality (XR) device 100c, a portable device 100d, a home appliance 100e, an Internet-of-Things (IoT) device 100f, and an artificial intelligence (AI) device / server 400. For example, vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of inter-vehicle communication. Vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices can include Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR) devices, and are implemented in the form of head-mounted devices (HMDs) and head-up displays (HUDs) worn on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. Portable devices include smartphones, smart pads, wearable devices (e.g., smart watches or smart glasses), and computers (e.g., laptops). Home appliances include TVs, refrigerators, and washing machines. IoT devices include sensors and smart meters.

[0028] In this specification, the wireless devices 100a to 100f may be referred to as user equipment (UE). Examples of UE include a mobile phone, a smartphone, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, an autonomous vehicle, a connected automobile, a UAV, an AI module, a robot, an AR device, a VR device, a MR device, a hologram 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 5G service-related device, or a Fourth Industrial Revolution-related device.

[0029] The wireless devices 100a to 100f are connected to a network 300 via a base station 200. AI technology can be applied to the wireless devices 100a to 100f, and the wireless devices 100a to 100f are connected to an AI server (400) via the network 300. The network 300 is configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, or a network beyond 5G. The wireless devices 100a to 100f can communicate with each other via the base station 200 / network 300, but can also communicate directly (e.g., sidelink communication) without going through the base station 200 / network 300. For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., V2V (vehicle-to-vehicle) / V2X (vehicle-to-everything) communication). Furthermore, an IoT device (for example, a sensor) can directly communicate with another IoT device (for example, a sensor) or another wireless device 100a to 100f.

[0030] Wireless communications / connections 150a, 150b, and 150c are established between wireless devices 100a-100f and / or between wireless devices 100a-100f and base station 200 and / or between base stations 200. Here, the wireless communications / connections are established via various RATs (e.g., 5G NR) such as uplink / downlink communications 150a, sidelink communications 150b (or device-to-device (D2D) communications), and inter-base station communications 150c (e.g., relaying, integrated access and backhaul (IAB)). Through the wireless communications / connections 150a, 150b, and 150c, wireless devices 100a-100f and base station 200 can transmit / receive wireless signals to / from each other. For example, the wireless communications / connections 150a, 150b, and 150c can transmit / receive signals via various physical channels. To this end, based on the various proposals in this specification, at least some of the processes of setting various configuration information for transmitting / receiving wireless signals, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and resource allocation processes are performed.

[0031] NR supports multiple numerologies or subcarrier spacings (SCS) to support various 5G services. For example, a 15 kHz SCS supports wide areas in traditional cellular bands, a 30 kHz / 60 kHz SCS supports dense urban areas, lower latency, and wider carrier bandwidths, and a 60 kHz or higher SCS supports bandwidths greater than 24.25 GHz to overcome phase noise.

[0032] The NR frequency band can be defined as two types of frequency ranges (FR1 and FR2). The values ​​of the frequency ranges can be changed. For example, the two types of frequency ranges (FR1 and FR2) are shown in Table 1 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 can mean the "sub 6 GHz range" and FR2 can mean the "above 6 GHz range" and can be called millimeter wave (mmW).

[0033] [Table 1]

[0034] As mentioned above, the numerical values ​​of the frequency range of the NR system can be changed. For example, FR1 can include the band from 410 MHz to 7125 MHz as shown in Table 2 below. That is, FR1 can include frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included in FR1 can include unlicensed bands. Unlicensed bands can be used for various purposes, such as communications for vehicles (e.g., autonomous driving).

[0035] [Table 2]

[0036] Here, the wireless communication technology implemented in the wireless device of this specification may include not only LTE, NR, and 6G, but also narrowband IoT (NB-IoT) for low-power communication. For example, NB-IoT technology is an example of low-power wide area network (LPWAN) technology and may be implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-mentioned names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of this specification may perform communication based on LTE-M technology. For example, LTE-M technology is an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced MTC). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE MTC, and / or 7) LTE M, and is not limited to the above-mentioned names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of this specification may include at least one of ZigBee (registered trademark), Bluetooth (registered trademark), and / or LPWAN, which consider low-power communication, but are not limited to the above names. For example, ZigBee technology can create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and may be called by various names.

[0037] FIG. 2 shows an example of a wireless device to which the implementation of this specification may be applied.

[0038] 2, the first wireless device 100 and / or the second wireless device 200 may be embodied in various forms depending on the use case / service. For example, {the first wireless device 100 and the second wireless device 200} may correspond to at least one of {the wireless devices 100a-100f and the base station 200}, {the wireless devices 100a-100f and the wireless devices 100a-100f}, and / or {the base station 200 and the base station 200} in FIG. 1. The first wireless device 100 and / or the second wireless device 200 may be configured with various components, devices / parts, and / or modules.

[0039] First wireless device 100 may include at least one transceiver, such as transceiver 106 , at least one processing chip, such as processing chip 101 , and / or one or more antennas 108 .

[0040] 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, memory 104 may be located external to processing chip 101.

[0041] The processor 102 may control the memory 104 and / or the transceiver 106 and may be configured to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed herein. For example, the processor 102 may process information in the memory 104 to generate first information / signals and transmit a wireless signal including the first information / signals via the transceiver 106. The processor 102 may receive a wireless signal including second information / signals via the transceiver 106 and store information obtained by processing the second information / signals in the memory 104.

[0042] The memory 104 may be operatively coupled 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 that, when executed by the processor 102, embodies code, instructions, and / or collections of instructions that perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. For example, the firmware and / or software code 105 may embodi instructions that, when executed by the processor 102, perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. For example, the firmware and / or software code 105 may control the processor 102 to implement one or more protocols. For example, the firmware and / or software code 105 may control the processor 102 to implement one or more air interface protocol layers.

[0043] Here, the processor 102 and memory 104 are part of a communications modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver 106 is connected to the processor 102 and can transmit and / or receive wireless signals via one or more antennas 108. Each transceiver 106 can include a transmitter and / or a receiver. The transceiver 106 is used interchangeably with an RF (radio frequency) unit. In this specification, the first wireless device 100 can refer to a communications modem / circuit / chip.

[0044] Second wireless device 200 may include at least one transceiver, such as transceiver 206 , at least one processing chip, such as processing chip 201 , and / or one or more antennas 208 .

[0045] Processing chip 201 may include at least one processor, such as processor 202, and at least one memory, such as memory 204. Additionally and / or alternatively, memory 204 may be located external to processing chip 201.

[0046] Processor 202 may control memory 204 and / or transceiver 206 and may be configured to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed herein. For example, processor 202 may process information in memory 204 to generate third information / signal and transmit a wireless signal including the third information / signal via transceiver 206. Processor 202 may receive a wireless signal including fourth information / signal via transceiver 206 and store the information obtained by processing the fourth information / signal in memory 204.

[0047] Memory 204 may be operatively coupled to processor 202. Memory 204 may store various types of information and / or instructions. Memory 204 may store firmware and / or software code 205 that, when executed by processor 202, embodies code, instructions, and / or collections of instructions that perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. For example, firmware and / or software code 205 may embodi instructions that, when executed by processor 202, perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. For example, firmware and / or software code 205 may control processor 202 to implement one or more protocols. For example, firmware and / or software code 205 may control processor 202 to implement one or more air interface protocol layers.

[0048] Here, the processor 202 and memory 204 are part of a communications modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver 206 is connected to the processor 202 and can transmit 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 is used interchangeably with an RF unit. In this specification, the second wireless device 200 can refer to a communications modem / circuit / chip.

[0049] The hardware elements of the wireless devices 100, 200 will be described in more detail below. Without limitation, one or more protocol layers may be implemented by one or more processors 102, 202. For example, one or more processors 102, 202 may implement one or more layers (e.g., functional layers such as a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) layer, and a service data adaptation protocol (SDAP) layer). The one or more processors 102, 202 may 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 operational flow charts disclosed herein. The one or more processors 102, 202 can generate and provide signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein to the one or more transceivers 106, 206. The one or more processors 102, 202 can receive signals (e.g., baseband signals) from the one or more transceivers 106, 206 and obtain the PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein.

[0050] The one or more processors 102, 202 may be referred to as a controller, microcontroller, microprocessor, and / or microcomputer. The one or more processors 102, 202 may be implemented using hardware, firmware, software, and / or a combination thereof. For example, the one or more processors 102, 202 may include one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), and / or one or more field programmable gate arrays (FPGAs). For example, the one or more processors 102, 202 may include a collection of a communication control processor, an application processor (AP), an electronic control unit (ECU), a central processing unit (CPU), a graphic processing unit (GPU), and a memory control processor. One or more memories 104, 204 may be coupled to one or more processors 102, 202 and may store various types of data, signals, messages, information, programs, code, instructions, and / or commands. The one or more memories 104, 204 may be comprised of Random Access Memory (RAM), Dynamic RAM (DRAM), Read-Only Memory (ROM), Erasable Programmable ROM (EPROM), flash memory, volatile memory, non-volatile memory, hard drives, registers, cache memory, computer-readable storage media, and / or combinations thereof. The one or more memories 104, 204 may be located internal and / or external to the one or more processors 102, 202.Additionally, one or more memories 104, 204 may be coupled to one or more processors 102, 202 via various techniques, such as wired or wireless coupling.

[0051] One or more transceivers 106, 206 can transmit user data, control information, wireless signals / channels, etc., as referenced in the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed herein to one or more other devices. One or more transceivers 106, 206 can receive user data, control information, wireless signals / channels, etc., as referenced in the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed herein from one or more other devices. For example, one or more transceivers 106, 206 can be coupled to one or more processors 102, 202 and can transmit and receive wireless signals. For example, one or more processors 102, 202 can control one or more transceivers 106, 206 to transmit user data, control information, wireless signals, etc., to one or more other devices. Also, one or more processors 102, 202 can control one or more transceivers 106, 206 to receive user data, control information, wireless signals, etc., from one or more other devices.

[0052] One or more transceivers 106, 206 may be coupled with one or more antennas 108, 208. Additionally and / or alternatively, one or more transceivers 106, 206 may include one or more antennas 108, 208. The one or more transceivers 106, 206 may be configured to transmit or receive user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, suggestions, methods, and / or operational flow charts disclosed herein via the one or more antennas 108, 208. As used herein, the one or more antennas 108, 208 may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

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

[0054] 2, the wireless devices 100, 200 may further include additional components. The additional components 140 may be configured in various ways depending on the type of the wireless devices 100, 200. For example, the additional components 140 may include at least one of a power unit / battery, an input / output (I / O) device (e.g., an audio I / O port, a video I / O port), a drive unit, and a computing device. The additional components 140 may be connected to one or more processors 102, 202 via various techniques, such as a wired or wireless connection.

[0055] In the implementations herein, a UE can operate from an uplink (UL) to a transmitter and from a downlink (DL) to a receiver. In the implementations herein, a base station can operate from the UL to a receiver and from the DL to a transmitter. For convenience of explanation, the following description primarily assumes that a first wireless device 100 operates as a UE and a second wireless device 200 operates as a base station. For example, a processor 102 coupled to, mounted on, or released in the first wireless device 100 is configured to perform UE operations in accordance with the implementations herein or to control a transceiver 106 to perform UE operations in accordance with the implementations herein. A processor 202 coupled to, mounted on, or released in the second wireless device 200 is configured to perform base station operations in accordance with the implementations herein or to control a transceiver 206 to perform base station operations in accordance with the implementations herein.

[0056] In this specification, a base station may be referred to as a Node B, an eNode B (eNB), or a gNB.

[0057] FIG. 3 shows an example of a UE to which the implementation of this specification may be applied.

[0058] Referring to FIG. 3, a UE 100 may correspond to the first wireless device 100 of FIG.

[0059] 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 SIM (Subscriber Identification Module) card 145, a speaker 146, and a microphone 147.

[0060] The processor 102 may be configured to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flow charts disclosed herein. The processor 102 may be configured to control one or more other components of the UE 100 to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flow charts disclosed herein. A layer of an air interface protocol may be embodied in the processor 102. The processor 102 may include an ASIC, other chipset, logic circuit, and / or data processing device. The processor 102 is an application processor. The processor 102 may include at least one of a DSP, a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). Examples of the processor 102 include the SNAPDRAGON® series processors made by Qualcomm®, the EXYNOS® series processors made by Samsung®, the A series processors made by Apple®, and the HELIO® processors made by MediaTek®. TM ATOM series processors, made by Intel® TM It can be found in the series processors or the corresponding next-generation processors.

[0061] Memory 104 is operatively coupled to processor 102 and stores various information for operating processor 102. Memory 104 may include ROM, RAM, flash memory, a memory card, a storage medium, and / or other storage devices. When implemented in software, the techniques described herein may be implemented using modules (e.g., procedures, functions, etc.) that execute the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. The modules may be stored in memory 104 and executed by processor 102. Memory 104 may be implemented within processor 102 or external to processor 102, in which case it may be communicatively coupled to processor 102 via various methods known in the art.

[0062] The transceiver 106 is operatively coupled to the processor 102 to transmit and / or receive radio signals. The transceiver 106 includes a transmitter and a receiver. The transceiver 106 may include baseband circuitry for processing radio frequency signals. The transceiver 106 controls one or more antennas 108 to transmit and / or receive radio signals.

[0063] The power management module 141 manages the power supply of the processor 102 and / or the transceiver 106. The battery 142 supplies power to the power management module 141.

[0064] The display 143 outputs the results processed by the processor 102. The keypad 144 receives input for use by the processor 102. The keypad 144 can be displayed on the display 143.

[0065] The SIM card 145 is an integrated circuit for securely storing an International Mobile Subscriber Identity (IMSI) and associated keys used to identify and authenticate a subscriber to a mobile device such as a cell phone or computer. Many SIM cards can also store contact information.

[0066] A speaker 146 outputs sound-related results processed by the processor 102. A microphone 147 receives sound-related input for use by the processor 102.

[0067] FIG. 4 shows an example of a 5G system architecture to which the implementation of this specification may be applied.

[0068] The 5G system (5GS) structure consists of the following network functions (NFs):

[0069] -AUSF(Authentication Server Function)

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

[0071] -DN (Data Network), such as operator services, Internet connection or other company services

[0072] -USDF(Unstructured Data Storage Function)

[0073] -NEF (Network Exposure Function)

[0074] -I-NEF (Intermediate NEF)

[0075] -NRF(Network Repository Function)

[0076] -NSSF(Network Slice Selection Function)

[0077] -PCF (Policy Control Function)

[0078] -SMF(Session Management Function)

[0079] -UDM (Unified Data Management)

[0080] -UDR (Unified Data Repository)

[0081] -UPF (User Plane Function)

[0082] -UCMF(UE radio Capability Management Function)

[0083] -AF (Application Function)

[0084] -UE (User Equipment)

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

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

[0087] -NWDAF(Network Data Analytics Function)

[0088] -CHF (Charging Function)

[0089] Additionally, the following network functions can be considered:

[0090] -N3IWF (Non-3GPP Inter Working Function)

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

[0092] -W-AGF(Wireline Access Gateway Function)

[0093] Figure 4 shows the 5G system architecture for the non-roaming case using a reference point representation that shows how various network functions interact with each other.

[0094] For clarity of the point-to-point diagram in Figure 4, the UDSF, NEF, and NRF are not illustrated, but all of the network functions shown can interact with the UDSF, UDR, NEF, and NRF as needed.

[0095] For clarity, the connections between the UDR and other NFs (e.g., PCFs) are not shown in Figure 4. For clarity, the connections between the NWDAF and other NFs (e.g., PCFs) are not shown in Figure 4.

[0096] The 5G system structure includes the following reference points:

[0097] N1: Reference point between UE and AMF.

[0098] -N2: (R) Reference point between AN and AMF.

[0099] -N3: Reference point between (R)AN and UPF.

[0100] - N4: Reference point between SMF and UPF.

[0101] N6: Reference point between the UPF and the data network.

[0102] - N9: Reference point between two UPFs.

[0103] The following reference points indicate the interactions that exist between NF services in an NF:

[0104] -N5: Reference point between PCF and AF.

[0105] - N7: Reference point between SMF and PCF.

[0106] -N8: Reference point between UDM and AMF.

[0107] -N10: Reference point between UDM and SMF.

[0108] - N11: Reference point between AMF and SMF.

[0109] -N12: Reference point between AMF and AUSF.

[0110] -N13: Reference point between UDM and AUSF.

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

[0112] N15: Reference point between the PCF and AMF in non-roaming scenarios, and between the PCF and AMF of the visited network in roaming scenarios.

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

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

[0115] In some cases, two NFs may be interconnected to serve a UE.

[0116] The PDU session establishment procedure is described in Section 4.3.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0117] 5 and 6 show an example of a PDU session establishment procedure to which the implementation of this specification is applied.

[0118] PDU session establishment applies to:

[0119] - UE-initiated PDU session establishment procedure

[0120] UE-disclosed 3GPP to non-3GPP PDU session handover

[0121] -PDU session handover to 5GS in EPS disclosed by UE

[0122] -Network-triggered PDU session establishment procedure

[0123] A PDU session can (a) be associated with a single connection type at a given time, i.e., either a 3GPP connection or a non-3GPP connection, or (b) be associated with multiple connection types simultaneously, i.e., one 3GPP connection and one non-3GPP connection. A PDU session associated with multiple connection types is called a multiaccess (MA) PDU session and can be requested by an access traffic steering, switching, and splitting (ATSSS)-supported UE.

[0124] 5 and 6 show the procedure for establishing a PDU session associated with a single connection type at a given time.

[0125] In the procedures shown in Figures 5 and 6, it is assumed that the AMF has already retrieved the user subscription data in the UDM unless the UE is urgently registered because the UE is already registered to the AMF.

[0126] First, the procedure in FIG. 5 will be explained.

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

[0128] The UE initiates the PDU session establishment procedure requested by the UE by sending an NAS message containing a PDU session establishment request message in an N1SM container. The PDU session establishment request message includes a PDU session ID, a requested PDU session type, a requested session and service continuity (SSC) mode, 5GSM capabilities, Protocol Configuration Options (PCO), an SM PDU DN Request Container, and a UE Integrity Protection Maximum Data Rate.

[0129] If the PDU session establishment is a request to establish a new PDU session, the request type indicates "Initial Request". If the request refers to an existing PDU session that is being switched between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing PDN (packet data network) 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 refers to an existing PDU session for an emergency service that is being switched between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing PDN connection for an emergency service in the EPC, the request type indicates "Existing Emergency PDU session".

[0130] The UE includes the S-NSSAI from the allowed NSSAI of the current connection type. If the Mapping of Allowed NSSAI is provided to the UE, the UE provides both the S-NSSAI of the VPLMN (visited VPLMN) from the allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the mapping of allowed NSSAI.

[0131] (2) Step 2: The AMF selects an SMF. If the request type indicates "initial request" or the request is for handover from an EPS or other non-3GPP connection provided by an AMF, the AMF stores not only the connection type of the PDU session, but also the S-NSSAI(s) associated with it, the DNN (Data Network name), the PDU session ID, and the SMF ID.

[0132] If the request type is "initial request" and a previous PDU session ID indicating an existing PDU session is also included in the message, the AMF selects an SMF and stores the new PDU session ID, S-NSAI(s), and connection for the selected SMF ID.

[0133] If the request type indicates "existing PDU session", the AMF selects an SMF based on the SMF-ID received in the UDM. The AMF updates the stored connection type for the PDU session.

[0134] If the request type indicates "existing PDU session" referring to an existing PDU session moving between a 3GPP connection and a non-3GPP connection, and if the serving PLMNS-NSSAI of the PDU session is present in the authorization NSSAI of the target connection type, the PDU session establishment procedure may be performed if:

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

[0136] - if the SMF ID corresponding to the PDU session ID belongs to the HPLMN;

[0137] If not, the AMF rejects the PDU session establishment request with an appropriate rejection cause.

[0138] The AMF rejects requests from emergency registered UEs whose request type does not indicate "emergency request" or "existing emergency PDU session".

[0139] (3) Step 3: If the AMF is not associated with an SMF for the PDU session ID provided in the UE (e.g., when the request type indicates "initial request"), the AMF invokes the create SM context request procedure (e.g., Nsmf_PDU session_CreateSMContextRequest). If the AMF is already associated with an SMF for the PDU session ID provided in the UE (e.g., when the request type indicates "existing PDU session"), the AMF invokes the update SM context request procedure (e.g., Nsmf_PDU session_UpdateSMContextRequest).

[0140] The AMF sends the S-NSSAI of the serving PLMN from the allowed NSSAI to the SMF. For local break out (LBO) roaming scenarios, the AMF also sends the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAI to the SMF.

[0141] The AMF ID is the UE's GUAMI and uniquely identifies the AMF serving the UE. The AMF transmits the PDU session ID along with the N1SM container containing the PDU session establishment request message received from the UE. The GPSI (generic public subscription identifier) ​​is included if available in the AMF.

[0142] If a UE in limited service state does not provide a SUPI and is registered for emergency services, the AMF provides a PEI instead of the SUPI. If a UE in limited service state provides a SUPI and is registered for emergency services but is not authenticated, the AMF indicates that the SUPI is not authenticated. If the SMF does not receive a SUPI from the UE or the AMF indicates that the SUPI is not authenticated, the UE is determined to be not authenticated.

[0143] The AMF can include a PCF ID in the Nsmf_PDU session_CreateSMContext, which identifies the H-PCF (home PCF) in the non-roaming case and the V-PCF (visited PCF) in the LBO roaming case.

[0144] (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 can retrieve the session management subscription data in the UDM and be notified when this subscription data is modified.

[0145] (5) Step 5: The SMF sends a create SM context response message (e.g., Nsmf_PDU session_CreateSMContextResponse) or an update SM context response message (e.g., Nsmf_PDU session_UpdateSMContextResponse) to the AMF according to the request received in step 3.

[0146] If the SMF receives the Nsmf_PDU session_CreateSMContextRequest in step 3 and is able to process the PDU session establishment request, the SMF creates an SM context and responds to the AMF by providing an SM context ID.

[0147] If the SMF decides not to accept the PDU session establishment, it rejects the UE request via a NASSM signal containing the associated SM rejection cause by responding to the AMF with an Nsmf_PDU session_CreateSMContextResponse. The SMF also indicates to the AMF that the PDU session ID is considered to be released and the PDU session establishment procedure is aborted, in which case the SMF proceeds to step 20 below.

[0148] (6) Step 6: Selective secondary authentication / authorization is performed.

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

[0150] (7b) Step 7b: The SMF executes the SM policy association establishment procedure to establish an SM policy association with the PCF, and the basic PCC rules for the PDU session are obtained.

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

[0152] (9) Step 9: The SMF can provide information on the policy control request trigger conditions that have been met by performing the SMF-disclosed SM policy-related modification procedures.

[0153] (10) Step 10: If the request type indicates an "initial request", the SMF may initiate the N4 Session Establishment procedure with the selected UPF. Otherwise, the SMF may initiate the N4 Session Modification procedure with the selected UPF.

[0154] In step 10a, the SMF can send an N4 session establishment / modification request to the UPF, providing packet detection, execution, and reporting rules established in the UPF for the PDU session. In step 10b, the UPF can send and confirm an N4 session establishment / modification response.

[0155] (11) Step 11: The SMF sends an N1N2 message transfer message (e.g., Namf_Communication_N1N2MessageTransfer) to the AMF.

[0156] The N1N2 message transfer message can contain N2 SM information. The N2 SM information follows the information transmitted by the AMF to the (R)AN.

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

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

[0159] PDU Session ID: Indicates to the UE the association between RAN resources and PDU sessions for the UE;

[0160] - S-NSSAI with the value for the serving PLMN (i.e. HPLMNS-NSSAI, or VPLMNS-NSSAI in case of LBO roaming);

[0161] - User plane security enforcement information determined by the SMF;

[0162] -UE integrity protection maximum data rate received in the PDU session establishment request message: If integrity protection is indicated as "Preferred" or "Required" in the user plane security execution information

[0163] -RSN (redundancy sequence number) parameter

[0164] The N1N2 messaging message may include an N1SM container. The N1SM container includes a PDU Session Establishment Accept message that the AMF provides to the UE. The PDU Session Establishment Accept message includes the S-NSSAI from the authorized NSSAI. In the case of an LBO roaming scenario, the PDU Session Establishment Accept message includes the S-NSSAI from the authorized NSSAI for the VPLMN and also includes the corresponding S-NSSAI for the HPLMN from the mapping of the authorized NSSAI received by the SMF in step 3.

[0165] For QoS flows associated with a QoS rule and a QoS profile, multiple QoS rules, QoS flow levels, and QoS parameters may be included in the PDU session establishment accept message and N2 SM information in the N1 SM container, if necessary.

[0166] If the PDU session establishment fails between step 5 and step 11, the N1N2 message transfer message contains an N1 SM container containing a PDU session establishment reject message and no N2 SM information. The (R)AN sends a NAS message containing a PDU session establishment reject message to the UE. In this case, steps 12-17 below are omitted.

[0167] (12) Step 12: The AMF sends a NAS message including the PDU session ID and PDU session establishment accept message towards the UE and the N2 SM information received from the SMF in an N2 PDU session request message to the (R)AN.

[0168] (13) Step 13: The (R)AN may perform AN-specific signaling exchange with the UE related to the information received in the SMF. For example, in the case of NG-RAN, the UE may perform RRC connection reconfiguration with the UE to configure the necessary NG-RAN resources related to the QoS rules for the PDU session request received in step 12.

[0169] The (R)AN conveys the received NAS message (PDU Session ID, N1 SM Container (PDU Session Establishment Accept Message)) to the UE in step 12. The (R)AN provides the NAS message to the UE only if the AN-specific signaling exchange with the UE includes an (R)AN resource addition related to the received N2 command.

[0170] If the N2 SM information is not included in step 11, the following steps 14 to 16b and step 17 are omitted.

[0171] The procedure of FIG. 6, which follows the procedure of FIG. 5, will now be described.

[0172] (14) Step 14: The (R)AN sends an N2 PDU session response message to the AMF. The N2 PDU session response message may include a PDU session ID, a cause, N2 SM information (PDU session ID, AN tunnel information, accepted / rejected QFI list, user plane execution policy notification), etc.

[0173] (15) Step 15: The AMF sends an update SM context request message (e.g., Nsmf_PDU session_UpdateSMContextRequest) to the SMF. The AMF conveys the N2 SM information received from the (R)AN to the SMF.

[0174] (16a) Step S16a: The SMF initiates the N4 session modification procedure with the UPF. The SMF provides the AN tunnel information and corresponding transmission rules to the UPF.

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

[0176] After this step, the UPF can deliver to the UE the DL packets that can be buffered for this PDU session.

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

[0178] (17) Step 17: The SMF sends an update SM context response message (e.g., Nsmf_PDU session_UpdateSMContextResponse) to the AMF.

[0179] After this step, the AMF will communicate any relevant events that the SMF has subscribed to.

[0180] (18) Step 18: If at any time during the procedure after step 5, the PDU session establishment cannot be successful, the SMF can inform the AMF by calling Nsmf_PDU session_SMContextStatusNotify(release). The SMF can also release the created N4 session, the PDU session address (e.g., IP address) if assigned, and, if possible, the relationship with the PCF. In this case, step 19 below is omitted.

[0181] (19) Step 19: If the PDU session type is IPv6 or IPv4v6, the SMF may generate and send an IPv6 Router Advertisement to the UE.

[0182] (20) Step 20: The SMF may implement the SM policy related modifications disclosed by the SMF.

[0183] (21) Step 21: If the PDU session establishment fails after step 4, and the SMF does not process the PDU session for the UE any more, the SMF can unsubscribe to the modification of the session management subscription data.

[0184] <UAS(Uncrewed Aerial System)>

[0185] A method for supporting UAS (Uncrewed Aerial Systems) in 5G is being discussed. A UAS can consist of one or more unmanned aerial vehicles (UAVs) and a UAV Controller (UAV-C) that controls one of the unmanned aerial vehicles. The unmanned aerial vehicles can be controlled by the unmanned aerial vehicle controller over a C2 (Command and Control) link of a 3GPP mobile communication network or a non-3GPP mobile communication network.

[0186] For reference, in the disclosure of this specification, C2 communication may refer to Command and Control (C2) Communication, which may refer to a user plane link for transmitting messages containing command and control information for UAV operation from a UAV controller or Uncrewed Aircraft Systems Traffic Management (UTM) to a UAV, or for reporting telemetry data from a UAV to a UAV controller or UTM.

[0187] For UAS management, the USS (UAS Service Supplier) / UTM (UAS Traffic Management) and the UAV can exchange application data traffic via a 3GPP mobile communication network. The UAV can be considered a UE. For example, the example in FIG. 7 below shows a logical 5GS and EPS architecture for a UAV. For details, please refer to TS 23.256 V17.0.0.

[0188] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0189] Figure 7 shows an example of a logical 5GS and EPS architecture for a UAV.

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

[0191] 1) UUAA can be performed during the process of UAV network registration: For example, a UAV may have an Aerial 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 called UUAA-MM). If UUAA-MM is not performed, the UAV can perform UUAA during the PDU session generation process.

[0192] 2) The UAV can perform UUAA during the PDU session creation process of the DNN for the UAV service (PDN connection in the case of EPS) (this can be called UUAA-SM): In the case of 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. In the case of EPS, it can be initiated by the SMF + PGW-C when the UAV provides a CAA-Level UAV ID in the ESM message container.

[0193] UAV communication can be divided into USS communication between the UAV and the USS and C2 communication. USS communication is user plane data transmission excluding C2 communication. The PDU Session / PDN connection for C2 communication and the PDU Session / PDN connection for USS communication can be used together or separately. That is, the PDU Session / PDN connection for C2 communication and the PDU Session / PDN connection for USS communication can be the same or different.

[0194] The UAS Network Function is supported by the Network Exposure Function (NEF) or Service Capability Exposure Function (SCEF) + NEF and can be used to expose services to the USS. The UAS-NF can utilize the existing NEF / SCEF exposure services for operations such as UAV authentication / authorization, flight permission, revocation of UAV-UAVC pairing permission and related operations, location reporting, and QoS / traffic filtering control for C2 communication. The UAS NF can store the results of the UUAA-MM and UUAA-SM procedures. To support re-authentication at the request of the USS, the UAS NF can store whether re-authentication should be requested from the AMF or the SMF / SMF+PGW-C. It may also store the addresses of the AMF and SMF / SMF+PGW-C currently providing the service.

[0195] The USS can initiate a re-authentication procedure via the UAS NF at any time after the UUAA procedure is completed. UUAA re-authentication can be performed via the SMF (UUAA-SM) or AMF (UUAA-MM) depending on the network configuration. The re-authentication result can be transmitted to the UE via the SMF (UUAA-SM) or AMF (UUAA-MM) from the USS via the UAS NF.

[0196] Additional measures to support UAS (Uncrewed Aerial System) services in 5GS are being discussed. 3GPP TR 23.700-58 v1.0.0 includes the following issues:

[0197] For example, there is a problem with Transport C2 communication over a PC5 interface.

[0198] This problem focuses on C2 communication transmission via PC5 in 3GPP system. It involves studying how to activate direct C2 communication between UAV and UAV controller. The following aspects must be considered:

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

[0200] -Whether or not architecture modifications are necessary in relation to solutions currently using PC5 (e.g., Proximity-based Services (ProSe), Cellular Vehicle-to-Everything (C-V2X)) and the details thereof:

[0201] -This includes studying scenarios where the drone and UAV controller (UAV-C) are all registered with 5GS, as well as scenarios where the UAV controller (UAV-C) is not registered with 5GS or does not have Uu capabilities;

[0202] This includes studying all scenarios in which the radio resources used for PC5 are configured and scheduled by the Mobile Network Operator (MNO) (coverage operating), as well as scenarios in which the radio resources used for PC5 are "non-operator-managed";

[0203] -Whether and how existing PC5-based unicast communications can be reused and / or extended to transmit C2 communications;

[0204] -How C2 communication is set up between the UAV and the UAV controller via PC5;

[0205] - How the UAV is authorized and how authorization is revoked to establish direct C2 communication via the UAV controller and PC5 in all in-coverage and out-of-coverage scenarios;

[0206] - Should the UAV discover the UAV controller, or vice versa, and if so, how?

[0207] TR 23.700-58v1.0.0 includes the following conclusion regarding the above example problem:

[0208] UAVs participating in C2 communications via PC5 may or may not be capable of Uu communications with the network.

[0209] Only unicast mode C2 communication over PC5 is supported.

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

[0211] Two types of authorization are supported for C2 communication over PC5:

[0212] -Certification based on provisioned policies for UAVs similar to clause 5.1.3 of TS 23.304 V17.4.0.

[0213] - If the UAV is capable of Uu communication with the network, authentication is performed based on the C2 communication authentication procedure defined in AUTHORIZATION.

[0214] The unicast mode 5G ProSe direct communication procedure defined in clause 6.4.3 of TS 23.304 V17.4.0 is used as the basis for setting up C2 communication over PC5, with the following enhancements and adaptations:

[0215] -ProSe service information will be replaced with "C2 communication service"

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

[0217] UE-oriented and service-oriented unicast link establishment are all supported as defined in TS 23.304 V17.4.0, clause 6.4.3.1.

[0218] The following additional explanation can be applied to the above conclusion. That is, the C2 communication authorization procedure via Uu defined in TS 23.256 V17.4.0 can be used to perform C2 communication between a UAV and a UAV-C via PC5 (i.e., when performing authorization with a USS / network). In this case, it becomes clear that the C2 communication authorization procedure via Uu should be performed before performing C2 communication via PC5. For example, the following additional explanation can be applied:

[0219] Two types of authentication are supported for C2 communications over PC5:

[0220] -Certification based on provisioned policies for UAVs similar to clause 5.1.3 of TS 23.304 V17.4.0.

[0221] - If the UAV is capable of Uu communication with the network, authentication according to the C2 communication authentication procedure defined in TS 23.256 V17.4.0. In this case, the UAV UE performs C2 communication authentication according to the procedure defined in TS 23.256 V17.4.0 before initiating direct communication from the UAV to the UAV-C via PC5.

[0222] It is also possible that the C2 communication authorization procedure via Uu defined in TS 23.256 V17.4.0 fails. In this case, it is unclear whether the UAV UE is allowed to perform C2 communication via UAV-C and PC5. Also, in this case, if the UAV UE is not allowed to perform C2 communication via UAV-C and PC5, it is unclear how to handle this (e.g., authentication or C2 communication).

[0223] Also, the C2 connection via Uu can be revoked by the USS or the network. In this case, it is unclear whether the UAV UE is allowed to perform C2 communication via UAV-C and PC5. Also, in this case, if the UAV UE is not allowed to perform C2 communication via UAV-C and PC5, it is unclear how to handle this (e.g., authentication or C2 communication).

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

[0225] In addition, a method is needed to provide the UE with information on whether C2 communication via PC5 can be performed using the Uu connection, or a method is needed to set the UE with information on whether C2 communication via PC5 can be performed.

[0226] Regarding C2 communication, the following contents defined in TS 23.256 V17.4.0 can be referred to.

[0227] C2 communication may refer to Command and Control (C2) Communication. C2 communication may refer to a user plane link for transmitting messages containing command and control information for UAV operation from a UAV controller or Uncrewed Aircraft Systems Traffic Management (UTM) to a UAV, or for reporting telemetry data from a UAV to a UAV controller or UTM.

[0228] The C2 communication authorization procedure via Uu can be referenced in Section 5.2.5 (Authorization for C2) of TS 23.256 V17.4.0, and the C2 connection revoke procedure via Uu can be referenced in Section 5.2.9 (Revocation of C2 Connectivity) of TS 23.256 V17.4.0.

[0229] The method for supporting C2 communication using the PC5 interface proposed in the disclosure of this specification may be configured by a combination of one or more operations / configurations / steps from the various examples below.

[0230] 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 as terms with the same meaning.

[0231] In this specification, "executing C2 communication" may be interpreted as establishing a C2 connection, or as an operation including establishing a C2 connection. Establishing a C2 connection via a PC5 interface may refer to the Layer-2 link establishment, i.e., unicast link establishment, operations of TS 23.287 V17.4.0 and TS 23.304 V17.4.0.

[0232] In this specification, the terms UE (User Equipment) and terminal may be used interchangeably.

[0233] In this specification, PC5, PC5 interface, PC5 reference point, and "PC5 board" may be used interchangeably.

[0234] In this specification, Uu, Uu interface, and Uu reference point may be used interchangeably.

[0235] In this specification, SMF can mean SMF+PGW-C in EPS.

[0236] The following describes the proposed content of this specification, and explanations of configurations that are the same as those in the prior art may be omitted. Regarding UAS-related operations and procedures, TS 23.256 V17.4.0 is generally referred to. Regarding PC5-related operations and procedures, TS 23.287 V17.4.0, TS 24.587, TS 23.304 V17.4.0, TS 24.554, etc. are generally referred to.

[0237] The examples of supporting C2 communication using the PC5 interface described herein can be extended / modified and applied not only to UAS services but also to other services (e.g., ProSe services, V2X services, etc.). In this case, C2 communication / C2 connection according to the disclosure of this specification can be interpreted as communication / connection between two UEs.

[0238] If C2 communication authorization (or authorization with the USS / network) via Uu fails or if C2 communication authorization (or authorization with the USS / network) is revoked, the following exemplary operations may be performed. For example, the SMF or USS may provide or configure to the UE whether C2 communication via PC5 can be performed. Alternatively, the SMF or USS may provide or configure to the UE whether C2 communication via PC5 can be performed using the Uu connection. When the USS performs such an operation, the information or configuration provided by the USS may be transmitted to the UE via the SMF.

[0239] As an example, if C2 communication authorization (or authorization with the USS / network) via Uu fails or if C2 communication authorization (or authorization with the USS / network) is revoked, the following exemplary operations may be performed. For example, the network may instruct or configure the UE as to whether it can perform C2 communication via PC5. Alternatively, the network may provide or configure the UE as to whether it can perform C2 communication via PC5 using the Uu connection. Here, it may be assumed that the UE is a UAV. However, this is merely an example, and the UE may be a UAV-C, or may be both a UAV and a UAV-C.

[0240] In this specification, the operation of providing or configuring the UE as to whether C2 communication via PC5 can be performed using the Uu connection can also be interpreted as the operation of the network providing or configuring the UE as to whether C2 communication via PC5 can be performed.

[0241] 1. First Example of the Disclosure

[0242] In the first example of the disclosure of this specification, an example of setting an authorization policy / parameter in a UE will be described.

[0243] One or more of the following authorization policies / parameters may be configured in the UE. These authorization policies / parameters may be configured in various forms, such as a combination form, an explicit form, or an implicit form.

[0244] (a) Information that indicates / instructs that a UE should perform / precede C2 communication authorization (or authorization with the USS / network) via Uu in order to perform C2 communication via the PC5 interface (or before the UE performs C2 communication via the PC5 interface).

[0245] (b) Information indicating / instructing not to perform C2 communication via the PC5 interface if C2 communication authorization (or authorization with the USS / network) via Uu fails (i.e., cannot be successful), which can be interpreted as meaning that if C2 communication authorization (or authorization with the USS / network) via Uu fails (i.e., cannot be successful), C2 communication via the PC5 interface is not allowed / authorized.

[0246] (c) Information indicating or indicating that C2 communication can be performed via the PC5 interface if C2 communication authorization (or authorization with the USS / network) via Uu is successful, which can be interpreted as meaning that C2 communication via the PC5 interface is permitted / authorized if C2 communication authorization (or authorization with the USS / network) via Uu is successful.

[0247] (d) Information indicating or indicating that C2 communication can be performed via the PC5 interface even if C2 communication authorization (or authorization with the USS / network) via Uu fails (i.e., cannot be successful), which can be interpreted as C2 communication being permitted / authorized via the PC5 interface even if C2 communication authorization (or authorization with the USS / network) via Uu fails (i.e., cannot be successful).

[0248] (e) Information indicating / instructing that C2 communication should not be performed via the PC5 interface when a Uu-based C2 connection is revoked. This can be interpreted as meaning that if C2 communication authorization (or authorization with USS / network) via Uu is revoked, C2 communication via the PC5 interface is not permitted / authorized.

[0249] (f) Information indicating or indicating that C2 communication can be performed via the PC5 interface even if the Uu-based C2 connection is revoked. This can be interpreted as C2 communication being permitted / authorized via the PC5 interface even if the C2 communication authorization (or authorization with the USS / network) via Uu is revoked.

[0250] (g) Information that indicates / instructs not to perform C2 communication via 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 used for Uu-based C2 communication) is terminated. This can be interpreted as meaning that if the C2 communication via Uu (or the PDU Session / PDN connection used for this) is terminated, C2 communication via the PC5 interface is not permitted / authorized.

[0251] (h) Information that C2 communication can be performed via the PC5 interface even if the Uu-based C2 connection (or the PDU Session / PDN connection used for Uu-based C2 communication) is terminated, or information indicating / indicating this. This can be interpreted as C2 communication via the PC5 interface being permitted / authorized even if the C2 communication via Uu (or the PDU Session / PDN connection used for this) is terminated.

[0252] For reference, the above (a) to (h) may also be referred to as (a) information to (h) information, respectively, in various examples of the disclosure of this specification.

[0253] In the above example, the release operation of the PDU Session / PDN connection used for Uu-based C2 communication can be interpreted as including the release of the QoS Flow / Bearer used for Uu-based C2 communication.

[0254] The authorization policy / parameter setting can be configured by one or more of the following methods: a method of being configured in the UICC, a method of being configured in the ME, a method of being configured by the PCF to the UE, and a method of being configured by the AF to the UE. For examples of operations for performing such configuration, please refer to sections 5.1.1 and 6.2 of TS 23.287 V17.4.0.

[0255] A first example of the first example of the disclosure of this specification will now be described with reference to the illustrations of FIGS. 8a and 8b.

[0256] The following example is an example based on the contents of Section 5.2.5.2.1 (C2 Authorization request during UUAA-SM procedure in 5GS) of TS 23.256 V17.4.0, and the following explanation focuses on the contents proposed in the disclosure of this specification. For reference, Section 5.2.5.2.1 of TS 23.256 V17.4.0 describes the items added compared to Section 5.2.3.2 of TS 23.256 V17.4.0.

[0257] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0258] 8a and 8b illustrate a first illustrative procedure of the first example of the present disclosure.

[0259] The examples of Figures 8a and 8b show examples in which UUAA is performed while a PDU session establishment procedure is being performed.

[0260] The explanation for the operations described in Section 5.2.5.2.1 of TS 23.256 V17.4.0 is omitted.

[0261] Step 0. When the information (a) is set in the UE, the UE may also decide to perform C2 communication authorization via Uu.

[0262] Step 7. Based on one or more of the information (b), (c), and (d) and the C2 authorization result (success or failure), the UE can determine whether to perform C2 communication via the PC5 interface. For example, the following exemplary operations can be performed:

[0263] If the C2 authorization is successful, the UE may determine that it can perform C2 communication via the PC5 interface. The UE may also make such a determination even if the (c) information is set or not set.

[0264] If the C2 authorization fails, and the (b) information is set, the UE can determine that it cannot perform C2 communication via the PC5 interface. Even if the (b) information is not set, and the (a) information is set, and the C2 authorization fails, the UE can also determine that it cannot perform C2 communication via the PC5 interface.

[0265] If C2 authorization fails, and the (d) information is set, the UE can determine that C2 communication can be performed via the PC5 interface.

[0266] The UE may also perform the above exemplary decision by implementing the UE instead of using the (b), (c), and (d) information.

[0267] The UE can receive an SM NAS message (e.g., PDU Session Establishment Accept, PDU Session Establishment Reject, etc.) from the SMF. Based on the received SM NAS message (e.g., PDU Session Establishment Accept, PDU Session Establishment Reject, etc.) and / or information included in this message (e.g., 5GSM cause value, information included in the Service-level-AA container, etc.), the UE can determine the C2 authorization result. For specific descriptions of the 5GSM cause value and Service-level-AA container information, please refer to TS 24.501 V17.8.0. For example, if C2 authorization fails, the 5GSM cause value included in the SM NAS message can be set to or include #29 "user authentication or authorization failed." For example, if C2 authorization fails, the Service-level-AA response information included in the Service-level-AA container can be set to or include "C2 authorization was not successful or C2 authorization is revoked."

[0268] [Table 3]

[0269] Table 3 is an example of a Service-level-AA response information element defined in Table 9.11.2.14.1 of 3GPP TS 24.501 V17.8.0.

[0270] A second example of the first example of the disclosure of this specification will now be described with reference to the examples of Figures 9a and 9b.

[0271] The following example is an example based on the contents of Section 5.2.5.3.0 of TS 23.256 V17.4.0 (C2 Authorization request during UUAA-SM procedure in EPS), and the following explanation focuses on the contents proposed in the disclosure of this specification. For reference, Section 5.2.5.3.0 of TS 23.256 V17.4.0 describes the items added compared to Section 5.2.3.3 of TS 23.256 V17.4.0.

[0272] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0273] 9a and 9b illustrate a second illustrative procedure of the first example of the present disclosure.

[0274] The examples of Figures 9a and 9b show an example in which UUAA is performed during a PDN connection establishment procedure in the EPS.

[0275] The explanation for the operations described in Section 5.2.5.3.0 of TS 23.256 V17.4.0 is omitted.

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

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

[0278] If C2 authorization is successful, the UE may determine that it can perform C2 communication via the PC5 interface. This may be determined even if the (c) information is set or not set.

[0279] If the C2 authorization fails, and the (b) information is set, the UE can determine that it cannot perform C2 communication via the PC5 interface. Even if the (b) information is not set, and the (a) information is set, and the C2 authorization fails, the UE can also determine that it cannot perform C2 communication via the PC5 interface.

[0280] If C2 authorization fails, and the (d) information is set, the UE can determine that C2 communication can be performed via the PC5 interface.

[0281] Instead of using the information (b), (c), and (d), the UE may also make the decisions illustrated in the examples above depending on the implementation of the UE.

[0282] The UE can receive SM-related NAS messages (e.g., MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY 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 MODIFY REQUEST, etc.) and / or information included in the NAS messages (e.g., ESM cause value, information included in the Service-level-AA container, etc.), the UE can determine the C2 authorization result. For specific descriptions of the ESM cause value and Service-level-AA container information, please refer to TS 24.301 V17.8.0. For example, when C2 authorization fails, #29 "user authentication or authorization failed" can be included or set as the ESM cause value. For example, when C2 authorization fails, "C2 authorization was not successful or C2 authorization is revoked." may be included / set as Service-level-AA response information included in the Service-level-AA container.

[0283] In the examples shown in Figures 8a and 8b and 9a and 9b, if the UE determines to perform C2 communication via the PC5 interface, the UE may perform an operation to establish a C2 connection using the PC5 interface. Also, if the UE determines not to perform C2 communication via the PC5 interface, if the UE receives a request to establish a C2 connection using the PC5 interface from a remote UE (i.e., UAV-C in the case of a UAV, or UAV in the case of a UAV-C), the UE may reject the request. If the UE rejects the request, the UE may send a rejection message to the remote UE. The rejection message may include the reason for the rejection (e.g., Uu-based C2 communication authorization failure, Uu-based C2 communication not-authorized, PC5-based C2 communication not-authorized, etc.).

[0284] Hereinafter, a third example of the first example of the disclosure of this specification will be described with reference to the example of FIG.

[0285] The following example is an example based on the contents of Section 5.2.9.1 (Revocation of C2 connectivity in 5GS) of TS 23.256 V17.4.0, and the following explanation will focus on the contents proposed in the disclosure of this specification.

[0286] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0287] FIG. 10 illustrates a third illustrative procedure of the first example of the present disclosure.

[0288] The example in Figure 10 shows an example of revocation of the C2 linkage in 5GS.

[0289] Step 3 or Step 6. Based on one or more of the information (e), (f), (g), and (h) and the C2 connection revocation (or release of the PDU session used for the C2 connection or release of the QoS flow used for the C2 connection), the UE can determine whether to perform C2 communication over the PC5 interface. For example, the following exemplary operations can be performed:

[0290] When a C2 connection revocation (or release of a PDU Session / QoS Flow used for the C2 connection) occurs, if one or more of the information (e) and (g) is set, the UE may determine that it cannot perform C2 communication via the PC5 interface. Even if the information (e) and (g) is not set, if the information (a) is set, when a C2 connection revocation (or release of a PDU Session / QoS Flow used for the C2 connection) occurs, the UE may determine that it cannot perform C2 communication via the PC5 interface.

[0291] If a C2 connection revocation occurs (or the PDU Session / QoS Flow used for the C2 connection is released), the UE may determine that it can perform C2 communication via the PC5 interface. The UE may make this determination even if one or more of the information (f) and (h) is set or not set.

[0292] 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 information contained therein (e.g., 5GSM cause value, information contained in the Service-level-AA container, etc.), the UE can know the C2 connection revocation (or the release of the PDU Session / QoS Flow used for the C2 connection). For a detailed description of the 5GSM cause value and Service-level-AA container information, please refer to TS 24.501 V17.8.0.

[0293] For example, at the time of C2 connection revocation, #29 "user authentication or authorization failed" can be included or set as the 5GSM cause value. For example, at the time of C2 connection revocation, "C2 authorization was not successful or C2 authorization is revoked." can be included or set as the Service-level-AA response information included in the Service-level-AA container.

[0294] Hereinafter, a fourth example of the first example of the disclosure of this specification will be described with reference to the example of FIG.

[0295] The following example is an example based on the contents of Section 5.2.9.2 (Revocation of C2 connectivity in EPS) of TS 23.256 V17.4.0, and the following description will focus on the contents proposed in the disclosure of this specification.

[0296] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0297] FIG. 11 illustrates a fourth illustrative procedure of the first example of the present disclosure.

[0298] The illustration in Figure 11 shows an example of revocation of a C2 linkage in an EPS.

[0299] Step 2 or Step 4. Based on one or more of the information (e), (f), (g), and (h) and the C2 connection revocation (or release of the PDN connection used for the C2 connection or release of the bearer used for the C2 connection), the UE can decide whether to perform C2 communication via the PC5 interface.

[0300] When a C2 connection revocation (or a release of a PDN connection / bearer used for the C2 connection) occurs, if one or more of the information (e) and (g) is set, the UE may determine that it cannot perform C2 communication via the PC5 interface. Even if the information (e) and (g) is not set, if the information (a) is set, when a C2 connection revocation (or a release of a PDN connection / bearer used for the C2 connection) occurs, the UE may determine that it cannot perform C2 communication via the PC5 interface.

[0301] If a C2 connection revocation occurs (or the PDN connection / bearer used for the C2 connection is released), the UE may determine that it can perform C2 communication via the PC5 interface. The UE may make this determination even if one or more of the information (f) and (h) is set or not set.

[0302] 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 MODIFY REQUEST, etc.) and / or information included in the NAS messages (e.g., ESM cause value, information included in the Service-level-AA container, etc.), the UE can learn of C2 connection revocation (or release of the PDN connection / bearer used for the C2 connection). For specific descriptions of the ESM cause value and Service-level-AA container information, please refer to TS 24.301 V17.8.0. For example, upon C2 connection revocation, #29 "user authentication or authorization failed" can be included or set as the ESM cause value. For example, upon C2 connection revocation, the Service-level-AA response information included in the Service-level-AA container may include or be set to "C2 authorization was not successful or C2 authorization is revoked."

[0303] In the examples of Figures 10 and 11, a UE that has been performing C2 communication via the PC5 interface may decide not to perform C2 communication via the PC5 interface. If the UE makes such a decision, the UE may perform an operation to release the C2 connection via the PC5 interface. The PC5 message used in the release operation may include the reason for release (e.g., Uu-based C2 communication revoked, Uu-based C2 communication not-authorized, PC5-based C2 communication not-authorized, etc.). For a detailed description of the operation to release the C2 connection via the PC5 interface, please refer to the L2 link release procedure defined in TS 23.287 V17.4.0 and TS 23.304 V17.4.0.

[0304] 2. Second Example of the Disclosure of the Present Specification

[0305] This section describes how to notify the UE during the execution of the C2 communication authorization procedure via Uu or using a Uu connection.

[0306] For example, an example will be described in which, in the course of executing a C2 communication authorization procedure via Uu or using a Uu connection, the network informs the UE whether it is permitted to perform C2 communication via PC5.

[0307] If C2 communication authorization via Uu fails (i.e., cannot be successful), or if the Uu-based C2 connection is revoked, or if the PDU Session / QoS Flow used for Uu-based C2 communication is released, or if the PDN connection / bearer used for Uu-based C2 communication is released, or if C2 communication authorization via PC5 fails (i.e., cannot be successful), or if the PC5-based C2 connection is revoked, the following exemplary operations may be performed: For example, the network may provide the UE with information indicating that C2 communication via PC5 should not be performed (or that C2 communication via PC5 is not allowed or that C2 communication via PC5 is not authorized).

[0308] In the opposite case to the above example, for example, if C2 communication authorization via Uu is successful or if C2 communication authorization via PC5 is successful, the following example operation may be performed: The network may provide the UE with information indicating that C2 communication via PC5 will be performed (or that C2 communication via PC5 is allowed or that C2 communication via PC5 is authorized).

[0309] An example of establishing a PC5 unicast link will be described with reference to Fig. 12. For a description related to establishing or forming a PC5 unicast link in the second example of the disclosure of this specification, the example of Fig. 12 can be referenced.

[0310] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0311] FIG. 12 illustrates a procedure for establishing a layer-2 link via a PC5 reference point according to one embodiment of the present disclosure.

[0312] An example of unicast mode V2X communication via PC5 reference point is described.

[0313] Referring to FIG. 12, an example of Layer-2 link establishment via the PC5 reference point will be described.

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

[0315] Figure 12 shows the Layer 2 link setup procedure for unicast mode of V2X communication over PC5 reference point.

[0316] 1.The UE(s) determine the destination Layer-2 ID for signaling reception for PC5 unicast link establishment.The destination Layer-2 ID is configured with the UE(s).

[0317] 1. The UE(s) determines the destination Layer-2 ID for signal reception for PC5 unicast link establishment. The destination Layer-2 ID is configured by the UE(s).

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

[0319] The V2X application layer of UE-1 can provide the V2X application requirements for this unicast communication. UE-1 determines the PC5 QoS parameters and the PC5 QoS Flow ID (PFI).

[0320] When UE-1 decides to reuse the existing PC5 unicast link, the UE may trigger a Layer 2 link modification procedure.

[0321] 3. UE-1 initiates the unicast Layer 2 link establishment procedure by sending a direct communication solicitation message. The direct communication solicitation message may include the following information:

[0322] Source User Info: Application layer ID of the initiating UE (ie, Application layer ID of UE-1).

[0323] -If the V2X application layer provided the application layer ID of the target UE in step 2, the following information is included:

[0324] Target User Info: Application layer ID of the target UE (ie, the application layer ID of UE-2).

[0325] -V2X Service Info: Information on the V2X service type requesting layer 2 link establishment.

[0326] -Security Information: Information for establishing security.

[0327] The source Layer-2 ID and destination Layer-2 ID used to send the direct communication request message are determined. The destination Layer-2 ID is a broadcast or unicast Layer-2 ID. If a unicast Layer-2 ID is used, the direct communication request message must include target user information.

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

[0329] If PC5 DRX operation is required for sending and receiving direct communication request messages, for example, based on the NR Tx profile, the basic PC5 DRX configuration is used.

[0330] 4. UE-1 security is established as follows:

[0331] 4a. If Target User info is included in the direct communication request message, the target UE, i.e., UE-2, responds by establishing security with UE-1.

[0332] 4b. Target User info is not included in the direct communication request message. In this case, a UE that wants to use the announced V2X service type via a PC5 unicast link with UE-1 establishes security with UE-1 and responds.

[0333] Once security protection is activated, UE-1 will send the following information to the target UE:

[0334] -When IP communication is used, the following information can be transmitted:

[0335] - IP Address Configuration: For IP communication, this link must have an IP address configuration, which can be one of the following values:

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

[0337] - "IPv6 address allocation not supported", if the IPv6 address allocation mechanism is not supported by the initiating UE.

[0338] -Link Local IPv6 Address: If UE-1 does not support the IPv6 IP address allocation mechanism, i.e., if "IPv6 address allocation not supported" is displayed in the IP address settings, this is a locally formed link-local IPv6 address.

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

[0340] The source Layer 2 ID used in the security establishment procedure is determined. The Destination Layer 2 ID is set to the Source Layer 2 ID of the received Direct Communication Request message.

[0341] Upon receiving the message related to the security establishment procedure, UE-1 obtains the Layer 2 ID of the peer UE for future communication for signaling and data traffic on this unicast link.

[0342] 5. A direct communication accept message is sent to UE-1 by the target UE that has successfully established security with UE-1:

[0343] 5a. (UE-oriented layer-2 link establishment) If the target user information is included in the direct communication request message, and the application layer ID of the target UE, i.e., UE-2, matches, UE-2 responds with a direct communication accept message.

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

[0345] The direct communication acceptance message includes:

[0346] -Source User Info: Application layer ID of the UE sending the direct communication acceptance message.

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

[0348] -If IP communication is used, it contains the following information:

[0349] - IP Address Configuration: For IP communication, this link must have an IP address configuration, which can be one of the following values:

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

[0351] - "IPv6 address allocation not supported" if the IPv6 address allocation mechanism is not supported by the target UE.

[0352] Link Local IPv6 Address: If the target UE does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration displays "IPv6 address allocation not supported" and UE-1 includes a link-local IPv6 address in the direct communication request message, this is a locally formed link-local IPv6 address. The target UE must include a non-conflicting link-local IPv6 address.

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

[0354] If the initiating UE or target UE indicates that it supports an IPv6 router, the corresponding address configuration procedure is performed after Layer 2 link configuration, and the link-local IPv6 address can be ignored.

[0355] The V2X layer of the UE that established the PC5 unicast link transmits the PC5 link identifier assigned to the unicast link and PC5 unicast link related information to the AS layer. The PC5 unicast link related information includes Layer-2 ID information (e.g., source Layer-2 ID and destination Layer-2 ID) and corresponding PC5 QoS parameters. This allows the AS layer to maintain the PC5 link identifier along with the PC5 unicast link related information.

[0356] 6. V2X service data is transmitted via the established unicast link as follows:

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

[0358] Optionally, layer 2 ID information (eg, source layer 2 ID and destination layer 2 ID) is additionally provided in the AS hierarchy.

[0359] Depending on the UE implementation, Layer 2 identity information may also be provided to the AS layer.

[0360] UE-1 sends V2X service data using the source Layer-2 ID (i.e., UE-1's Layer-2 ID for this unicast link) and destination Layer-2 ID (i.e., peer UE's Layer-2 ID for this unicast link).

[0361] Because the PC5 unicast link is bidirectional, the peer UE of UE-1 can transmit V2X service data to UE-1 via the unicast link with UE-1.

[0362] Hereinafter, a first example of the second example of the disclosure of the present specification will be described with reference to Figures 8a and 8b. For reference, Figures 8a and 8b were referred to above to describe the first example of the first example of the disclosure of the present specification, and below, the content proposed in the first example of the second example of the disclosure of the present specification will be described based on Figures 8a and 8b.

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

[0364] Step 0. Steps 1 to 5 of the example in FIG. 5 can be executed.

[0365] The UAV can include information such as the following examples in the PDU session establishment request message: For example, the UAV can include a service-level device identifier (e.g., a CAA-level UAV ID for UVA), an authentication server address (e.g., a USS address), and optionally authentication data (e.g., a UUAA air payload) in the PDU session establishment request message.

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

[0367] Step 2. The UAS NF / NEF can send authentication-related messages to the USS. For example, the UAS NF / NEF can invoke the Naf_Authentication_AuthenticateAuthorize service operation to transmit the authentication request information received from the SMF to the USS. For example, the UAS NF can convert the Cell ID received as part of the UAV location in the Naf_Authentication_AuthenticateAuthorize request in step 1 into the corresponding geographic area. And / or, the UAS NF can obtain additional UE location information using the location service procedure and include it in the Naf_Authentication_AuthenticateAuthorize message to the USS to support geo-caging functionality.

[0368] Step 3. [Conditional Action] Depending on the authentication method used by the USS, multiple round-trip messages may be sent or received as needed. The USS response message (e.g., Naf_Authentication_AuthenticateAuthorize response message) includes GPSI, and the authentication message according to the authentication method used is transparently transmitted to the UE via the NAS SM transmission message. The authentication message in Step 3 may include a UUAA aviation payload required by the USS if not previously provided by the UE.

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

[0370] Step 5. The SMF may receive an authentication response message from the UAS NF / NEF. For example, the SMF may receive a response message from the UAS NF / NEF containing information / results indicating whether the C2 authorization failed or succeeded. In this embodiment, the C2 authorization is authorization for C2 communication via Uu and / or authorization for C2 communication via PC5. The authentication response message is a message sent by the UAS to the SMF via the UAS NF / NEF.

[0371] Step 6. If authentication / authorization is successful, the USS subscribes to PDU session state events. For example, the operations according to Steps 1 to 5 in Figure 4.15.3.2.3-1 of TS 23.502 V17.6.0 can be performed. Step 6 can also be performed in parallel with Step 4. The UAS NF / NEF determines the DNN, S-NSSAI, that will subscribe to PDU session state event notifications.

[0372] Step 7. The SMF can 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 can include the following example information in the SM NAS message:

[0373] i) In case of C2 authorization failure (i.e., when the SMF receives a response message from the UAS NF / NEF containing information / results that C2 authorization failed), the SMF can include information indicating / instructing not to perform C2 communication via the PC5 interface in the SM NAS message, which can be interpreted as C2 communication via the PC5 interface not being allowed / authorized.

[0374] ii) When C2 authorization is successful (i.e., when the SMF receives a response message from the UAS NF / NEF containing information / results indicating that C2 authorization was successful), the SMF may include information that is the opposite of case i) above (e.g., information indicating that C2 communication can be performed via the PC5 interface. This information may be interpreted as C2 communication via the PC5 interface being permitted / authorized) in the SM NAS message. The SMF may also provide UAV-C related information (e.g., the UAV-C's Application Layer ID (which may be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) to the UE. For example, the SMF may send an SM NAS message containing UAV-C related information (e.g., the UAV-C's Application Layer ID (which may be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) to the UE via the AMF. The SMF can receive or acquire UAV-C related information from one or more of the following entities: USS, UAS NF / NEF, UDM, UDR, PCF, UAV-C, and Application Server / Function. Alternatively, UAV-C related information may be configured in the SMF. All UAV-C related information may be provided or acquired from a single entity, or from multiple entities. For example, the SMF can receive UAV-C related information (e.g., UAV-C Application Layer ID) from the USS and send UAV-C related information (e.g., UAV-C Application Layer ID) to the UE (e.g., UAV).The UAV can use the provided UAV-C-related information when establishing a PC5 unicast link for C2 communication with the UAV-C (or the UAV can establish a PC5 unicast link for C2 communication with the UAV-C using the provided UAV-C-related information). For example, a UE (e.g., a UAV) can perform a procedure for establishing a PC5 unicast link for C2 communication with the UAV-C based on the example of FIG. 12. For example, in Step 3 of FIG. 12, the UE (e.g., a UAV) can set Target User Info to the Application Layer ID of the UAV-C. The SMF includes the UAV-C-related information because the UE requested such information (in Step 1). The UAV-C-related information may also be TPAE (Third Party Authorized Entity)-related information. In this case, the TPAE can be considered to be a PC5-capable UE, a V2X-capable UE, or a ProSe-enabled UE.

[0375] The UAV can establish a PC5 unicast link for C2 communication with the UAV-C or a Third Party Authorized Entity (TPAE). In this case, if the UAV has received an Application Layer ID from the network, it can set the Application Layer ID to Target User Info. Also, if the UAV has received a Layer-2 ID from the network, it can set the Layer-2 ID to the Destination Layer-2 ID and use it to establish a PC5 unicast link (i.e., the UAV uses the Destination Layer-2 ID to send a Direct Communication Request message). If the UAV's Layer-2 ID is also provided by the network, it can set the UAV's Layer-2 ID to the Source Layer-2 ID and use it to establish a PC5 unicast link (i.e., the UAV uses the Source Layer-2 ID to send a Direct Communication Request message). The operation of the UAV receiving its Layer-2 ID from the network can be performed in a similar manner to the operation of the UAV receiving the UAV-C-related information from the network. The contents regarding the formation of such a PC5 unicast link can be applied throughout this specification.

[0376] The UAV-C related information or TPAE related information may be inferred / determined based on the identification information of the UAV (e.g., one or more of the following identification information: CAA-Level UAV ID (or Service Level Device Identity of the UAV), GPSI, PEI, and IP address information). This may be applied throughout this specification.

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

[0378] For example, in step 0 of the example in Figures 8a and 8b, the following example description can be applied: The UAV must establish a direct PC5 link required to connect to the UAV-C (i.e., direct C2 communication). In this case, the C2 Aviation payload transmitted 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 Aviation payload.

[0379] For example, in step 4 of the examples in Figures 8a and 8b, the following example description may be applied: If an authorization request for direct C2 communication is included in step 0 and the C2 authorization is successful, the USS may include direct C2 pairing information in which the application layer ID of the UAV-C is included in the C2 authorization payload. The C2 authorization payload including the application layer ID of the UAV-C is included in the Naf_Authentication_AuthenticateAuthorize response, which may be additionally transmitted to the UE.

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

[0381] For example, in step 4 of the example in FIG. 13 below, the following example description can be applied: If an authorization request for direct C2 communication is included in step 0 and the C2 authorization is successful, the USS can include direct C2 pairing information in which the application layer ID of the UAV-C is included in the C2 authorization payload. The C2 authorization payload including the application layer ID of the UAV-C is included in the Naf_Authentication_AuthenticateAuthorize response, which can be additionally transmitted to the UE.

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

[0383] The UAV can establish a C2 connection via PC5 with the C2 connection partner (e.g., UAV-C or TPAE) that was most recently established or provided by the network. This can be applied throughout this specification.

[0384] The SMF may include information related to i) or ii) in the SM NAS message for the following reasons: For example, if the UE requests authorization information for PC5-based C2 communication in step 0, the SMF may include the information in the SM NAS message. For example, if the AMF requests that authorization information for PC5-based C2 communication be provided to the UE (step 1), the SMF may include the information in the SM NAS message. The SMF may include the information in the SM NAS message based on subscriber information (e.g., information that authorization information for PC5-based C2 communication must be provided to the UE when Uu-based C2 communication authorization is performed, or information that the UE can perform PC5-based C2 communication). If the USS requests that authorization information for PC5-based C2 communication be provided to the UE (step 4), the SMF may include the information in the SM NAS message. If the UAS NF / NEF requests that authorization information for PC5-based C2 communication be provided to the UE (step 5), the SMF may include the information in the SM NAS message. The SMF may include the information in the SM NAS message based on the SMF's local policy / operator policy / local configuration. The SMF may include the information in the SM NAS message based on one or more of the various pieces of information listed above.

[0385] The UE may receive an SMF NAS message from the SMF. The SM NAS message may include information based on i) or information based on ii). The UE may determine whether to perform C2 communication over the PC5 interface based on the SM NAS message received from the SMF and / or the information i) or ii).

[0386] Hereinafter, a second example of the second example of the disclosure of the present specification will be described with reference to Figures 9a and 9b. For reference, Figures 9a and 9b were referred to above to describe the second example of the first example of the disclosure of the present specification, but below, the content proposed in the second example of the second example of the disclosure of the present specification will be described based on Figures 9a and 9b.

[0387] Step 5. The SMF+PGW-C receives a response message from the UAS NF / NEF, which includes information / results indicating whether the C2 authorization failed or succeeded. In this embodiment, the C2 authorization is authorization for C2 communication via Uu and / or authorization for C2 communication via PC5.

[0388] Step 8 (or after step 5): The SMF+PGW-C can send an SM-related NAS message to the UE via the MME. The SMF+PGW-C can include the following information in the SM-related NAS message (e.g., MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, etc.):

[0389] I) When C2 authorization fails (i.e., when a response message containing information / results indicating that C2 authorization failed is received from the UAS NF / NEF), the SMF+PGW-C can include information in the SM-related NAS message that indicates / instructs not to perform C2 communication via the PC5 interface. This can be interpreted as meaning that C2 communication via the PC5 interface is not allowed / authorized.

[0390] II) When C2 authorization is successful (i.e., when a response message including information / results indicating that C2 authorization was successful is received from the UAS NF / NEF), the SMF+PGW-C can include information that is the opposite of that in I) above (e.g., information indicating that C2 communication can be performed via the PC5 interface. This information can be interpreted as C2 communication via the PC5 interface being permitted / authorized) in the SM-related NAS message. In this case, the SMF+PGW-C can also provide the UE with UAV-C-related information (e.g., the UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.). For example, the SMF+PGW-C can provide the UE with an SM NAS message including UAV-C-related information (e.g., the UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.). The SMF+PGW-C may receive or acquire the UAV-C-related information from one or more entities among the USS, UAS NF / NEF, UDM / HSS, UDR, PCF, UAV-C, and Application Server / Function. Alternatively, the UAV-C-related information may be configured in the SMF+PGW-C. All UAV-C-related information may be received or acquired from one entity or multiple entities. The UAV can use the received UAV-C-related information when establishing a PC5 unicast link for C2 communication with the UAV-C (or the UAV can use the received UAV-C-related information to establish a PC5 unicast link for C2 communication with the UAV-C). The SMF+PGW-C includes the UAV-C-related information because the UE has requested such information (e.g., the UE may request it in step 0).The UAV-C related information may be TPAE (Third Party Authorized Entity) related information. In this case, the TPAE may be considered to be a PC5 capable UE, a V2X capable UE, or a ProSe enabled UE.

[0391] The SMF+PGW-C may include information related to I) or II) in the SM NAS message for the following reasons: For example, if the UE requests authorization information for PC5-based C2 communication (step 0), the SMF+PGW-C may include the information in the SM NAS message. For example, if the MME requests that authorization information for PC5-based C2 communication be provided to the UE (step 1), the SMF+PGW-C may include the information in the SM NAS message. For example, the SMF+PGW-C may include the information in the SM NAS message based on subscriber information (e.g., information that authorization information for PC5-based C2 communication must be provided to the UE when Uu-based C2 communication authorization is performed, or information that the UE can perform PC5-based C2 communication). For example, if the USS requests that authorization information for PC5-based C2 communication be provided to the UE (step 5), the SMF+PGW-C may include the information in the SM NAS message. For example, if the UAS NF / NEF requests that authorization information for PC5-based C2 communication be provided to the UE (step 5), the SMF+PGW-C can include the information in the SM NAS message. The SMF+PGW-C can include the information in the SM NAS message based on the local policy / operator policy / local configuration of the SMF+PGW-C. The SMF+PGW-C can include the information in the SM NAS message based on one or more of various pieces of information such as these examples.

[0392] The UE can determine whether C2 communication can be performed via the PC5 interface based on the SM-related NAS message to the UE received from the network and / or the information I) or II).

[0393] A third example of the second example of the disclosure of this specification will now be described.

[0394] For reference, the third example of the second example of the disclosure of the present specification is an example based on the first example and / or second example of the second example of the disclosure of the present specification described above. For example, the third example of the second example of the disclosure of the present specification is an example to which the description of the second example of the disclosure of the present specification applies.

[0395] C2 communication and direct C2 communication can be defined as follows:

[0396] Command and Control (C2) Communication: A user plane link for transmitting messages containing command and control information for UAV operation from a UAV controller or UTM to a UAV, or for reporting telemetry data from a UAV to a UAV controller or UTM. C2 communication can be established via the Uu reference point or PC5 reference point.

[0397] Direct C2 Communication: The UAV controller and the UAV can establish a direct C2 link via the PC5 reference point to communicate with each other.

[0398] C2 Aviation Payload: Contains application layer information that the UAS sends to the USS, including UAV pairing information and / or flight authorization information transparent to the 3GPP system.

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

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

[0401] Explains Authorization for C2 over Uu.

[0402] When a UAV establishes a user plane connection for C2 operations (i.e., when transmitting a message containing command and control information for UAV operations from the UAV-C or USS to the UAV, or when the UAV attempts to report telemetry data to the UAV-C), C2 authentication is required. Both sides of the C2 communication, i.e., the UAV and UAV-C, can belong to the same UAS.

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

[0404] -UAV to UAV-C pairing authorization: This is authorization for pairing with a UAV-C connected to a network or a UAV-C connected to a UAV via an Internet connection before the UAV and UAV-C exchange C2 communications. One UAV can only be paired with one UAV-C at any time. One UAV-C can be paired with one or more UAVs at the same time.

[0405] Flight Authorization: Authorization for flight if the UAV also provides flight authorization information.

[0406] C2 authentication can be performed in the following example cases:

[0407] During the UUAA procedure (when UUAA is performed during PDU session / PDN connection establishment): When the UAV requests PDU session / PDN connection establishment for connection.

[0408] During a PDU session modification procedure or a UE-requested bearer resource modification procedure: If the UAV should use an existing PDU session / PDN connection to exchange C2 communication-related messages.

[0409] -While establishing a new PDU session / PDN connection: If the UAV should use a separate PDU session / PDN connection for C2 communication

[0410] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0411] FIG. 13 illustrates an example of a PDU session establishment procedure for C2 communication according to one embodiment of the disclosure herein.

[0412] 13 shows a PDU session establishment procedure for C2 communication initiated by a UE. The example of FIG. 13 illustrates a case where a separate PDU session is used for the UAS service.

[0413] If C2 authorization is requested during the establishment procedure for a PDU session specifically used for C2 communication with UAV-C, the UAV requests C2 authorization as follows.

[0414] 0. The UAV successfully performs UUAA with the USS (UUAA-SM or UUAA-MM), and the USS can subscribe to PDU session state events from the NEF for that GPSI.

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

[0416] 2. Based on whether the requested DNN / S-NSSAI combination is dedicated to aerial services (the aerial service indicator is set) and the request includes a service-level device identity (CAA-level UAV ID), the SMF can determine whether authentication is required. The SMF can then send an Nnef_Authentication_AuthenticateAuthorize request message to the UAS NF / NEF, which is used to request authorization for pairing the UAV-C with the UAV. This request message includes the GPSI, CAA-level UAV ID, and C2 Aviation payload, optionally the UAV position (e.g., cell ID) if provided by the AMF, and the DNN and S-NSSAI of the PDU session.

[0417] If the requested DNN / S-NSSAI is dedicated to aerial services but the service-level device ID (CAA-level UAV ID) is not provided with the request, the SMF may reject the PDU session establishment request with the reason that USS authorization is required. For example, the SMF may send a PDU session establishment rejection message containing reason information that USS authorization is required.

[0418] The SMF also provides a notification endpoint to the UAS NF / NEF, which allows the SMF to implicitly subscribe to receive notifications for re-authentication, authentication data updates, or revocation of the UAS NF / NEF's C2 connection if the C2 authentication result is successful in step 5.

[0419] 3. The UAS NF / NEF checks whether a valid UUAA is stored for the GPSI and sends a Naf_Authentication_AuthenticateAuthorize request message containing the received authentication request to the USS. If not, the request is not sent to the USS and the PDU session is rejected.

[0420] The UAS NF / NEF also provides a notification endpoint to the USS, which allows the UAS NF / NEF to implicitly subscribe to receive reauthentication, authentication data update, or C2 decoupling notifications from the USS if the UUAA result in step 5 is successful.

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

[0422] 4. The USS can perform C2 authentication based on the received information and send a Naf_Authentication_AuthenticateAuthorize response message to the UAS NF / NEF. The Naf_Authentication_AuthenticateAuthorize response message contains the service-level device identification (e.g., CAA-level UAV-ID) (potentially a new one), the C2 authentication result, and the C2 authentication payload (e.g., C2 pairing information and C2 security information, direct C2 pairing information).

[0423] In step 1, an authentication request for direct C2 communication is included and C2 authentication can be successful. In this case, the USS can include direct C2 pairing information including the UAV-C application layer ID in the Naf_Authentication_AuthenticateAuthorize response message.

[0424] 5. The UAS-NF / NEF can send an Nnef_Authentication_AuthenticateAuthorize response message containing the information received from the USS to the SMF.

[0425] 6. The SMF can send a PDU session establishment accept message to the UE. To inform the UE of the C2 authentication result, the SMF can include the authentication result, optionally an authentication payload (e.g., C2 pairing information and C2 security information, or direct C2 pairing information), and a new CAA-level UAV ID, if received from the USS, in the PDU session establishment accept message. The SMF can then continue until the PDU session establishment procedure is completed.

[0426] If a failed C2 authentication result is received from the USS, the SMF may reject the PDU establishment and send a PDU Session Establishment Reject message with a reason code indicating failure to authenticate.

[0427] 7. [Conditional] If C2 authentication is successful, the USS subscribes to PDU session status events for the PDU session used for C2 by sending a request message including the UAV's GPSI via the UAS-NF. The UAS NF determines the DNN and S-NSSAI corresponding to the PDU session used for C2 communication and subscribes to PDU session status events from the SMF using this DNN and S-NSSAI. The SMF detects that the PDU session has been established as described in steps 6-7 of fig. 4.15.3.2.3-1 of TS 23.502 V17.6.0 and can send a PDU session status event report to the UAS NF / NEF via an Nsmf_EventExposure_Notify message including the GPSI and UE IP Address. The UAS NF / NEF then transmits the event message to the USS.

[0428] 8. [Conditional] The USS stores the received UE IP address, enters the received PDU session IP address and the IP address of the authenticated paired UAV-C, and invokes the pairing policy setting procedure, whereby the USS requests that the UPF allow the corresponding traffic in the PDU session.

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

[0430] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0431] FIG. 14 is an example of PDN connections for C2 authentication according to one embodiment of the disclosure herein.

[0432] FIG. 14 illustrates an example of a PDN connection establishment procedure for C2 authentication requested by a UE.

[0433] When the UAV requests to establish a connection to an additional PDN via the E-UTRAN for C2, the following modifications may be applied to the procedure of clause 5.10.2 of TS 23.401:

[0434] 0. The UAV successfully performs UUAA with the USS (UUAA-SM), and the USS subscribes to the NEF's PDN connection status event report for the corresponding GPSI.

[0435] 1. Steps 1 to 3 described in Figure 5.10.2-1 of TS 23.401 can be performed.

[0436] If a UAV needs to establish C2 communication, it can determine that a new PDN connection or a direct PC5 link is required to connect to the UAV-C. The UE initiates the UE-requested PDN connection procedure to connect to the UAV-C. The PCO included in the PDN connection request message contains the service-level device identity (e.g., CAA-level UAV ID) and a C2 aviation payload used for C2 authorization, and the PCO is transmitted to the MME. The pairing information includes the service-level device identifier (e.g., CAA-level UAV ID) of the requesting UAV, and the identification information of the pairing UAV-C can be included in the C2 aviation payload. If the authorization request is for direct C2 communication, the C2 aviation payload includes an indication of authorization for direct C2 communication. The UAV can also include other information such as flight authorization information. The USS can also use locally configured pairing information for UAV-UAV-C pairing authorization, and this information overrides the pairing information provided by the UAV.

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

[0438] 2. Based on the fact that the requested APN / DNN is dedicated to aerial services (the aerial service indicator is set) and the request message includes a service-level device identifier (CAA-level UAV ID), the SMF+PGW-C determines whether 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 for pairing the UAV with the UAV-C. This request message includes the GPSI, service-level device identifier (e.g., CAA-level UAV ID), and C2 Aviation payload, and optionally includes the UAV's location (e.g., cell ID) (if provided by the MME) and the APN / DNN of the PDN connection.

[0439] If the SMF+PGW-C determines that an authentication procedure with the USS is required but the UAV does not provide a service-level device ID (e.g., CAA-level UAV ID), the SMF+PGW-C sends a PDN connection request rejection message including the reason that USS authorization is required.

[0440] 3. The UAS NF / NEF checks whether a valid UUAA is stored for the GPSI and transmits the received authentication request to the USS as a Naf_Authentication_AuthenticateAuthorize request. If not, the request is not transmitted to the USS and the PDN connection is rejected.

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

[0442] If Step 1 includes an authentication request for direct C2 communication and C2 authentication is successful, the USS can include direct C2 pairing information including the application layer ID of the UAV-C in the Naf_Ahentication_AuthenticateAuthorize response.

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

[0444] 6. To inform the UE of the C2 authentication result, the SMF+PGW-C includes the C2 authentication result and optionally the authentication payload (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 Accept sent to the UE. The SMF+PGW-C then continues including the PDN connection request procedure until it is completed.

[0445] If a failed C2 authentication result is received from the USS, the SMF+PGW-C instead rejects the PDN connection request and sends a rejection message including a cause code indicating that authentication was not possible.

[0446] 7. If C2 authentication is successful, the USS includes the UAV's GPSI in the request and subscribes to PDN connection status event reports for the PDN connection used for C2 via the UAS NF / NEF. The UAS NF / NEF determines the APN / DNN and uses this APN / DNN to subscribe to PDN connection status events from the SMF+PGW-C. The SMF+PGW-C detects when the PDN connection is established as described in steps 6-7 of figure 4.15.3.2.3-1 of TS 23.502. The SMF+PGW-C then sends a PDN connection status event report, including the GPSI and UE IP address, to the UAS NF / NEF via an Nsmf_EventExposure_Notify message. The UAS NF / NEF then transmits the event message to the USS.

[0447] 8. To request that the PGW-U allow the corresponding traffic in the PDN connection, the USS stores the received UE IP address, inputs the received PDN connection IP address and the IP address of the authenticated paired UAV-C, and can call the USS-initiated C2 pairing policy setting procedure in the EPS procedure (see Figure 5.2.5.4.2-1).

[0448] This procedure does not invoke any interaction with the UE, MME or RAN unless dedicated QoS is requested for the C2 flow.

[0449] Explain Direct C2 Communication.

[0450] A UAV that supports direct C2 communication can establish a direct PC5 link with a UAV-C. A UAV that uses direct C2 communication may or may not be connected to a 3GPP network. The UAV can be authenticated by a USS so that it can establish direct C2 communication with the UAV-C. As described in the examples with reference to FIG. 13 and FIG. 14, information related to the UAV-C that performs direct C2 communication with the UAV can be pre-configured in the UAV or provided by the network. The UAV can be pre-configured with the Aircraft-to-Everything (A2X) service type for direct C2 communication, direct C2 pairing information (e.g., the application layer ID of the UAV-C), the layer-2 ID of the UAV-C, the default destination layer-2 ID for initial signaling to establish a unicast connection, and an authentication policy for direct C2 communication.

[0451] This section explains Authorization for Direct C2 Communication.

[0452] The following authentication policies can be provided for UAVs that support direct C2 communications:

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

[0454] - PLMNs that are authorized to perform C2 communications directly via PC5 reference points when the UAV is "served by NG-RAN".

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

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

[0457] If the UAV is capable of 3GPP network connectivity, the UAV performs C2 authentication as described above for "Authorization for C2 over Uu." If the UAV supports direct C2 communication and there is no authentication policy for direct C2, the UAV can include an indication for direct C2 communication authentication in the authentication request.

[0458] This section explains the procedure for establishing direct C2 communication.

[0459] The unicast mode 5G ProSe direct communication procedure defined in Section 6.4.3.1 of TS 23.304 V17.4.0 is used to establish C2 communication via PC5, and the following improvements can be applied: The following improvements can also be applied to the example shown in Figure 12.

[0460] - In Step 3 of Section 6.4.3.1 (or Figure 12) of TS 23.304 V17.4.0, the following explanation can be applied:

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

[0462] -Source User information can be set to a service-level device ID (e.g., CAA-Level UAV ID).

[0463] -Target User Info can be set to the application layer ID of the UAV-C. As described in the examples of Fig. 13 and Fig. 14, the application layer ID of the UAV-C can be pre-configured in the UAV or provided by the network.

[0464] The Destination Layer-2 ID is set to the Layer-2 ID of the UAV-C (if the Layer-2 ID of the UAV-C is pre-configured in the UAV). Otherwise, the destination Layer-2 ID is set to the default destination Layer-2 ID of the initial signaling for setting up the unicast connection, as pre-configured in the UAV.

[0465] For direct C2 communication, unicast mode 5G direct communication procedures can be supported.

[0466] 3. Third Example of the Disclosure

[0467] An example will be described in which, when the target for performing PC5-based C2 communication with the UAV is to be changed, the network notifies the UE using the Uu connection.

[0468] For example, when attempting to change UAV-C that has a PC5-based C2 connection with the UAV (i.e., performs PC5-based C2 communication), or when attempting to change from UAV-C to TPAE, or when attempting to change from TPAE to UAV-C, the network can notify the UE using the Uu connection.

[0469] When attempting to change a UAV-C that has a PC5-based C2 connection with a UAV (i.e., is performing PC5-based C2 communication), or when attempting to change from a UAV-C to a TPAE, or when attempting to change from a TPAE to a UAV-C, one or more of the following actions may be performed:

[0470] a) The UAV Controller Replacement procedure can be used (see Section 5.2.8 of TS 23.256 V17.4.0). For example, the USS can provide information about the change or information indicating that (re-)authorization is for the change to the UAS NF / NEF. The UAS NF / NEF can provide the information to the SMF (in the case of 5GS) or the SMF+PGW-C (in the case of EPS). The information can be included 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.

[0471] b) A C2 connectivity revocation procedure can be used (see examples in FIG. 10 and FIG. 11). For example, the USS can provide information on the change or information indicating that the revocation is for the change to the UAS NF / NEF. The UAS NF / NEF can provide the information to the SMF (in the case of 5GS) or the SMF+PGW-C (in the case of EPS). The information can be included 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.

[0472] When changing from a UAV-C to another UAV-C or from a TPAE to a UAV-C, the USS can provide the UE with information about the new UAV-C (e.g., the UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.). When changing to a TPAE, the USS can provide the UE with information about the TPAE (e.g., the TPAE's Application Layer ID (which can be interpreted as User Info, Pilot Info, or Officer Info, etc.), Layer-2 ID, etc.).

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

[0474] In the above a) and b) operations, the procedures / operations related to C2 communication via Uu can be skipped if unnecessary.

[0475] 4. Fourth Example of the Disclosure of the Present Specification

[0476] An example is described in which, when C2 communication authorization (or authorization with USS / network) via Uu fails or is revoked, the core network provides the base station with information on whether C2 communication via PC5 is authorized.

[0477] If C2 communication authorization via Uu fails (i.e., cannot be successful), or if the Uu-based C2 connection is revoked, or if the PDU Session / QoS Flow used for Uu-based C2 communication is released, or if the PDN connection / bearer used for Uu-based C2 communication 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, such as combined, explicit, or implicit:

[0478] (A) Information that PC5-based C2 communication is not authorized

[0479] (B) Information that PC5-based C2 communication is not permitted

[0480] (C) Information requesting no resource allocation for PC5-based C2 communication. The resource is a radio resource.

[0481] It is assumed that the UE associated with the information is a UAV, but this is merely an example, and the UE associated with the information may be a UAV-C, or may be both a UAV and a UAV-C.

[0482] The method by which the Core Network provides the above information (e.g., one or more pieces of information (A) to (C)) to the base station may be based on one or more of the following:

[0483] The SMF can include the information in (or in this form) the N2 message / information and transmit it to the base station via the AMF.

[0484] The SMF provides the information to the AMF, which then transmits it to the base station. The SMF provides the information to the AMF in the form of an event notification.

[0485] The SMF+PGW-C provides the information to the MME, which can then send it to the base station.

[0486] The SMF requests the UDM to provide the information or report the information to the AMF. At that time, the UDM provides / reports the information to the AMF, and the AMF can transmit it to the base station. In this case, the UDM can also provide / report the information to the AMF for the UE's partner UE (i.e., UAV-C if the UE is a UAV, or UAV if the UE is a UAV-C) so that the AMF can transmit it to the base station. Information about the UE's partner UE can be based on subscriber information.

[0487] 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 corresponding UE.

[0488] In the first to fourth examples of the present disclosure described based on the various examples, a method for supporting C2 communication using a PC5 interface has been described in relation to the execution of Uu-based C2 communication authorization. The content described in relation to C2 communication using a PC5 interface in the present disclosure can also be applied to the case where Uu-based C2 communication re-authorization is executed.

[0489] In the first to fourth examples of the disclosure of this specification described based on the various examples above, operations related to PC5-based C2 communication may also be interpreted as including PC5 operations for performing such operations or other PC5 operations related thereto (e.g., Direct discovery).

[0490] The following drawings are created to explain a specific example of the present specification. The names of specific devices and names of specific signals / messages / fields shown in the drawings are provided for illustrative purposes only, and the technical features of the present specification are not limited to the specific names used in the following drawings.

[0491] FIG. 15 illustrates an example procedure according to one embodiment of the present disclosure.

[0492] For reference, the procedure illustrated in Figure 15 is merely an example, and the scope of the disclosure of this specification is not limited by the example of Figure 15. For example, the UE, SMF, and USS illustrated in Figure 15 may perform the operations described in the examples of Figures 1 to 14. For reference, the example of Figure 15 does not illustrate the AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc., but this is for convenience of explanation. In other words, even in the embodiment based on Figure 15, the AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc. may perform the operations described in various examples of the disclosure of this specification.

[0493] For example, the operations described in the examples of Figures 1 to 14 may also be applied to the example of Figure 15. For example, even if there are operations or content not directly described in the example of Figure 15, the operations or content described in various examples of the disclosure of this specification may be applied.

[0494] In step S1501, a UE (e.g., a UAV) may send a request message to the SMF. For example, the UE may request authorization for direct C2 communication with the UAV-C. For example, the request message sent by the UE may include information requesting authorization for direct C2 communication. For example, the authentication request message may include C2 aviation payload information, which may include information about authorization for direct C2 communication.

[0495] In step S1502, the SMF may send an authentication request message to the USS. For example, the SMF may send a message related to authentication to the USS via the UAS NF / NEF. The authentication request message sent by the SMF may be, for example, an 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 as an Nnef_Authentication_AuthenticateAuthorize request message and send it to the USS.

[0496] In step S1503, the USS may send an authentication response message to the SMF. Here, the authentication response message may be, for example, a Naf_Authentication_AuthenticateAuthorize response message. If the USS successfully performs direct C2 authentication, the USS may send an authentication response message including the application layer ID of the UAV-C to the SMF. The application layer ID of the UAV-C may be transmitted to the UE. For example, the Naf_Authentication_AuthenticateAuthorize response message sent by the USS may include a C2 authentication payload, and the C2 authentication payload may directly include C2 pairing information. The C2 pairing information may include the application layer ID of the UAV-C.

[0497] The SMF can convey the application layer ID of the UAV to the UE.

[0498] If the USS fails the direct C2 authentication, the USS can send a response message to the SMF containing information that the direct C2 authentication failed. In this case, the SMF can send information to the UE informing it not to perform C2 communication based on PC5.

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

[0500] According to an embodiment of the present disclosure, the following exemplary operations may be performed in relation to setting whether PC5-based C2 communication is permitted based on the result of Uu-based C2 communication authorization. For example, the result of Uu-based C2 communication authorization (or authorization with USS / network) may instruct or configure a UE as to whether PC5-based C2 communication can be performed. For example, the UE may perform Uu-based C2 communication authorization (or authorization with USS / network) before performing PC5-based C2 communication. For example, the UE may determine whether PC5-based C2 communication can be performed based on the result of Uu-based C2 communication authorization (i.e., success or failure) and instruction / configuration information on whether PC5-based C2 communication can be performed.

[0501] According to an embodiment of the present disclosure, in relation to setting whether PC5-based C2 communication is permissible when Uu-based C2 communication revocation is performed, the following exemplary operations may be performed. For example, when Uu-based C2 communication revocation is performed, a UE may be instructed or configured as to whether PC5-based C2 communication can be performed. For example, Uu-based C2 communication revocation may be performed. For example, based on instruction / configuration information on whether PC5-based C2 communication can be performed, the UE may determine whether PC5-based C2 communication can be performed / sustained.

[0502] According to various examples of the disclosure of the present specification, the present specification may have various effects. For example, authorization for executing C2 communication between a UAV and a UAV-C may be effectively performed. For example, a UAV may execute 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 a C2 communication authorization procedure via Uu. For example, if C2 communication via PC5 is authorized via the C2 communication authorization procedure via Uu (i.e., by executing authorization with the USS / network), if the C2 communication authorization procedure via Uu fails, C2 communication via PC5 may not be executed.

[0503] The effects that can be obtained through the specific examples of this specification are not limited to the effects listed above. For example, there may be various technical effects that a person having ordinary skill in the related art can understand or derive from this specification. Therefore, the specific effects of this specification are not limited to those explicitly described in this specification, but may include various effects that can be understood or derive from the technical features of this specification.

[0504] For reference, the operations of the terminal (e.g., UE, UAV, UAV-C, etc.) described herein may be implemented by the devices of FIGS. 1 to 3. For example, the terminal (e.g., UE) may be the first device 100 or the second device 200 of FIG. 2. For example, the operations of the terminal described herein may be processed by one or more processors 102 or 202. The 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 the one or more processors 102 or 202. The one or more processors 102 or 202 may control the one or more memories 104 or 204 and one or more transceivers 105 or 206 to execute the instructions / programs stored in the one or more memories 104 or 204, thereby performing the operations of the terminal (e.g., UE) described in the disclosure of this specification.

[0505] The instructions for performing the operations of the terminal described in this disclosure may also be stored on a non-volatile computer-readable storage medium, which may be included in one or more memories 104 or 204. The instructions stored on the storage medium may then be executed by one or more processors 102 or 202 to perform the operations of the terminal described in this disclosure.

[0506] For reference, the operations of a network node (e.g., AMF, SMF, UPF, PCF, USS, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc.) or a base station (e.g., (R)AN, NG-RAN, gNB, etc.) described herein may be implemented by the devices of FIGS. 1 to 3 described below. For example, the network node or base station is the first device 100 or the second device 200 of FIG. 2. For example, the operations of the network node or base station described herein may be processed by one or more processors 102 or 202. The 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 the one or more processors 102 or 202. The one or more processors 102 or 202 may control the one or more memories 104 or 204 and the one or more transceivers 106 or 206 and execute instructions / programs stored in the one or more memories 104 or 204 to perform the operations of the network node or base station described in this disclosure.

[0507] Additionally, instructions for performing the network node or base station operations described in this disclosure may be stored on a non-volatile (or non-transitory) computer-readable storage medium, which may be included in one or more memories 104 or 204. The instructions stored on the storage medium may then be executed by one or more processors 102 or 202 to perform the network node or base station operations described in this disclosure.

[0508] Although the preferred embodiments have been described above as examples, the disclosure of this specification is not limited to such specific embodiments, and various modifications, changes, or improvements can be made within the spirit of this specification and the scope of the claims.

[0509] In the exemplary systems described above, the methods are described based on flowcharts as a series of steps or blocks, but are not limited to the order of the steps described, and a step 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 flowcharts are not exclusive, and other steps may be included, or one or more steps in the flowcharts may be omitted without affecting the scope of the scope.

[0510] The claims described herein may be combined in various ways. For example, technical features of method claims herein may be combined and embodied in an apparatus, and technical features of apparatus claims herein may be combined and embodied in a method. Furthermore, technical features of method claims herein and technical features of apparatus claims herein may be combined and embodied in an apparatus, and technical features of method claims herein and technical features of apparatus claims herein may be combined and embodied in a method. Other implementations are within the scope of the following claims.

Claims

1. A method for a Session Management Function (SMF) to perform communication, comprising: receiving authorization request information for direct Command and Control (C2) communication from User Equipment (UE); sending an authentication request message to an Uncrewed Aerial System (UAS) Service Supplier (USS); receiving an Uncrewed Aerial Vehicle (UAV) controller (UAV-C) application hierarchical ID from the USS based on successful authentication for the direct C2 communication; and A method comprising the step of transmitting an application layer ID of the UAV-C to the UE.

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

3. The method according to claim 2, wherein the application layer ID of the UAV-C is set in target user information (Target User Info).

4. The method of claim 3, wherein a direct communication request message including the target user information is transmitted by the UE.

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

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

7. The direct C2 communication 7. The method according to any one of claims 1 to 6, characterized in that it involves a direct C2 link established via a PC5 reference point between the UAV controller and the UAV.

8. The method according to any one of claims 1 to 7, characterized in that if the authentication for the direct C2 communication fails, information informing the UE not to perform the direct C2 communication is transmitted to the UE.

9. A Session Management Function (SMF) configured to operate in a wireless communication system, the SMF comprising: one or more transceivers; one or more processors; and one or more memories operable to store instructions and to be coupled to the one or more processors; The SMF, wherein the operations performed upon the instructions being executed by the one or more processors are the methods according to any one of claims 1 to 8.

10. A method for performing communication by a User Equipment (UE), comprising: sending authorization request information for direct Command and Control (C2) communication to a Session Management Function (SMF); The authentication request information is used by the SMF to send an authentication request message to an Uncrewed Aerial System (UAS) Service Supplier (USS); and receiving an application layer ID of an Uncrewed Aerial Vehicle (UAV) controller (UAV-C) from the SMF; The method, characterized in that the application layer ID of the UAV-C is sent by the USS to the UE via the SMF based on successful authentication for the direct C2 communication.

11. The method of claim 10, further comprising: establishing a PC5-based unicast link with the UAV-C based on an application layer ID of the UAV-C.

12. The method of claim 11, further comprising the step of sending a direct communication request message to the UAV-C, the message including target user information set to the application layer ID of the UAV-C.

13. The direct C2 communication 13. The method of any one of claims 10 to 12, characterized in that it involves a direct C2 link established via a PC5 reference point between the UAV controller and the UAV.

14. The method of any one of claims 10 to 13, further comprising receiving information from the SMF informing the SMF not to perform the direct C2 communication.

15. In 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 operable to store instructions and to be coupled to the one or more processors; 15. The UE, wherein the operation performed upon the instruction being executed by the one or more processors is a method according to any one of claims 10 to 14.

16. An apparatus for mobile communications, comprising: at least one processor; and at least one memory that stores instructions and is operably electrically coupled to the at least one processor; The operations that are performed upon the execution of the instruction by the at least one processor include: sending authorization request information for direct Command and Control (C2) communication to a Session Management Function (SMF); The authentication request information is used by the SMF to send an authentication request message to an Uncrewed Aerial System (UAS) Service Supplier (USS); and receiving an application layer ID of an Uncrewed Aerial Vehicle (UAV) controller (UAV-C) from the SMF; The device, characterized in that the application layer ID of the UAV-C is sent by the USS to the UE via the SMF based on successful authentication for the direct C2 communication.

17. A non-transitory computer-readable storage medium that records an instruction, The instructions, when executed by one or more processors, cause the one or more processors to: sending authorization request information for direct Command and Control (C2) communication to a Session Management Function (SMF); The authentication request information is used by the SMF to send an authentication request message to an Uncrewed Aerial System (UAS) Service Supplier (USS); and receiving an application layer ID of an Uncrewed Aerial Vehicle (UAV) controller (UAV-C) from the SMF; The CRM is characterized in that the application layer ID of the UAV-C is transmitted to the UE by the USS via the SMF based on successful authentication for the direct C2 communication.

Images