WO2024085512A1 - 직접 c2 인증 - Google Patents

직접 c2 인증 Download PDF

Info

Publication number
WO2024085512A1
WO2024085512A1 PCT/KR2023/015402 KR2023015402W WO2024085512A1 WO 2024085512 A1 WO2024085512 A1 WO 2024085512A1 KR 2023015402 W KR2023015402 W KR 2023015402W WO 2024085512 A1 WO2024085512 A1 WO 2024085512A1
Authority
WO
WIPO (PCT)
Prior art keywords
uav
communication
information
smf
direct
Prior art date
Application number
PCT/KR2023/015402
Other languages
English (en)
French (fr)
Inventor
김래영
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2024085512A1 publication Critical patent/WO2024085512A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • This specification relates to mobile communications.
  • 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) is a technology to enable high-speed packet communication. Many methods have been proposed to achieve the LTE goals of reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. 3GPP LTE requires lower cost per bit, improved service usability, flexible use of frequency bands, simple structure, open interface, and appropriate power consumption of the terminal as high-level requirements.
  • NR New Radio
  • 3GPP identifies the technology components needed to successfully standardize NR that meets both urgent market needs and the longer-term requirements presented by the ITU Radio communication sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process in a timely manner. and must be developed. Additionally, NR should be able to use any spectrum band up to at least 100 GHz, which can be used for wireless communications even in the distant future.
  • ITU-R ITU Radio communication sector
  • IMT International Mobile Telecommunications
  • NR targets a single technology framework that addresses all deployment scenarios, usage scenarios, and requirements, including enhanced Mobile Broadband (eMBB), massive Machine Type-Communications (mMTC), and Ultra-Reliable and Low Latency Communications (URLLC). do. NR must be inherently forward compatible.
  • eMBB enhanced Mobile Broadband
  • mMTC massive Machine Type-Communications
  • URLLC Ultra-Reliable and Low Latency Communications
  • Uncrewed Aerial System UAS
  • C2 Command and Control
  • UAV Uncrewed Aerial Vehicle
  • UAV-C UAV-Controller
  • SMF provides a method for conducting communications.
  • the method includes receiving authentication request information for C2 communication directly from the UE; Transmitting an authentication request message to USS; Receiving an application layer ID of UAV-C from USS; And it may include transmitting the application layer ID of the UAV-C to the UE.
  • an apparatus implementing the method is provided.
  • a method for a UE to perform communication includes transmitting authentication request information for direct C2 communication to the SMF; And it may include receiving the application layer ID of the UAV-C from the SMF.
  • an apparatus implementing the method is provided.
  • FIG. 1 shows an example of a communication system to which implementations of the present disclosure are applied.
  • FIG. 2 shows an example of a wireless device to which implementations of the present disclosure are applied.
  • Figure 3 shows an example of a UE to which the implementation of the present specification is applied.
  • Figure 4 shows an example of a 5G system structure to which the implementation of the present specification is applied.
  • Figures 5 and 6 show an example of a PDU session establishment procedure to which the implementation of the present specification is applied.
  • Figure 7 shows an example of a logical 5GS and EPS architecture for a UAV.
  • 8A and 8B illustrate a procedure according to a first example of the first example of the disclosure herein.
  • 9A and 9B illustrate a procedure according to a second example of the first example of the disclosure herein.
  • FIG. 10 illustrates a procedure according to a third example of the first example of the disclosure herein.
  • Example 11 illustrates a procedure according to a fourth example of Example 1 of the disclosure of this specification.
  • Figure 12 shows a procedure for establishing a layer-2 link through a PC5 reference point, according to an embodiment of the disclosure of the present specification.
  • Figure 13 shows an example of a PDU session establishment procedure for C2 communication according to an embodiment of the disclosure of the present specification.
  • Figure 14 is an example of a PDN connection for C2 authentication according to an embodiment of the disclosure of the present specification.
  • Figure 15 shows an example of a procedure according to one embodiment of the disclosure herein.
  • multiple access systems include Code Division Multiple Access (CDMA) systems, Frequency Division Multiple Access (FDMA) systems, Time Division Multiple Access (TDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, and Single Access (SC-FDMA) systems. It includes a Carrier Frequency Division Multiple Access (MC-FDMA) system and a Multi-Carrier Frequency Division Multiple Access (MC-FDMA) system.
  • CDMA can be implemented through wireless technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000.
  • TDMA can be implemented over wireless technologies such as Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data rates for GSM Evolution (EDGE).
  • OFDMA can be implemented through wireless technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA).
  • UTRA is part of the Universal Mobile Telecommunications System (UMTS).
  • 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) is part of Evolved UMTS (E-UMTS) using E-UTRA.
  • 3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL).
  • the evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and/or 5G NR (New Radio).
  • implementations herein are primarily described in relation to a 3GPP based wireless communication system.
  • the technical features of this specification are not limited to this.
  • the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of the present specification that are not limited to a 3GPP-based wireless communication system can be applied to other mobile communication systems.
  • a or B may mean “only A,” “only B,” or “both A and B.” In other words, in this specification, “A or B” may be interpreted as “A and/or B.”
  • A, B or C refers to “only A,” “only B,” “only C,” or “any and all combinations of A, B, and C ( It can mean “any combination of A, B and C)”.
  • the slash (/) or comma used in this specification may mean “and/or.”
  • A/B can mean “A and/or B.”
  • A/B can mean “only A,” “only B,” or “both A and B.”
  • A, B, C can mean “A, B, or C.”
  • At least one of A and B may mean “only A,” “only B,” or “both A and B.”
  • the expression “at least one of A or B” or “at least one of A and/or B” means “A and It can be interpreted the same as “at least one of A and B.”
  • At least one of A, B and C means “only A”, “only B”, “only C”, or “A, B and C”. It may mean “any combination of A, B and C”.
  • at least one of A, B or C” or “at least one of A, B and/or C” means It may mean “at least one of A, B and C.”
  • control information may be proposed as an example of “control information.”
  • control information in this specification is not limited to “PDCCH,” and “PDCCH” may be proposed as an example of “control information.”
  • PDCCH control information
  • FIG. 1 shows an example of a communication system to which implementations of the present disclosure are applied.
  • the 5G usage scenario shown in FIG. 1 is only an example, and the technical features of this specification can be applied to other 5G usage scenarios not shown in FIG. 1.
  • the three main requirements categories for 5G are (1) enhanced Mobile BroadBand (eMBB) category, (2) massive Machine Type Communication (mMTC) category, and (3) ultra-reliable low-latency communication. (URLLC; Ultra-Reliable and Low Latency Communications) category.
  • eMBB enhanced Mobile BroadBand
  • mMTC massive Machine Type Communication
  • URLLC Ultra-Reliable and Low Latency Communications
  • the communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200, and a network 300.
  • Figure 1 illustrates a 5G network as an example of a network of the communication system 1, but the implementation of this specification is not limited to the 5G system and can be applied to future communication systems beyond the 5G system.
  • Base station 200 and network 300 may be implemented as wireless devices, and certain wireless devices may operate as base stations/network nodes in relation to other wireless devices.
  • Wireless devices 100a to 100f represent devices that perform communication using Radio Access Technology (RAT) (e.g., 5G NR or LTE), and may also be referred to as communication/wireless/5G devices.
  • Wireless devices 100a to 100f include, but are not limited to, robots 100a, vehicles 100b-1 and 100b-2, extended reality (XR; eXtended Reality) devices 100c, portable devices 100d, and home appliances. It may include a product 100e, an Internet-Of-Things (IoT) device 100f, and an Artificial Intelligence (AI) device/server 400.
  • vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of vehicle-to-vehicle communication.
  • Vehicles may include Unmanned Aerial Vehicles (UAVs) (e.g., drones).
  • UAVs Unmanned Aerial Vehicles
  • XR devices may include Augmented Reality (AR)/Virtual Reality (VR)/Mixed Realty (MR) devices and may be mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. It can be implemented in the form of a Head-Mounted Device (HMD) or Head-Up Display (HUD).
  • Portable devices may include smartphones, smart pads, wearable devices (e.g., smart watches or smart glasses), and computers (e.g., laptops).
  • Home appliances may include TVs, refrigerators, and washing machines.
  • IoT devices can include sensors and smart meters.
  • the wireless devices 100a to 100f may be referred to as user equipment (UE).
  • UE includes, for example, mobile phones, smartphones, laptop computers, digital broadcasting terminals, PDA (Personal Digital Assistant), PMP (Portable Multimedia Player), navigation systems, slate PCs, tablet PCs, ultrabooks, vehicles, and autonomous driving functions.
  • vehicles connected cars, UAVs, AI modules, robots, AR devices, VR devices, MR devices, hologram devices, public safety devices, MTC devices, IoT devices, medical devices, fintech devices (or financial devices), security devices , weather/environment devices, 5G service-related devices, or 4th Industrial Revolution-related devices.
  • Wireless devices 100a to 100f may be connected to the network 300 through the base station 200.
  • AI technology may be applied to the wireless devices 100a to 100f, and the wireless devices 100a to 100f may be connected to the AI server 400 through the network 300.
  • the network 300 may be configured using a 3G network, a 4G (eg, LTE) network, a 5G (eg, NR) network, and a post-5G network.
  • Wireless devices 100a - 100f may communicate with each other via base station 200/network 300, but communicate directly (e.g., sidelink communication) rather than via base station 200/network 300. You may.
  • vehicles 100b-1 and 100b-2 may perform direct communication (e.g., vehicle-to-vehicle (V2V)/vehicle-to-everything (V2X) communication).
  • an IoT device e.g., sensor
  • another IoT device e.g., sensor
  • another wireless device e.g., 100f
  • Wireless communication/connections 150a, 150b, 150c may be established between wireless devices 100a - 100f and/or between wireless devices 100a - 100f and base station 200 and/or between base station 200.
  • wireless communication/connection includes uplink/downlink communication (150a), sidelink communication (150b) (or D2D (Device-To-Device) communication), communication between base stations (150c) (e.g. relay, IAB (Integrated Access and Backhaul) can be established through various RATs (e.g. 5G NR).
  • RATs e.g. 5G NR
  • wireless communication/connection 150a, 150b, and 150c may transmit/receive signals through various physical channels.
  • various configuration information setting processes for transmitting/receiving wireless signals various signal processing processes (e.g. channel encoding/decoding, modulation/demodulation, resource mapping/demapping, etc.), and a resource allocation process, etc. may be performed.
  • NR supports multiple numerologies or subcarrier spacing (SCS) to support various 5G services. For example, if SCS is 15kHz, it supports a wide area in traditional cellular bands, and if SCS is 30kHz/60kHz, it supports dense-urban, lower latency, and wider areas. It supports a wider carrier bandwidth, and when SCS is 60kHz or higher, it supports a bandwidth greater than 24.25GHz to overcome phase noise.
  • SCS subcarrier spacing
  • the NR frequency band can be defined as two types of frequency ranges (FR1, FR2).
  • the values of the frequency range may vary.
  • the frequency ranges of the two types (FR1, FR2) may be as shown in Table 1 below.
  • FR1 may mean “sub 6GHz range”
  • FR2 may mean “above 6GHz range” and may be referred to as MilliMeter Wave (mmW). there is.
  • mmW MilliMeter Wave
  • Frequency range definition frequency range Subcarrier spacing FR1 450MHz - 6000MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz
  • FR1 may include a band of 410MHz to 7125MHz as shown in Table 2 below. That is, FR1 may include a frequency band of 6GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency band above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included within FR1 may include an unlicensed band. Unlicensed bands can be used for a variety of purposes, for example for communications for vehicles (e.g. autonomous driving).
  • Frequency range definition frequency range Subcarrier spacing FR1 410MHz - 7125MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240 kHz
  • wireless communication technologies implemented in the wireless device of this specification may include NarrowBand IoT (NB-IoT) for low-power communication as well as LTE, NR, and 6G.
  • NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) 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.
  • the wireless communication technology implemented in the wireless device of the present specification may perform communication based on LTE-M technology.
  • LTE-M technology may be an example of LPWAN technology and may be called various names such as enhanced MTC (eMTC).
  • eMTC enhanced MTC
  • LTE-M technologies include 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, etc. may be implemented in at least one of various standards, and are not limited to the above-mentioned names.
  • the wireless communication technology implemented in the wireless device of the present specification may include at least one of ZigBee, Bluetooth, and/or LPWAN considering low-power communication, and is limited to the above-mentioned names. That is not the case.
  • ZigBee technology can create PANs (Personal Area Networks) related to small/low-power digital communications based on various standards such as IEEE 802.15.4, and can be called by various names.
  • FIG. 2 shows an example of a wireless device to which implementations of the present disclosure are applied.
  • the first wireless device 100 and/or the second wireless device 200 may be implemented in various forms depending on usage examples/services.
  • ⁇ first wireless device 100 and second wireless device 200 ⁇ are ⁇ wireless devices 100a to 100f and base station 200 ⁇ of FIG. 1, ⁇ wireless devices 100a to 100f ) and wireless devices (100a to 100f) ⁇ and/or ⁇ base station 200 and base station 200 ⁇ .
  • the first wireless device 100 and/or the second wireless device 200 may be composed of various components, devices/parts and/or modules.
  • the 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.
  • 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 include processing chip 101. ) can be placed externally.
  • Processor 102 may control memory 104 and/or transceiver 106 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • the processor 102 may process information in the memory 104 to generate first information/signal and transmit a wireless signal including the first information/signal through the transceiver 106.
  • the processor 102 may receive a wireless signal including the second information/signal through the transceiver 106 and store information obtained by processing the second information/signal in the memory 104.
  • Memory 104 may be operatively coupled to processor 102. Memory 104 may store various types of information and/or instructions. Memory 104 may include firmware and/or code that, when executed by processor 102, implements code, instructions, and/or sets of instructions that perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • Software code 105 may be stored.
  • firmware and/or software code 105 may, when executed by processor 102, implement instructions that perform the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • firmware and/or software code 105 may control processor 102 to perform one or more protocols.
  • firmware and/or software code 105 may control processor 102 to perform one or more air interface protocol layers.
  • the processor 102 and memory 104 may be part of a communication modem/circuit/chip designed to implement RAT (eg, LTE or NR).
  • Transceiver 106 may be coupled to processor 102 to transmit and/or receive wireless signals via one or more antennas 108.
  • Each transceiver 106 may include a transmitter and/or receiver.
  • the transceiver 106 can be used interchangeably with the RF (Radio Frequency) unit.
  • the first wireless device 100 may represent a communication modem/circuit/chip.
  • the 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.
  • 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 include processing chip 201. ) can be placed externally.
  • 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.
  • the processor 202 may process information in the memory 204 to generate third information/signal and transmit a wireless signal including the third information/signal through the transceiver 206.
  • the processor 202 may receive a wireless signal including the fourth information/signal through the transceiver 206, and store information obtained by processing the fourth information/signal in the memory 204.
  • Memory 204 may be operatively coupled to processor 202. Memory 204 may store various types of information and/or instructions. Memory 204 may include firmware and/or code that, when executed by processor 202, implements code, instructions, and/or sets of instructions that perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • Software code 205 may be stored.
  • firmware and/or software code 205 may, when executed by processor 202, implement instructions that perform the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • firmware and/or software code 205 may control processor 202 to perform one or more protocols.
  • firmware and/or software code 205 may control processor 202 to perform one or more air interface protocol layers.
  • the processor 202 and memory 204 may be part of a communication modem/circuit/chip designed to implement RAT (eg, LTE or NR).
  • Transceiver 206 may be coupled to processor 202 to transmit and/or receive wireless signals via one or more antennas 208.
  • Each transceiver 206 may include a transmitter and/or receiver.
  • the transceiver 206 can be used interchangeably with the RF unit.
  • the second wireless device 200 may represent a communication modem/circuit/chip.
  • one or more protocol layers may be implemented by one or more processors 102, 202.
  • one or more processors 102, 202 may support one or more layers (e.g., a physical (PHY) layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, Functional layers such as RRC (Radio Resource Control) layer and SDAP (Service Data Adaptation Protocol) layer) can be implemented.
  • layers e.g., a physical (PHY) layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, Functional layers such as RRC (Radio Resource Control) layer and SDAP (Service Data Adaptation Protocol) layer
  • PHY physical
  • MAC Media Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • Functional layers such as RRC (Radio Resource Control) layer and SDAP (Service Data
  • One or more processors 102, 202 may process one or more Protocol Data Units (PDUs), one or more Service Data Units (SDUs), messages, and controls according to the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein. It can generate information, data or information.
  • One or more processors 102, 202 may process signals (e.g., baseband) containing PDUs, SDUs, messages, control information, data, or information in accordance with the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein. signal) can be generated and provided to one or more transceivers (106, 206).
  • One or more processors (102, 202) may receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein. Depending on the PDU, SDU, message, control information, data or information can be obtained.
  • signals e.g., baseband signals
  • One or more processors 102, 202 may be referred to as a controller, microcontroller, microprocessor, and/or microcomputer.
  • One or more processors 102, 202 may be implemented by hardware, firmware, software, and/or a combination thereof.
  • ASICs Application Specific Integrated Circuits
  • DSPs Digital Signal Processors
  • DSPDs Digital Signal Processing Devices
  • PLDs Programmable Logic Devices
  • FPGAs Field Programmable Gates
  • one or more processors 102, 202 may include a communication control processor, an application processor (AP), an electronic control unit (ECU), a central processing unit (CPU), and a graphics processing unit. It can be configured by a set of (GPU; Graphic Processing Unit) and a memory control processor.
  • One or more memories 104, 204 may be connected to one or more processors 102, 202 and may store various types of data, signals, messages, information, programs, codes, instructions, and/or instructions.
  • One or more memories 104 and 204 may include random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, volatile memory, non-volatile memory, hard drive, It may consist of registers, cache memory, computer-readable storage media, and/or combinations thereof.
  • RAM random access memory
  • DRAM dynamic RAM
  • ROM read-only memory
  • EPROM erasable programmable ROM
  • flash memory volatile memory
  • non-volatile memory hard drive
  • It may consist of registers, cache memory, computer-readable storage media, and/or combinations thereof.
  • One or more memories 104, 204 may be located internal to and/or external to one or more processors 102, 202. Additionally, one or more memories 104, 204 may be connected to one or more processors 102, 202 through various technologies, such as wired or wireless connections.
  • One or more transceivers 106, 206 may transmit user data, control information, wireless signals/channels, etc. referred to 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 may receive user data, control information, wireless signals/channels, etc. referred to in the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein from one or more other devices. there is.
  • one or more transceivers 106 and 206 may be connected to one or more processors 102 and 202 and may transmit and receive wireless signals.
  • one or more processors 102, 202 may control one or more transceivers 106, 206 to transmit user data, control information, wireless signals, etc. to one or more other devices. Additionally, one or more processors 102 and 202 may control one or more transceivers 106 and 206 to receive user data, control information, wireless signals, etc. from one or more other devices.
  • One or more transceivers (106, 206) may be connected to one or more antennas (108, 208). Additionally and/or alternatively, one or more transceivers (106, 206) may include one or more antennas (108, 208). One or more transceivers (106, 206) transmit, through one or more antennas (108, 208), user data, control information, and wireless signals/channels referred to in the descriptions, functions, procedures, proposals, methods, and/or operational flow diagrams disclosed herein. It may be configured to transmit and receive, etc.
  • one or more antennas 108 and 208 may be a plurality of physical antennas or a plurality of logical antennas (eg, antenna ports).
  • One or more transceivers (106, 206) process the received user data, control information, wireless signals/channels, etc. using one or more processors (102, 202). etc. can be converted from an RF band signal to a baseband signal.
  • One or more transceivers (106, 206) may convert user data, control information, wireless signals/channels, etc. processed using one or more processors (102, 202) from baseband signals to RF band signals.
  • one or more transceivers 106, 206 may include an (analog) oscillator and/or filter.
  • one or more transceivers (106, 206) up-convert an OFDM baseband signal to an OFDM signal through an (analog) oscillator and/or filter under the control of one or more processors (102, 202). , the up-converted OFDM signal can be transmitted at the carrier frequency.
  • One or more transceivers (106, 206) receive an OFDM signal at a carrier frequency and, under the control of one or more processors (102, 202), down-convert the OFDM signal to an OFDM baseband signal via an (analog) oscillator and/or filter ( down-convert).
  • wireless devices 100 and 200 may further include additional components.
  • Additional components 140 may be configured in various ways depending on the type of wireless device 100 or 200.
  • 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 device, and a computing device. You can.
  • Additional components 140 may be connected to one or more processors 102, 202 through various technologies, such as wired or wireless connections.
  • the UE may operate as a transmitting device in the uplink and as a receiving device in the downlink.
  • the base station may operate as a receiving device in the UL and as a transmitting device in the DL.
  • the first wireless device 100 operates as a UE and the second wireless device 200 operates as a base station.
  • a processor 102 connected to, mounted on, or released from the first wireless device 100 may perform UE operations according to implementations herein or may use transceiver 106 to perform UE operations according to implementations herein. It can be configured to control.
  • the processor 202 connected to, mounted on, or released from the second wireless device 200 is configured to perform a base station operation according to an implementation of the present specification or to control the transceiver 206 to perform a base station operation according to the implementation of the present specification. It can be.
  • the base station may be referred to as Node B, eNode B (eNB), or gNB.
  • Node B Node B
  • eNode B eNode B
  • gNB gNode B
  • Figure 3 shows an example of a UE to which the implementation of the present specification is applied.
  • UE 100 may correspond to the first wireless device 100 of FIG. 2.
  • UE 100 includes a processor 102, memory 104, transceiver 106, one or more antennas 108, power management module 141, battery 142, display 143, keypad 144, and SIM.
  • SIM Subscriber Identification Module
  • Processor 102 may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein. Processor 102 may be configured to control one or more other components of UE 100 to implement the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • a layer of the air interface protocol may be implemented in processor 102.
  • Processor 102 may include ASICs, other chipsets, logic circuits, and/or data processing devices.
  • Processor 102 may be 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).
  • processors 102 include SNAPDRAGON TM series processors manufactured by Qualcomm®, EXYNOS TM series processors manufactured by Samsung®, A series processors manufactured by Apple®, HELIO TM series processors manufactured by MediaTek®, and ATOM TM series processors manufactured by Intel®. Alternatively, it can be found in the corresponding next-generation processor.
  • the memory 104 is operatively coupled to the processor 102 and stores various information for operating the processor 102.
  • Memory 104 may include ROM, RAM, flash memory, memory cards, storage media, and/or other storage devices.
  • modules e.g., procedures, functions, etc.
  • 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 through various methods known in the art.
  • Transceiver 106 is operatively coupled to processor 102 and transmits and/or receives wireless signals.
  • Transceiver 106 includes a transmitter and a receiver.
  • 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 wireless signals.
  • the power management module 141 manages power of the processor 102 and/or the transceiver 106.
  • the battery 142 supplies power to the power management module 141.
  • the display 143 outputs the results processed by the processor 102.
  • Keypad 144 receives input for use by processor 102.
  • the keypad 144 may be displayed on the display 143.
  • the SIM card 145 is an integrated circuit for securely storing an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate subscribers in mobile phone devices such as mobile phones and computers. You can also store contact information on many SIM cards.
  • IMSI International Mobile Subscriber Identity
  • the speaker 146 outputs sound-related results processed by the processor 102.
  • Microphone 147 receives sound-related input for use by processor 102.
  • Figure 4 shows an example of a 5G system structure to which the implementation of the present specification is applied.
  • the 5G system (5GS; 5G system) structure consists of the following network functions (NF).
  • Data Network e.g. operator services, Internet access or third-party services
  • Figure 4 shows the 5G system architecture for the non-roaming case using a reference point representation that shows how the various network functions interact with each other.
  • the 5G system architecture includes the following reference points:
  • the following baseline shows the interactions that exist between NF services in NF.
  • two NFs may need to be connected to each other to serve the UE.
  • the PDU session establishment procedure is described. Please refer to section 4.3.2 of 3GPP TS 23.502 V16.3.0 (2019-12).
  • Figures 5 and 6 show an example of a PDU session establishment procedure to which the implementation of the present specification is applied.
  • Establishing a PDU session may involve:
  • a PDU session may be (a) associated with a single connection type at any given time, either a 3GPP connection or a non-3GPP connection, or (b) associated with multiple connection types simultaneously, i.e., one 3GPP connection and one non-3GPP connection. It can be related.
  • a PDU session associated with multiple access types is called a multi access (MA) PDU session and may be requested by a UE that supports access traffic steering, switching, splitting (ATSSS).
  • MA multi access
  • Figures 5 and 6 specify procedures for establishing a PDU session associated with a single connection type at a given time.
  • Step 1 To establish a new PDU session, the UE creates a new PDU session ID.
  • the UE transmits a NAS message including a PDU session establishment request message in the N1 SM container to initiate the PDU session establishment procedure requested by the UE.
  • the PDU session establishment request message includes PDU session ID, Requested PDU Session Type, requested session and service continuity (SSC) mode, 5G SM capability, Protocol Configuration Options (PCO), and SM. Includes PDU DN Request Container (SM PDU DN Request Container), UE Integrity Protection Maximum Data Rate, etc.
  • 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 being switched between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing packet data network (PDN) connection in the EPC, the request type is "Existing PDU Session”. ".
  • the request type indicates "Emergency Request.” If the request refers to an existing PDU session for emergency services being switched between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing PDN connection for emergency services in the EPC, the request type is "Existing emergency PDU session ( Existing Emergency PDU Session)”.
  • the UE includes the S-NSSAI from the allowed NSSAI of the current connection type. If a Mapping Of Allowed NSSAI is provided to the UE, the UE provides both the S-NSSAI of the visited VPLMN (VPLMN) from the allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAI. .
  • VPLMN visited VPLMN
  • Step 2 AMF selects SMF. If the request type indicates "initial request", or if the request is due to a handover from an EPS or another AMF-provided non-3GPP connection, the AMF will determine the connection type of the PDU session as well as the association of S-NSSAI(s), DNN ( data network name), PDU session ID, and SMF ID are saved.
  • the AMF selects the SMF and stores the new PDU session ID, S-NSAI(s), and the association of the selected SMF ID. .
  • the AMF selects an SMF based on the SMF-ID received from the UDM. AMF updates the stored connection type for the PDU session.
  • the PDU session establishment procedure can be performed in the following cases.
  • AMF rejects the PDU session establishment request with an appropriate rejection reason.
  • AMF rejects requests from emergency registered UEs where the request type does not indicate "emergency request” or "existing emergency PDU session".
  • Step 3 If the AMF is not associated with an SMF for the PDU session ID provided by the UE (e.g. when the request type indicates "initial request"), the AMF sends the Create SM Context request procedure (e.g. Nsmf_PDUSession_CreateSMContext) Request). If the AMF is already associated with the SMF for the PDU session ID provided by the UE (e.g. when the request type indicates "existing PDU session"), the AMF calls the Update SM Context Request procedure (e.g. Nsmf_PDUSession_UpdateSMContext Request) do.
  • the Create SM Context request procedure e.g. Nsmf_PDUSession_UpdateSMContext Request
  • AMF transmits the S-NSSAI of the serving PLMN from the allowed NSSAI to the SMF.
  • the AMF also transmits the corresponding S-NSSAI of the HPLMN from the mapping of allowed NSSAIs to the SMF.
  • the AMF ID is the UE's GUAMI and uniquely identifies the AMF serving the UE.
  • AMF delivers the PDU session ID along with the N1 SM container containing the PDU session establishment request message received from the UE.
  • GPSI generator public subscription identifier
  • AMF provides PEI instead of SUPI. If a UE in limited service state is registered for emergency services while providing SUPI but is not authenticated, the AMF indicates that SUPI is not authenticated. If the SMF does not receive SUPI for the UE or the AMF indicates that the SUPI is not authenticated, it determines that the UE is not authenticated.
  • AMF can include the PCF ID in Nsmf_PDUSession_CreateSMContext. This PCFID identifies the home PCF (H-PCF) in the non-roaming case and the visited PCF (V-PCF) in the LBO roaming case.
  • Step 4 If the session management subscription data for the S-NSSAI of the corresponding SUPI, DNN, or HPLMN is not available, the SMF may retrieve the session management subscription data from the UDM, and this subscription You can be notified when your data is modified.
  • Step 5 The SMF sends a create SM context response message (e.g., Nsmf_PDUSession_CreateSMContext Response) or an update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to the AMF, according to the request received in step 3.
  • a create SM context response message e.g., Nsmf_PDUSession_CreateSMContext Response
  • an update SM context response message e.g., Nsmf_PDUSession_UpdateSMContext Response
  • the SMF receives the Nsmf_PDUSession_CreateSMContext Request in step 3 and can process the PDU session establishment request, the SMF creates an SM context and responds to the AMF by providing the SM context ID.
  • the SMF rejects the UE request via a NAS SM signal including the relevant SM rejection reason by responding to the AMF with an Nsmf_PDUSession_CreateSMContext Response.
  • the SMF also indicates to the AMF that the PDU session ID is considered released and the SMF proceeds to step 20 below and the PDU session establishment procedure is stopped.
  • Step 6 Optional secondary authentication/authorization may be performed.
  • Step 7a If dynamic policy and charging control (PCC) is used for the PDU session, the SMF may perform PCF selection.
  • PCC dynamic policy and charging control
  • Step 7b The SMF can perform the SM policy association establishment procedure to establish the SM policy association with the PCF and obtain the basic PCC rules for the PDU session.
  • Step 8 SMF selects one or more UPFs.
  • Step 9 The SMF may perform the SM policy association modification procedure initiated by the SMF to provide information about the satisfied policy control request trigger conditions.
  • Step 10 If the request type indicates "initial request", the SMF may initiate an N4 Session Establishment procedure with the selected UPF. Otherwise, the SMF may initiate an N4 Session Modification procedure with the selected UPF.
  • the SMF may send an N4 session establishment/modification request to the UPF and provide packet detection, enforcement and reporting rules to be installed in the UPF for the PDU session.
  • UPF can confirm by sending an N4 session establishment/modification response.
  • Step 11 SMF sends an N1N2 message transfer message (e.g. Namf_Communication_N1N2 Message Transfer) to AMF.
  • N1N2 message transfer message e.g. Namf_Communication_N1N2 Message Transfer
  • the N1N2 message delivery message may include N2 SM information.
  • N2 SM information carries the following information to be delivered by AMF to (R)AN.
  • QFI QoS flow ID
  • - PDU Session ID Indicates to the UE the association between the RAN resource and the PDU session for the UE;
  • - S-NSSAI with value for the serving PLMN (i.e. HPLMN S-NSSAI, or VPLMN S-NSSAI for LBO roaming);
  • the N1N2 message delivery message may include the N1 SM container.
  • the N1 SM container includes a PDU session establishment acceptance message to be provided by AMF to the UE.
  • the PDU Session Establishment Accept message includes the S-NSSAI from the permitted NSASI.
  • the PDU Session Establishment Accept message includes the S-NSSAI from the allowed NSSAI for the VPLMN and also includes the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAI received by the SMF in step 3. .
  • 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.
  • the N1N2 message delivery message includes an N1 SM container including a PDU session establishment rejection message and does not include N2 SM information.
  • (R)AN transmits a NAS message including a PDU session establishment rejection message to the UE. In this case, steps 12-17 below are omitted.
  • Step 12 AMF transmits a NAS message containing the PDU session ID and PDU session establishment acceptance message destined for the UE and the N2 SM information received from the SMF to (R)AN within the N2 PDU session request message.
  • Step 13 (R)AN may perform AN-specific signal exchange with the UE related to information received from the SMF.
  • the UE may perform RRC connection reconfiguration with the UE to set the necessary NG-RAN resources in relation to the QoS rules for the PDU session request received in step 12.
  • (R)AN delivers the NAS message (PDU session ID, N1 SM container (PDU session establishment acceptance message)) received in step 12 to the UE.
  • (R)AN provides NAS messages to the UE only if the AN-specific signaling exchange with the UE includes adding (R)AN resources related to the received N2 command.
  • steps 14 to 16b and 17 below are omitted.
  • Step 14 (R)AN transmits an N2 PDU session response message to AMF.
  • the N2 PDU session response message may include PDU session ID, cause, N2 SM information (PDU session ID, AN tunnel information, accepted/rejected QFI list, user plane enforcement policy notification), etc.
  • Step 15 AMF sends an update SM context request message (e.g. Nsmf_PDUSession_UpdateSMContext Request) to SMF.
  • AMF transmits the N2 SM information received from (R)AN to SMF.
  • Step S16a SMF initiates the N4 session modification procedure with UPF.
  • SMF provides AN tunnel information and corresponding forwarding rules to UPF.
  • Step S16b UPF provides an N4 session modification response to SMF.
  • the UPF can forward any DL packets that may have been buffered for this PDU session to the UE.
  • Step 16c If the SMF is not yet registered for this PDU session, the SMF may register with the UDM for the given PDU session.
  • Step 17 SMF transmits an update SM context response message (e.g. Nsmf_PDUSession_UpdateSMContext Response) to AMF.
  • an update SM context response message e.g. Nsmf_PDUSession_UpdateSMContext Response
  • AMF delivers relevant events to which SMF has subscribed.
  • Step 18 If the PDU session establishment is not successful during the procedure at any time after step 5, the SMF may call Nsmf_PDUSession_SMContextStatusNotify (release) to notify the AMF. The SMF may also release the N4 session that was created, the PDU session address (e.g. IP address) if assigned, and possibly its association with the PCF. In this case, step 19 below is omitted.
  • Nsmf_PDUSession_SMContextStatusNotify release
  • the SMF may also release the N4 session that was created, the PDU session address (e.g. IP address) if assigned, and possibly its association with the PCF.
  • step 19 is omitted.
  • Step 19 For PDU session type IPv6 or IPv4v6, SMF may generate an IPv6 Router Advertisement and transmit it to the UE.
  • Step 20 The SMF may perform SM policy association modifications initiated by the SMF.
  • Step 21 If PDU session establishment fails after step 4, and the SMF no longer processes the UE's PDU session, the SMF may unsubscribe for modification of session management subscription data.
  • a UAS may consist of one or more unmanned aerial vehicles (UAV) (Uncrewed Aerial Vehicle) and one unmanned aerial vehicle controller (UAV-C) (UAV Controller).
  • UAV Uncrewed Aerial Vehicle
  • UAV-C Unmanned aerial vehicle controller
  • the unmanned aerial vehicle may be controlled by an unmanned aerial vehicle controller on a C2 (Command and Control) link of a 3GPP mobile communication network or a non-3GPP mobile communication network.
  • C2 communication may mean Command and Control (C2) Communication.
  • C2 communications convey messages containing command and control information for UAV operation from the UAV controller or Uncrewed Aircraft Systems Traffic Management (UTM) to the UAV, or report telemetry data from the UAV to the UAV controller or UTM. It can refer to a user plane link for
  • UAV For UAS management, USS (UAS Service Supplier)/UTM (UAS Traffic Management) and UAV can exchange application data traffic via 3GPP mobile communication network.
  • UAVs can be considered UEs.
  • the example in Figure 7 below shows a logical 5GS and EPS architecture for a UAV.
  • TS 23.256 V17.0.0 please refer to TS 23.256 V17.0.0.
  • Figure 7 shows an example of a logical 5GS and EPS architecture for a UAV.
  • UAV In order to receive connection services from the network, UAV must perform an authentication procedure through UUAA (UAV USS authentication and authorization procedure). For example, depending on the network operator's policy, authentication may be performed in the following manner.
  • UUAA UAV USS authentication and authorization procedure
  • UUAA can be performed during the UAV registration process in the network: For example, the UAV may have an Aerial UE subscription in Access and Mobility Subscription data. If the registration request message transmitted by the UAV includes a CAA-Level UAV ID, UUAA may be performed (this may be referred to as UUAA-MM). If UUAA-MM is not performed, the UAV can perform UUAA during the PDU session creation process.
  • UUAA-SM UUAA-SM
  • 5GS the UAV has a CAA-Level UAV ID
  • UUAA-SM can be started by the SMF when provided in the PDU session creation request message.
  • EPS if the UAV provides the CAA-Level UAV ID to the ESM message container, it can be started by SMF+PGW-C.
  • UAV communication can be divided into USS communication and C2 communication between the UAV and USS.
  • USS communication may be user plane data transmission excluding C2 communication.
  • PDU Session/PDN Connection for C2 communication and PDU Session/PDN Connection for USS communication may be used in common or may be used separately. That is, the PDU Session/PDN Connection for C2 communication and the PDU Session/PDN Connection for USS communication may be the same or different.
  • the UAS Network Function is supported by NEF (Network Exposure Function) or SCEF (Service Capability Exposure Function) + NEF and can be used for external exposure of services to the USS.
  • NEF Network Exposure Function
  • SCEF Service Capability Exposure Function
  • UAS-NF exposes existing NEF/SCEF services for operations such as authentication/authorization of UAV, flight authorization, withdrawal of UAV-UAVC pairing authorization and related operations, location reporting, and control of QoS/traffic filtering for C2 communication. You can use .
  • UAS NF can store the results of the UUAA-MM process and the results of the UUAA-SM process.
  • the UAS NF can store whether re-authentication should be requested from AMF or SMF/SMF+PGW-C, along with the current service
  • the address of the AMF or SMF/SMF+PGW-C being provided may be stored.
  • the USS can start the re-authentication process through UAS NF at any time after the UUAA process is completed.
  • UUAA re-authentication can be performed through SMF (UUAA-SM) or AMF (UUAA-MM), depending on network settings.
  • the result of re-authentication can be delivered from the USS to the UE via the UAS NF via SMF (UUAA-SM) or AMF (UUAA-MM).
  • 3GPP TR 23.700-58 v1.0.0 includes the following issues:
  • PC5 can support C2 communication between UAV and UAV controller (UAV-C);
  • PC5 Proximity based Services (ProSe), Cellular Vehicle-to-Everything (C-V2X):
  • TR 23.700-58v1.0.0 includes the following conclusion on the same issue as the example above.
  • UAVs participating in C2 communication through PC5 may or may not be capable of Uu communication with the network.
  • UAV-C can be pre-paired or dynamically paired.
  • 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 establishing C2 communication over PC5, based on the following enhancements and adaptations. :
  • the C2 communication service identifier can be pre-set or derived from the UAV ID at the CAA-level.
  • Both UE-oriented and service-oriented unicast link establishment are supported as defined in section 6.4.3.1 of TS 23.304 V17.4.0.
  • the C2 communication authorization procedure through Uu defined in TS 23.256 V17.4.0 can be used to perform C2 communication through PC5 between UAV and UAV-C (i.e., when performing authorization with USS/network).
  • the C2 communication authorization procedure through Uu must be performed before performing C2 communication through PC5.
  • the following additional explanation may apply:
  • the UAV UE performs C2 communication authentication according to the procedure defined in TS 23.256 V17.4.0 before initiating direct communication from UAV to UAV-C through PC5.
  • the C2 communication authorization procedure via Uu defined in TS 23.256 V17.4.0 may fail. In this case, it is not clear whether the UAV UE can perform C2 communication through UAV-C and PC5. Also, in this case, if the UAV UE should not perform C2 communication through UAV-C and PC5, it is not clear how to handle this (e.g. authentication or C2 communication).
  • C2 connection through Uu may be revoked by USS or network.
  • the UAV UE can perform C2 communication through UAV-C and PC5.
  • the UAV UE should not perform C2 communication through UAV-C and PC5, it is not clear how to handle this (e.g. authentication or C2 communication).
  • C2 communication may mean Command and Control (C2) Communication.
  • C2 communications convey messages containing command and control information for UAV operation from the UAV controller or Uncrewed Aircraft Systems Traffic Management (UTM) to the UAV, or report telemetry data from the UAV to the UAV controller or UTM. It can refer to a user plane link for
  • the method of supporting C2 communication using the PC5 interface proposed in the disclosure of this specification may be composed of a combination of one or more operations/configurations/steps among the following various examples.
  • C2 communication, C2 connection, C2 connectivity, and C2 may be used interchangeably.
  • C2 communication, C2 connection, C2 connectivity, and C2 can all be used as terms with the same meaning.
  • performing C2 communication may be interpreted as performing a C2 connection connection, or may be interpreted as an operation including performing a C2 connection connection.
  • C2 connection connection through the PC5 interface can refer to the Layer-2 link establishment, that is, unicast link establishment operation of TS 23.287 V17.4.0 and TS 23.304 V17.4.0.
  • UE User Equipment
  • terminal may be used as terms with the same meaning.
  • PC5 PC5 interface
  • PC5 reference point PC5 reference point
  • PC5-based PC5-based
  • SMF may mean SMF+PGW-C in EPS.
  • C2 communication/C2 connection can be interpreted as communication/connection between two UEs.
  • C2 communication authorization (or authorization with USS/network) through Uu fails or when C2 communication authorization (or authorization with USS/network) is revocation, operations such as the following example may be performed. For example, whether SMF or USS can perform C2 communication through PC5 may be provided to the UE or set to the UE. Alternatively, whether SMF or USS can perform C2 communication through PC5 using Uu connection may be provided to the UE or set to the UE. When the USS performs this operation, information or settings provided by the USS may be delivered to the UE through the SMF.
  • C2 communication authorization (or authorization with USS/network) through Uu fails or when C2 communication authorization (or authorization with USS/network) is revocation
  • operations such as the following example may be performed.
  • the network may instruct or configure the UE whether it can perform C2 communication through PC5.
  • whether C2 communication can be performed through PC5 using Uu connection can be provided to or set in the UE.
  • the UE can be assumed to be a UAV. However, this is only an example, and the UE may be a UAV-C, or the UE may be both a UAV and a UAV-C.
  • the operation of providing or configuring to the UE whether C2 communication can be performed through PC5 using Uu connection refers to the network providing to the UE or UE whether C2 communication can be performed through PC5. It can also be interpreted as an operation to set .
  • the first example of the disclosure of this specification describes an example of setting an authentication policy/parameter in the UE.
  • This Authorization Policy/Parameter can be set in various forms, such as combined form, explicit form, and implicit form.
  • the operation of releasing the PDU Session/PDN connection used in Uu-based C2 communication can be interpreted as including releasing the QoS Flow/Bearer used in Uu-based C2 communication.
  • the above Authorization Policy/Parameter settings can be set by one or more of the following methods: setting in the UICC, setting in the ME, setting in the UE by the PCF, and setting in the UE by the AF.
  • setting in the UICC setting in the ME
  • setting in the UE by the PCF setting in the UE by the AF.
  • operations that perform these settings please refer to sections 5.1.1 and 6.2 of TS 23.287 V17.4.0.
  • Section 5.2.5.2.1 C2 Authorization request during UUAA-SM procedure in 5GS
  • Section 5.2.5.2.1 of TS 23.256 V17.4.0 described above describes additional matters compared to Section 5.2.3.2 of TS 23.256 V17.4.0.
  • 8A and 8B illustrate a procedure according to a first example of the first example of the disclosure herein.
  • FIGS. 8A and 8B show an example in which UUAA is performed while the PDU session establishment procedure is performed.
  • Step 1 If the information (a) above is set in the UE, the UE may decide to perform C2 communication authorization through Uu.
  • Step 7 Based on one or more of the information (b), (c), and (d) above and the C2 authorization result (success or failure), the UE can decide whether to perform C2 communication through the PC5 interface. . For example, operations such as the following example may be performed:
  • the UE may determine that C2 communication can be performed through the PC5 interface. The UE may perform this decision even if the (c) information above is set or not.
  • the UE may determine that C2 communication cannot be performed through the PC5 interface. Even if the (b) information is not set, if the (a) information is set, if C2 authorization fails, the UE may determine that C2 communication cannot be performed through the PC5 interface.
  • the UE may determine that C2 communication can be performed through the PC5 interface.
  • the UE may perform the decision according to the above example, depending on the implementation of the UE, instead of using the information (b), information (c), and (d).
  • the UE may receive a 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 the information contained in this message (e.g. 5GSM cause value, information contained in Service-level-AA container, etc.) , the UE can know the C2 authorization result.
  • 5GSM cause value and Service-level-AA container information please refer to TS 24.501 V17.8.0.
  • C2 authorization fails #29 "user authentication or authorization failed" may be included or set as the 5GSM cause value included in the SM NAS message.
  • C2 authorization fails "C2 authorization was not successful or C2 authorization is revoked.” may be included or set as Service-level-AA response information included in the Service-level-AA container.
  • Service-level-AA result field (SLAR) (octet 3, bits 1 and 2) Bits One 2 0 0 No information 0 One Service level authentication and authorization were successful. One 0 Service level authentication and authorization were not successful, or service level authorization was revoked.
  • One One Reserved C2 authorization result field (C2AR) (octet 3, bits 3 and 4) Bits 3 4 0 0 No information 0 One C2 authorization was successful. One 0 C2 authorization was not successful, or C2 authorization was revoked.
  • One Reserved Bits 5 to 8 of octet 3 are spare and shall be coded as zero.
  • Table 3 is an example of the Service-level-AA response information element defined in Table 9.11.2.14.1 of 3GPP TS 24.501 V17.8.0.
  • Section 5.2.5.3.0 C2 Authorization request during UUAA-SM procedure in EPS
  • Section 5.2.5.3.0 of TS 23.256 V17.4.0 described above describes additional matters compared to Section 5.2.3.3 of TS 23.256 V17.4.0.
  • 9A and 9B illustrate a procedure according to a second example of the first example of the disclosure herein.
  • FIGS. 9A and 9B show an example in which UUAA is performed while the PDN connection establishment procedure is performed in the EPS.
  • Step 1 If the information (a) above is set in the UE, the UE may decide to perform C2 communication authorization through Uu.
  • Step 8 (or after step 5). Based on one or more of the information (b), (c), and (d) above and the C2 authorization result (success or failure), the UE may decide whether to perform C2 communication through the PC5 interface. For example, operations such as the following example may be performed:
  • the UE may determine that C2 communication can be performed through the PC5 interface. This may be determined in this way even if the information (c) above is set or not.
  • C2 authorization fails, if the information in (b) above is set, the UE may determine that C2 communication cannot be performed through the PC5 interface. Even if the (b) information is not set, if the (a) information is set, if C2 authorization fails, the UE may determine that C2 communication cannot be performed through the PC5 interface.
  • the UE may determine that C2 communication can be performed through the PC5 interface.
  • the UE may make a decision according to the above example depending on the UE's implementation.
  • 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).
  • Received SM-related NAS messages e.g., MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY REQUEST, etc.
  • information contained in the NAS message e.g., ESM cause value, included in Service-level-AA container
  • the UE can know the C2 authorization result.
  • ESM cause value and Service-level-AA container information please refer to TS 24.301 V17.8.0.
  • #29 “user authentication or authorization failed” may be included or set as the ESM cause value.
  • 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.
  • the UE if the UE decides to perform C2 communication through the PC5 interface, the UE can perform an operation to establish a C2 connection using the PC5 interface. . Additionally, if the UE decides not to perform C2 communication through the PC5 interface, a request to establish a C2 connection using the PC5 interface is received from the other UE (i.e., UAV-C in the case of UAV and UAV in the case of UAV-C). Upon receiving, the UE may reject it. If the UE rejects, the UE may transmit a rejection message to the other UE. The rejection message may include the reason for rejection (e.g., Uu-based C2 communication authorization failure, Uu-based C2 communication not-authorized, PC5-based C2 communication not-authorized, etc.).
  • the rejection message may include the reason for rejection (e.g., Uu-based C2 communication authorization failure, Uu-based C2 communication not-authorized, PC5-based C2 communication not-authorized, etc.).
  • FIG. 10 illustrates a procedure according to a third example of the first example of the disclosure herein.
  • FIG. 10 shows an example of revocation of a C2 connection in 5GS.
  • the UE can decide whether to perform C2 communication through the PC5 interface. For example, operations such as the following example may be performed:
  • the UE may determine that C2 communication can be performed through the PC5 interface. Even if one or more of the information in (f) and (h) above is set or not, the UE may make this decision.
  • the UE can receive SM NAS messages from SMF. Based on the received SM NAS message (e.g., PDU Session Release Command, PDU Session Modification Command, etc.) and/or the information contained therein (e.g., 5GSM cause value, information contained in Service-level-AA container, etc.), The UE can recognize C2 connection revocation (or release of PDU Session/QoS Flow used for C2 connection).
  • 5GSM cause value and Service-level-AA container information please refer to TS 24.501 V17.8.0.
  • C2 connection revocation #29 “user authentication or authorization failed” may be included or set as the 5GSM cause value.
  • C2 connection revocation "C2 authorization was not successful or C2 authorization is revoked.” may be included or set as Service-level-AA response information included in the Service-level-AA container.
  • Example 11 illustrates a procedure according to a fourth example of Example 1 of the disclosure of this specification.
  • the example in Figure 11 shows an example of revocation of a C2 connection in EPS.
  • the UE can decide whether to perform C2 communication through the PC5 interface.
  • the UE may determine that C2 communication can be performed through the PC5 interface. Even if one or more of the information (f) and (h) above is set or not, the UE may perform this decision.
  • the UE can receive SM-related NAS messages from the network (MME/SMF+PGW-C). Received SM-related NAS messages (e.g., MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY REQUEST, etc.) and/or information contained in the NAS message (e.g., ESM cause value, included in Service-level-AA container) Based on this information, the UE can know C2 connection revocation (or release of PDN connection/bearer used for C2 connection). For detailed descriptions of ESM cause value and Service-level-AA container information, please refer to TS 24.301 V17.8.0.
  • C2 connection revocation #29 "user authentication or authorization failed" may be included or set as the ESM cause value.
  • C2 connection revocation "C2 authorization was not successful or C2 authorization is revoked.” may be included or set as Service-level-AA response information included in the Service-level-AA container.
  • the UE that was performing C2 communication through the PC5 interface may decide not to perform C2 communication through the PC5 interface. If the UE makes this decision, the UE can perform an operation to release the C2 connection through the PC5 interface.
  • the PC5 message used during 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.).
  • the reason for release e.g., Uu-based C2 communication revoked, Uu-based C2 communication not-authorized, PC5-based C2 communication not-authorized, etc.
  • the operation to release the C2 connection through 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.
  • C2 communication authorization through Uu fails (i.e., is not successful), or Uu-based C2 connection is revoked, or PDU Session/QoS Flow used for Uu-based C2 communication is released, or Uu-based C2
  • the PDN connection/bearer used for communication is released, or C2 communication authorization through PC5 fails (i.e., is not successful), or PC5-based C2 connection is revoked, the following example actions are performed: It can be.
  • the network may provide the UE with information indicating not to perform C2 communication through PC5 (or C2 communication through PC5 is not permitted or C2 communication through PC5 is not authorized).
  • the network may provide the UE with information indicating that C2 communication will be performed through PC5 (or C2 communication through PC5 is permitted or C2 communication through PC5 is authorized).
  • FIG. 12 an example of establishing a PC5 unicast link will be described.
  • the example of FIG. 12 may be referred to.
  • Figure 12 shows a procedure for establishing a layer-2 link through a PC5 reference point, according to an embodiment of the disclosure of the present specification.
  • related information can be set in the UE.
  • Figure 12 shows the layer 2 link setup procedure for unicast mode of V2X communication through the PC5 reference point.
  • 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).
  • 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).
  • the V2X application layer of UE-1 provides application information for PC5 unicast communication.
  • Application information includes the V2X service type and the application layer ID of the initiating UE.
  • the application layer ID of the target UE may be included in the application information.
  • the V2X application layer of UE-1 can provide V2X application requirements for this unicast communication.
  • UE-1 determines PC5 QoS parameters and PC5 QoS Flow ID (PFI).
  • the UE can trigger a layer 2 link modification procedure.
  • UE-1 begins the unicast layer 2 link establishment procedure by directly sending a communication request message.
  • the direct communication request message may include the following information:
  • Application layer ID of the initiating UE i.e., application layer ID of UE-1.
  • V2X application layer provides the application layer ID of the target UE in step 2
  • the following information is included:
  • Target User Info Application layer ID of target UE (i.e., application layer ID of UE-2).
  • V2X Service Info Information about the type of V2X service requesting Layer 2 link establishment.
  • Security Information Information for establishing security.
  • the source layer 2 ID and destination layer 2 ID used to send a direct communication request message are determined.
  • the destination Layer-2 ID may be a broadcast or unicast Layer-2 ID.
  • target user information When using a unicast layer 2 ID, target user information must be included in the direct communication request message.
  • UE-1 sends a communication request message directly via PC5 broadcast or unicast using the source layer-2 ID and destination layer-2 ID.
  • PC5 DRX operation For transmission meet reception of a direct communication request message, for example, based on the NR Tx profile, if PC5 DRX operation is required, the default PC5 DRX settings are used.
  • Target User info is included in the direct communication request message
  • the target UE i.e. UE-2
  • Target User info may not be included in the direct communication request message.
  • the UE that wishes to use the announced V2X service type through the PC5 unicast link with UE-1 responds by establishing security with UE-1.
  • UE-1 When security protection is activated, UE-1 transmits the following information to the target UE:
  • IP communication When IP communication is used, the following information can be transmitted:
  • IP Address Configuration In case of IP communication, IP address setting is required for this link. Indicates one of the following values:
  • IPv6 Router If the IPv6 address allocation mechanism is supported by the initiating UE (i.e. acting as an IPv6 router). ; or
  • IPv6 address allocation mechanism is not supported by the initiating UE.
  • - QoS Info Information about the PC5 QoS flow to be added.
  • the PFI the corresponding PC5 QoS parameters (i.e. PQI and conditional other parameters (e.g. MFBR/GFBR, etc.)) and the associated V2X service type.
  • the source layer 2 ID used in the security establishment procedure is determined. Destination layer 2 ID is set to the source layer 2 ID of the received direct communication request message.
  • UE-1 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.
  • a direct communication acceptance message is sent to UE-1 by the target UE that has successfully established security with UE-1:
  • UE-oriented layer-2 link establishment If target user information is included in the direct communication request message and the application layer ID of the target UE, that is, UE-2, matches, UE-2 sends a direct communication acceptance message. Respond.
  • V2X service-oriented layer 2 link establishment If target user information is not included in the direct communication request message, the UE wishing to use the announced V2X service responds to the request by sending a direct communication acceptance message ( Figure 12 UE-2 and UE-4).
  • the direct communication acceptance message includes:
  • PC5 QoS Info Information about PC5 QoS Flow requested by UE-1. For each PC5 QoS Flow, it contains PFI, corresponding PC5 QoS parameters (i.e. PQI and conditional other parameters (e.g. MFBR/GFBR, etc.)) and related V2X service type information.
  • IP communication includes the following information:
  • IP Address Configuration In case of IP communication, IP address setting is required for this link. Indicates one of the following values:
  • IPv6 Router If the IPv6 address allocation mechanism is supported by the initiating UE (i.e. acting as an IPv6 router). ; or
  • IPv6 address allocation mechanism When the IPv6 address allocation mechanism is not supported by the target UE.
  • IPv6 address allocation mechanism that is, “IPv6 address allocation not supported” is displayed in the IP address settings, and UE-1 specifies Link-Local IPv6 in the direct communication request message. If you include an address, a locally formed link-local IPv6 address. The target UE must contain a non-conflicting link-local IPv6 address.
  • the corresponding address setup procedure is performed after Layer 2 link setup and link-local IPv6 addresses can be ignored.
  • the V2X layer of the UE that has set up the PC5 unicast link transmits the PC5 link identifier assigned to the unicast link and PC5 unicast link-related information to the AS layer.
  • 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 PC5 unicast link-related information.
  • V2X service data is transmitted through a unicast link established as follows:
  • PC5 link identifier and PFI are provided to the AS layer along with V2X service data.
  • layer 2 ID information (e.g., source layer 2 ID and destination layer 2 ID) is additionally provided to the AS layer.
  • layer 2 ID information may be provided to the AS layer.
  • UE-1 has a source layer-2 ID (i.e., UE-1's layer-2 ID for this unicast link) and a destination layer-2 ID (i.e., peer UE's layer-2 ID for this unicast link). Transmit V2X service data using .
  • source layer-2 ID i.e., UE-1's layer-2 ID for this unicast link
  • destination layer-2 ID i.e., peer UE's layer-2 ID for this unicast link
  • UE-1's peer UE can transmit V2X service data to UE-1 through the unicast link with UE-1.
  • FIGS. 8A and 8B a first example of the second example of the disclosure of this specification will be described.
  • FIGS. 8A and 8B were previously referred to to explain the first example of the first example of the disclosure of the present specification, but below, based on FIGS. 8A and 8B, the first example of the second example of the disclosure of the present specification Let's explain what is being proposed.
  • UUAA USS UAV Authorization/Authentication
  • SMF SMF during PDU session establishment.
  • UUAA may be triggered based on SM subscription data obtained from UDM and the service level device ID provided by the UE in a PDU session establishment request or PDN connection establishment request.
  • Step 0. Steps 1 to 5 of the example of FIG. 5 may be performed.
  • the UAV may include information such as the following example in the PDU session establishment request message.
  • a UAV includes a service-level device identifier (e.g., UVA's CAA-level UAV ID), an Authentication Server Address (e.g., USS address), and optionally authentication data (e.g., USS address) in the PDU session establishment request.
  • a service-level device identifier e.g., UVA's CAA-level UAV ID
  • an Authentication Server Address e.g., USS address
  • authentication data e.g., USS address
  • UUAA aviation payload can be included in the PDU session establishment request message.
  • SMF can transmit an authentication-related message to UAS NF/NEF.
  • SMF can transmit authentication-related messages to USS via UAS NF/NEF.
  • SMF can call the Nnef_Authentication_AuthenticateAuthorize service operation.
  • This service operation may include service level device ID (including the UAV's CAA level UAV ID), DNN, S-NSSAI, authentication server address (i.e. USS address), and UUAA aviation payload (if provided by the UE). ), GPSI, optionally UAV location, PEI if possible, and UE IP address if possible.
  • UAV location is user location information (e.g. cell ID) provided by 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 the authentication server address (e.g., USS address).
  • UAS NF/NEF can transmit an authentication-related message to USS.
  • UAS NF/NEF may call the Naf_Authentication_AuthenticateAuthorize service operation to transfer authentication request information received from SMF to USS.
  • the UAS NF can convert the Cell ID received as part of the UAV location in the Nnef_Authentication_AuthenticateAuthorize request in step 1 to the corresponding geographic area.
  • the UAS NF may support the geo-caging function by additionally obtaining UE location information using the location service procedure and including it in the Naf_Ahentication_AuthenticateAuthorize message to the USS.
  • Step 3 Depending on the authentication method used by USS, multiple necessary round-trip messages may be transmitted or received.
  • the USS's response message (e.g. Naf_Authentication_AuthenticateAuthorize response message) includes GPSI, and the authentication message according to the used authentication method is transparently delivered to the UE through the NAS SM transmission message.
  • the authentication message in Step 3 may include the UUAA aviation payload required by the USS if not previously provided by the UE.
  • USS can transmit an authentication response message (e.g. Naf_Authentication_AuthenticateAuthorize response) to UAS NF/NEF.
  • the authentication response message may include the result of authentication/authentication.
  • the authorization/authentication result may include UUAA results for the UAS NF and information about whether UAS services related to network resources can be released for re-authentication or re-authorization in case of UUAA failure.
  • the authorization/authentication result may include the authenticated CAA-level UAV ID, the requested policy information, and the service level device ID including the UUAA authentication payload.
  • Policy information requested by the USS may include a DN authorization profile index and/or a DN authorization session AMBR.
  • USS may include new CAA-level UAV IDs as approved CAA-level UAV IDs.
  • SMF can receive an authentication response message from UAS NF/NEF.
  • the SMF may receive a response message containing information/results that C2 authorization failed or succeeded from UAS NF/NEF.
  • C2 authorization may be authorization for C2 communication through Uu and/or authorization for C2 communication through PC5.
  • the authentication response message may be a message sent from the USS to the SMF via UAS NF/NEF.
  • Step 6 If authentication/authorization is successful, USS subscribes to the PDU session status event. For example, operations according to Steps 1 to 5 of 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.
  • UAS NF/NEF determines the DNN and S-NSSAI to subscribe to PDU session status event notifications.
  • Step 7 SMF can transmit an SM NAS message to the UE.
  • the SMF transmits an SM NAS message (e.g., PDU Session Establishment Accept, PDU Session Establishment Reject, PDU Session Modification Command, etc.) to the UE
  • the SMF may include information such as the following example in the SM NAS message. there is.
  • C2 authorization fails (i.e., when the SMF receives a response message from UAS NF/NEF containing information/results that C2 authorization has failed), the SMF shall not perform C2 communication through the PC5 interface, or Information indicating/indicating this can be included in the SM NAS message. This can be interpreted as C2 communication through the PC5 interface is not allowed/authorized.
  • the SMF receives information opposite to case i) above (e.g., PC5 interface Information indicating that C2 communication can be performed through the PC5 interface (this information can be interpreted as allowing/authorizing C2 communication through the PC5 interface) may be included in the SM NAS message.
  • the SMF may provide UAV-C related information (e.g., UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) to the UE.
  • SMF sends SM NAS messages containing UAV-C related information (e.g. UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) to the UE via AMF.
  • UAV-C related information e.g. UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.
  • SMF may receive or obtain information related to UAV-C from one or more entities among USS, UAS NF/NEF, UDM, UDR, PCF, UAV-C, and Application Server/Function.
  • information related to UAV-C may be set in SMF. All information related to UAV-C may be provided or obtained from one entity, or may be provided or obtained from multiple entities.
  • the SMF may receive information related to the UAV-C (e.g., Application Layer ID of UAV-C) from the USS, and the SMF may receive information related to the UAV-C (e.g., Application Layer ID of UAV-C) can be transmitted to the UE (e.g., UAV).
  • the UAV can use the information related to the UAV-C provided above when forming a PC5 unicast link for UAV-C and C2 communication (or, the UAV can use the information related to the UAV-C provided above to establish a PC5 unicast link for UAV-C and C2 communication For PC5 unicast link can be formed).
  • a UE may perform a procedure to establish a PC5 unicast link for UAV-C and C2 communication based on the example of FIG. 12.
  • the UE eg, UAV
  • the UE may set Target User Info to the Application Layer ID of UAV-C.
  • the reason the SMF includes information related to the UAV-C may be because the UE requested this information (in step 1).
  • the information related to the UAV-C may be information related to a Third Party Authorized Entity (TPAE).
  • the TPAE may be considered a PC5 capable UE, V2X capable UE, or ProSe enabled UE.
  • the UAV can establish a PC5 unicast link for C2 communication with a UAV-C or Third Party Authorized Entity (TPAE).
  • TPAE Third Party Authorized Entity
  • the UAV can set the Layer-2 ID as the Destination Layer-2 ID and use it to establish a PC5 unicast link (i.e., the UAV sends a Direct Communication Request message Destination Layer-2 ID is used for transmission).
  • the UAV can set the UAV's Layer-2 ID as the Source Layer-2 ID and use the Source Layer-2 ID to form a PC5 unicast link (i.e. , UAV uses Source Layer-2 ID to transmit Direct Communication Request message).
  • the operation of the UAV receiving the UAV's Layer-2 ID from the network may be performed in a similar manner to the operation of the UAV receiving the UAV-C related information from the network. This information regarding PC5 unicast link formation can be applied throughout this specification.
  • UAV-C-related information or TPAE-related information is inferred based on the UAV's identification information (e.g., one or more of CAA-Level UAV ID (or Service Level Device Identity of the UAV), GPSI, PEI, and IP address information) /It may be decided. This may apply throughout this specification.
  • application layer-related information may be considered direct C2 pairing information or C2 pairing information.
  • application layer-related information e.g., Application Layer ID
  • step 0 of the example of FIGS. 8A and 8B a description such as the following example may be applied. It may be necessary to establish a direct PC5 link for the UAV to connect to the UAV-C (i.e. direct C2 communication).
  • the C2 Aviation payload transmitted by the UAV may include an indication that it is also authorized for direct C2 communication. Additionally, the UAV may include direct C2 pairing information (if available) in the C2 Aviation payload.
  • step 4 of the example of FIGS. 8A and 8B a description such as the following example may be applied.
  • the USS sends direct C2 pairing information that includes the application layer ID of the UAV-C in the C2 authorization payload. may include.
  • the C2 authorization payload including the application layer ID of the UAV-C is included in the Naf_Ahentication_AuthenticateAuthorize response and can be additionally delivered to the UE.
  • step 1 of the example of FIG. 13 below a description such as the following example may be applied. It may be necessary to establish a direct PC5 link for the UAV to connect to the UAV-C (i.e. direct C2 communication).
  • the C2 Aviation payload transmitted by the UAV may include an indication that it is also an authorization for direct C2 communication. Additionally, the UAV may include direct C2 pairing information (if available) in the C2 Aviation payload.
  • step 4 of the example of FIG. 13 below a description such as the following example may be applied.
  • the USS sends direct C2 pairing information that includes the application layer ID of the UAV-C in the C2 authorization payload. may include.
  • the C2 authorization payload including the application layer ID of the UAV-C is included in the Naf_Ahentication_AuthenticateAuthorize response and can be additionally delivered to the UE.
  • the UAV-C related information or TPAE related information may be provided.
  • this information can be interpreted as in the following example.
  • this information authorizes the UAV-C or TPAE to control the UAV, authorizes to perform C2 communication with the UAV, authorizes to perform C2 communication through the UAV and PC5, and authorizes to pair with the UAV. It can be interpreted that the pair with the UAV is authorized, etc. This may apply throughout this specification.
  • the UAV can form a C2 connection through PC5 with the C2 connection partner most recently established or provided from the network (e.g., it may be UAV-C or TPAE). This may apply throughout this specification.
  • the SMF may include information related to i) or ii) described above in the SM NAS message for reasons such as the examples below.
  • the SMF may include the information in the SM NAS message.
  • the SMF may include the information in the SM NAS message.
  • subscriber information e.g., when performing Uu-based C2 communication authorization, authorization information for PC5-based C2 communication must be provided to the UE, information such as that the UE can perform PC5-based C2 communication, etc.
  • the SMF provides the above information. can be included in the SM NAS message.
  • the SMF can include the information in the SM NAS message.
  • the SMF can include the information in the SM NAS message.
  • the SMF may include the above information in the SM NAS message.
  • the SMF may include the information in the SM NAS message.
  • the UE can receive an SMF NAS message from SMF.
  • the SM NAS message may include information based on i) or information based on ii).
  • the UE may determine whether C2 communication can be performed through the PC5 interface based on the SM NAS message received from the SMF and/or the i) information or ii) information.
  • FIGS. 9A and 9B a second example of the second disclosure of the present specification will be described.
  • FIGS. 9A and 9B were previously referred to to explain the second example of the first example of the disclosure of the present specification, but hereinafter, based on FIGS. 9A and 9B, the second example of the second example of the disclosure of the present specification Let's explain what is being proposed.
  • Step 5 SMF+PGW-C receives a response message from UAS NF/NEF containing information/results that C2 authorization failed or succeeded.
  • C2 authorization may be authorization for C2 communication through Uu and/or authorization for C2 communication through PC5.
  • Step 8 can transmit SM-related NAS messages to the UE through the MME.
  • SMF+PGW-C can include the following information in SM-related NAS messages (e.g., MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, etc.).
  • C2 authorization fails (i.e., when a response message containing information/results that C2 authorization has failed is received from UAS NF/NEF), SMF+PGW-C is informed not to perform C2 communication through PC5 interface. , or information indicating/indicating this can be included in the SM-related NAS message. This can be interpreted as C2 communication through the PC5 interface is not allowed/authorized.
  • SMF+PGW-C provides information opposite to the case of I) above (e.g. , Information indicating that C2 communication can be performed through the PC5 interface. This information can be interpreted as allowing/authorizing C2 communication through the PC5 interface.) may be included in the SM-related NAS message. In this case, SMF+PGW-C may provide UAV-C related information (e.g., UAV-C's Application Layer ID (this can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) to the UE.
  • UAV-C related information e.g., UAV-C's Application Layer ID (this can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.
  • SMF+PGW-C sends an SM NAS message containing UAV-C related information (e.g., UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) It can be provided to the UE.
  • UAV-C related information e.g., UAV-C's Application Layer ID (which can be interpreted as User Info or Pilot Info), Layer-2 ID, etc.) It can be provided to the UE.
  • SMF+PGW-C may receive or obtain the UAV-C related information from one or more entities among USS, UAS NF/NEF, UDM/HSS, UDR, PCF, UAV-C, and Application Server/Function.
  • the UAV-C related information may be set in SMF+PGW-C. All UAV-C related information may be provided or obtained from one entity, or may be provided or obtained from multiple entities.
  • the UAV can use the UAV-C-related information provided above when forming a PC5 unicast link for UAV-C and C2 communcation (or the UAV can use the UAV-C-related information provided above to establish a PC5 unicast link for UAV-C and C2 communcation) PC5 unicast link can be formed).
  • the reason why SMF+PGW-C includes the UAV-C related information may be because the UE has requested this 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 a PC5 capable UE, V2X capable UE, or ProSe enabled UE.
  • SMF+PGW-C may include information related to I) or II) described above in the SM NAS message for reasons such as the example below.
  • SMF+PGW-C may include the information in the SM NAS message.
  • SMF+PGW-C may include the information in the SM NAS message.
  • SMF+PGW-C may include the above information in the SM NAS message.
  • SMF+PGW-C may include the information in the SM NAS message.
  • SMF+PGW-C may include the information in the SM NAS message.
  • SMF+PGW-C may include the above information in the SM NAS message. Based on one or more of various information such as these examples, SMF+PGW-C may include the information in the SM NAS message.
  • the UE may determine whether C2 communication can be performed through the PC5 interface based on the SM-related NAS message and/or the I) or II) information received from the network.
  • the third example of the second example of the disclosure of the present specification is an embodiment based on the first example and/or the second example of the second example of the disclosure of the present specification described above.
  • the third example of the second example of the disclosure of this specification is an example to which the description of the second example of the disclosure of this specification applies.
  • C2 communication and direct C2 communication can be defined as follows.
  • C2 Communication A user plane link for passing messages containing command and control information for UAV operation from the UAV controller or UTM to the UAV. Or a user plane link for reporting telemetry data from the UAV to the UAV controller or UTM. C2 communication can be established via the Uu reference point or the PC5 reference point.
  • the UAV controller and UAV can establish a direct C2 link through the PC5 reference point to communicate with each other.
  • C2 Aviation Payload Contains application layer information transmitted by the UAS to the USS, including UAV pairing information and/or flight authorization information transparent to the 3GPP system.
  • C2 Authorization Payload Contains application layer information transmitted by the USS to the UAV, such as C2 pairing information and/or C2 security information transparent to the 3GPP system.
  • C2 Pairing Information Contains UAV-C addressing information (e.g., includes UAV-C IP address).
  • a UAV When a UAV establishes a user plane connection for C2 operations (i.e., to pass messages containing command and control information for UAV operations from a UAV-C or USS to a UAV, or to report telemetry data from a UAV to a UAV-C) ), authentication for C2 is required.
  • Both sides of a C2 communication, i.e. UAV and UAV-C, may belong to the same UAS.
  • the UAV can be authorized by the USS to use a PDU session or PDN connection for C2.
  • Certification for C2 includes:
  • UAV to UAV-C pairing authorization This may be authentication for pairing with a UAV-C connected to a network or a UAV-C connected to a UAV through an Internet connection before the UAV and UAV-C exchange C2 communication.
  • One UAV can only pair with one UAV-C at any time.
  • One UAV-C can be paired with more than one UAV at the same time.
  • Flight Authorization This may be authorization for flight if the UAV also provides flight authorization information.
  • C2 authentication can be performed in the following examples:
  • UUAA procedure (when UUAA is performed on PDU session/PDN connection establishment): When the UAV requests establishment of a PDU session/PDN connection for connection.
  • Figure 13 shows an example of a PDU session establishment procedure for C2 communication according to an embodiment of the disclosure of the present specification.
  • Figure 13 is a PDU session establishment procedure for C2 communication initiated by the UE.
  • the example in FIG. 13 is an example of a case where a separate PDU session is used for UAS services.
  • 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.
  • the UAV has performed a successful UUAA with the USS (UUAA-SM or UUAA-MM), and the USS can subscribe to PDU session status events from the NEF for that GPSI.
  • the UAV may determine that a new dedicated PDU session or a direct PC5 link is needed to connect to the UAV-C.
  • the UE may initiate the PDU session establishment procedure for DNN/S-NSSAI used for connection to UAV-C.
  • the PDU session establishment request includes the CAA-Level UAV ID and C2 Aviation payload to be used for C2 authentication, and the PDU session establishment request is sent to the SMF.
  • Pairing information includes the CAA-level UAV ID of the requesting UAV, and identification information of the UAV-C to be paired may be included in the C2 Aviation payload.
  • the authentication request is a request for direct C2 communication
  • the C2 aviation payload includes an indication that it is authentication for direct C2 communication.
  • UAVs may also include other information, such as flight certification information, in their Aviation Payload.
  • the USS can 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.
  • the SMF determines whether authentication is required. You can judge whether or not. The SMF can then send the Nnef_Authentication_AuthenticateAuthorize request message to the UAS NF/NEF, which is used to request authorization to pair the UAV-C with the UAV.
  • This request message includes GPSI, CAA level UAV ID and C2 Aviation payload, optionally UAV location (e.g. cell ID) if provided by AMF, and DNN and S-NSSAI of the PDU session.
  • the SMF requests PDU session establishment with the reason that USS authorization is required. can be rejected. For example, the SMF may transmit a PDU session establishment rejection message containing reason information that USS authorization is required.
  • SMF provides a Notification Endpoint to UAS NF/NEF.
  • the SMF can implicitly subscribe to receive notifications about re-authentication, authentication data update, or revocation of the UAS NF/NEF's C2 connection if the C2 authentication result in step 5 is successful.
  • the UAS NF/NEF checks whether a valid UUAA is stored for the GPSI and forwards a Naf_Authentication_AuthenticateAuthorize request message containing the received authentication request to the USS. Otherwise, the request will not be forwarded to the USS and the PDU session will be rejected.
  • UAS NF/NEF provides notification endpoints to the USS. By providing a notification endpoint, the UAS NF/NEF can implicitly subscribe to receive notifications of re-authentication, authentication data update, or C2 connection termination from the USS if the UUAA result is successful in step 5.
  • the USS can trigger UAV re-authentication/re-authorization in response to a query from the UAS NF/NEF.
  • the USS may perform C2 authentication based on the received information and transmit a Naf_Authentication_AuthenticateAuthorize response message to the UAS NF/NEF.
  • the Naf_Authentication_AuthenticateAuthorize response message contains service level device identification (e.g. CAA-level UAV-ID) (potentially new), C2 authentication results, and C2 authentication payload (e.g. C2 pairing information and C2 security information, direct C2 pairing information). Includes.
  • step 1 an authentication request for direct C2 communication is included, and C2 authentication can be successful.
  • the USS may include direct C2 pairing information including the application layer ID of the UAV-C in the Naf_Ahentication_AuthenticateAuthorize response message.
  • UAS-NF/NEF can transmit a Nnef_Authentication_AuthenticateAuthorize response message containing information received from USS to SMF.
  • the SMF may transmit a PDU session establishment acceptance message to the UE.
  • the SMF sends the authentication result, optionally the authentication payload (e.g. C2 pairing information and C2 security information, direct C2 pairing information), and a new CAA-level UAV ID if received from the USS in the PDU session. It can be included in the establishment acceptance message. And, SMF can continue to proceed until the PDU session establishment procedure is completed.
  • the authentication payload e.g. C2 pairing information and C2 security information, direct C2 pairing information
  • the SMF may reject PDU establishment and transmit a PDU session establishment rejection message including a reason code indicating that it has not been authenticated.
  • the USS subscribes to the PDU session status event for the PDU session used for C2 by sending a request message containing the GPSI of the UAV through UAS-NF.
  • the UAS NF determines the DNN and S-NSSAI corresponding to the PDU session used for C2 communication and uses this DNN and S-NSSAI to subscribe to the PDU session status event in SMF.
  • SMF is fig. of TS 23.502 V17.6.0.
  • USS stores the received UE IP address, and by inputting the received PDU session IP address and the IP address of the authenticated paired UAV-C, the USS can call the pairing policy setting procedure. You can. Accordingly, the USS requests that the UPF allow the corresponding traffic in the PDU session.
  • this procedure does not invoke interaction with the UE, AMF or RAN.
  • Figure 14 is an example of a PDN connection for C2 authentication according to an embodiment of the disclosure of the present specification.
  • Figure 14 is an example of a PDN connection establishment procedure for C2 authentication requested by the UE.
  • the UAV has performed a successful UUAA with the USS (UUAA-SM), and the USS may have subscribed to the NEF's PDN connection status event report for the corresponding GPSI.
  • Steps 1 to 3 described in Figure 5.10.2-1 of TS 23.401 can be performed.
  • the UAV may determine that a new PDN connection or a direct PC5 link is needed to connect to the UAV-C.
  • the UE starts the PDN connection procedure requested by the UE to connect to the UAV-C.
  • the PCO included in the PDN connection request message includes a service level device identity (e.g. CAA-level UAV ID) and a C2 air payload to be used for C2 authorization, and the PCO is delivered 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 UAV-C to be paired may be included in the C2 air payload.
  • the C2 airborne payload includes an indication that it is authentication for direct C2 communications.
  • UAVs may also include other information, such as flight authorization information. Additionally, the USS can use locally configured pairing information for UAV-UAV-C pairing authorization, and this information takes precedence over pairing information provided by the UAV.
  • SMF+PGW-C uses the Nudm_SDM_Get service operation to retrieve the UE's session management subscription data (if not already available) from the UDM+HSS. Search.
  • SMF+PGW-C Based on the requested APN/DNN being dedicated to aerial service (aerial service indicator is set) and the request message containing a service level device identifier (CAA-level UAV ID), SMF+PGW-C authenticates Determine if authorization is necessary. Then, SMF+PGW-C transmits the Nnef_Authentication_AuthenticateAuthorize request message to the UAS NF/NEF, which is used to request authorization to pair UAV-C with the UAV.
  • This request message includes the GPSI, service level device identifier (e.g. CAA-level UAV ID) and C2 Aviation payload, and optionally the UAV location (e.g. cell ID) (if provided by the MME) and the PDN connection.
  • APN/DNN included.
  • SMF+PGW-C determines that authorization with the USS is necessary, but the UAV has not provided a service-level device ID (e.g., CAA-level UAV ID), SMF+PGW-C determines that authorization with the USS is required. A PDN connection request rejection message containing is transmitted.
  • a service-level device ID e.g., CAA-level UAV ID
  • UAS NF/NEF checks whether a valid UUAA is stored for GPSI and forwards the received authentication request to the USS as a Naf_Authentication_AuthenticateAuthorize request. Otherwise, the request is not delivered to the USS and the PDN connection is refused.
  • the USS performs C2 authentication based on the received information and collects the service level device ID (e.g. CAA level UAV-ID) (potentially new), C2 authentication result, and C2 authentication payload (e.g. C2 pairing information and C2 Send a Naf_Authentication_AuthenticateAuthorize response including security information and direct C2 pairing information to the UAS NF/NEF.
  • service level device ID e.g. CAA level UAV-ID
  • C2 authentication payload e.g. C2 pairing information and C2 Send a Naf_Authentication_AuthenticateAuthorize response including security information and direct C2 pairing information to the UAS NF/NEF.
  • Step 1 an authentication request for direct C2 communication was included, and if C2 authentication was successful, the USS may include direct C2 pairing information including the application layer ID of the UAV-C in the Naf_Ahentication_AuthenticateAuthorize response.
  • UAS NF/NEF transmits the information received from USS to SMF+PGW C as a Nnef_Authentication_AuthenticateAuthorize response.
  • SMF+PGW-C sends the C2 authentication result and optionally the authentication payload (e.g. C2 pairing information and C2 security information, directly to the C2 PCO in PDN Connectivity Accept) to be transmitted to the UE. pairing information) and new service level device ID (e.g. CAA level UAV ID) (if received from USS). Then, include SMF+PGW-C and continue until the PDN connection request procedure is completed.
  • the authentication payload e.g. C2 pairing information and C2 security information, directly to the C2 PCO in PDN Connectivity Accept
  • new service level device ID e.g. CAA level UAV ID
  • SMF+PGW-C When receiving a failed C2 authentication result from the USS, SMF+PGW-C instead rejects the PDN connection request and sends a rejection message containing a reason code indicating that it has not been authenticated.
  • 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 through UAS NF/NEF.
  • UAS NF/NEF determines the APN/DNN and uses this APN/DNN to subscribe to PDN connection status events to SMF+PGW-C.
  • SMF+PGW-C detects when a PDN connection is established, as described in steps 6-7 of figure 4.15.3.2.3-1 of TS 23.502. And, SMF+PGW-C transmits a PDN connection status event report including GPSI and UE IP Address to UAS NF/NEF through Nsmf_EventExposure_Notify message. The UAS NF/NEF then delivers the event message to the USS.
  • the USS stores the received UE IP address, and uses the received PDN connection IP address and the IP address of the authenticated paired UAV-C as input.
  • the USS-initiated C2 pairing policy setting procedure can be called in the EPS procedure (see Figure 5.2.5.4.2-1).
  • this procedure does not invoke interaction with the UE, MME or RAN.
  • UAVs that support direct C2 communication can establish a direct PC5 link with the UAV-C.
  • UAVs using direct C2 communications may or may not be able to connect to 3GPP networks.
  • the UAV can be authenticated by the USS, allowing it to establish C2 communication directly with the UAV-C.
  • information related to the UAV-C that performs C2 communication directly with the UAV may be preset within the UAV or provided by the network.
  • the UAV must provide the Aircraft-to-Everything (A2X) service type for direct C2 communication, direct C2 pairing information (e.g., application layer ID of UAV-C), layer-2 ID of UAV-C, and A default destination layer-2 ID for initial signaling and an authentication policy for direct C2 communication can be set in advance.
  • A2X Aircraft-to-Everything
  • the following authentication policy may be provided to UAVs that support direct C2 communication:
  • the UAV performs C2 authentication as previously described in "Authorization for C2 over Uu”. If the UAV supports direct C2 communication and there is no authentication policy for direct C2, the UAV may include an indication for direct C2 communication authentication in the authentication request.
  • the unicast mode 5G ProSe direct communication procedure defined in clause 6.4.3.1 of TS 23.304 V17.4.0 is used to establish C2 communication over PC5, and the following enhancements may be applied. Additionally, the following improvements can also be applied to the example referring to FIG. 12.
  • A2X service type for C2 communication can be set in advance on the UAV.
  • - Source User information can be set to a service level device ID (e.g., CAA-Level UAV ID).
  • a service level device ID e.g., CAA-Level UAV ID
  • the application layer ID of the UAV-C may be preset in the UAV or provided by the network.
  • - Destination Layer-2 ID is set to the Layer-2 ID of UAV-C (if the Layer-2 ID of UAV-C is preset in the UAV). Otherwise, the destination layer-2 ID is set to the default destination layer-2 ID in the initial signaling to establish a unicast connection as preset in the UAV.
  • unicast mode 5G direct communication procedure may be supported.
  • the network can notify the UE using Uu connection.
  • the UAV Controller Replacement procedure may be used (see section 5.2.8 of TS 23.256 V17.4.0).
  • the USS may provide information about the change or information indicating that (re-)authorization is for the change to the UAS NF/NEF.
  • UAS NF/NEF can provide the above information to SMF (for 5GS) or SMF+PGW-C (for EPS).
  • SMF in the case of 5GS
  • SMF+PGW-C in the case of EPS
  • the above information may be included.
  • the C2 connectivity revocation procedure can be used (see the example in FIG. 10 and the example in FIG. 11).
  • the USS may provide the UAS NF/NEF with information about the change or information indicating that revocation is for the change.
  • UAS NF/NEF can provide the above information to SMF (for 5GS) or SMF+PGW-C (for EPS).
  • SMF in the case of 5GS
  • SMF+PGW-C in the case of EPS
  • the above information may be included.
  • USS When changing from UAV-C to another UAV-C or from TPAE to UAV-C, USS provides information about the new UAV-C (e.g. Application Layer ID of UAV-C (this can be interpreted as User Info or Pilot Info) ), Layer-2 ID, etc.) may also be provided to the UE.
  • information about the TPAE e.g., TPAE's Application Layer ID (which can be interpreted as User Info, Pilot Info, or Officer Info, etc.), Layer-2 ID, etc.
  • TPAE's Application Layer ID which can be interpreted as User Info, Pilot Info, or Officer Info, etc.
  • Layer-2 ID etc.
  • the UE may form a PC5 unicast link for C2 connection with a new UAV-C or TPAE based on the information included in the SM NAS message received from the SMF or the SM-related NAS message to the UE received from the network/MME. Additionally, the PC5 unicast link for the existing C2 connection can be released.
  • the Core Network may provide one or more of the following information to the base station. This information can be provided in a variety of forms, including combinatorial, explicit, and implicit forms:
  • the resource may be a radio resource.
  • the UE related to the above information is a UAV.
  • the UE related to the above information may be a UAV-C or both a UAV and a UAV-C.
  • the method by which the Core Network provides the above information (e.g., one or more of (A) to (C)) to the base station may be based on one or more of the following:
  • the SMF can include the above information in the N2 message/information (or in this form) and transmit it to the base station through AMF.
  • the SMF providing the information to the AMF may be in the form of event notification.
  • the UDM requests UDM to provide the above information or notify the AMF of the above information. Then, the UDM provides/notifies the above information to the AMF, and the AMF can transmit it to the base station. In this case, the UDM may provide/notify the above information to the AMF for the corresponding UE's counterpart UE (i.e., if the UE is a UAV, it is UAV-C, and if the UE is a UAV-C, it is a UAV), allowing the AMF to transmit this to the base station. There is. Information about the UE's counterpart UE may be based on subscriber information.
  • the base station may decide not to allocate/provide radio resources required for PC5-based C2 communication (or PC5 communication, direct communication) to the corresponding UE.
  • operations related to PC5-based C2 communication include PC5 operations for performing these operations or other PC5 operations (e.g., direct discovery) related thereto. It may be interpreted as including.
  • Figure 15 shows an example of a procedure according to one embodiment of the disclosure herein.
  • the procedure shown in FIG. 15 is merely an example, and the scope of the disclosure of this specification is not limited by the example of FIG. 15.
  • the UE, SMF, and USS shown in FIG. 15 may perform the operations described in the examples of FIGS. 1 to 14.
  • AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc. are not shown, but this is for convenience of explanation. It is for. That is, even in the embodiment based on FIG.
  • AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc. are various examples of the disclosure of the present specification. You can perform the operations described in .
  • the UE may transmit a request message to the SMF.
  • the UE may request authentication for direct C2 communication with the UAV-C.
  • a request message transmitted by the UE may include information requesting authentication for direct C2 communication.
  • the authentication request message may include C2 aviation payload information, and this information may include information about authentication for direct C2 communication.
  • the SMF may transmit an authentication request message to the USS.
  • SMF can transmit an authentication-related message to USS via UAS NF/NEF.
  • the authentication request message transmitted by SMF may be the Nnef_Authentication_AuthenticateAuthorize message.
  • SMF transmits this request message to UAS NF/NEF, and UAS NF/NEF can generate this request message as a Naf_Authentication_AuthenticateAuthorize request message and transmit it to USS.
  • the USS may transmit an authentication response message to the SMF.
  • the authentication response message may be, for example, a Naf_Authentication_AuthenticateAuthorize response message. If the USS directly performs C2 authentication successfully, the USS can transmit an authentication response message including the application layer ID of the UAV-C to the SMF.
  • the application layer ID of UAV-C may be transmitted to the UE.
  • the Naf_Authentication_AuthenticateAuthorize response message transmitted by the USS may include a C2 authentication payload, and the C2 authentication payload may directly include C2 pairing information.
  • C2 pairing information may include the application layer ID of the UAV-C.
  • the SMF can deliver the UAV's application layer ID to the UE.
  • the USS may transmit a response message containing information that direct C2 authentication failed to the SMF.
  • the SMF may transmit information informing the UE not to perform C2 communication based on PC5.
  • the SMF may transmit information to the UE.
  • the SMF may transmit the application layer ID of the UAV-C to the UE.
  • the UE may set the application layer ID of the UAV-C as target user information.
  • the UE may set the application layer ID of the UAV-C as target user information and send a direct communication request message containing target user information to another user. Can be transmitted to UE (e.g. UAV-C).
  • the UE can establish C2 communication with UAV-C through the UAV-C and PC5 reference point.
  • operations such as the following example may be performed.
  • the UE may be instructed or configured as to whether PC5-based C2 communication can be performed.
  • the UE may perform Uu-based C2 communication authorization (or authorization with USS/network) prior to performing PC5-based C2 communication.
  • operations such as the following example may be performed.
  • the UE when performing Uu-based C2 communication revocation, the UE may be instructed or set as to whether PC5-based C2 communication can be performed.
  • Uu-based C2 communication revocation can be performed.
  • the UE may determine whether PC5-based C2 communication can be performed/continued.
  • this specification can have various effects. For example, authentication to perform C2 communication between UAV and UAV-C can be performed effectively.
  • a UAV can perform Direct C2 communication by receiving information for Direct C2 communication from the network through a C2 communication authorization procedure through Uu, that is, information for forming a UAV-C and PC5 unicast link.
  • a C2 communication authorization procedure through Uu that is, information for forming a UAV-C and PC5 unicast link.
  • C2 communication authorization procedure through Uu i.e., by performing authorization with USS/network
  • the operation of the terminal may be implemented by the devices of FIGS. 1 to 3 described above.
  • the terminal e.g., UE
  • the terminal may be the first device 100 or the second device 200 of FIG. 2.
  • operations of the terminal described herein may be processed by one or more processors 102 or 202.
  • the operations of the terminal described in this specification may be stored in one or more memories 104 or 204 in the form of instructions/programs (e.g. instructions, executable code) executable by one or more processors 102 or 202.
  • One or more processors (102 or 202) control one or more memories (104 or 204) and one or more transceivers (105 or 206) and execute instructions/programs stored in one or more memories (104 or 204) as disclosed herein.
  • the operations of the terminal (e.g., UE) described above can be performed.
  • instructions for performing the operations of the terminal described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium.
  • the storage medium may be included in one or more memories 104 or 204.
  • instructions recorded in the storage medium can be executed by one or more processors 102 or 202 to perform the operations of the terminal described in the disclosure of this specification.
  • the network nodes described herein e.g., AMF, SMF, UPF, PCF, USS, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF, etc.
  • a base station e.g., (R)AN, NG-RAN, gNB, etc.
  • the network node or base station may be the first device 100 or the second device 200 of FIG. 2 .
  • operations of a network node or base station described herein may be handled by one or more processors 102 or 202.
  • the operations of the terminal described in this specification may be stored in one or more memories 104 or 204 in the form of instructions/programs (e.g. instructions, executable code) executable by one or more processors 102 or 202.
  • One or more processors (102 or 202) control one or more memories (104 or 204) and one or more transceivers (106 or 206) and execute instructions/programs stored in one or more memories (104 or 204) as disclosed herein.
  • the operation of the network node or base station described above can be performed.
  • instructions for performing operations of a network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium.
  • the storage medium may be included in one or more memories 104 or 204.
  • the instructions recorded in the storage medium can be executed by one or more processors 102 or 202 to perform the operations of the network node or base station described in the disclosure of this specification.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 명세서(present disclosure)의 일 개시는 SMF가 통신을 수행하는 방법을 포함한다. 상기 방법은 UE로부터 직접 C2 통신을 위한 인증 요청 정보를 수신하는 단계; 인증 요청 메시지를 USS에게 전송하는 단계; USS로부터 UAV-C의 어플리케이션 계층 ID를 수신하는 단계; 및 UAV-C의 어플리케이션 계층 ID를 UE에게 전송하는 단계를 포함할 수 있다.

Description

직접 C2 인증
본 명세서는 이동 통신과 관련된다.
3GPP(3rd Generation Partnership Project) LTE(Long-Term Evolution)는 고속 패킷 통신을 가능하게 하기 위한 기술이다. LTE 목표인 사용자와 사업자의 비용 절감, 서비스 품질 향상, 커버리지 확장 및 시스템 용량 증대를 위해 많은 방식이 제안되었다. 3GPP LTE는 상위 레벨 필요조건으로서 비트당 비용 절감, 서비스 유용성 향상, 주파수 밴드의 유연한 사용, 간단한 구조, 개방형 인터페이스 및 단말의 적절한 전력 소비를 요구한다.
ITU(International Telecommunication Union) 및 3GPP에서 NR(New Radio) 시스템에 대한 요구 사항 및 사양을 개발하는 작업이 시작되었다. 3GPP는 긴급한 시장 요구와 ITU-R(ITU Radio communication sector) IMT(International Mobile Telecommunications)-2020 프로세스가 제시하는 보다 장기적인 요구 사항을 모두 적시에 만족시키는 NR을 성공적으로 표준화하기 위해 필요한 기술 구성 요소를 식별하고 개발해야 한다. 또한, NR은 먼 미래에도 무선 통신을 위해 이용될 수 있는 적어도 100 GHz에 이르는 임의의 스펙트럼 대역을 사용할 수 있어야 한다.
NR은 eMBB(enhanced Mobile Broadband), mMTC(massive Machine Type-Communications), URLLC(Ultra-Reliable and Low Latency Communications) 등을 포함하는 모든 배치 시나리오, 사용 시나리오, 요구 사항을 다루는 단일 기술 프레임 워크를 대상으로 한다. NR은 본질적으로 순방향 호환성이 있어야 한다.
5G에서 Uncrewed Aerial System (UAS)가 논의되고 있다. Uncrewed Aerial Vehicle (UAV)와 UAV-Controller (UAV-C) 사이에 PC5 인터페이스에 기초하여 Command and Control (C2) 통신이 수행될 수 있다. 하지만, 종래에는 이러한 C2 통신을 수행하기 위한 인증(Authorization)을 수행하는 구체적인 방안이 논의되지 않았다.
일 양태에 있어서, SMF가 통신을 수행하는 방법을 제공한다. 상기 방법은 UE로부터 직접 C2 통신을 위한 인증 요청 정보를 수신하는 단계; 인증 요청 메시지를 USS에게 전송하는 단계; USS로부터 UAV-C의 어플리케이션 계층 ID를 수신하는 단계; 및 UAV-C의 어플리케이션 계층 ID를 UE에게 전송하는 단계를 포함할 수 있다.
다른 양태에 있어서, 상기 방법을 구현하는 장치가 제공된다.
일 양태에 있어서, UE가 통신을 수행하는 방법을 제공한다. 상기 방법은 직접 C2 통신을 위한 인증 요청 정보를 SMF에게 전송하는 단계; 및 상기 SMF로부터 UAV-C의 어플리케이션 계층 ID를 수신하는 단계를 포함할 수 있다.
다른 양태에 있어서, 상기 방법을 구현하는 장치가 제공된다.
도 1은 본 명세서의 구현이 적용되는 통신 시스템의 예를 나타낸다.
도 2는 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
도 3은 본 명세서의 구현이 적용되는 UE의 예를 나타낸다.
도 4는 본 명세서의 구현이 적용되는 5G 시스템 구조의 예를 나타낸다.
도 5 및 도 6은 본 명세서의 구현이 적용되는 PDU 세션 수립 절차의 예를 나타낸다.
도 7은 UAV를 위한 논리적인 5GS와 EPS의 아키텍쳐의 일 예를 나타낸다.
도 8a 및 도 8b은 본 명세서의 개시의 제1예의 제1 예시에 따른 절차를 설명한다.
도 9a 및 도 9b는 본 명세서의 개시의 제1예의 제2 예시에 따른 절차를 설명한다.
도 10은 본 명세서의 개시의 제1예의 제3 예시에 따른 절차를 설명한다.
도 11은 본 명세서의 개시의 제1예의 제4 예시에 따른 절차를 설명한다.
도 12는 본 명세서의 개시의 일 실시예에 따라, PC5 레퍼런스 포인트를 통해 layer-2 link 를 수립하는 절차를 나타낸다.
도 13은 본 명세서의 개시의 일 실시예에 따른 C2 통신을 위한 PDU 세션 수립 절차의 예시를 나타낸다.
도 14는 본 명세서의 개시의 일 실시예에 따른 C2 인증을 위한 PDN 연결의 예시이다.
도 15는 본 명세서의 개시의 일 실시예에 따른 절차의 예를 나타낸다.
다음의 기법, 장치 및 시스템은 다양한 무선 다중 접속 시스템에 적용될 수 있다. 다중 접속 시스템의 예시는 CDMA(Code Division Multiple Access) 시스템, FDMA(Frequency Division Multiple Access) 시스템, TDMA(Time Division Multiple Access) 시스템, OFDMA(Orthogonal Frequency Division Multiple Access) 시스템, 시스템, SC-FDMA(Single Carrier Frequency Division Multiple Access) 시스템, MC-FDMA(Multi-Carrier Frequency Division Multiple Access) 시스템을 포함한다. CDMA는 UTRA(Universal Terrestrial Radio Access) 또는 CDMA2000과 같은 무선 기술을 통해 구현될 수 있다. TDMA는 GSM(Global System for Mobile communications), GPRS(General Packet Radio Service) 또는 EDGE(Enhanced Data rates for GSM Evolution)와 같은 무선 기술을 통해 구현될 수 있다. OFDMA는 IEEE(Institute of Electrical and Electronics Engineers) 802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, 또는 E-UTRA(Evolved UTRA)와 같은 무선 기술을 통해 구현될 수 있다. UTRA는 UMTS(Universal Mobile Telecommunications System)의 일부이다. 3GPP(3rd Generation Partnership Project) LTE(Long-Term Evolution)는 E-UTRA를 이용한 E-UMTS(Evolved UMTS)의 일부이다. 3GPP LTE는 하향링크(DL; Downlink)에서 OFDMA를, 상향링크(UL; Uplink)에서 SC-FDMA를 사용한다. 3GPP LTE의 진화는 LTE-A(Advanced), LTE-A Pro, 및/또는 5G NR(New Radio)을 포함한다.
설명의 편의를 위해, 본 명세서의 구현은 주로 3GPP 기반 무선 통신 시스템과 관련하여 설명된다. 그러나 본 명세서의 기술적 특성은 이에 국한되지 않는다. 예를 들어, 3GPP 기반 무선 통신 시스템에 대응하는 이동 통신 시스템에 기초하여 다음과 같은 상세한 설명이 제공되지만, 3GPP 기반 무선 통신 시스템에 국한되지 않는 본 명세서의 측면은 다른 이동 통신 시스템에 적용될 수 있다.
본 명세서에서 사용된 용어와 기술 중 구체적으로 기술되지 않은 용어와 기술에 대해서는, 본 명세서 이전에 발행된 무선 통신 표준 문서를 참조할 수 있다.
본 명세서에서 "A 또는 B(A or B)"는 "오직 A", "오직 B" 또는 "A와 B 모두"를 의미할 수 있다. 달리 표현하면, 본 명세서에서 "A 또는 B(A or B)"는 "A 및/또는 B(A and/or B)"으로 해석될 수 있다. 예를 들어, 본 명세서에서 "A, B 또는 C(A, B or C)"는 "오직 A", "오직 B", "오직 C", 또는 "A, B 및 C의 임의의 모든 조합(any combination of A, B and C)"을 의미할 수 있다.
본 명세서에서 사용되는 슬래쉬(/)나 쉼표(comma)는 "및/또는(and/or)"을 의미할 수 있다. 예를 들어, "A/B"는 "A 및/또는 B"를 의미할 수 있다. 이에 따라, "A/B"는 "오직 A", "오직 B", 또는 "A와 B 모두"를 의미할 수 있다. 예를 들어, "A, B, C"는 "A, B 또는 C"를 의미할 수 있다.
본 명세서에서 "A 및 B의 적어도 하나(at least one of A and B)"는, "오직 A", "오직 B" 또는 "A와 B 모두"를 의미할 수 있다. 또한, 본 명세서에서 "A 또는 B의 적어도 하나(at least one of A or B)"나 "A 및/또는 B의 적어도 하나(at least one of A and/or B)"라는 표현은 "A 및 B의 적어도 하나(at least one of A and B)"와 동일하게 해석될 수 있다.
또한, 본 명세서에서 "A, B 및 C의 적어도 하나(at least one of A, B and C)"는, "오직 A", "오직 B", "오직 C", 또는 "A, B 및 C의 임의의 모든 조합(any combination of A, B and C)"을 의미할 수 있다. 또한, "A, B 또는 C의 적어도 하나(at least one of A, B or C)"나 "A, B 및/또는 C의 적어도 하나(at least one of A, B and/or C)"는 "A, B 및 C의 적어도 하나(at least one of A, B and C)"를 의미할 수 있다.
또한, 본 명세서에서 사용되는 괄호는 "예를 들어(for example)"를 의미할 수 있다. 구체적으로, "제어 정보(PDCCH)"로 표시된 경우, "제어 정보"의 일례로 "PDCCH"가 제안된 것일 수 있다. 달리 표현하면 본 명세서의 "제어 정보"는 "PDCCH"로 제한(limit)되지 않고, "PDCCH"가 "제어 정보"의 일례로 제안될 것일 수 있다. 또한, "제어 정보(즉, PDCCH)"로 표시된 경우에도, "제어 정보"의 일례로 "PDCCH"가 제안된 것일 수 있다.
본 명세서에서 하나의 도면 내에서 개별적으로 설명되는 기술적 특징은, 개별적으로 구현될 수도 있고, 동시에 구현될 수도 있다.
여기에 국한되지는 않지만, 본 명세서에서 개시된 다양한 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도는 기기 간 무선 통신 및/또는 연결(예: 5G)이 요구되는 다양한 분야에 적용될 수 있다.
이하, 본 명세서는 도면을 참조하여 보다 상세하게 기술될 것이다. 다음의 도면 및/또는 설명에서 동일한 참조 번호는 달리 표시하지 않는 한 동일하거나 대응하는 하드웨어 블록, 소프트웨어 블록 및/또는 기능 블록을 참조할 수 있다.
도 1은 본 명세서의 구현이 적용되는 통신 시스템의 예를 나타낸다.
도 1에 표시된 5G 사용 시나리오는 본보기일 뿐이며, 본 명세서의 기술적 특징은 도 1에 나와 있지 않은 다른 5G 사용 시나리오에 적용될 수 있다.
5G에 대한 세 가지 주요 요구사항 범주는 (1) 향상된 모바일 광대역(eMBB; enhanced Mobile BroadBand) 범주, (2) 거대 기계 유형 통신(mMTC; massive Machine Type Communication) 범주 및 (3) 초고신뢰 저지연 통신(URLLC; Ultra-Reliable and Low Latency Communications) 범주이다.
도 1을 참조하면, 통신 시스템(1)은 무선 장치(100a~100f), 기지국(BS; 200) 및 네트워크(300)을 포함한다. 도 1은 통신 시스템(1)의 네트워크의 예로 5G 네트워크를 설명하지만, 본 명세서의 구현은 5G 시스템에 국한되지 않으며, 5G 시스템을 넘어 미래의 통신 시스템에 적용될 수 있다.
기지국(200)과 네트워크(300)는 무선 장치로 구현될 수 있으며, 특정 무선 장치는 다른 무선 장치와 관련하여 기지국/네트워크 노드로 작동할 수 있다.
무선 장치(100a~100f)는 무선 접속 기술(RAT; Radio Access Technology) (예: 5G NR 또는 LTE)을 사용하여 통신을 수행하는 장치를 나타내며, 통신/무선/5G 장치라고도 할 수 있다. 무선 장치(100a~100f)는, 이에 국한되지 않고, 로봇(100a), 차량(100b-1 및 100b-2), 확장 현실(XR; eXtended Reality) 장치(100c), 휴대용 장치(100d), 가전 제품(100e), IoT(Internet-Of-Things) 장치(100f) 및 인공 지능(AI; Artificial Intelligence) 장치/서버(400)을 포함할 수 있다. 예를 들어, 차량에는 무선 통신 기능이 있는 차량, 자율주행 차량 및 차량 간 통신을 수행할 수 있는 차량이 포함될 수 있다. 차량에는 UAV(UAV; Unmanned Aerial Vehicle)(예: 드론)가 포함될 수 있다. XR 장치는 AR(Augmented Reality)/VR(Virtual Reality)/MR(Mixed Realty) 장치를 포함할 수 있으며, 차량, 텔레비전, 스마트폰, 컴퓨터, 웨어러블 장치, 가전 제품, 디지털 표지판, 차량, 로봇 등에 장착된 HMD(Head-Mounted Device), HUD(Head-Up Display)의 형태로 구현될 수 있다. 휴대용 장치에는 스마트폰, 스마트 패드, 웨어러블 장치(예: 스마트 시계 또는 스마트 안경) 및 컴퓨터(예: 노트북)가 포함될 수 있다. 가전 제품에는 TV, 냉장고, 세탁기가 포함될 수 있다. IoT 장치에는 센서와 스마트 미터가 포함될 수 있다.
본 명세서에서, 무선 장치(100a~100f)는 사용자 장비(UE; User Equipment)라고 부를 수 있다. UE는 예를 들어, 휴대 전화, 스마트폰, 노트북 컴퓨터, 디지털 방송 단말기, PDA(Personal Digital Assistant), PMP(Portable Multimedia Player), 네비게이션 시스템, 슬레이트 PC, 태블릿 PC, 울트라북, 차량, 자율주행 기능이 있는 차량, 연결된 자동차, UAV, AI 모듈, 로봇, AR 장치, VR 장치, MR 장치, 홀로그램 장치, 공공 안전 장치, MTC 장치, IoT 장치, 의료 장치, 핀테크 장치(또는 금융 장치), 보안 장치, 날씨/환경 장치, 5G 서비스 관련 장치 또는 4차 산업 혁명 관련 장치를 포함할 수 있다.
무선 장치(100a~100f)는 기지국(200)을 통해 네트워크(300)와 연결될 수 있다. 무선 장치(100a~100f)에는 AI 기술이 적용될 수 있으며, 무선 장치(100a~100f)는 네트워크(300)를 통해 AI 서버(400)와 연결될 수 있다. 네트워크(300)는 3G 네트워크, 4G(예: LTE) 네트워크, 5G(예: NR) 네트워크 및 5G 이후의 네트워크 등을 이용하여 구성될 수 있다. 무선 장치(100a~100f)는 기지국(200)/네트워크(300)를 통해 서로 통신할 수도 있지만, 기지국(200)/네트워크(300)를 통하지 않고 직접 통신(예: 사이드링크 통신(sidelink communication))할 수도 있다. 예를 들어, 차량(100b-1, 100b-2)은 직접 통신(예: V2V(Vehicle-to-Vehicle)/V2X(Vehicle-to-everything) 통신)을 할 수 있다. 또한, IoT 기기(예: 센서)는 다른 IoT 기기(예: 센서) 또는 다른 무선 장치(100a~100f)와 직접 통신을 할 수 있다.
무선 장치(100a~100f) 간 및/또는 무선 장치(100a~100f)와 기지국(200) 간 및/또는 기지국(200) 간에 무선 통신/연결(150a, 150b, 150c)이 확립될 수 있다. 여기서, 무선 통신/연결은 상향/하향링크 통신(150a), 사이드링크 통신(150b)(또는, D2D(Device-To-Device) 통신), 기지국 간 통신(150c)(예: 중계, IAB(Integrated Access and Backhaul)) 등과 같이 다양한 RAT(예: 5G NR)을 통해 확립될 수 있다. 무선 통신/연결(150a, 150b, 150c)을 통해 무선 장치(100a~100f)와 기지국(200)은 서로 무선 신호를 송신/수신할 수 있다. 예를 들어, 무선 통신/연결(150a, 150b, 150c)은 다양한 물리 채널을 통해 신호를 송신/수신할 수 있다. 이를 위해, 본 명세서의 다양한 제안에 기반하여, 무선 신호의 송신/수신을 위한 다양한 구성 정보 설정 과정, 다양한 신호 처리 과정(예: 채널 인코딩/디코딩, 변조/복조, 자원 맵핑/디맵핑 등), 및 자원 할당 과정 등 중 적어도 일부가 수행될 수 있다.
NR은 다양한 5G 서비스를 지원하기 위한 다수의 뉴머럴로지(numerology) 또는 부반송파 간격(SCS; SubCarrier Spacing)을 지원한다. 예를 들어, SCS가 15kHz인 경우, 전통적인 셀룰러 밴드에서의 넓은 영역(wide area)를 지원하며, SCS가 30kHz/60kHz인 경우, 밀집한 도시(dense-urban), 저지연(lower latency) 및 더 넓은 반송파 대역폭(wider carrier bandwidth)를 지원하며, SCS가 60kHz 또는 그보다 높은 경우, 위상 잡음(phase noise)를 극복하기 위해 24.25GHz보다 큰 대역폭을 지원한다.
NR 주파수 대역은 2가지 타입(FR1, FR2)의 주파수 범위(frequency range)로 정의될 수 있다. 주파수 범위의 수치는 변경될 수 있다. 예를 들어, 2가지 타입(FR1, FR2)의 주파수 범위는 아래 표 1과 같을 수 있다. 설명의 편의를 위해, NR 시스템에서 사용되는 주파수 범위 중 FR1은 "sub 6GHz range"를 의미할 수 있고, FR2는 "above 6GHz range"를 의미할 수 있고 밀리미터 웨이브(MilliMeter Wave, mmW)로 불릴 수 있다.
주파수 범위 정의 주파수 범위 부반송파 간격
FR1 450MHz - 6000MHz 15, 30, 60kHz
FR2 24250MHz - 52600MHz 60, 120, 240kHz
상술한 바와 같이, NR 시스템의 주파수 범위의 수치는 변경될 수 있다. 예를 들어, FR1은 아래 표 2와 같이 410MHz 내지 7125MHz의 대역을 포함할 수 있다. 즉, FR1은 6GHz (또는 5850, 5900, 5925 MHz 등) 이상의 주파수 대역을 포함할 수 있다. 예를 들어, FR1 내에서 포함되는 6GHz (또는 5850, 5900, 5925 MHz 등) 이상의 주파수 대역은 비면허 대역(unlicensed band)을 포함할 수 있다. 비면허 대역은 다양한 용도로 사용될 수 있고, 예를 들어 차량을 위한 통신(예: 자율 주행)을 위해 사용될 수 있다.
주파수 범위 정의 주파수 범위 부반송파 간격
FR1 410MHz - 7125MHz 15, 30, 60kHz
FR2 24250MHz - 52600MHz 60, 120, 240kHz
여기서, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 LTE, NR 및 6G뿐만 아니라 저전력 통신을 위한 협대역 IoT(NB-IoT, NarrowBand IoT)를 포함할 수 있다. 예를 들어, NB-IoT 기술은 LPWAN(Low Power Wide Area Network) 기술의 일례일 수 있고, LTE Cat NB1 및/또는 LTE Cat NB2 등의 규격으로 구현될 수 있으며, 상술한 명칭에 한정되는 것은 아니다. 추가적으로 또는 대체적으로, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 LTE-M 기술에 기초하여 통신을 수행할 수 있다. 예를 들어, LTE-M 기술은 LPWAN 기술의 일례일 수 있고, eMTC(enhanced MTC) 등의 다양한 명칭으로 불릴 수 있다. 예를 들어, LTE-M 기술은 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, 및/또는 7) LTE M 등의 다양한 규격 중 적어도 어느 하나로 구현될 수 있으며 상술한 명칭에 한정되는 것은 아니다. 추가적으로 또는 대체적으로, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 저전력 통신을 고려한 지그비(ZigBee), 블루투스(Bluetooth) 및/또는 LPWAN 중 적어도 어느 하나를 포함할 수 있으며, 상술한 명칭에 한정되는 것은 아니다. 예를 들어, 지그비 기술은 IEEE 802.15.4 등의 다양한 규격에 기초하여 소형/저-파워 디지털 통신에 관련된 PAN(Personal Area Networks)을 생성할 수 있으며, 다양한 명칭으로 불릴 수 있다.
도 2는 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
도 2에서, 제1 무선 장치(100) 및/또는 제2 무선 장치(200)는 사용 예/서비스에 따라 다양한 형태로 구현될 수 있다. 예를 들어, {제1 무선 장치(100) 및 제2 무선 장치(200)}은(는) 도 1의 {무선 장치(100a~100f) 및 기지국(200)}, {무선 장치(100a~100f) 및 무선 장치(100a~100f)} 및/또는 {기지국(200) 및 기지국(200)} 중 적어도 하나에 대응할 수 있다. 제1 무선 장치(100) 및/또는 제2 무선 장치(200)는 다양한 구성 요소, 장치/부분 및/또는 모듈에 의해 구성될 수 있다.
제1 무선 장치(100)는 송수신기(106)와 같은 적어도 하나의 송수신기, 프로세싱 칩(101)과 같은 적어도 하나의 프로세싱 칩 및/또는 하나 이상의 안테나(108)를 포함할 수 있다.
프로세싱 칩(101)은 프로세서(102)와 같은 적어도 하나의 프로세서와 메모리(104)와 같은 적어도 하나의 메모리를 포함할 수 있다.. 추가적으로 및/또는 대체적으로, 메모리(104)는 프로세싱 칩(101) 외부에 배치될 수 있다.
프로세서(102)는 메모리(104) 및/또는 송수신기(106)를 제어할 수 있으며, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 구성될 수 있다. 예를 들어, 프로세서(102)는 메모리(104) 내의 정보를 처리하여 제1 정보/신호를 생성하고, 제1 정보/신호를 포함하는 무선 신호를 송수신기(106)를 통해 전송할 수 있다. 프로세서(102)는 송수신기(106)를 통해 제2 정보/신호를 포함하는 무선 신호를 수신하고, 제2 정보/신호를 처리하여 얻은 정보를 메모리(104)에 저장할 수 있다.
메모리(104)는 프로세서(102)에 동작 가능하도록 연결될 수 있다. 메모리(104)는 다양한 유형의 정보 및/또는 명령을 저장할 수 있다. 메모리(104)는 프로세서(102)에 의해 실행될 때 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 코드, 명령어 및/또는 명령어의 집합을 구현하는 펌웨어 및/또는 소프트웨어 코드(105)를 저장할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(105)는 프로세서(102)에 의해 실행될 때, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(105)는 하나 이상의 프로토콜을 수행하기 위해 프로세서(102)를 제어할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(105)는 하나 이상의 무선 인터페이스 프로토콜 계층을 수행하기 위해 프로세서(102)를 제어할 수 있다.
여기에서, 프로세서(102)와 메모리(104)는 RAT(예: LTE 또는 NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(106)는 프로세서(102)에 연결되어 하나 이상의 안테나(108)를 통해 무선 신호를 전송 및/또는 수신할 수 있다. 각 송수신기(106)는 송신기 및/또는 수신기를 포함할 수 있다. 송수신기(106)는 RF(Radio Frequency)부와 교체 가능하게 사용될 수 있다. 본 명세서에서 제1 무선 장치(100)는 통신 모뎀/회로/칩을 나타낼 수 있다.
제2 무선 장치(200)는 송수신기(206)와 같은 적어도 하나의 송수신기, 프로세싱 칩(201)과 같은 적어도 하나의 프로세싱 칩 및/또는 하나 이상의 안테나(208)를 포함할 수 있다.
프로세싱 칩(201)은 프로세서(202)와 같은 적어도 하나의 프로세서와 메모리(204)와 같은 적어도 하나의 메모리를 포함할 수 있다.. 추가적으로 및/또는 대체적으로, 메모리(204)는 프로세싱 칩(201) 외부에 배치될 수 있다.
프로세서(202)는 메모리(204) 및/또는 송수신기(206)를 제어할 수 있으며, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 구성될 수 있다. 예를 들어, 프로세서(202)는 메모리(204) 내의 정보를 처리하여 제3 정보/신호를 생성하고, 제3 정보/신호를 포함하는 무선 신호를 송수신기(206)를 통해 전송할 수 있다. 프로세서(202)는 송수신기(206)를 통해 제4 정보/신호를 포함하는 무선 신호를 수신하고, 제4 정보/신호를 처리하여 얻은 정보를 메모리(204)에 저장할 수 있다.
메모리(204)는 프로세서(202)에 동작 가능하도록 연결될 수 있다. 메모리(204)는 다양한 유형의 정보 및/또는 명령을 저장할 수 있다. 메모리(204)는 프로세서(202)에 의해 실행될 때 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 코드, 명령어 및/또는 명령어의 집합을 구현하는 펌웨어 및/또는 소프트웨어 코드(205)를 저장할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(205)는 프로세서(202)에 의해 실행될 때, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(205)는 하나 이상의 프로토콜을 수행하기 위해 프로세서(202)를 제어할 수 있다. 예를 들어, 펌웨어 및/또는 소프트웨어 코드(205)는 하나 이상의 무선 인터페이스 프로토콜 계층을 수행하기 위해 프로세서(202)를 제어할 수 있다.
여기에서, 프로세서(202)와 메모리(204)는 RAT(예: LTE 또는 NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(206)는 프로세서(202)에 연결되어 하나 이상의 안테나(208)를 통해 무선 신호를 전송 및/또는 수신할 수 있다. 각 송수신기(206)는 송신기 및/또는 수신기를 포함할 수 있다. 송수신기(206)는 RF부와 교체 가능하게 사용될 수 있다. 본 명세서에서 제2 무선 장치(200)는 통신 모뎀/회로/칩을 나타낼 수 있다.
이하, 무선 장치(100, 200)의 하드웨어 요소에 대해 보다 구체적으로 설명한다. 이로 제한되는 것은 아니지만, 하나 이상의 프로토콜 계층이 하나 이상의 프로세서(102, 202)에 의해 구현될 수 있다. 예를 들어, 하나 이상의 프로세서(102, 202)는 하나 이상의 계층(예: PHY(physical) 계층, MAC(Media Access Control) 계층, RLC(Radio Link Control) 계층, PDCP(Packet Data Convergence Protocol) 계층, RRC(Radio Resource Control) 계층, SDAP(Service Data Adaptation Protocol) 계층과 같은 기능적 계층)을 구현할 수 있다. 하나 이상의 프로세서(102, 202)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 하나 이상의 PDU(Protocol Data Unit), 하나 이상의 SDU(Service Data Unit), 메시지, 제어 정보, 데이터 또는 정보를 생성할 수 있다. 하나 이상의 프로세서(102, 202)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 PDU, SDU, 메시지, 제어 정보, 데이터 또는 정보를 포함하는 신호(예: 베이스밴드 신호)를 생성하여, 하나 이상의 송수신기(106, 206)에게 제공할 수 있다. 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)로부터 신호(예: 베이스밴드 신호)를 수신할 수 있고, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 PDU, SDU, 메시지, 제어 정보, 데이터 또는 정보를 획득할 수 있다.
하나 이상의 프로세서(102, 202)는 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 및/또는 마이크로 컴퓨터로 지칭될 수 있다. 하나 이상의 프로세서(102, 202)는 하드웨어, 펌웨어, 소프트웨어, 및/또는 이들의 조합에 의해 구현될 수 있다. 일 예로, 하나 이상의 ASIC(Application Specific Integrated Circuit), 하나 이상의 DSP(Digital Signal Processor), 하나 이상의 DSPD(Digital Signal Processing Device), 하나 이상의 PLD(Programmable Logic Device) 및/또는 하나 이상의 FPGA(Field Programmable Gate Arrays)가 하나 이상의 프로세서(102, 202)에 포함될 수 있다. 일 예로, 하나 이상의 프로세서(102, 202)는 통신 제어 프로세서, 애플리케이션 프로세서(AP; Application Processor), 전자 제어 장치(ECU; Electronic Control Unit), 중앙 처리 장치(CPU; Central Processing Unit), 그래픽 처리 장치(GPU; Graphic Processing Unit) 및 메모리 제어 프로세서의 집합에 의해 구성될 수 있다. 하나 이상의 메모리(104, 204)는 하나 이상의 프로세서(102, 202)와 연결될 수 있고, 다양한 형태의 데이터, 신호, 메시지, 정보, 프로그램, 코드, 지시 및/또는 명령을 저장할 수 있다. 하나 이상의 메모리(104, 204)는 RAM(Random Access Memory), DRAM(Dynamic RAM), ROM(Read-Only Memory), EPROM(Erasable Programmable ROM), 플래시 메모리, 휘발성 메모리, 비휘발성 메모리, 하드 드라이브, 레지스터, 캐쉬 메모리, 컴퓨터 판독 저장 매체 및/또는 이들의 조합으로 구성될 수 있다. 하나 이상의 메모리(104, 204)는 하나 이상의 프로세서(102, 202)의 내부 및/또는 외부에 위치할 수 있다. 또한, 하나 이상의 메모리(104, 204)는 유선 또는 무선 연결과 같은 다양한 기술을 통해 하나 이상의 프로세서(102, 202)와 연결될 수 있다.
하나 이상의 송수신기(106, 206)는 하나 이상의 다른 장치에게 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 전송할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 다른 장치로부터 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 수신할 수 있다. 예를 들어, 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)와 연결될 수 있고, 무선 신호를 송수신할 수 있다. 예를 들어, 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)가 하나 이상의 다른 장치에게 사용자 데이터, 제어 정보, 무선 신호 등을 전송하도록 제어할 수 있다. 또한, 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)가 하나 이상의 다른 장치로부터 사용자 데이터, 제어 정보, 무선 신호 등을 수신하도록 제어할 수 있다.
하나 이상의 송수신기(106, 206)는 하나 이상의 안테나(108, 208)와 연결될 수 있다. 추가적으로 및/또는 대체적으로, 하나 이상의 송수신기(106, 206)는 하나 이상의 안테나(108, 208)를 포함할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 안테나(108, 208)를 통해 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 송수신하도록 구성될 수 있다. 본 명세서에서, 하나 이상의 안테나(108, 208)는 복수의 물리 안테나이거나, 복수의 논리 안테나(예: 안테나 포트)일 수 있다.
하나 이상의 송수신기(106, 206)는 수신된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 하나 이상의 프로세서(102, 202)를 이용하여 처리하기 위해, 수신된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 RF 밴드 신호에서 베이스밴드 신호로 변환할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)를 이용하여 처리된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 베이스밴드 신호에서 RF 밴드 신호로 변환할 수 있다. 이를 위하여, 하나 이상의 송수신기(106, 206)는 (아날로그) 발진기(oscillator) 및/또는 필터를 포함할 수 있다. 예를 들어, 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)의 제어 하에 (아날로그) 발진기 및/또는 필터를 통해 OFDM 베이스밴드 신호를 OFDM 신호로 상향 변환(up-convert)하고, 상향 변환된 OFDM 신호를 반송파 주파수에서 전송할 수 있다. 하나 이상의 송수신기(106, 206)는 반송파 주파수에서 OFDM 신호를 수신하고, 하나 이상의 프로세서(102, 202)의 제어 하에 (아날로그) 발진기 및/또는 필터를 통해 OFDM 신호를 OFDM 베이스밴드 신호로 하향 변환(down-convert)할 수 있다.
도 2에 도시되지는 않았으나, 무선 장치(100, 200)는 추가 구성 요소를 더 포함할 수 있다. 추가 구성 요소(140)는 무선 장치(100, 200)의 유형에 따라 다양하게 구성될 수 있다. 예를 들어, 추가 구성 요소(140)는 동력 장치/배터리, 입출력(I/O) 장치(예: 오디오 I/O 포트, 비디오 I/O 포트), 구동 장치 및 컴퓨팅 장치 중 적어도 하나를 포함할 수 있다. 추가 구성 요소(140)는 유선 또는 무선 연결과 같은 다양한 기술을 통해 하나 이상의 프로세서(102, 202)와 연결될 수 있다.
본 명세서의 구현에서, UE는 상향링크에서 송신 장치로, 하향링크에서 수신 장치로 작동할 수 있다. 본 명세서의 구현에서, 기지국은 UL에서 수신 장치로, DL에서 송신 장치로 동작할 수 있다. 이하에서 기술 상의 편의를 위하여, 제1 무선 장치(100)는 UE로, 제2 무선 장치(200)는 기지국으로 동작하는 것으로 주로 가정한다. 예를 들어, 제1 무선 장치(100)에 연결, 탑재 또는 출시된 프로세서(102)는 본 명세서의 구현에 따라 UE 동작을 수행하거나 본 명세서의 구현에 따라 UE 동작을 수행하도록 송수신기(106)를 제어하도록 구성될 수 있다. 제2 무선 장치(200)에 연결, 탑재 또는 출시된 프로세서(202)는 본 명세서의 구현에 따른 기지국 동작을 수행하거나 본 명세서의 구현에 따른 기지국 동작을 수행하기 위해 송수신기(206)를 제어하도록 구성될 수 있다.
본 명세서에서, 기지국은 노드 B(Node B), eNode B(eNB), gNB로 불릴 수 있다.
도 3은 본 명세서의 구현이 적용되는 UE의 예를 나타낸다.
도 3을 참조하면, UE(100)는 도 2의 제1 무선 장치(100)에 대응할 수 있다.
UE(100)는 프로세서(102), 메모리(104), 송수신기(106), 하나 이상의 안테나(108), 전원 관리 모듈(141), 배터리(142), 디스플레이(143), 키패드(144), SIM(Subscriber Identification Module) 카드(145), 스피커(146), 마이크(147)를 포함한다.
프로세서(102)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 구성될 수 있다. 프로세서(102)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 UE(100)의 하나 이상의 다른 구성 요소를 제어하도록 구성될 수 있다. 무선 인터페이스 프로토콜의 계층은 프로세서(102)에 구현될 수 있다. 프로세서(102)는 ASIC, 기타 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다. 프로세서(102)는 애플리케이션 프로세서일 수 있다. 프로세서(102)는 DSP, CPU(Central Processing Unit), GPU(Graphics Processing Unit), 모뎀(변조 및 복조기) 중 적어도 하나를 포함할 수 있다. 프로세서(102)의 예는 Qualcomm®에서 만든 SNAPDRAGONTM 시리즈 프로세서, Samsung®에서 만든 EXYNOSTM 시리즈 프로세서, Apple®에서 만든 A 시리즈 프로세서, MediaTek®에서 만든 HELIOTM 시리즈 프로세서, Intel®에서 만든 ATOMTM 시리즈 프로세서 또는 대응하는 차세대 프로세서에서 찾을 수 있다.
메모리(104)는 프로세서(102)와 동작 가능하도록 결합되며, 프로세서(102)를 작동하기 위한 다양한 정보를 저장한다. 메모리(104)는 ROM, RAM, 플래시 메모리, 메모리 카드, 저장 매체 및/또는 기타 저장 장치를 포함할 수 있다. 구현이 소프트웨어에서 구현될 때, 여기에 설명된 기술은 본 명세서에서 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 모듈(예: 절차, 기능 등)을 사용하여 구현될 수 있다. 모듈은 메모리(104)에 저장되고 프로세서(102)에 의해 실행될 수 있다. 메모리(104)는 프로세서(102) 내에 또는 프로세서(102) 외부에 구현될 수 있으며, 이 경우 기술에서 알려진 다양한 방법을 통해 프로세서(102)와 통신적으로 결합될 수 있다.
송수신기(106)는 프로세서(102)와 동작 가능하도록 결합되며, 무선 신호를 전송 및/또는 수신한다. 송수신기(106)는 송신기와 수신기를 포함한다. 송수신기(106)는 무선 주파수 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 송수신기(106)는 하나 이상의 안테나(108)를 제어하여 무선 신호를 전송 및/또는 수신한다.
전원 관리 모듈(141)은 프로세서(102) 및/또는 송수신기(106)의 전원을 관리한다. 배터리(142)는 전원 관리 모듈(141)에 전원을 공급한다.
디스플레이(143)는 프로세서(102)에 의해 처리된 결과를 출력한다. 키패드(144)는 프로세서(102)에서 사용할 입력을 수신한다. 키패드(144)는 디스플레이(143)에 표시될 수 있다.
SIM 카드(145)는 IMSI(International Mobile Subscriber Identity)와 관련 키를 안전하게 저장하기 위한 집적 회로이며, 휴대 전화나 컴퓨터와 같은 휴대 전화 장치에서 가입자를 식별하고 인증하는 데에 사용된다. 또한, 많은 SIM 카드에 연락처 정보를 저장할 수도 있다.
스피커(146)는 프로세서(102)에서 처리한 사운드 관련 결과를 출력한다. 마이크(147)는 프로세서(102)에서 사용할 사운드 관련 입력을 수신한다.
도 4는 본 명세서의 구현이 적용되는 5G 시스템 구조의 예를 나타낸다.
5G 시스템(5GS; 5G system) 구조는 다음과 같은 네트워크 기능(NF; Network Function)으로 구성된다.
- AUSF (Authentication Server Function)
- AMF (Access and Mobility Management Function)
- DN (Data Network), 예를 들어 운영자 서비스, 인터넷 접속 또는 타사 서비스
- USDF (Unstructured Data Storage Function)
- NEF (Network Exposure Function)
- I-NEF (Intermediate NEF)
- NRF (Network Repository Function)
- NSSF (Network Slice Selection Function)
- PCF (Policy Control Function)
- SMF (Session Management Function)
- UDM (Unified Data Management)
- UDR (Unified Data Repository)
- UPF (User Plane Function)
- UCMF (UE radio Capability Management Function)
- AF (Application Function)
- UE (User Equipment)
- (R)AN ((Radio) Access Network)
- 5G-EIR (5G-Equipment Identity Register)
- NWDAF (Network Data Analytics Function)
- CHF (CHarging Function)
또한, 다음과 같은 네트워크 기능이 고려될 수 있다.
- N3IWF (Non-3GPP InterWorking Function)
- TNGF (Trusted Non-3GPP Gateway Function)
- W-AGF (Wireline Access Gateway Function)
도 4는 다양한 네트워크 기능이 어떻게 서로 상호 작용하는지를 보여주는 기준점(reference point) 표현을 사용하여 비로밍(non-roaming) 사례의 5G 시스템 구조를 보여준다.
도 4에서는 점 대 점 도면의 명확성을 위해, UDSF, NEF 및 NRF는 설명되지 않았다. 그러나 표시된 모든 네트워크 기능은 필요에 따라 UDSF, UDR, NEF 및 NRF와 상호 작용할 수 있다.
명확성을 위해, UDR과 다른 NF(예: PCF)와의 연결은 도 4에 도시되지 않는다. 명확성을 위해, NWDAF과 다른 NF(예: PCF)와의 연결은 도 4에 도시되지 않는다.
5G 시스템 구조는 다음과 같은 기준점을 포함한다.
- N1: UE와 AMF 사이의 기준점.
- N2: (R)AN과 AMF 사이의 기준점.
- N3: (R)AN과 UPF 사이의 기준점.
- N4: SMF와 UPF 사이의 기준점.
- N6: UPF와 데이터 네트워크 사이의 기준점.
- N9: 두 UPF 사이의 기준점.
다음의 기준점은 NF의 NF 서비스 간에 존재하는 상호 작용을 보여준다.
- N5: PCF와 AF 사이의 기준점.
- N7: SMF와 PCF 사이의 기준점.
- N8: UDM과 AMF 사이의 기준점.
- N10: UDM과 SMF 사이의 기준점.
- N11: AMF와 SMF 사이의 기준점.
- N12: AMF와 AUSF 사이의 기준점.
- N13: UDM과 AUSF 사이의 기준점.
- N14: 두 AMF 사이의 기준점.
- N15: 비로밍 시나리오의 경우 PCF와 AMF 사이의 기준점, 로밍 시나리오의 경우 방문 네트워크의 PCF와 AMF 사이의 기준점.
- N16: 두 SMF 사이의 기준점(로밍의 경우 방문 네트워크의 SMF와 홈 네트워크의 SMF 사이)
- N22: AMF와 NSSF 사이의 기준점.
경우에 따라, UE를 서비스하기 위해 두 개의 NF를 서로 연결해야 할 수도 있다.
PDU 세션 수립(PDU session establishment) 절차에 대해 설명한다. 3GPP TS 23.502 V16.3.0 (2019-12)의 섹션 4.3.2를 참조할 수 있다.
도 5 및 도 6은 본 명세서의 구현이 적용되는 PDU 세션 수립 절차의 예를 나타낸다.
PDU 세션 수립은 다음에 해당할 수 있다:
- UE가 개시한 PDU 세션 수립 절차
- UE가 개시한 3GPP와 비-3GPP 사이의 PDU 세션 핸드오버
- UE가 개시한 EPS에서 5GS로 PDU 세션 핸드오버.
- 네트워크가 트리거 한 PDU 세션 수립 절차
PDU 세션은 (a) 주어진 시간에 단일 접속 유형, 즉 3GPP 접속 또는 비-3GPP 접속 중 어느 하나에 연관되거나, 또는 (b) 동시에 여러 접속 유형, 즉 하나의 3GPP 접속 및 하나의 비-3GPP 접속과 연관될 수 있다. 다중 접속 유형과 연관된 PDU 세션을 MA(multi access) PDU 세션이라고 하며, ATSSS(access traffic steering, switching, splitting) 지원 UE에 의해 요청될 수 있다.
도 5 및 도 6은 주어진 시간에 단일 접속 유형과 연관된 PDU 세션을 수립하기 위한 절차를 명시한다.
도 5 및 도 6에 나타난 절차에서는, UE가 이미 AMF에 등록되었으므로 UE가 긴급 등록되지 않은 한, AMF는 UDM에서 사용자 구독 데이터를 이미 회수한 것을 가정한다.
먼저, 도 5의 절차를 설명한다.
(1) 1단계: 새로운 PDU 세션을 수립하기 위해 UE는 새로운 PDU 세션 ID를생성한다다.
UE는 N1 SM 컨테이너(container) 내에 PDU 세션 수립 요청 메시지를 포함하는 NAS 메시지를 전송하여 UE가 요청한 PDU 세션 수립 절차를 시작한다. PDU 세션 수립 요청 메시지는 PDU 세션 ID(PDU session ID), 요청된 PDU 세션 유형(Requested PDU Session Type), 요청된 SSC(session and service continuity) 모드, 5G SM 능력, PCO(Protocol Configuration Options), SM PDU DN 요청 컨테이너(SM PDU DN Request Container), UE 무결성 보호 최대 데이터 전송 속도(UE Integrity Protection Maximum Data Rate) 등을 포함한다.
PDU 세션 수립이 새 PDU 세션을 수립하기 위한 요청인 경우, 요청 유형은 "초기 요청(Initial Request)"을 나타낸다. 요청이 3GPP 접속과 비-3GPP 접속 사이에서 전환되는 기존 PDU 세션 또는 EPC에서 기존 PDN(packet data network) 연결로부터의 PDU 세션 핸드오버를 참조하는 경우, 요청 유형은 "기존 PDU 세션(Existing PDU Session)"을 나타낸다. PDU 세션 수립이 긴급 서비스에 대한 PDU 세션을 수립하기 위한 요청인 경우, 요청 유형은 "긴급 요청(Emergency Request)"을 나타낸다. 요청이 3GPP 접속과 비-3GPP 접속 사이에서 전환되는 긴급 서비스에 대한 기존 PDU 세션 또는 EPC에서 비상 서비스를 위한 기존 PDN 연결로부터의 PDU 세션 핸드오버를 참조하는 경우, 요청 유형은 "기존 긴급 PDU 세션(Existing Emergency PDU Session)"을 나타낸다.
UE는 현재 접속 유형의 허용된 NSSAI로부터 S-NSSAI를 포함한다. 허용된 NSSAI의 맵핑(Mapping Of Allowed NSSAI)이 UE에 제공된 경우, UE는 허용된 NSSAI로부터 VPLMN(visited VPLMN)의 S-NSSAI 및 허용된 NSSAI의 맵핑으로부터 HPLMN의 대응하는 S-NSSAI를 모두 제공한다.
(2) 2단계: AMF는 SMF를 선택한다. 요청 유형이 "초기 요청"을 나타내거나, 요청이 EPS 또는 다른 AMF가 제공하는 비-3GPP 접속으로부터 핸드오버 때문인 경우, AMF는 PDU 세션의 접속 유형뿐만 아니라 S-NSSAI(s)의 연관, DNN(data network name), PDU 세션 ID, SMF ID를 저장한다.
요청 유형이 "초기 요청"이고 기존 PDU 세션을 나타내는 이전 PDU 세션 ID도 메시지에 포함된 경우, AMF는 SMF를 선택하고 새 PDU 세션 ID, S-NSAI(s), 선택한 SMF ID의 연결을 저장한다.
요청 유형이 "기존 PDU 세션"을 나타내는 경우, AMF는 UDM에서 수신한 SMF-ID에 기초하여 SMF를 선택한다. AMF는 PDU 세션에 대해 저장된 접속 유형을 업데이트한다.
요청 유형이 3GPP 접속과 비-3GPP 접속 사이에서 이동하는 기존 PDU 세션을 참조하는 "기존 PDU 세션"을 나타내는 경우, 그리고 PDU 세션의 서빙 PLMN S-NSSAI가 대상 접속 유형의 허용 NSSAI에 존재하는 경우, PDU 세션 수립 절차는 다음의 경우에 수행될 수 있다.
- PDU 세션 ID에 대응하는 SMF ID와 AMF가 동일한 PLMN에 속하는 경우;
- PDU 세션 ID에 대응하는 SMF ID가 HPLMN에 속하는 경우;
그렇지 않은 경우, AMF는 적절한 거부 원인과 함께 PDU 세션 수립 요청을 거절한다.
AMF는 요청 유형은 "긴급 요청" 또는 "기존 긴급 PDU 세션"을 지시하지 않는 긴급 등록된 UE로부터의 요청을 거절한다.
(3) 3단계: AMF가 UE에서 제공하는 PDU 세션 ID에 대해 SMF와 연관되지 않은 경우(예: 요청 유형이 "초기 요청"을 지시할 때), AMF는 생성 SM 컨텍스트 요청 절차(예: Nsmf_PDUSession_CreateSMContext Request)를 호출한다. AMF가 UE에서 제공하는 PDU 세션 ID에 대해 SMF와 이미 연관되어 있는 경우(예: 요청 유형이 "기존 PDU 세션"을 지시할 때), AMF는 업데이트 SM 컨텍스트 요청 절차(예: Nsmf_PDUSession_UpdateSMContext Request)를 호출한다.
AMF는 허용 NSSAI로부터 서빙 PLMN의 S-NSSAI를 SMF로 전송한다. 로컬 브레이크아웃(LBO; local breakout)의 로밍 시나리오에 대해, AMF는 허용된 NSSAI의 맵핑으로부터 HPLMN의 대응하는 S-NSSAI를 또한 SMF로 전송한다.
AMF ID는 UE의 GUAMI로, UE를 서빙하는 AMF를 고유하게 식별한다. AMF는 UE로부터 수신한 PDU 세션 수립 요청 메시지가 포함된 N1 SM 컨테이너와 함께 PDU 세션 ID를 전달한다. GPSI(generic public subscription identifier)는 AMF에서 사용할 수 있는 경우 포함된다.
제한된 서비스 상태의 UE가 SUPI를 제공하지 않고 긴급 서비스를 위해 등록된 경우, AMF는 SUPI 대신 PEI를 제공한다. 제한된 서비스 상태의 UE가 SUPI를 제공하면서 긴급 서비스를 위해 등록되었지만 인증되지 않은 경우, AMF는 SUPI가 인증되지 않았음을 지시한다. SMF는 UE에 대해 SUPI를 수신하지 않거나 AMF가 SUPI가 인증되지 않았음을 지시하면, UE가 인증되지 않았다고 판단한다.
AMF는 Nsmf_PDUSession_CreateSMContext에 PCF ID를 포함할 수 있다. 이 PCFID는 비로밍 경우에서 H-PCF(home PCF)와 LBO 로밍 경우에서 V-PCF(visited PCF)를 식별한다.
(4) 4단계: 대응하는 SUPI, DNN, HPLMN의 S-NSSAI에 대한 세션 관리 가입 데이터(session management subscription data)를 사용할 수 없는 경우 SMF는 UDM에서 세션 관리 가입 데이터를 회수할 수 있고, 이 가입 데이터가 수정될 때 이를 통지 받을 수 있다.
(5) 5단계: SMF는, 3단계에서 수신한 요청에 따라, 생성 SM 컨텍스트 응답 메시지(예: Nsmf_PDUSession_CreateSMContext Response) 또는 업데이트 SM 컨텍스트 응답 메시지(예: Nsmf_PDUSession_UpdateSMContext Response)를 AMF로 전송한다.
SMF가 3단계에서 Nsmf_PDUSession_CreateSMContext Request를 수신하였고 PDU 세션 수립 요청을 처리할 수 있으면, SMF는 SM 컨텍스트를 생성하고 SM 컨텍스트 ID를 제공하여 AMF에 응답한다.
SMF가 PDU 세션 수립을 수락하지 않기로 결정하면, SMF는 Nsmf_PDUSession_CreateSMContext Response로 AMF에 응답함으로써 관련 SM 거부 원인을 포함한 NAS SM 신호를 통해 UE 요청을 거절한다. SMF는 또한 AMF에 PDU 세션 ID가 해제된 것으로 간주되고 SMF가 아래 20단계를 진행하고 PDU 세션 설정 절차가 중지됨을 나타낸다.
(6) 6단계: 선택적 2차 인증/허가가 수행될 수 있다.
(7a) 7a 단계: PDU 세션에 동적 정책 및 과금 제어(PCC; policy and charging control)를 사용할 경우, SMF가 PCF 선택을 수행할 수 있다.
(7b) 7b 단계: SMF는 SM 정책 연관 수립 절차를 수행하여 PCF와 SM 정책 연관을 수립하고, PDU 세션에 대한 기본 PCC 규칙을 얻을 수 있다.
(8) 8단계: SMF는 하나 이상의 UPF를 선택한다.
(9) 9단계: SMF는 SMF가 개시한 SM 정책 연관 수정 절차를 수행하여 충족된 정책 제어 요청 트리거 조건에 대한 정보를 제공할 수 있다.
(10) 10단계: 요청 유형이 "초기 요청"을 지시하는 경우, SMF는 선택한 UPF와 N4 세션 수립(N4 Session Establishment) 절차를 개시할 수 있다. 그렇지 않으면, SMF는 선택한 UPF와 N4 세션 수정(N4 Session Modification) 절차를 개시할 수 있다.
10a 단계에서, SMF는 UPF에 N4 세션 수립/수정 요청을 보낼 수 있고, PDU 세션에 대해 UPF에 설치되는 패킷 감지, 시행 및 보고 규칙을 제공한다. 10b 단계에서, UPF는 N4 세션 수립/수정 응답을 전송하여 확인할 수 있다.
(11) 11단계: SMF는 N1N2 메시지 전달 메시지(예: Namf_Communication_N1N2 Message Transfer)를 AMF에 전송한다.
N1N2 메시지 전달 메시지는 N2 SM 정보가 포함할 수 있다. N2 SM 정보는 AMF가 (R)AN으로 전달할 다음의 정보를 나른다.
- CN 터널 정보(CN Tunnel Info): PDU 세션에 대응하는 N3 터널의 코어 네트워크 주소에 해당함;
- 하나 이상의 QoS(quality of service) 프로파일과 대응하는 QFI(QoS flow ID);
- PDU 세션 ID: RAN 자원과 UE를 위한 PDU 세션 간의 연관을 UE에게 지시함;
- 서빙 PLMN을 위한 값을 갖는 S-NSSAI(즉, HPLMN S-NSSAI, 또는 LBO 로밍의 경우 VPLMN S-NSSAI);
- SMF에 의해 결정된 사용자 평면 보안 시행 정보;
- PDU 세션 수립 요청 메시지에서 수신된 UE 무결성 보호 최대 데이터 속도: 사용자 평면 보안 시행 정보에 무결성 보호가 "우선(Preferred)" 또는 "필요(Required)"로 지시된 경우
- RSN(redundancy sequence number) 파라미터
N1N2 메시지 전달 메시지는 N1 SM 컨테이너를 포함할 수 있다. N1 SM 컨테이너는 AMF가 UE에 제공할 PDU 세션 수립 수락 메시지를 포함한다. PDU 세션 수립 수락 메시지는 허용된 NSASI로부터의 S-NSSAI를 포함한다. LBO 로밍 시나리오의 경우, PDU 세션 수립 수락 메시지는 VPLMN에 대해 허용된 NSSAI로부터 S-NSSAI를 포함하며, 3단계서 SMF가 수신한 허용된 NSSAI의 맵핑으로부터 HPLMN의 대응하는 S-NSSAI를 또한 포함한다.
QoS 규칙 및 QoS 프로파일과 관련된 QoS 흐름에 대해 필요한 경우, 복수의 QoS 규칙, QoS 흐름 수준, QoS 파라미터가 N1 SM 컨테이너 내의 PDU 세션 수립 수락 메시지 및 N2 SM 정보 내에 포함될 수 있다.
5단계와 11단계 사이에 PDU 세션 수립이 실패한 경우, N1N2 메시지 전달 메시지는 PDU 세션 수립 거절 메시지를 포함하는 N1 SM 컨테이너를 포함하며, N2 SM 정보는 포함하지 않는다. (R)AN은 PDU 세션 수립 거절 메시지를 포함하는 NAS 메시지를 UE로 전송한다. 이 경우 아래 12-17단계를 생략된다.
(12) 12단계: AMF는 UE로 향하는 PDU 세션 ID 및 PDU 세션 수립 수락 메시지 및 SMF로부터 수신한 N2 SM 정보를 포함하는 NAS 메시지를 N2 PDU 세션 요청 메시지 내에서 (R)AN으로 전송한다.
(13) 13단계: (R)AN은 SMF에서 수신한 정보와 관련된 UE와 AN 특정 신호 교환을 수행할 수 있다. 예를 들어, NG-RAN의 경우, UE가 12단계에서 수신한 PDU 세션 요청에 대한 QoS 규칙과 관련하여 필요한 NG-RAN 자원을 설정하는 RRC 연결 재구성을 UE와 수행할 수 있다.
(R)AN은 12단계에서 수신한 NAS 메시지(PDU 세션 ID, N1 SM 컨테이너(PDU 세션 수립 수락 메시지))를 UE로 전달한다. (R)AN은 UE와의 AN 특정 신호 교환이 수신된 N2 명령과 관련된 (R)AN 자원 추가를 포함하는 경우에만 UE에 NAS 메시지를 제공한다.
N2 SM 정보가 11단계에 포함되지 않는 경우, 아래 14~16b 단계 및 17단계는 생략된다.
이제, 도 5의 절차에 뒤따르는 도 6의 절차가 설명된다.
(14) 14단계: (R)AN은 N2 PDU 세션 응답 메시지를 AMF로 전송한다. N2 PDU 세션 응답 메시지는 PDU 세션 ID, 원인, N2 SM 정보(PDU 세션 ID, AN 터널 정보, 수락/거절된 QFI 목록, 사용자 평면 시행 정책 알림) 등을 포함할 수 있다.
(15) 15단계: AMF는 업데이트 SM 컨텍스트 요청 메시지(예: Nsmf_PDUSession_UpdateSMContext Request)를 SMF로 전송한다. AMF는 (R)AN으로부터 수신한 N2 SM 정보를 SMF로 전달한다.
(16a) S16a 단계: SMF는 UPF와 함께 N4 세션 수정 절차를 개시한다. SMF는 AN 터널 정보와 대응하는 전달 규칙을 UPF로 제공한다.
(16b) S16b 단계: UPF는 SMF에 N4 세션 수정 응답을 제공한다.
이 단계 후에, UPF는 이 PDU 세션을 위하여 버퍼 되었을 수 있는 DL 패킷을 UE에 전달할 수 있다.
(16c) 16c 단계: SMF가 이 PDU 세션에 대해 아직 등록되지 않은 경우, SMF는 주어진 PDU 세션에 대해 UDM에 등록할 수 있다.
(17) 17단계: SMF는 업데이트 SM 컨텍스트 응답 메시지(예: Nsmf_PDUSession_UpdateSMContext Response)를 AMF로 전송한다.
이 단계 후에, AMF는 SMF가 구독한 관련 이벤트를 전달한다.
(18) 18단계: 5단계 이후 언제라도 절차 도중, PDU 세션 수립이 성공하지 못하는 경우, SMF는 Nsmf_PDUSession_SMContextStatusNotify (해제)를 호출하여 AMF에 알릴 수 있다. SMF는 또한 생성된 N4 세션, 할당된 경우 PDU 세션 주소(예: IP 주소)를 해제할 수 있으며, 가능한 경우 PCF와의 연관도 해제할 수 있다. 이 경우 아래 19단계는 생략된다.
(19) 19단계: PDU 세션 유형 IPv6 또는 IPv4v6의 경우, SMF는 IPv6 라우터 알림(IPv6 Router Advertisement)을 생성하여 UE에 전송할 수 있다.
(20) 20단계: SMF는 SMF가 개시한 SM 정책 연관 수정을 수행할 수 있다.
(21) 21단계: 4단계 이후에 PDU 세션 수립이 실패한 경우, SMF는 UE의 PDU 세션을 더 이상 처리하지 않을 경우 SMF는 세션 관리 구독 데이터의 수정에 대해 구독 해제할 수 있다.
<UAS (Uncrewed Aerial System)>
5G에서, UAS(Uncrewed Aerial System)을 지원하는 방안이 논의되고 있다. UAS는 1개 이상의 무인 비행체인 UAV(Uncrewed Aerial Vehicle)과 1개의 무인 비행체 제어기인 UAV-C (UAV Controller)로 구성될 수 있다. 무인 비행체는 3GPP 이동 통신망 또는 비 3GPP 이동 통신망의 C2 (Command and Control) 링크 상에서 무인 비행체 제어기에 의해 제어될 수 있다.
참고로, 본 명세서의 개시에서, C2 통신은 Command and Control (C2) Communication을 의미할 수 있다. C2 통신은 UAV 컨트롤러 또는 Uncrewed Aircraft Systems Traffic Management (UTM)에서 UAV로 UAV 동작을 위한 명령 및 제어 정보가 포함된 메시지를 전달하거나 UAV에서 UAV 컨트롤러 또는 UTM으로 텔레메트리 데이터(telemetry data)를 보고하기 위한 사용자 평면 링크를 의미할 수 있다.
UAS의 관리를 위하여 USS (UAS Service Supplier)/UTM (UAS Traffic Management)과 UAV 은 3GPP 이동통신망을 경유하여 응용 데이터 트래픽을 교환할 수 있다. UAV는 UE로 간주될 수 있다. 예를 들어, 이하 도 7의 예시는 UAV를 위한 논리적인 5GS 및 EPS 아키텍처를 보여준다. 자세한 사항은 TS 23.256 V17.0.0을 참고할 수 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 7은 UAV를 위한 논리적인 5GS와 EPS의 아키텍쳐의 일 예를 나타낸다.
UAV는 네트워크로부터 연결 서비스를 받기 위해, UUAA (UAV USS authentication and authorization procedure)를 통한 인증 절차를 수행해야 한다. 예를 들어, 네트워크 사업자의 정책에 따라 아래와 같은 방법으로 인증이 수행될 수 있다.
1) UAV가 네트워크에 등록하는 과정에서 UUAA를 수행할 수 있다: 일례로, UAV가 Access and Mobility Subscription data에 Aerial UE subscription을 가지고 있을 수 있다. UAV가 전송하는 등록 요청 메시지에 CAA-Level UAV ID가 포함되는 경우에, UUAA가 수행될 수 있다 (이를 UUAA-MM이라고 지칭할 수 있다). UUAA-MM이 수행되지 않으면, UAV는 PDU session 생성 과정에서 UUAA를 수행할 수 있다.
2) UAV가 UAV 서비스를 위한 DNN의 PDU session 생성과정에서 (EPS의 경우 PDN connection) UUAA를 수행할 수 있다 (이를 UUAA-SM이라고 지칭할 수 있다): 5GS의 경우 UAV가 CAA-Level UAV ID를 PDU session 생성 요청 메시지에 제공할 때 UUAA-SM가 SMF에 의해 시작될 수 있다. EPS의 경우 UAV가 CAA-Level UAV ID를 ESM message container에 제공하는 경우, SMF+PGW-C에 의해 시작될 수 있다.
UAV의 통신은 UAV와 USS사이의 USS 통신과 C2 통신으로 나누어 질 수 있다. USS 통신은 C2 통신을 제외한 사용자평면 데이터 전송일 수 있다. C2 통신을 위한 PDU Session/PDN connection과 USS 통신을 위한 PDU Session/PDN Connection은 공통으로 사용될 수도 있고 분리되어 사용될 수도 있다. 즉, C2 통신을 위한 PDU Session/PDN connection과 USS 통신을 위한 PDU Session/PDN Connection이 동일할 수도 있고, 서로 다를 수도 있다.
UAS Network Function은 NEF (Network Exposure Function) 또는 SCEF(Service Capability Exposure Function)+NEF에 의해 지원되며, USS에 대한 서비스의 외부 노출 (exposure)에 사용될 수 있다. UAS-NF는 UAV의 authentication/authorization, 비행 허가, UAV-UAVC pairing 허가 및 관련 동작의 철회, 위치 보고, C2 통신을 위한 QoS/트래픽 필터링의 제어등의 동작을 위해 기존의 NEF/SCEF의 노출 서비스를 활용할 수 있다. UAS NF는 UUAA-MM 과정의 결과와 UUAA-SM과정의 결과를 저장할 수 있다. 그리고, USS의 요청에 의한 재인증 (re-authentication)을 지원하기 위해 UAS NF는 re-authentication을 AMF에게 요청해야 하는지, SMF/SMF+PGW-C에게 요청해야 하는지를 저장할 수 있으며, 이와 함께 현재 서비스 제공 중인 AMF나 SMF/SMF+PGW-C의 주소 등을 저장하고 있을 수 있다.
USS 는 UUAA 절차가 끝난 이후, 언제라도 UAS NF를 통해 재인증(Re-authentication) 절차를 시작할 수 있다. UUAA re-authentication은 네트워크 설정에 따라 SMF (UUAA-SM) 또는 AMF (UUAA-MM)을 통해 수행될 수 있다. re-authentication의 결과는 USS에서 UAS NF를 거쳐 SMF (UUAA-SM) 또는 AMF (UUAA-MM)을 통해 UE에게 전달될 수 있다.
5GS에서 UAS (Uncrewed Aerial System) services를 지원하기 위한 추가적인 방안이 논의되고 있다. 3GPP TR 23.700-58 v1.0.0은 다음과 같은 이슈를 포함한다.
예를 들어, PC5 인터페이스를 통한 C2 통신 전송(Transport C2 communication over PC5 interface)에 대한 이슈가 있다.
이 이슈는 3GPP 시스템에서 PC5를 통한 C2 통신 전송에 중점을 둔다. 여기에는 UAV와 UAV 컨트롤러 간의 직접 C2 통신을 활성화하는 방법을 연구하는 것이 포함된다. 다음과 같은 측면을 고려되어야 한다:
- PC5가 UAV와 UAV 컨트롤러(UAV-C) 간의 C2 통신을 지원할 수 있는지 여부;
- 현재 PC5를 사용하는 솔루션(예: Proximity based Services (ProSe), Cellular Vehicle-to-Everything (C-V2X))과 관련하여 아키텍처 수정이 필요한지 여부와 그 내용:
- 여기에는 드론과 UAV 컨트롤러 (UAV-C)가 모두 5GS에 등록되어 있는 시나리오와 UAV 컨트롤러 (UAV-C)가 5GS에 등록되어 있지 않거나 Uu 기능이 없을 수 있는 시나리오를 모두 연구하는 것이 포함된다;
- 여기에는 PC5에 사용되는 무선 리소스가 Mobile Network Operator (MNO) (커버리지 운영 중)에 의해 설정되고, 스케줄되되는 시나리오와 PC5에 사용되는 무선 리소스가 "운영자가 관리하지 않는(non-operator-managed)" 시나리오를 모두 연구하는 것이 포함된다;
- 기존 PC5 기반 유니캐스트 통신이 재사용되거나 및/또는 확장되어 C2 통신을 전송할 수 있는지 여부 및 방법;
- UAV와 UAV 컨트롤러 간에 PC5를 통한 C2 통신은 어떻게 설정되는지;
- 커버리지 내(in-coverage) 및 커버리지 외(out of coverage) 시나리오 모두에서 UAV 컨트롤러와 PC5를 통해 직접 C2 통신을 설정하기 위해 UAV가 어떻게 인증(authorized)되며, 인증은 어떻게 취소되는지(how is authorization revoked);
- UAV가 UAV 컨트롤러를 발견해야 하는지, 아니면 그 반대인지, 그렇다면 어떻게 해야 하는지.
TR 23.700-58v1.0.0은 상기의 예시와 같은 이슈에 대해 다음과 같은 결론(conclusion)을 포함하고 있다.
PC5를 통해 C2 통신에 참여하는 UAV는 네트워크와 Uu 통신이 가능할 수도 있고 불가능할 수도 있다.
PC5를 통한 유니캐스트 모드 C2 통신만 지원된다.
PC5를 통한 C2 통신의 경우, UAV-C는 사전 페어링되거나(pre-paired) 동적으로 페어링될 수 있다.
PC5를 통한 C2 통신에는 두 가지 유형의 인증(authorization)이 지원된다:
- clause 5.1.3 of TS 23.304 V17.4.0과 유사한 UAV의 프로비저닝된 정책에 기반한 인증.
- UAV가 네트워크와 Uu 통신이 가능한 경우 인증 (AUTHORIZATION)에 정의된 C2 통신 인증 절차에 기반한 인증.
clause 6.4.3 of TS 23.304 V17.4.0에 정의된 유니캐스트 모드 5G ProSe 직접 통신 절차는 다음과 같은 개선 및 조정(enhancements and adaptations)에 기초하여, PC5를 통한 C2 통신을 설정하기 위한 기준으로 사용된다:
- ProSe 서비스 정보가 "C2 통신 서비스"로 대체됨
- C2 통신 서비스 식별자는 미리-설정되거나 CAA-레벨의 UAV ID에서 파생될 수 있다.
UE 지향(UE-oriented) 및 서비스 지향(service-oriented) 유니캐스트 링크 수립은 TS 23.304 V17.4.0 의 6.4.3.1 절에 정의된 대로 모두 지원된다.
위 결론에 아래와 같은 추가적인 설명이 적용될 수 있다. 즉, UAV와 UAV-C 간에 PC5를 통해 C2 communication을 하기 위해 TS 23.256 V17.4.0에 정의된 Uu를 통한 C2 communication authorization procedure가 사용될 수 있다 (즉, USS/네트워크와 authorization을 수행하는 경우). 이 경우, PC5를 통해 C2 communication을 하기 전에 Uu를 통한 C2 communication authorization procedure를 수행해야 한다는 점이 명확해질 수 있다. 예를 들어, 이하의 추가적인 설명이 적용될 수 있다:
PC5를 통한 C2 통신에는 두 가지 유형의 인증이 지원된다:
- clause 5.1.3 of TS 23.304 V17.4.0와 유사한 UAV의 프로비저닝된 정책에 기초한 인증.
- UAV가 네트워크와 Uu 통신이 가능한 경우 TS 23.256 V17.4.0에 정의된 C2 통신 인증 절차에 기초한 인증. 이 경우 UAV UE는 PC5를 통해 UAV에서 UAV-C로의 직접 통신을 시작하기 전에 TS 23.256 V17.4.0에 정의된 절차에 따라 UAV UE는 C2 통신 인증을 수행한다.
TS 23.256 V17.4.0에 정의된 Uu를 통한 C2 communication authorization procedure가 실패할 수도 있다. 이 경우, UAV UE가 UAV-C와 PC5를 통해 C2 communication를 수행해도 되는지 여부가 명확하지 않다. 또한, 이 경우, UAV UE가 UAV-C와 PC5를 통해 C2 communication를 수행하면 안된다면, 이를(예: 인증 또는 C2 통신) 어떻게 처리할지가 명확하지 않다.
또한, Uu를 통한 C2 connection이 USS 또는 네트워크에 의해 revoke될 수도 있다. 이 경우 UAV UE가 UAV-C와 PC5를 통해 C2 communication을 수행되도 되는지 여부가 명확하지 않다. 또한, 이 경우, UAV UE가 UAV-C와 PC5를 통해 C2 communication를 수행하면 안된다면, 이를(예: 인증 또는 C2 통신) 어떻게 처리할지가 명확하지 않다.
따라서, 이러한 문제를 해결하기 위한 방안이 필요하다.
또한, Uu connection을 이용하여 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에게 제공하는 방안 또는 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에 설정하는 방안이 필요할 수 있다.
C2 communication 관련해서는 TS 23.256 V17.4.0에 정의되어 있는 다음의 내용을 참고할 수 있다.
C2 통신은 Command and Control (C2) Communication을 의미할 수 있다. C2 통신은 UAV 컨트롤러 또는 Uncrewed Aircraft Systems Traffic Management (UTM)에서 UAV로 UAV 동작을 위한 명령 및 제어 정보가 포함된 메시지를 전달하거나 UAV에서 UAV 컨트롤러 또는 UTM으로 텔레메트리 데이터(telemetry data)를 보고하기 위한 사용자 평면 링크를 의미할 수 있다.
Uu를 통한 C2 communication authorization 절차는 TS 23.256 V17.4.0의 5.2.5절 (Authorization for C2)을 참고할 수 있다. 그리고 Uu를 통한 C2 connection의 revoke 절차는 TS 23.256 V17.4.0의 5.2.9절 (Revocation of C2 Connectivity)을 참고할 수 있다.
본 명세서의 개시에서 제안하는 PC5 인터페이스를 이용하는 C2 communication을 지원하는 방안은, 다음의 다양한 예시 중 하나 이상의 동작/구성/단계의 조합으로 구성될 수 있다.
본 명세서에서 C2 communication, C2 connection, C2 connectivity, C2는 혼용하여 사용될 수 있다. 즉, C2 communication, C2 connection, C2 connectivity, C2는 모두 동일한 의미의 용어로 사용될 수 있다.
본 명세서에서 "C2 communication 수행"은 C2 connection 연결 수행으로 해석될 수도 있고, C2 connection 연결 수행을 포함하는 동작으로 해석될 수도 있다. PC5 interface를 통한 C2 connection 연결은 TS 23.287 V17.4.0, TS 23.304 V17.4.0의 Layer-2 link establishment, 즉 unicast link establishment 동작을 참고할 수 있다.
본 명세서에서 UE(User Equipment)와 단말은 동일한 의미의 용어로 사용될 수 있다.
본 명세서에서 PC5, PC5 interface, PC5 reference point, "PC5 기반"은 동일한 의미의 용어로 사용될 수 있다.
본 명세서에서 Uu, Uu interface, Uu reference point는 동일한 의미의 용어로 사용될 수 있다.
본 명세서에서 SMF는, EPS에서는 SMF+PGW-C를 의미할 수 있다.
이하에서는, 본 명세서의 개시에서 제안하는 내용을 설명하며, 종래 기술과 동일한 구성에 대해서는 설명을 생략할 수 있다. UAS 관련 동작 및 절차에 대해서는 기본적으로 TS 23.256 V17.4.0을 참고하기로 한다. 또한, PC5 관련 동작 및 절차에 대해서는 기본적으로 TS 23.287 V17.4.0, TS 24.587, TS 23.304 V17.4.0, TS 24.554 등을 참고하기로 한다.
본 명세서에서 설명하는 PC5 인터페이스를 이용하는 C2 communication을 지원하는 예시는 UAS services 뿐만 아니라 다른 services (예, ProSe services, V2X services 등)에도 확장/변형되어 적용될 수 있다. 이 경우, 본 명세서의 개시에 따른 C2 communication/C2 connection은 두 UE 간의 통신/연결로 치환하여 해석될 수 있다.
Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 실패한 경우 또는 C2 communication authorization (또는 USS/네트워크와의 authorization) revocation된 경우, 다음의 예시와 같은 동작이 수행될 수 있다. 예를 들어, SMF 또는 USS가 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에게 제공하거나 또는 UE에 설정할 수 있다. 또는 SMF 또는 USS가 Uu connection을 이용하여 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에게 제공하거나 또는 UE에 설정할 수 있다. USS가 이러한 동작을 수행하는 경우, USS가 제공한 정보 또는 설정이 SMF를 거쳐 UE에게 전달될 수 있다.
일례로, Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization) 실패한 경우 또는 C2 communication authorization (또는 USS/네트워크와의 authorization) revocation된 경우, 다음의 예시와 같은 동작이 수행될 수 있다. 예를 들어, 네트워크가 UE에게 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 지시 또는 설정할 수 있다. 또는 Uu connection을 이용하여 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에게 제공 또는 UE에 설정할 수 있다. 여기서, UE는 UAV인 것으로 가정할 수 있다. 다만, 이는 예시에 불과하며, UE는 UAV-C일 수도 있고, UE는 UAV와 UAV-C 모두일 수도 있다.
본 명세서에서 Uu connection을 이용하여 PC5를 통한 C2 communication을 수행할 수 있는지 여부를 UE에게 제공 또는 UE에 설정하는 동작은, PC5를 통한 C2 communication을 수행할 수 있는지 여부를 네트워크가 UE에게 제공 또는 UE에 설정하는 동작으로 해석될 수도 있다.
1. 본 명세서의 개시의 제1예
본 명세서의 개시의 제1예에서는 UE에 인증 정책/파라미터 (Authorization Policy/Parameter)를 설정을 하는 예시를 설명한다.
UE에 다음과 같은 Authorization Policy/Parameter 중 하나 이상이 설정될 수 있다. 이러한 Authorization Policy/Parameter는 조합적인 형태, 명시적인 형태, 암시적인 형태 등 다양한 형태로 설정될 수 있다.
(a) UE가 PC5 interface를 통해 C2 communication을 수행하기 위해서(또는, UE가 PC5 interface를 통해 C2 communication을 수행하기 전에), Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)을 수행/선행해야 한다는 정보 또는 이를 나타내는/지시하는 정보.
(b) Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 실패한 경우 (즉, 성공하지 못한 경우), PC5 interface를 통해 C2 communication을 수행하지 말라는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 실패한 경우 (즉, 성공하지 못한 경우), PC5 interface를 통한 C2 communication이 허용/authorize되지 않는 것으로 해석될 수 있다.
(c) Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 성공한 경우, PC5 interface를 통해 C2 communication을 수행할 수 있다는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 성공한 경우, PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있다.
(d) Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 실패했더라도 (즉, 성공하지 못했더라도), PC5 interface를 통해 C2 communication을 수행할 수 있다는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 실패한 경우라도 (즉, 성공하지 못한 경우라도), PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있다.
(e) Uu 기반 C2 connection이 revoke되면, PC5 interface를 통해 C2 communication을 수행하지 말라는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 revoke된 경우, PC5 interface를 통한 C2 communication이 허용/authorize되지 않는 것으로 해석될 수 있다.
(f) Uu 기반 C2 connection이 revoke되더라도, PC5 interface를 통해 C2 communication을 수행할 수 있다는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization)이 revoke된 경우라도, PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있다.
(g) Uu 기반 C2 connection (또는 Uu 기반 C2 communication에 사용되던 PDU (Packet Data Unit 또는 Protocol Data Unit) Session/ PDN (Packet Data Network) connection)이 해제되면, PC5 interface를 통해 C2 communication을 수행하지 말라는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication (또는 이를 위해 사용되던 PDU Session/PDN connection)이 해제된 경우, PC5 interface를 통한 C2 communication이 허용/authorize되지 않는 것으로 해석될 수 있다.
(h) Uu 기반 C2 connection (또는 Uu 기반 C2 communication에 사용되던 PDU Session/PDN connection)이 해제되더라도, PC5 interface를 통해 C2 communication을 수행할 수 있다는 정보, 또는 이를 나타내는/지시하는 정보. 이는 Uu를 통한 C2 communication (또는 이를 위해 사용되던 PDU Session/PDN connection)이 해제된 경우라도, PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있다.
참고로, 앞서 설명한 (a) 내지 (h)는, 본 명세서의 개시의 다양한 예시에서, 각각 (a) 정보 내지 (h) 정보로 지칭될 수도 있다.
앞서 설명한 예시들에서, Uu 기반 C2 communication에 사용되던 PDU Session/PDN connection의 해제하는 동작은 Uu 기반 C2 communication에 사용되던 QoS Flow/Bearer의 해제를 포함하는 것으로 해석될 수 있다.
상기의 Authorization Policy/Parameter 설정은 UICC에 설정되는 방식, ME에 설정되는 방식, PCF가 UE에 설정하는 방식, AF가 UE에 설정하는 방식 중 하나 이상의 방법에 의해 설정될 수 있다. 이러한 설정을 수행하는 동작에 대한 예시는 TS 23.287 V17.4.0의 5.1.1절 및 6.2절을 참고할 수 있다.
이하에서, 도 8a 및 도 8b의 예시를 참조하여, 본 명세서의 개시의 제1예의 제1예시를 설명한다.
이하의 실시예는 TS 23.256 V17.4.0의 5.2.5.2.1절 (C2 Authorization request during UUAA-SM procedure in 5GS)의 내용에 기초한 예시이며, 이하에서는 본 명세서의 개시에서 제안하는 내용 위주로 설명한다. 참고로, 상기한 TS 23.256 V17.4.0의 5.2.5.2.1절은 TS 23.256 V17.4.0의 5.2.3.2절 대비 추가되는 사항들에 대해 기술하고 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 8a 및 도 8b은 본 명세서의 개시의 제1예의 제1 예시에 따른 절차를 설명한다.
도 8a 및 도 8b의 예시는 PDU 세션 수립 절차가 수행되는 동안 UUAA가 수행되는 예시를 나타낸다.
TS 23.256 V17.4.0의 5.2.5.2.1절에 설명된 동작에 대한 설명은 생략한다.
Step 0. 상기 (a) 정보가 UE에 설정된 경우, UE는 Uu를 통한 C2 communication authorization을 수행하는 것을 결정할 수도 있다.
Step 7. 상기 (b), (c), (d) 정보 중 하나 이상의 정보 및 C2 authorization 결과 (성공 또는 실패)에 기초하여, UE는 PC5 interface를 통해 C2 communication을 수행할 지 여부를 결정할 수 있다. 예를 들어, 이하의 예시와 같은 동작이 수행될 수 있다:
- C2 authorization이 성공한 경우, UE는 PC5 interface를 통해 C2 communication을 수행할 수 있음을 결정할 수도 있다. 상기 (c) 정보가 설정되었거나 설정되지 않았더라도, UE가 이러한 결정을 수행할 수도 있다.
- C2 authorization이 실패한 경우, 상기 (b) 정보가 설정되었다면, UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수 있다. 상기 (b) 정보가 설정되어 있지 않더라도, 상기 (a) 정보가 설정되었다면, C2 authorization이 실패한 경우 UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수도 있다.
- C2 authorization이 실패한 경우, 상기 (d) 정보가 설정되었다면 UE는 PC5 interface를 통해 C2 communication을 수행할 수 있음을 결정할 수 있다.
UE는 상기 (b) 정보, (c) 정보, (d) 정보를 이용하는 대신에 UE의 구현에 따라, 위의 예시에 따른 결정을 수행할 수도 있다.
UE는 SM NAS message (예, PDU Session Establishment Accept, PDU Session Establishment Reject 등)를 SMF로부터 수신할 수 있다. 수신된 SM NAS message (예, PDU Session Establishment Accept, PDU Session Establishment Reject 등) 및/또는 이 메시지에 포함된 정보 (예, 5GSM cause value, Service-level-AA container에 포함된 정보 등) 에 기초하여, UE는 C2 authorization 결과를 알 수 있다. 5GSM cause value, Service-level-AA container 정보에 대한 구체적인 설명은 TS 24.501 V17.8.0을 참고할 수 있다. 예를 들어, C2 authorization이 실패 시, SM NAS message에 포함된 5GSM cause value로써, #29 "user authentication or authorization failed" 가 포함되거나 설정될 수 있다. 예를 들어, C2 authorization이 실패 시, Service-level-AA container에 포함되는 Service-level-AA response 정보로써, "C2 authorization was not successful or C2 authorization is revoked."가 포함되거나 설정될 수 있다.
Service-level-AA result field (SLAR) (octet 3, bits 1 and 2)
Bits
1 2
0 0 정보 없음(No information)
0 1 서비스 레벨 authentication 및 authorization이 성공적이었다.
1 0 서비스 레벨 authentication 및 authorization이 성공적이지 않거나, 서비스 레벨 authorization이 revoke되었다.
1 1 Reserved
C2 authorization result field (C2AR) (octet 3, bits 3 and 4)
Bits
3 4
0 0 정보 없음(No information)
0 1 C2 authorization이 성공적이었다.
1 0 C2 authorization 이 성공적이지 않거나, C2 authorization이 revoke되었다.
1 1 Reserved
Bits 5 to 8 of octet 3 are spare and shall be coded as zero.
표 3은 3GPP TS 24.501 V17.8.0의 Table 9.11.2.14.1에 정의된 Service-level-AA response information element의 예시이다.
이하에서, 도 9a 및 도 9b의 예시를 참조하여, 본 명세서의 개시의 제1예의 제2예시를 설명한다.
이하의 실시예는 TS 23.256 V17.4.0의 5.2.5.3.0절 (C2 Authorization request during UUAA-SM procedure in EPS)의 내용에 기초한 예시이며, 이하에서는 본 명세서의 개시에서 제안하는 내용 위주로 설명한다. 참고로, 상기한 TS 23.256 V17.4.0의 5.2.5.3.0절은 TS 23.256 V17.4.0의 5.2.3.3절 대비 추가되는 사항들에 대해 기술하고 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 9a 및 도 9b는 본 명세서의 개시의 제1예의 제2 예시에 따른 절차를 설명한다.
도 9a 및 도 9b의 예시는 EPS에서의 PDN 연결 수립 절차가 수행되는 동안 UUAA가 수행되는 예시를 나타낸다.
TS 23.256 V17.4.0의 5.2.5.3.0절에 설명된 동작에 대한 설명은 생략한다.
Step 0. 상기 (a) 정보가 UE에 설정되어 있는 경우, UE는 Uu를 통한 C2 communication authorization을 수행하는 것을 결정할 수도 있다.
Step 8 (또는 step 5 이후). 상기 (b), (c), (d) 정보 중 하나 이상의 정보 및 C2 authorization 결과 (성공 또는 실패)에 기초하여, UE는 PC5 interface를 통해 C2 communication을 수행할 지 여부를 결정할 수 있다. 예를 들어, 이하의 예시와 같은 동작이 수행될 수 있다:
- C2 authorization이 성공한 경우 UE는 PC5 interface를 통해 C2 communication을 수행할 수 있음을 결정할 수 있다. 이는 상기 (c) 정보가 설정되었거나 설정되지 않았더라도 이렇게 결정할 수도 있다.
- C2 authorization이 실패한 경우, 상기 (b) 정보가 설정되었다면 UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수 있다. 상기 (b) 정보가 설정되어 있지 않더라도, 상기 (a) 정보가 설정되었다면 C2 authorization이 실패한 경우 UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수도 있다.
- C2 authorization이 실패한 경우, 상기 (d) 정보가 설정되었다면 UE는 PC5 interface를 통해 C2 communication을 수행할 수 있음을 결정할 수 있다.
UE는 상기 (b), (c), (d) 정보를 이용하는 대신에, UE의 구현에 따라 위의 예시에 따른 결정을 수행할 수도 있다.
UE는 네트워크 (MME/SMF+PGW-C)로부터 SM 관련 NAS message (예, MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY REQUEST 등)를 수신할 수 있다. 수신된 SM 관련 NAS message (예, MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY REQUEST 등) 및/또는 NAS 메시지 안에 포함된 정보 (예, ESM cause value, Service-level-AA container에 포함된 정보 등) 에 기초하여, UE는 C2 authorization 결과를 알 수 있다. ESM cause value, Service-level-AA container 정보에 대한 구체적인 설명은 TS 24.301 V17.8.0을 참고할 수 있다. 예를 들어, C2 authorization이 실패 시, ESM cause value로써 #29 "user authentication or authorization failed" 가 포함되거나 설정될 수 있다. 예를 들어, C2 authorization이 실패 시, Service-level-AA container에 포함되는 Service-level-AA response 정보로써 "C2 authorization was not successful or C2 authorization is revoked."가 포함/설정될 수 있다.
도 8a 및 도 8b을 참조한 예시 및 도 9a 및 도 9b를 참조한 예시에서 UE가 PC5 interface를 통해 C2 communication을 수행할 것을 결정하면, UE는 PC5 interface를 이용하여 C2 connection을 맺는 동작을 수행할 수 있다. 또한, UE가 PC5 interface를 통해 C2 communication을 수행하지 않는 것을 결정한 경우, 만약 상대 UE로부터 (즉, UAV의 경우 UAV-C이고 UAV-C의 경우 UAV) PC5 interface를 이용하여 C2 connection을 수립하는 요청을 수신하면, UE는 이를 거절할 수도 있다. UE가 거절하는 경우, UE는 상대 UE에게 거절 메시지를 전송할 수 있다. 거절 메시지는 거절하는 이유 (예, Uu 기반 C2 communication authorization 실패, Uu 기반 C2 communication not-authorized, PC5 기반 C2 communication not-authorized 등)를 포함할 수도 있다.
이하에서, 도 10의 예시를 참조하여, 본 명세서의 개시의 제1예의 제3예시를 설명한다.
이하의 실시예는 TS 23.256 V17.4.0의 5.2.9.1절 (Revocation of C2 connectivity in 5GS)의 내용에 기초한 예시이며, 이하에서는 본 명세서의 개시에서 제안하는 내용 위주로 설명한다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 10은 본 명세서의 개시의 제1예의 제3 예시에 따른 절차를 설명한다.
도 10의 예시는 5GS에서의 C2 연결을 revocation하는 예시를 나타낸다.
Step 3 또는 Step 6. 상기 (e), (f), (g), (h) 정보 중 하나 이상의 정보 및 C2 connection revocation (또는 C2 connection에 사용되던 PDU Session의 해제 또는 C2 connection에 사용되던 QoS Flow의 해제)에 기초하여, UE는 PC5 interface를 통해 C2 communication을 수행할 지 여부를 결정할 수 있다. 예를 들어, 이하의 예시와 같은 동작이 수행될 수 있다:
- C2 connection revocation이 (또는 C2 connection에 사용되던 PDU Session/QoS Flow의 해제가) 발생한 경우, 상기 (e), (g) 중 하나 이상의 정보가 설정되었다면 UE는 PC5 interface를 통한 C2 communication을 수행할 수 없다고 결정할 수 있다. 상기 (e), (g) 정보가 설정되어 있지 않더라도 상기 (a) 정보가 설정되었다면, C2 connection revocation이 (또는 C2 connection에 사용되던 PDU Session/QoS Flow의 해제가) 발생한 경우, UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수도 있다.
- C2 connection revocation이 (또는 C2 connection에 사용되던 PDU Session/QoS Flow의 해제가) 발생한 경우, UE는 PC5 interface를 통한 C2 communication을 수행할 수 있다고 결정할 수 있다. 상기 (f), (h) 중 하나 이상의 정보가 설정되었거나 설정되지 않았더라도, UE는 이러한 결정을 할 수도 있다.
UE는 SMF로부터 SM NAS 메시지를 수신할 수 있다. 수신된 SM NAS message (예, PDU Session Release Command, PDU Session Modification Command 등) 및/또는 그 안에 포함된 정보 (예, 5GSM cause value, Service-level-AA container에 포함된 정보 등) 에 기초하여, UE는 C2 connection revocation을 (또는 C2 connection에 사용되던 PDU Session/QoS Flow의 해제를) 알 수 있다. 5GSM cause value, Service-level-AA container 정보에 대한 자세한 설명은TS 24.501 V17.8.0을 참고할 수 있다.
예를 들어, C2 connection revocation 시, 5GSM cause value로써, #29 "user authentication or authorization failed" 가 포함되거나 설정될 수 있다. 예를 들어, C2 connection revocation 시, Service-level-AA container에 포함되는 Service-level-AA response 정보로써, "C2 authorization was not successful or C2 authorization is revoked."가 포함되거나 설정될 수 있다.
이하에서, 도 11의 예시를 참조하여, 본 명세서의 개시의 제1예의 제4예시를 설명한다.
아래의 실시예는 TS 23.256 V17.4.0의 5.2.9.2절 (Revocation of C2 connectivity in EPS)의 내용에 기초한 예시이며, 이하에서는 본 명세서의 개시에서 제안하는 내용 위주로 설명한다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 11은 본 명세서의 개시의 제1예의 제4 예시에 따른 절차를 설명한다.
도 11의 예시는 EPS 에서 C2 연결을 revocation하는 예시를 나타낸다.
Step 2 또는 Step 4. 상기 (e), (f), (g), (h) 정보 중 하나 이상의 정보 및 C2 connection revocation (또는 C2 connection에 사용되던 PDN connection의 해제 또는 C2 connection에 사용되던 bearer의 해제)에 기초하여, UE는 PC5 interface를 통한 C2 communication을 수행할 지 여부를 결정할 수 있다.
- C2 connection revocation이 (또는 C2 connection에 사용되던 PDN connection/bearer의 해제가) 발생한 경우, 상기 (e), (g) 중 하나 이상의 정보가 설정되었다면 UE는 PC5 interface를 통해 C2 communication을 수행할 수 없음을 결정할 수 있다. 상기 (e), (g) 정보가 설정되어 있지 않더라도, 상기 (a) 정보가 설정되었다면, C2 connection revocation이 (또는 C2 connection에 사용되던 PDN connection/bearer의 해제가) 발생한 경우 UE는 PC5 interface를 통해 C2 communication을 수행할 수 없다고 결정할 수도 있다.
- C2 connection revocation이 (또는 C2 connection에 사용되던 PDN connection/bearer의 해제가) 발생한 경우 UE는 PC5 interface를 통해 C2 communication을 수행할 수 있다고 결정할 수 있다. 상기 (f), (h) 중 하나 이상의 정보가 설정되었거나 설정되지 않았더라도, UE는 이러한 결정을 수행할 수도 있다.
UE는 네트워크 (MME/SMF+PGW-C)로부터 SM 관련 NAS 메시지를 수신할 수 있다. 수신된 SM 관련 NAS message (예, MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST, BEARER MODIFY REQUEST 등) 및/또는 NAS 메시지 안에 포함된 정보 (예, ESM cause value, Service-level-AA container에 포함된 정보 등) 에 기초하여, UE는 C2 connection revocation을 (또는 C2 connection에 사용되던 PDN connection/bearer의 해제를) 알 수 있다. ESM cause value, Service-level-AA container 정보에 대한 구체적인 설명은, TS 24.301 V17.8.0을 참고할 수 있다. 예를 들어, C2 connection revocation 시, ESM cause value로써 #29 "user authentication or authorization failed" 가 포함되거나 설정될 수 있다. 예를 들어, C2 connection revocation 시, Service-level-AA container에 포함되는 Service-level-AA response 정보로써 "C2 authorization was not successful or C2 authorization is revoked."가 포함되거나 설정될 수 있다.
도 10에 따른 예시와 도 11에 따른 예시에서, PC5 interface를 통해 C2 communication을 수행하고 있었던 UE가, PC5 interface를 통해 C2 communicaiton을 수행하지 않기로 결정할 수 있다. UE가 이러한 결정을 하면, UE는 PC5 interface를 통한 C2 connection을 해제하는 동작을 수행할 수 있다. 상기 해제 동작 시 사용되는 PC5 메시지는 해제하는 이유 (예, Uu 기반 C2 communication revoked, Uu 기반 C2 communication not-authorized, PC5 기반 C2 communication not-authorized 등)를 포함할 수도 있다. PC5 interface를 통한 C2 connection을 해제하는 동작에 대한 자세한 설명은 TS 23.287 V17.4.0, TS 23.304 V17.4.0에 정의된 L2 link release 절차를 참고할 수 있다.
2. 본 명세서의 개시의 제2예
Uu를 통한 또는 Uu connection을 이용한 C2 communication authorization 절차 수행 과정에서 UE에게 알리는 방법을 설명한다.
예를 들어, Uu를 통한 또는 Uu connection을 이용한 C2 communication authorization 절차 수행 과정에서, 네트워크가 UE에게 PC5를 통한 C2 통신을 수행할 수 있는지 여부를 알리는 예시를 설명한다.
Uu를 통한 C2 communication authorization이 실패한 경우 (즉, 성공하지 못한 경우), 또는 Uu 기반 C2 connection이 revoke된 경우, 또는 Uu 기반 C2 communication에 사용되던 PDU Session/QoS Flow가 해제된 경우, 또는 Uu 기반 C2 communication에 사용되던 PDN connection/bearer가 해제된 경우, 또는 PC5를 통한 C2 communication authorization이 실패한 경우, (즉, 성공하지 못한 경우) 또는 PC5 기반 C2 connection이 revoke된 경우, 다음의 예시와 같은 동작이 수행될 수 있다. 예를 들어, 네트워크는 PC5를 통한 C2 communication을 수행하지 말 것 (또는 PC5를 통한 C2 communication이 허용되지 않음 또는 PC5를 통한 C2 communication이 authorize되지 않음)을 나타내는 정보를 UE에게 제공할 수 있다.
상기의 예시와 반대의 경우, 예를 들어, Uu를 통한 C2 communication authorization이 성공한 경우 또는 PC5를 통한 C2 communication authorization이 성공한 경우, 다음의 예시와 같은 동작이 수행될 수 있다. 네트워크는 PC5를 통한 C2 communication을 수행할 것 (또는 PC5를 통한 C2 communication이 허용됨 또는 PC5를 통한 C2 communication이 authorize됨)을 나타내는 정보를 UE에게 제공할 수 있다.
도 12를 참조하여, PC5 unicast link를 수립하는 예시를 설명한다. 본 명세서의 개시의 제2예에서 PC5 unicast link의 수립 또는 형성에 관련된 설명에 대해, 도 12의 예시가 참조될 수 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 12는 본 명세서의 개시의 일 실시예에 따라, PC5 레퍼런스 포인트를 통해 layer-2 link 를 수립하는 절차를 나타낸다.
PC5 reference point 통한 유니캐스트 모드 V2X 통신의 예시를 설명한다.
도 12를 참조하여, PC5 레퍼런스 포인트를 통한 Layer-2 link 수립의 예시를 설명한다.
PC5 레퍼런스 포인트를 통해 유니캐스트 모드의 V2X 통신을 수행하기 위해, 관련된 정보가 UE에 설정될 수 있다.
도 12는 PC5 레퍼런스 포인트를 통한 V2X 통신의 유니캐스트 모드에 대한 레이어 2 링크 설정 절차를 보여준다.
1.The UE(s) determine the destination Layer-2 ID for signalling reception for PC5 unicast link establishment. The destination Layer-2 ID is configured with the UE(s).
1. UE(s)는 PC5 유니캐스트 링크 수립을 위한 신호 수신을 위한 destination 레이어-2 ID를 결정한다. destination 레이어-2 ID는 UE(들)에 의해 구성된다.
2. UE-1 의 V2X 응용 계층(application layer)은 PC5 유니캐스트 통신을 위한 어플리케이션 정보를 제공한다. 어플리케이션 정보에는 V2X 서비스 유형과 개시하는 UE의 어플리케이션 레이어 ID가 포함된다. 타겟 UE의 응용 계층 ID는 응용 정보에 포함될 수 있다.
UE-1의 V2X 어플리케이션 계층은 이 유니캐스트 통신을 위한 V2X 어플리케이션 요구 사항을 제공할 수 있다. UE-1은 PC5 QoS 파라미터와 PC5 QoS Flow ID (PFI)를 결정한다.
UE-1이 기존 PC5 유니캐스트 링크를 재사용하기로 결정하면 UE는 레이어 2 링크 수정 절차를 트리거할 수 있다.
3. UE-1 이 직접 통신 요청 메시지를 전송하여 유니캐스트 레이어 2 링크 수립 절차를 시작한다. 직접 통신 요청 메시지는 다음의 정보를 포함할 수 있다:
- Source User Info: initiating UE의 애플리케이션 레이어 ID(즉, UE-1의 애플리케이션 레이어 ID).
- V2X 애플리케이션 계층이 step 2에서 대상 UE의 애플리케이션 레이어 ID를 제공한 경우 다음 정보가 포함된다:
- Target User Info: 타겟 UE의 애플리케이션 레이어 ID(즉, UE-2의 애플리케이션 레이어 ID).
- V2X Service Info: 레이어 2 링크 수립을 요청하는 V2X 서비스 유형에 대한 정보.
- Security Information: 보안의 수립을 위한 정보.
직접 통신 요청 메시지를 보내는 데 사용되는 소스 레이어 2 ID와 destination 레이어 2 ID가 결정된다. destination 레이어-2 ID는 브로드캐스트 또는 유니캐스트 Layer -2 ID일 수 있다. 유니캐스트 레이어 2 ID를 사용하는 경우 직접 통신 요청 메시지에 타겟 사용자 정보(Target User Info)가 포함되어야 한다.
UE-1은 소스 레이어-2 ID와 destination 레이어-2 ID를 사용하여 PC5 브로드캐스트 또는 유니캐스트를 통해 직접 통신 요청 메시지를 전송한다.
직접 통신 요청 메시지의 전송 밋 수신을 위해, 예를 들어 NR Tx 프로파일에 기초하여, PC5 DRX 동작이 필요한 경우 기본 PC5 DRX 설정이 사용된다.
4. UE-1의 보안은 아래와 같이 수립된다:
4a. Targe User info가 직접 통신 요청 메시지에 포함된 경우 타겟 UE, 즉 UE-2는 UE-1과 보안을 수립함으로써 응답한다.
4b. Targe User info가 직접 통신 요청 메시지에 포함되지 않을 수 있다. 이 경우, 발표된(announced) V2X 서비스 유형을 UE-1과의 PC5 유니캐스트 링크를 통해 사용하고자 하는 UE는 UE-1과 보안을 수립하여 응답한다.
보안 보호가 활성화되면 UE-1은 다음 정보를 타겟 UE에게 전송한다:
- IP 통신이 사용되면, 다음의 정보가 전송될 수 있다:
- IP Address Configuration: IP 통신의 경우 이 링크에 IP 주소 설정이 필요하며. 다음 값 중 하나를 나타낸다:
- "IPv6 Router". IPv6 주소 할당 메커니즘이 initiating UE에 의해 지원되는 경우(즉, IPv6 라우터 역할을 하는 경우). ; 또는
- "IPv6 address allocation not supported". IPv6 주소 할당 메커니즘이 initiating UE에서 지원되지 않는 경우.
- Link Local IPv6 Address: UE-1이 IPv6 IP 주소 할당 메커니즘을 지원하지 않는 경우, 즉 IP 주소 설정에 "IPv6 주소 할당이 지원되지 않음"이 표시된 경우, 로컬로 형성된 링크-로컬 IPv6 주소이다.
- QoS Info: 추가될 PC5 QoS 플로우에 대한 정보. 각 PC5 QoS 플로우에 대해 PFI, 해당 PC5 QoS 파라미터(즉, PQI 및 조건부 기타 파라미터(예: MFBR/GFBR 등)) 및 관련 V2X 서비스 유형.
보안 수립 절차에 사용되는 소스 레이어 2 ID가 결정된다. Destination 레이어 2 ID는 수신된 직접 통신 요청 메시지의 소스 레이어 2 ID로 설정된다.
보안 수립 절차에 관련된 메시지를 수신하면, UE-1은 이 유니캐스트 링크의 신호 및 데이터 트래픽을 위한 향후 통신을 위해 피어 UE의 레이어 2 ID를 획득한다.
5. 직접 통신 수락 메시지는 UE-1과 보안을 성공적으로 수립한 타겟 UE에 의해 UE-1로 전송된다:
5a. (UE 지향(oriented) layer-2 링크 수립) 타겟 사용자 정보가 직접 통신 요청 메시지에 포함되어 있는 경우, 타겟 UE, 즉 UE-2의 응용 계층 ID가 일치하는 경우 UE-2는 직접 통신 수락 메시지로 응답한다.
5b. (V2X 서비스 지향 레이어 2 링크 수립) 타겟 사용자 정보가 직접 통신 요청 메시지에 포함되지 않은 경우, 발표된(announced) V2X 서비스를 사용하고자 하는 UE는 직접 통신 수락 메시지를 전송하여 요청에 응답한다(그림 12의 UE-2 및 UE-4).
직접 통신 수락 메시지는 다음을 포함한다:
- Source User Info: 직접 통신 수락 메시지를 전송하는 UE의 애플리케이션 레이어 ID.
- QoS Info: UE-1 이 요청한 PC5 QoS Flow 에 대한 정보. 각 PC5 QoS Flow에 대해 PFI, 해당 PC5 QoS 파라미터(즉, PQI 및 조건부 기타 파라미터(예: MFBR/GFBR 등)) 및 관련 V2X 서비스 유형 정보를 포함함.
- IP communication 이 사용된 경우, 다음의 정보를 포함한다:
- IP Address Configuration: IP 통신의 경우 이 링크에 IP 주소 설정이 필요하며. 다음 값 중 하나를 나타낸다:
- "IPv6 Router". IPv6 주소 할당 메커니즘이 initiating UE에 의해 지원되는 경우(즉, IPv6 라우터 역할을 하는 경우). ; 또는
- "IPv6 address allocation not supported" IPv6 주소 할당 메커니즘이 타겟 UE에서 지원되지 않는 경우.
- Link Local IPv6 Address: 타겟 UE 가 IPv6 IP 주소 할당 메커니즘을 지원하지 않는 경우, 즉 IP 주소 설정에 "IPv6 주소 할당 지원되지 않음"이 표시되고, UE-1 이 직접 통신 요청 메시지에 링크-로컬 IPv6 주소를 포함시킨 경우, 로컬로 형성된 링크-로컬 IPv6 주소. 타겟 UE는 충돌하지 않는 링크-로컬 IPv6 주소를 포함해야 한다.
두 UE(즉, initiating UE와 타겟 UE)가 모두 링크-로컬 IPv6 주소를 사용하도록 선택한 경우, 중복 주소 감지(duplicate address detection)를 비활성화해야 한다.
initiating UE 또는 타겟 UE가 IPv6 라우터를 지원한다고 표시하는 경우, 해당 주소 설정 절차는 레이어 2 링크 설정 후에 수행되며 링크-로컬 IPv6 주소는 무시될 수 있다.
PC5 유니캐스트 링크를 설정한 UE의 V2X 계층은 유니캐스트 링크에 할당된 PC5 링크 식별자 및 PC5 유니캐스트 링크 관련 정보를 AS 계층으로 전달한다. PC5 유니캐스트 링크 관련 정보는 레이어-2 ID 정보(예: 소스 레이어-2 ID 및 destination 레이어-2 ID) 및 해당 PC5 QoS 파라미터를 포함한다. 이를 통해 AS 계층은 PC5 유니캐스트 링크 관련 정보와 함께 PC5 링크 식별자를 유지할 수 있다.
6. V2X 서비스 데이터는 아래와 같이 수립된 유니캐스트 링크를 통해 전송된다:
PC5 링크 식별자 및 PFI는 V2X 서비스 데이터와 함께 AS 계층에 제공된다.
선택적으로 레이어 2 ID 정보(예, 소스 레이어 2 ID 및 destination 레이어 2 ID)가 AS 계층에 추가로 제공된다.
UE 구현에 따라, 레이어 2 ID 정보가 AS 계층에 제공될 수도 있다.
UE-1은 소스 레이어-2 ID(즉, 이 유니캐스트 링크에 대한 UE-1의 레이어-2 ID)와 destination 레이어-2 ID(즉, 이 유니캐스트 링크에 대한 피어 UE의 레이어-2 ID)를 사용하여 V2X 서비스 데이터를 전송한다.
PC5 유니캐스트 링크는 양방향이므로 UE-1의 피어 UE는 UE-1과의 유니캐스트 링크를 통해 V2X 서비스 데이터를 UE-1로 전송할 수 있다.
이하에서, 도 8a 및 도 8b을 참조하여, 본 명세서의 개시의 제2예의 제1예시를 설명한다. 참고로, 앞서 도 8a 및 도 8b은 본 명세서의 개시의 제1예의 제1예시를 설명하기 위해 참조했지만, 이하에서는 도 8a 및 도 8b에 기초하여, 본 명세서의 개시의 제2예의 제1예시에서 제안하는 내용을 설명하기로 한다.
UUAA(USS UAV Authorization/Authentication)는 PDU 세션 설정 중에 SMF에 의해 트리거될 수 있다. UUAA는 UDM에서 획득한 SM 가입 데이터와 PDU 세션 설정 요청 또는 PDN connection 설정 요청에서 UE가 제공한 서비스 수준 장치 ID를 기반으로 트리거될 수도 있다.
Step 0. 도 5의 예시의 step 1 내지 5가 수행될 수 있다.
UAV는 PDU 세션 수립 요청 메시지에, 다음의 예시와 같은 정보를 포함시킬 수 있다. 예를 들어, UAV는 서비스 레벨 장치 식별자(예: UVA의 CAA-레벨 UAV ID)을 포함하며, PDU 세션 설정 요청에 인증 서버 주소(Authentication Server Address) (예: USS 주소) 및 선택적으로 인증 데이터(예: UUAA 항공 페이로드)를 PDU 세션 수립 요청 메시지에 포함시킬 수 있다.
Step 1. SMF는 인증 관련 메시지를 UAS NF/NEF에게 전송할 수 있다. 예를 들어, SMF는 인증 관련 메시지를 UAS NF/NEF를 거쳐 USS에게 전송할 수 있다. 예를 들어, SMF는 Nnef_Authentication_AuthenticateAuthorize 서비스 오퍼레이션을 호출할 수 있다. 이 서비스 오퍼레이션은 서비스 레벨 장치 ID(UAV의 CAA 레벨 UAV ID를 포함), DNN, S-NSSAI가 포함할 수 있으며, 인증 서버 주소(즉, USS 주소) 및 UUAA aviation 페이로드(UE에서 제공한 경우), GPSI, 선택적으로 UAV 위치, 가능한 경우 PEI 및 가능한 경우 UE IP 주소가 포함될 수 있다. UAV 위치는 AMF에서 제공하는 사용자 위치 정보(예: 셀 ID)이다. UAS NF/NEF는 서비스 수준 장치 ID(예: UAV의 CAA-레벨 UAV ID) 또는 인증 서버 주소(예: USS 주소)를 기반으로 USS를 선택합니다.
Step 2. UAS NF/NEF가 USS에게 인증 관련 메시지를 전송할 수 있다. 예를 들어, UAS NF/NEF는 SMF로부터 받은 인증 요청 정보를 USS로 전달하기 위해 Naf_Authentication_AuthenticateAuthorize 서비스 운영을 호출할 수 있다. 예를 들어, UAS NF 는 step 1의 Nnef_Authentication_AuthenticateAuthorize 요청에서 UAV 위치의 일부로 수신된 Cell ID 를 해당 지리적 영역으로 변환할 수 있다. 그리고/또는 UAS NF는 위치 서비스 프로시저를 사용하여 UE 위치 정보를 추가로 획득하고 이를 USS로 향하는 Naf_Ahentication_AuthenticateAuthorize 메시지에 포함시켜 geo-caging 기능을 지원할 수 있다.
Step 3. [조건부 동작] USS에서 사용하는 인증 방법에 따라 필요한 여러 개의 round-trip 메시지가 전송되거나 수신될 수 있다. USS의 응답 메시지(예: Naf_Authentication_AuthenticateAuthorize 응답 메시지)는 GPSI를 포함하고, 사용된 인증 방법에 따른 인증 메시지가 NAS SM 전송 메시지를 통해 UE 에게 투명하게 전달된다. Step 3의 인증 메시지는 이전에 UE가 제공하지 않은 경우 USS 에 의해 요구되는 UUAA aviation 페이로드를 포함할 수 있다.
Step 4. USS는 UAS NF/NEF에게 인증 응답 메시지(예: Naf_Authentication_AuthenticateAuthorize response)를 전송할 수 있다. 인증 응답 메시지는 승인/인증(Authentication/Authorization)의 결과를 포함할 수 있다. 승인/인증 결과는 UAS NF를 위한 UUAA 결과 및 UUAA 실패시 재-인증 또는 재-승인을 위해 네트워크 자원에 관련된 UAS 서비스가 릴리즈될 수 있는지에 대한 정보를 포함할 수 있다. 선택적으로, 승인/인증 결과는 인증된 CAA-레벨 UAV ID, 요청된 정책 정보 및 UUAA 인증 페이로드를 포함하는 서비스 레벨 장치 ID를 포함할 수 있다. USS에서 요청한 정책 정보에는 DN 권한 부여 프로필 인덱스 및/또는 DN 권한 부여 세션 AMBR이 포함될 수 있다. USS는 새로운 CAA-레벨 UAV ID를 승인된 CAA-레벨 UAV ID로 포함할 수 있다.
Step 5. SMF는 UAS NF/NEF로부터 인증 응답 메시지를 수신할 수 있다. 예를 들어, SMF는 UAS NF/NEF로부터 C2 authorization이 실패 또는 성공했다는 정보/결과를 포함하는 응답 메시지를 수신할 수 있다. 본 실시예에서 C2 authorization은 Uu를 통한 C2 communication에 대한 authorization 및/또는 PC5를 통한 C2 communication에 대한 authorization일 수 있다. 인증 응답 메시지는 USS가 UAS NF/NEF를 거쳐 SMF에게 전송한 메시지일 수 있다.
Step 6. 인증/승인에 성공하면 USS는 PDU 세션 상태 이벤트에 가입한다. 예를 들어, Figure 4.15.3.2.3-1 of TS　23.502　V17.6.0의 Steps 1 내지 5에 따른 동작이 수행될 수 있다. Step 6은 step 4과 병렬적으로 수행될 수도 있다. UAS NF/NEF는 PDU 세션 상태 이벤트 알림을 구독할 DNN, S-NSSAI를 결정한다.
Step 7. SMF는 SM NAS message를 UE에게 전송할 수 있다. 예를 들어, SMF가 SM NAS message (예, PDU Session Establishment Accept, PDU Session Establishment Reject, PDU Session Modification Command 등)를 UE에게 전송할 때, SMF는 SM NAS 메시지에 다음의 예시와 같은 정보를 포함시킬 수 있다.
i) C2 authorization 실패 시 (즉, SMF가 UAS NF/NEF로부터 C2 authorization이 실패했다는 정보/결과를 포함하는 응답 메시지를 수신한 경우), SMF는 PC5 interface를 통해 C2 communication을 수행하지 말 것, 또는 이를 나타내는/지시하는 정보를 SM NAS 메시지에 포함시킬 수 있다. 이는 PC5 interface를 통한 C2 communication이 허용/authorize되지 않는 것으로 해석될 수 있다.
ii) SMF는 C2 authorization 성공 시 (즉, UAS NF/NEF로부터 C2 authorization이 성공했다는 정보/결과를 포함하는 응답 메시지를 수신한 경우), 상기 i)의 경우의 반대인 정보 (예, PC5 interface를 통해 C2 communication을 수행할 수 있음을 나타내는 정보. 이 정보는 PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있음)를 SM NAS message에 포함시킬 수도 있다. SMF는 UAV-C 관련 정보 (예, UAV-C의 Application Layer ID (이는 User Info 또는 Pilot Info로 해석 가능), Layer-2 ID 등)를 UE에게 제공할 수도 있다. 예를 들어, SMF는 UAV-C 관련 정보 (예, UAV-C의 Application Layer ID (이는 User Info 또는 Pilot Info로 해석 가능), Layer-2 ID 등)를 포함하는 SM NAS 메시지를 AMF를 거쳐 UE에게 전송할 수 있다. SMF는 UAV-C에 관련된 정보를 USS, UAS NF/NEF, UDM, UDR, PCF, UAV-C, Application Server/Function 중 하나 이상의 entity로부터 제공받거나 획득할 수도 있다. 또는, UAV-C에 관련된 정보가 SMF에 설정되어 있을 수도 있다. UAV-C에 관련된 정보 모두를 하나의 entity로부터 제공받거나 획득할 수도 있고, 다수의 entity로부터 제공받거나 획득할 수도 있다. 예를 들어, SMF는 UAV-C에 관련된 정보(예, UAV-C의 Application Layer ID)를 USS로부터 수신할 수 있고, SMF는 UAV-C에 관련된 정보(예, UAV-C의 Application Layer ID)를 UE(예, UAV)에게 전송할 수 있다. UAV는 상기 제공받은 UAV-C에 관련된 정보를 UAV-C와 C2 communcation을 위한 PC5 unicast link 형성 시 사용할 수 있다 (또는, UAV는 상기 제공받은 UAV-C 관련 정보를 사용하여 UAV-C와 C2 communcation을 위한 PC5 unicast link 형성할 수 있다). 예를 들어, UE(예, UAV)는 도 12의 예시에 기초하여, UAV-C와 C2 communcation을 위한 PC5 unicast link를 수립하기 위한 절차를 수행할 수 있다. 예를 들어, 도 12의 Step 3에서, UE(예, UAV)는 Target User Info를 UAV-C의 Application Layer ID로 설정할 수 있다. SMF가 상기 UAV-C에 관련된 정보를 포함하는 이유는 UE가 이러한 정보를 요청했기 때문일 수 있다 (step 1에서). 상기 UAV-C에 관련된 정보는 TPAE(Third Party Authorized Entity) 관련 정보일 수도 있다. 이 경우, TPAE는 PC5 capable한 UE 또는 V2X capable UE 또는 ProSe enabled UE인 것으로 간주될 수 있다.
UAV가 UAV-C 또는 Third Party Authorized Entity(TPAE)와 C2 communication을 위해 PC5 unicast link를 수립할 수 있다. 이 경우, UAV는 네트워크로부터 제공받은 Application Layer ID가 있다면, Application Layer ID를 Target User Info로 설정할 수 있다. 또한, 네트워크로부터 제공받은 Layer-2 ID가 있다면, UAV는 Layer-2 ID를 Destination Layer-2 ID로 설정하고, 이를 PC5 unicast link를 수립하기 위해 사용할 수 있다 (즉, UAV가 Direct Communication Request 메시지를 전송하기 위해 Destination Layer-2 ID를 사용함). 만약 네트워크로부터 UAV의 Layer-2 ID도 제공받았다면, UAV는 UAV의 Layer-2 ID를 Source Layer-2 ID로 설정하고, Source Layer-2 ID를 PC5 unicast link를 형성하기 위해 사용할 수 있다 (즉, UAV가 Direct Communication Request 메시지를 전송하기 위해 Source Layer-2 ID를 사용). UAV가 UAV의 Layer-2 ID를 네트워크로부터 제공받는 동작은, UAV가 네트워크로부터 상기 UAV-C 관련 정보를 제공받는 동작과 유사한 방식으로 수행될 수 있다. 이러한 PC5 unicast link 형성에 대한 내용은 본 명세서 전반에 걸쳐 적용될 수 있다.
UAV-C 관련 정보 또는 TPAE 관련 정보는 UAV의 식별 정보 (예, CAA-Level UAV ID (또는 Service Level Device Identity of the UAV), GPSI, PEI, IP 주소 정보 중 하나 이상의 식별 정보)에 기초하여 유추/결정될 수도 있다. 이는 본 명세서 전반에 걸쳐 적용될 수 있다.
UAV-C 관련 정보와 TPAE 관련 정보 중에서, application layer 관련 정보 (예, Application Layer ID)는 direct C2 pairing information 또는 C2 pairing information으로 간주될 수도 있다. 예를 들어, application layer 관련 정보 (예, Application Layer ID)는 direct C2 pairing information 또는 C2 pairing information로써 UE에게 제공될 수도 있다. 이는 본 명세서 전반에 걸쳐 적용될 수 있다.
예를 들어, 도 8a 및 도 8b의 예시의 step 0에서, 다음의 예시와 같은 설명이 적용될 수 있다. UAV가 UAV-C에 연결하는 데 필요한 직접 PC5 링크를 수립해야 할 수 있다(즉, 직접 C2 통신). 이 경우, UAV가 전송한 C2 Aviation 페이로드는 직접 C2 통신에 대한 인증이기도 하다는 것을 나타내는 표시를 포함할 수 있다. 또한 UAV는 C2 Aviation 페이로드에 직접 C2 페어링 정보(direct C2 pairing information)(사용 가능한 경우)를 포함할 수 있다.
예를 들어, 도 8a 및 도 8b의 예시의 step 4에서, 다음의 예시와 같은 설명이 적용될 수 있다. 직접 C2 통신에 대한 인증 (authorization) 요청이 step 0에 포함되었고, C2 인증 (authorization)이 성공한 경우, USS 는 C2 인증 (authorization) 페이로드에 UAV-C 의 어플리케이션 레이어 ID 가 포함된 직접 C2 페어링 정보를 포함할 수 있다. UAV-C의 어플리케이션 레이어 ID를 포함하는 C2 인증 (authorization) 페이로드는 Naf_Ahentication_AuthenticateAuthorize 응답에 포함되고 이는 UE 에게 추가로 전달될 수 있다.
예를 들어, 이하의 도 13의 예시의 step 1에서, 다음의 예시와 같은 설명이 적용될 수 있다. UAV가 UAV-C에 연결하는 데 필요한 직접 PC5 링크를 수립해야 할 수 있다(즉, 직접 C2 통신). 이 경우, UAV가 전송한 C2 Aviation 페이로드는 직접 C2 통신에 대한 인증 (authorization)이기도 하다는 것을 나타내는 표시를 포함할 수 있다. 또한 UAV는 C2 Aviation 페이로드에 직접 C2 페어링 정보(direct C2 pairing information)(사용 가능한 경우)를 포함할 수 있다.
예를 들어, 이하의 도 13의 예시의 step 4에서, 다음의 예시와 같은 설명이 적용될 수 있다. 직접 C2 통신에 대한 인증 (authorization) 요청이 step 0에 포함되었고, C2 인증 (authorization)이 성공한 경우, USS 는 C2 인증 (authorization) 페이로드에 UAV-C 의 어플리케이션 레이어 ID 가 포함된 직접 C2 페어링 정보를 포함할 수 있다. UAV-C의 어플리케이션 레이어 ID를 포함하는 C2 인증 (authorization) 페이로드는 Naf_Ahentication_AuthenticateAuthorize 응답에 포함되고 이는 UE 에게 추가로 전달될 수 있다.
상기 UAV-C 관련 정보 또는 TPAE 관련 정보가 제공될 수 있다. 이 경우, 이러한 정보는 다음의 예시와 같이 해석될 수 있다. 예를 들어, 이러한 정보는 상기 UAV-C 또는 TPAE가 UAV를 control하는 것이 authorize됨, UAV와 C2 communication을 수행하는 것이 authorize됨, UAV와 PC5를 통해 C2 communication을 수행하는 것이 authorize됨, UAV와 pair됨, UAV와의 pair가 authorize됨 등으로 해석될 수 있다. 이는 본 명세서 전반에 걸쳐 적용될 수 있다.
UAV는 가장 최근에 설정되거나 네트워크로부터 제공받은 C2 connection 상대 (예, UAV-C 또는 TPAE일 수 있음)와 PC5를 통한 C2 connection을 형성할 수 있다. 이는 본 명세서 전반에 걸쳐 적용될 수 있다.
SMF는 아래의 예시와 같은 이유로 인해, SM NAS 메시지에 앞서 설명한 i) 또는 ii)에 관련된 정보를 포함시킬 수 있다. 예를 들어, step 0에서, UE가 PC5 기반 C2 communication에 대한 authorization 정보를 요청했기 때문에, SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 예를 들어, AMF가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 1에서), SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 가입자 정보 (예, Uu 기반 C2 communication authorization 수행 시 UE에게 PC5 기반 C2 communication에 대한 authorization 정보를 제공해야 함, UE가 PC5 기반 C2 communication을 수행할 수 있음 등의 정보)에 기초하여, SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. USS가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 4에서), SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. UAS NF/NEF가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 5에서), SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. SMF의 local policy/operator policy/local configuration에 기초하여, SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 이러한 예시와 같은 다양한 정보 중 하나 이상에 기초하여, SMF가 상기 정보를 SM NAS 메시지에 포함할 수 있다.
UE는 SMF로부터 SMF NAS 메시지를 수신할 수 있다. SM NAS 메시지는 i)에 기초한 정보 또는 ii)에 기초한 정보를 포함할 수 있다. UE는 SMF로부터 수신한 SM NAS message 및/또는 상기 i) 정보 또는 ii) 정보에 기초하여 PC5 interface를 통해 C2 communication을 수행할 수 있는 지 여부를 결정할 수 있다.
이하에서, 도 9a 및 도 9b를 참조하여, 본 명세서의 개시의 제2예의 제2예시를 설명한다. 참고로, 앞서 도 9a 및 도 9b는 본 명세서의 개시의 제1예의 제2예시를 설명하기 위해 참조했지만, 이하에서는 도 9a 및 도 9b에 기초하여, 본 명세서의 개시의 제2예의 제2예시에서 제안하는 내용을 설명하기로 한다.
Step 5. SMF+PGW-C는 UAS NF/NEF로부터 C2 authorization이 실패 또는 성공했다는 정보/결과를 포함하는 응답 메시지를 수신한다. 본 실시예에서 C2 authorization은 Uu를 통한 C2 communication에 대한 authorization 및/또는 PC5를 통한 C2 communication에 대한 authorization일 수 있다.
Step 8 (또는 step 5 이후). SMF+PGW-C는 MME를 통해 SM 관련 NAS 메시지를 UE에게 전송할 수 있다. SMF+PGW-C는 SM 관련 NAS message (예, MODIFY EPS BEARER CONTEXT REQUEST, DEACTIVATE EPS BEARER CONTEXT REQUEST 등)에 다음의 정보를 포함시킬 수 있다.
I) C2 authorization 실패 시 (즉, UAS NF/NEF로부터 C2 authorization이 실패했다는 정보/결과를 포함하는 응답 메시지를 수신한 경우), SMF+PGW-C는 PC5 interface를 통해 C2 communication을 수행하지 말라는 정보, 또는 이를 나타내는/지시하는 정보를 SM 관련 NAS message에 포함시킬 수 있다. 이는 PC5 interface를 통한 C2 communication이 허용/authorize되지 않는 것으로 해석될 수 있다.
II) SMF+PGW-C는 C2 authorization 성공 시 (즉, UAS NF/NEF로부터 C2 authorization이 성공했다는 정보/결과를 포함하는 응답 메시지를 수신한 경우), 상기 I)의 경우와 반대인 정보 (예, PC5 interface를 통해 C2 communication을 수행할 수 있음을 나타내는 정보. 이 정보는 PC5 interface를 통한 C2 communication이 허용/authorize되는 것으로 해석될 수 있음)를 SM 관련 NAS message에 포함시킬 수도 있다. 이 경우 SMF+PGW-C는 UAV-C 관련 정보 (예, UAV-C의 Application Layer ID (이는 User Info 또는 Pilot Info로 해석 가능), Layer-2 ID 등)를 UE에게 제공할 수도 있다. 예를 들어, SMF+PGW-C는 UAV-C 관련 정보 (예, UAV-C의 Application Layer ID (이는 User Info 또는 Pilot Info로 해석 가능), Layer-2 ID 등)를 포함하는 SM NAS 메시지를 UE에게 제공할 수 있다. SMF+PGW-C는 상기 UAV-C 관련 정보는 USS, UAS NF/NEF, UDM/HSS, UDR, PCF, UAV-C, Application Server/Function 중 하나 이상의 entity로부터 제공받거나 획득할 수도 있다. 또는, 상기 UAV-C 관련 정보가 SMF+PGW-C에 설정되어 있을 수도 있다. UAV-C 관련 정보 모두를 하나의 entity로부터 제공받거나 획득할 수도 있고, 다수의 entity로부터 제공받거나 획득할 수도 있다. UAV는 상기 제공받은 UAV-C 관련 정보를 UAV-C와 C2 communcation을 위한 PC5 unicast link 형성 시 사용할 수 있다 (또는 UAV는 상기 제공받은 UAV-C 관련 정보를 사용하여 UAV-C와 C2 communcation을 위한 PC5 unicast link 형성할 수 있다). SMF+PGW-C가 상기 UAV-C 관련 정보를 포함하는 이유는 UE가 이러한 정보를 요청했기 때문일 수 있다 (예, step 0에서 UE가 요청할 수 있음). 상기 UAV-C 관련 정보는 TPAE(Third Party Authorized Entity) 관련 정보일 수도 있다. 이 경우, TPAE는 PC5 capable한 UE 또는 V2X capable UE 또는 ProSe enabled UE인 것으로 간주될 수 있다.
SMF+PGW-C는 아래의 예시와 같은 이유로 인해, SM NAS 메시지에 앞서 설명한 I) 또는 II)에 관련된 정보를 포함시킬 수 있다. 예를 들어, UE가 PC5 기반 C2 communication에 대한 authorization 정보를 요청한 바 (step 0에서), SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 예를 들어, MME가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 1에서), SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 예를 들어, 가입자 정보 (예, Uu 기반 C2 communication authorization 수행 시 UE에게 PC5 기반 C2 communication에 대한 authorization 정보를 제공해야 함, UE가 PC5 기반 C2 communication을 수행할 수 있음 등의 정보)에 기초하여, SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 예를 들어, USS가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 5에서), SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 예를 들어, UAS NF/NEF가 PC5 기반 C2 communication에 대한 authorization 정보를 UE에게 제공하기를 요청한 바 (step 5에서), SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. SMF+PGW-C의 local policy/operator policy/local configuration에 기초하여, SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다. 이러한 예시와 같은 다양한 정보 중 하나 이상에 기초하여, SMF+PGW-C가 상기 정보를 SM NAS 메시지에 포함할 수 있다.
UE는 네트워크로부터 수신한 UE로의 SM 관련 NAS message 및/또는 상기 I) 또는 II) 정보에 기초하여, PC5 interface를 통해 C2 communication을 수행할 수 있는지 여부를 결정할 수 있다.
이하에서, 본 명세서의 개시의 제2예의 제3예시를 설명한다.
참고로, 본 명세서의 개시의 제2예의 제3예시는 앞서 설명한 본 명세서의 개시의 제2예의 제1예시 및/또는 제2예시에 기초한 실시예이다. 예를 들어, 본 명세서의 개시의 제2예의 제3예시는 본 명세서의 개시의 제2예에 대한 설명이 적용되는 예시이다.
C2 통신과 직접 C2 통신은 다음과 같이 정의될 수 있다.
Command and Control (C2) Communication: UAV 컨트롤러 또는 UTM에서 UAV로 UAV 작동을 위한 명령 및 제어 정보가 포함된 메시지를 전달하기 위한 사용자 평면 링크. 또는 UAV에서 UAV 컨트롤러 또는 UTM으로 telemetry 데이터를 보고하기 위한 사용자 평면 링크. C2 통신은 Uu reference point 또는 PC5 reference point를 통해 수립될 수 있다.
Direct C2 Communication: UAV 컨트롤러와 UAV는 서로 통신하기 위해, PC5 기준점을 통해 직접 C2 링크를 수립할 수 있다.
C2 Aviation Payload: 3GPP 시스템에 투명한 UAV 페어링 정보 및/또는 비행 인증(flight authorization) 정보를 포함하여 UAS가 USS로 전송하는 애플리케이션 계층 정보를 포함한다.
C2 Authorization Payload: 3GPP 시스템에 투명한 C2 페어링 정보 및/또는 C2 보안 정보 등 USS가 UAV에 전송하는 애플리케이션 계층 정보를 포함한다.
C2 Pairing Information: UAV-C 어드레싱 정보(예, UAV-C IP 주소를 포함함)를 포함한다.
Uu를 통한 C2 인증(Authorization for C2 over Uu)을 설명한다.
UAV가 C2 동작을 위해 사용자 평면 연결을 수립할 때(즉, UAV-C 또는 USS에서 UAV로 UAV 작업에 대한 명령 및 제어 정보가 포함된 메시지를 전달하거나 UAV에서 UAV-C로 telemetry 데이터를 보고하려면), C2에 대한 인증이 필요하다. C2 통신의 양측, 즉 UAV와 UAV-C는 동일한 UAS에 속할 수 있다.
UAV는 C2를 위해 PDU 세션 또는 PDN 연결을 사용할 것을 USS에 의해 인증받을 수 있다. C2에 대한 인증에는 다음이 포함된다:
- UAV to UAV-C pairing authorization: UAV와 UAV-C가 C2 통신을 교환하기 전, 네트워크에 연결된 UAV-C 또는 인터넷 연결을 통해 UAV에 연결되는 UAV-C와의 페어링을 위한 인증일 수 있다. 하나의 UAV는 언제든지 한 대의 UAV-C와만 페어링할 수 있다. 하나의 UAV-C는 동시에 하나 이상의 UAV와 페어링될 수 있다.
- Flight Authorization: UAV가 비행 인증 정보도 제공하는 경우 비행을 위한 인증일 수 있다.
C2 인증은 다음의 예시와 같은 경우에 수행될 수 있다:
- UUAA 절차 중(PDU 세션/PDN 연결 설정에서 UUAA가 수행되는 경우): UAV가 연결을 위해 PDU 세션/PDN 연결 수립을 요청하는 경우.
- PDU 세션 수정 절차 또는 UE가 요청한 베어러 자원 수정 절차 중: UAV가 C2 통신 관련 메시지를 교환하기 위해 기존 PDU 세션/PDN 연결을 사용해야 하는 경우.
- 새 PDU 세션/PDN 연결을 수립하는 동안: UAV가 C2 통신을 위해 별도의 PDU 세션/PDN 연결을 사용해야 하는 경우
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 13은 본 명세서의 개시의 일 실시예에 따른 C2 통신을 위한 PDU 세션 수립 절차의 예시를 나타낸다.
도 13은 UE가 개시한 C2 통신을 위한 PDU 세션 수립 절차이다. 도 13의 예시는 UAS 서비스들을 위해 별도의 PDU 세션이 사용되는 경우의 예시이다.
UAV-C와의 C2 통신을 위해 특별히 사용되는 PDU 세션에 대한 수립 절차가 수행되는 중에 C2 인증 (authorization)이 요청되는 경우, UAV는 다음과 같이 C2 인증 (authorization)을 요청한다.
0. UAV가 USS와 성공적인 UUAA를 수행했으며(UUAA-SM 또는 UUAA-MM), USS는 해당 GPSI에 대해 NEF로부터의 PDU 세션 상태 이벤트에 가입할 수 있다.
1. UAV가 C2 통신을 수립해야 하는 경우, UAV는 UAV-C에 연결하기 위해 새로운 전용 PDU 세션 또는 직접 PC5 링크가 필요하다고 판단할 수 있다. UE는 UAV-C에 대한 연결에 사용되는 DNN/S-NSSAI 에 대한 PDU 세션 수립 절차를 시작할 수 있다. PDU 세션 수립 요청은 C2 인증에 사용될 CAA-Level UAV ID와 C2 Aviation 페이로드가 포함되고, PDU 세션 수립 요청은 SMF로 전달된다. 페어링 정보는 요청하는 UAV의 CAA-레벨 UAV ID를 포함하며, 페어링할 UAV-C의 식별 정보는 C2 Aviation 페이로드에 포함될 수 있다. 인증 요청이 직접 C2 통신에 대한 요청인 경우, C2 aviation 페이로드는 직접 C2 통신에 대한 인증이라는 인디케이션을 포함한다. UAV는 비행 인증 정보와 같은 다른 정보도 Aviation Payload에 포함할 수 있다. 또한 USS는 로컬로 구성된 페어링 정보를 UAV - UAV-C 페어링 인증에 사용할 수 있으며, 이 페어링 정보는 UAV가 제공한 페어링 정보보다 우선한다.
2. 요청된 DNN/S-NSSAI 조합이 aerial 서비스 전용이고(aerial 서비스 인디케이터가 설정되어 있음), 요청이 서비스 수준 장치 식별(CAA-레벨 UAV ID)을 포함하는지에 기초하여, SMF는 인증이 필요한지 여부를 판단할 수 있다. 그런 다음 SMF는 UAV-C와 UAV를 페어링하기 위한 인증 (authorization)을 요청하는 데 사용되는 Nnef_Authentication_AuthenticateAuthorize 요청 메시지를 UAS NF/NEF에 전송할 수 있다. 이 요청 메시지는 GPSI, CAA 레벨 UAV ID 및 C2 Aviation 페이로드, 선택적으로 AMF가 제공한 경우 UAV 위치(예: 셀 ID), 및 PDU 세션의 DNN 및 S-NSSAI를 포함한다.
요청된 DNN/S-NSSAI가 aerial 서비스 전용이지만, 요청과 함께 서비스 레벨 장치 ID(CAA-레벨 UAV ID)가 제공되지 않은 경우, SMF는 USS 인증 (authorization)이 필요하다는 이유와 함께 PDU 세션 수립 요청을 거부할 수 있다. 예를 들어, SMF는 USS 인증 (authorization)이 필요하다는 이유 정보를 포함하는 PDU 세션 수립 거절 메시지를 전송할 수 있다.
또한 SMF는 UAS NF/NEF에 알림 엔드포인트(Notification Endpoint)를 제공한다. 알림 엔드포인트를 제공함으로써 SMF는 step 5에서 C2 인증 결과가 성공할 경우 재인증, 인증 데이터 업데이트 또는 UAS NF/NEF의 C2 연결의 revocation에 대한 알림을 받도록 암시적으로 구독할 수 있다.
3. UAS NF/NEF는 GPSI에 대해 유효한 UUAA가 저장되어 있는지 확인하고 수신된 인증 요청을 포함하는 Naf_Authentication_AuthenticateAuthorize 요청 메시지를 USS에 전달한다. 그렇지 않은 경우 요청이 USS로 전달되지 않고 PDU 세션이 거부된다.
또한 UAS NF/NEF는 USS에 알림 엔드포인트를 제공한다. 알림 엔드포인트를 제공함으로써, UAS NF/NEF는 step 5에서 UUAA 결과가 성공할 경우 USS로부터 재인증, 인증 데이터 업데이트 또는 C2 연결 해지 알림을 받도록 암시적으로 구독할 수 있다.
USS는 UAS NF/NEF의 쿼리에 대한 응답으로 UAV 재인증/재인증 (authorization)을 트리거할 수 있다.
4. USS는 수신된 정보에 기초하여 C2 인증을 수행하고 Naf_Authentication_AuthenticateAuthorize 응답 메시지를 UAS NF/NEF에 전송할 수 있다. Naf_Authentication_AuthenticateAuthorize 응답 메시지는 서비스 수준 장치 식별(예: CAA-레벨 UAV-ID)(잠재적으로 새로운 것), C2 인증 결과 및 C2 인증 페이로드(예: C2 페어링 정보 및 C2 보안 정보, 직접 C2 페어링 정보)를 포함한다.
step 1에서 직접 C2 통신에 대한 인증 요청이 포함되었고 C2 인증에 성공할 수 있다. 이 경우, USS는 UAV-C의 애플리케이션 레이어 ID를 포함하는 직접 C2 페어링 정보를 Naf_Ahentication_AuthenticateAuthorize 응답 메시지에 포함시킬 수 있다.
5. UAS-NF/NEF는 USS로부터 받은 정보를 포함하는 Nnef_Authentication_AuthenticateAuthorize 응답 메시지를 SMF에게 전송할 수 있다.
6. SMF는 UE에게 PDU 세션 수립 수락 메시지를 UE에게 전송할 수 있다. C2 인증 결과를 UE에 알리기 위해, SMF는 인증 결과, 선택적으로 인증 페이로드(예: C2 페어링 정보 및 C2 보안 정보, 직접 C2 페어링 정보) 및 USS 로부터 수신된 경우 새로운 CAA-레벨 UAV ID를 PDU 세션 수립 수락 메시지에 포함시킬 수 있다. 그리고, SMF는 PDU 세션 수립 절차가 완료될 때까지 계속 진행할 수 있다.
USS로부터 실패한 C2 인증 결과가 수신되면, SMF는 PDU 수립을 거절하고, 인증되지 않았음을 나타내는 이유 코드(reason code)를 포함하는 PDU 세션 수립 거절 메시지를 전송할 수 있다.
7. [조건부(conditional)] C2 인증이 성공하면, USS는 UAS-NF를 통해 UAV의 GPSI를 포함하는 요청 메시지를 전송함으로써, C2에 사용되는 PDU 세션에 대한 PDU 세션 상태 이벤트를 구독한다. UAS NF는 C2 통신에 사용되는 PDU 세션에 해당하는 DNN, S-NSSAI를 결정하고 이 DNN, S-NSSAI를 사용하여 SMF에 PDU 세션 상태 이벤트를 구독한다. SMF 는 TS 23.502 V17.6.0의 fig. 4.15.3.2.3-1 의 steps 6-7에 설명된 바와 같이, PDU 세션이 설정된 것을 감지하고, GPSI 및 UE IP Address 를 포함한 Nsmf_EventExposure_Notify 메시지를 통해 PDU 세션 상태 이벤트 보고를 UAS NF/NEF 에 전송할 수 있다. 그러면 UAS NF/NEF는 이벤트 메시지를 USS에 전달한다.
8. [조건부(conditional)] USS 는 수신된 UE IP 주소를 저장하고, 수신된 PDU 세션 IP 주소와 인증된 페어링된 UAV-C 의 IP 주소를 입력으로 하여, USS 가 페어링 정책 설정 절차를 호출할 수 있다. 이에 따라, USS는 UPF 가 PDU 세션에서 해당 트래픽을 허용하도록 요청한다.
C2 플로우에 대해 전용 QoS를 요청하지 않는 한, 이 절차는 UE, AMF 또는 RAN과의 상호 작용을 호출하지 않는다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 14는 본 명세서의 개시의 일 실시예에 따른 C2 인증을 위한 PDN 연결의 예시이다.
도 14는 UE가 요청한 C2 인증을 위한 PDN 연결 수립 절차의 예시이다.
UAV가 C2용 E-UTRAN을 통해 추가 PDN에 대한 연결을 설정하도록 요청하면, clause 5.10.2 of TS 23.401의 절차에 대해, 다음의 예시와 같은 수정 사항이 적용될 수 있다.
0. UAV가 USS(UUAA-SM)와 성공적인 UUAA를 수행했으며, USS는 해당 GPSI에 대해 NEF의 PDN 연결 상태 이벤트 보고를 구독한 상태일 수 있다.
1. TS　23.401의 Figure 5.10.2-1에 설명된 steps 1 내지 3이 수행될 수 있다.
UAV가 C2 통신을 수립해야 하는 경우, UAV는 UAV-C에 연결하기 위해 새로운 PDN 연결 또는 직접 PC5 링크가 필요하다고 판단할 수 있다. UE 는 UAV-C로의 연결을 위해, UE가 요청한 PDN 연결 절차를 시작한다. PDN 연결 요청 메시지에 포함된 PCO는 서비스 레벨 장치 identity(예: CAA-레벨 UAV ID)와 C2 인증 (authorization)에 사용될 C2 항공 페이로드가 포함하고, PCO는 MME로 전달된다. 페어링 정보는 requesting UAV의 서비스 수준 장치 식별자(예: CAA 레벨 UAV ID)를 포함하며, 페어링할 UAV-C의 식별 정보는 C2 항공 페이로드에 포함될 수 있다. 인증 요청이 직접 C2 통신에 대한 인증 요청인 경우, C2 항공 페이로드는 직접 C2 통신에 대한 인증이라는 표시를 포함한다. UAV는 비행 인증 (authorization) 정보와 같은 다른 정보도 포함시킬 수 있다. 또한 USS는 로컬로 구성된 페어링 정보를 UAV - UAV-C 페어링 인증 (authorization)에 사용할 수 있으며, 이 정보는 UAV가 제공한 페어링 정보보다 우선한다.
요청 메시지와 함께, 서비스 레벨 장치 ID(CAA-레벨 UAV ID)가 제공된 경우, SMF+PGW-C는 Nudm_SDM_Get 서비스 작업을 사용하여 UDM+HSS에서 UE의 세션 관리 가입 데이터(아직 사용할 수 없는 경우)를 검색한다.
2. 요청된 APN/DNN이 aerial 서비스 전용이고(aerial 서비스 인디케이터가 설정되어 있음), 요청 메시지가 서비스 수준 장치 식별자(CAA-레벨 UAV ID)를 포함하는 것에 기초하여, SMF+PGW-C는 인증 (authorization)이 필요한지 판단한다. 그런 다음 SMF+PGW-C는 UAV-C와 UAV를 페어링하기 위한 인증 (authorization)을 요청하는데 사용되는 Nnef_Authentication_AuthenticateAuthorize 요청 메시지를 UAS NF/NEF에게 전송한다. 이 요청 메시지에는 GPSI, 서비스 수준 장치 식별자(예: CAA-레벨 UAV ID) 및 C2 Aviation 페이로드가 포함되고, 선택적으로 UAV 위치(예: 셀 ID)(MME에 의해 제공되는 경우)와 PDN 연결의 APN/DNN가 포함된다.
SMF+PGW-C가 USS와의 인증 절차가 필요하다고 판단하지만 UAV가 서비스 레벨 장치 ID(예: CAA 수준 UAV ID)를 제공하지 않은 경우, SMF+PGW-C는 USS 인증 (authorization)이 필요하다는 사유를 포함하는 PDN 연결 요청 거절 메시지를 전송한다.
3. UAS NF/NEF는 GPSI에 대해 유효한 UUAA가 저장되어 있는지 확인하고, 수신된 인증 요청을 Naf_Authentication_AuthenticateAuthorize 요청으로 USS에 전달한다. 그렇지 않은 경우 요청이 USS로 전달되지 않고 PDN 연결이 거부다.
4. USS는 수신된 정보를 기반으로 C2 인증을 수행하고 서비스 수준 장치 ID(예: CAA 수준 UAV-ID)(잠재적으로 신규), C2 인증 결과 및 C2 인증 페이로드(예: C2 페어링 정보 및 C2 보안 정보, 직접 C2 페어링 정보)를 포함한 Naf_Authentication_AuthenticateAuthorize 응답을 UAS NF/NEF에 전송한다.
Step 1에서 직접 C2 통신에 대한 인증 요청이 포함되었고, C2 인증에 성공한 경우, USS는 Naf_Ahentication_AuthenticateAuthorize 응답에 UAV-C의 애플리케이션 레이어 ID가 포함된 직접 C2 페어링 정보를 포함할 수 있다.
5.UAS NF/NEF는 USS로부터 받은 정보를 Nnef_Authentication_AuthenticateAuthorize 응답으로 SMF+PGW C에 전달한다.
6. C2 인증 결과를 UE 에 알리기 위해, SMF+PGW-C 는 UE에게 전송될 PDN Connectivity Accept 의 PCO 에, C2 인증 결과와 선택적으로 인증 페이로드(예: C2 페어링 정보 및 C2 보안 정보, 직접 C2 페어링 정보) 및 새로운 서비스 레벨 장치 ID(예: CAA 레벨 UAV ID)(USS 로부터 수신된 경우)를 포함시킨다. 그리고 SMF+PGW-C 는 포함시키고 PDN 연결 요청 절차가 완료될 때까지 계속 진행하도록 한다.
USS로부터 실패한 C2 인증 결과를 수신한 경우, SMF+PGW-C는 대신 PDN 연결 요청을 거절하고, 인증되지 않았음을 나타내는 원인 코드를 포함하는 거절 메시지를 전송한다.
7. C2 인증이 성공하면 USS는 UAV의 GPSI를 요청에 포함시켜, UAS NF/NEF를 통해 C2에 사용된 PDN 연결에 대한, PDN 연결 상태 이벤트 보고를 구독한다. UAS NF/NEF는 APN/DNN을 결정하고 이 APN/DNN을 사용하여 SMF+PGW-C에 PDN 연결 상태 이벤트를 구독한다. SMF+PGW-C 는 TS 23.502의 figure 4.15.3.2.3-1 의 steps 6-7에 설명된 바와 같이, PDN 연결이 설정되면 이를 감지한다. 그리고, SMF+PGW-C 는 GPSI 및 UE IP Address 를 포함한 PDN 연결 상태 이벤트 보고서를 Nsmf_EventExposure_Notify 메시지를 통해 UAS NF/NEF 에 전송한다. 그러면 UAS NF/NEF는 이벤트 메시지를 USS로 전달한다.
8. PGW-U에 의한 PDN 연결에서 해당 트래픽을 허용하도록 요청하기 위해, USS 는 수신된 UE IP 주소를 저장하고, 수신된 PDN 연결 IP 주소와 인증된 페어링된 UAV-C 의 IP 주소를 입력으로 하여, EPS 절차(그림 5.2.5.4.2-1 참조)에서 USS 개시 C2 페어링 정책 설정 절차를 호출할 수 있다.
C2 플로우에 대해 전용 QoS를 요청하지 않는 한, 이 절차는 UE, MME 또는 RAN과의 상호 작용을 호출하지 않는다.
Direct C2 Communication을 설명한다.
직접 C2 통신을 지원하는 UAV는 UAV-C와 직접 PC5 링크를 수립할 수 있다. 직접 C2 통신을 사용하는 UAV는 3GPP 네트워크에 연결할 수 있거나 연결할 수 없을 수 있다. UAV는 UAV-C와 직접 C2 통신을 수립할 수 있도록, USS에 의해 인증될 수 있다. 도 13을 참조한 예시 및 도 14를 참조한 예시에서 설명된 바와 같이, UAV와 직접 C2 통신을 수행하는 UAV-C에 관련된 정보는 UAV 내에 미리 설정되거나 네트워크에 의해 제공될 수 있다. UAV는 직접 C2 통신을 위한 Aircraft-to-Everything (A2X) 서비스 유형, 직접 C2 페어링 정보(예: UAV-C의 애플리케이션 계층 ID), UAV-C의 layer-2 ID, 유니캐스트 연결을 수립하기 위한 초기 시그널링용 디폴트 destination 계층-2 ID, 직접 C2 통신을 위한 인증 정책이 미리 설정될 수 있다.
직접 C2 통신을 위한 인증(Authorization for Direct C2 Communication)을 설명한다.
직접 C2 통신을 지원하는 UAV에게 다음과 같은 인증 정책이 제공될 수 있다:
- UAV가 "NG-RAN에 의해 서빙되는 경우":
- UAV가 "NG-RAN에 의해 서빙"될 때, PC5 레퍼런스 포인트를 통해 직접 C2 통신을 수행할 수 있도록 인증된 PLMN.
- UAV가 "NG-RAN에 의해 서빙되지 않는 경우":
- "NG-RAN에 의해 서빙되지 않는 경우" UE가 PC5 레퍼런스 포인트를 통해 C2 통신을 수행하도록 인증되는지 여부를 나타내는 정보.
UAV가 3GPP 네트워크 연결이 가능한 경우, UAV는 앞서 "Authorization for C2 over Uu"에 대해 설명된 대로 C2 인증을 수행한다. UAV가 직접 C2 통신을 지원하고, 직접 C2에 대한 인증 정책이 없는 경우, UAV는 직접 C2 통신 인증에 대한 인디케이션을 인증 요청에 포함시킬 수 있다.
직접 C2 통신 수립을 위한 절차(Procedure for Direct C2 Communication establishment)를 설명한다.
TS 23.304 V17.4.0의 6.4.3.1절에 정의된 유니캐스트 모드 5G ProSe 직접 통신 절차는 PC5를 통한 C2 통신 수립에 사용되며, 다음과 같은 개선 사항이 적용될 수 있다. 또한, 이하의 개선 사항은 도 12를 참조한 예시에도 적용될 수 있다.
- TS 23.304 V17.4.0의 6.4.3.1절(또는 도 12)의 Step 3에서, 이하의 설명이 적용될 수 있다:
- Prose Service Info가 C2 통신을 위한 A2X service type로 설정될 수 있다. C2 통신을 위한 A2X service type은 UAV에 미리 설정될 수 있다.
- Source User 정보는 서비스 레벨 장치 ID(예, CAA-Level UAV ID)로 설정될 수 있다.
- Target User Info가 UAV-C의 어플리케이션 계층 ID로 설정될 수 있다. 도 13의 예시 및 도 14의 예시에서 설명한 바와 같이, UAV-C의 어플리케이션 계층 ID는 UAV에 미리 설정되거나, 네트워크에 의해 제공될 수 있다.
- Destination Layer-2 ID는 UAV-C의 레이어-2 ID로 설정된다(UAV에 UAV-C의 레이어-2 ID가 미리설정된 경우). 그렇지 않으면, destination 레이어-2 ID는 UAV에 미리설정된 대로 유니캐스트 연결을 설정하기 위한 초기 시그널링의 디폴트 destination 레이어-2 ID로 설정된다.
직접 C2 통신에 대해, 유니캐스트 모드 5G 직접 통신 절차가 지원될 수 있다.
3. 본 명세서의 개시의 제3예
UAV와 PC5 기반 C2 통신을 수행하는 대상을 변경하고자 할 때, 네트워크가 Uu 연결을 이용하여 UE에게 알리는 예시를 설명한다.
예를 들어, UAV와 PC5 기반 C2 connection을 갖는 (즉, PC5 기반으로 C2 communication 수행하는) UAV-C를 변경하고자 할때, 또는 UAV-C에서 TPAE로 변경하고자 할때, 또는 TPAE에서 UAV-C로 변경하고자 할 때, 네트워크가 Uu connection을 이용하여 UE에게 알릴 수 있다.
UAV와 PC5 기반 C2 connection을 갖는 (즉, PC5 기반으로 C2 communication 수행하는) UAV-C를 변경하고자 할때, 또는 UAV-C에서 TPAE로 변경하고자 할때, 또는 TPAE에서 UAV-C로 변경하고자 할 때 다음 중 하나 이상의 동작이 수행될 수 있다:
a) UAV Controller Replacement 절차가 이용될 수 있다 (TS 23.256 V17.4.0의 5.2.8절 참고). 예를 들어, USS는 상기 변경에 대한 정보 또는 (re-)authorization이 상기 변경을 위한 것임을 나타내는 정보를 UAS NF/NEF로 제공할 수 있다. UAS NF/NEF는 상기 정보를 SMF (5GS의 경우) 또는 SMF+PGW-C (EPS의 경우)에게 제공할 수 있다. SMF (5GS의 경우)가 SM NAS message를 UE에게 전송하거나, 또는 SMF+PGW-C (EPS의 경우)가 SM 관련 NAS message를 MME를 통해 UE에게 전송하는 경우, 상기 정보를 포함할 수 있다.
b) C2 connectivity revocation 절차를 이용할 수 있다 (도 10의 예시 및 도 11의 예시 참고). 예를 들어, USS는 상기 변경에 대한 정보 또는 revocation이 상기 변경을 위한 것임을 나타내는 정보를 UAS NF/NEF로 제공할 수 있다. UAS NF/NEF는 상기 정보를 SMF (5GS의 경우) 또는 SMF+PGW-C (EPS의 경우)에게 제공할 수 있다. SMF (5GS의 경우)가 SM NAS message를 UE에게 전송하는 경우 또는 SMF+PGW-C (EPS의 경우)가 SM 관련 NAS message를 MME를 통해 UE에게 전송하는 경우, 상기 정보를 포함할 수 있다.
USS는 UAV-C에서 다른 UAV-C로 변경 시 또는 TPAE에서 UAV-C로 변경 시, 새로운 UAV-C에 대한 정보 (예, UAV-C의 Application Layer ID (이는 User Info 또는 Pilot Info로 해석 가능), Layer-2 ID 등)를 포함하여 UE에게 제공할 수도 있다. TPAE로 변경 시, TPAE에 대한 정보 (예, TPAE의 Application Layer ID (이는 User Info 또는 Pilot Info 또는 Officer Info 등으로 해석 가능), Layer-2 ID 등)를 포함하여 UE에게 제공할 수도 있다.
UE는 상기 SMF로부터 받은 SM NAS message 또는 네트워크/MME로부터 받은 UE로의 SM 관련 NAS message에 포함된 정보에 기반하여 새로운 UAV-C 또는 TPAE와 C2 connection을 위한 PC5 unicast link를 형성할 수 있다. 또한, 기존의 C2 connection을 위한 PC5 unicast link를 해제할 수 있다.
상기 a), b) 동작에서 Uu를 통한 C2 communication 관련 절차/동작은 불필요한 경우 skip될 수도 있다.
4. 본 명세서의 개시의 제4예
Uu를 통한 C2 communication authorization (또는 USS/네트워크와의 authorization) 실패 시 또는 revocation 시, 코어 네트워크가 PC5를 통한 C2 communication이 authorize 되는지 여부를 기지국으로 제공하는 예시를 설명한다.
Uu를 통한 C2 communication authorization이 실패한 경우 (즉, 성공하지 못한 경우) 또는 Uu 기반 C2 connection이 revoke된 경우 또는 Uu 기반 C2 communication에 사용되던 PDU Session/QoS Flow가 해제된 경우 또는 Uu 기반 C2 communication에 사용되던 PDN connection/bearer가 해제된 경우, Core Network가 기지국으로 다음 중 하나 이상의 정보를 제공할 수 있다. 이러한 정보는 조합적인 형태, 명시적인 형태, 암시적인 형태 등 다양한 형태로 제공될 수 있다:
(A) PC5 기반 C2 communication이 authorize되지 않는다는 정보
(B) PC5 기반 C2 communication이 허용되지 않는다는 정보
(C) PC5 기반 C2 communication을 위한 자원 할당을 하지 말 것을 요청하는 정보. 상기 자원은 radio resource일 수 있음.
상기의 정보에 연관되는 UE는 UAV인 것으로 가정한다. 다만 이는 예시에 불과하며, 상기의 정보에 연관되는 UE는 UAV-C일 수도 있고 UAV와 UAV-C 모두일 수도 있다.
Core Network이 상기의 정보(예, (A) 내지 (C) 중 하나 이상의 정보)를 기지국으로 제공하는 방법은 다음 중 하나 이상에 기초할 수 있다:
- SMF가 N2 message/정보에 (또는 이 형태로) 상기 정보를 포함하여 AMF를 통해 기지국으로 전송할 수 있다.
- SMF가 AMF로 상기 정보를 제공하고, AMF가 이를 기지국으로 전송한다. 상기 SMF가 AMF로 상기 정보를 제공하는 것은 event 통보의 형태일 수도 있다.
- SMF+PGW-C가 MME로 상기 정보를 제공하고, MME가 이를 기지국으로 전송할 수 있다.
- SMF가 UDM에게 상기 정보를 제공 또는 상기 정보를 AMF에게 통보해 줄 것을 요청한다. 그러면 UDM이 AMF로 상기 정보를 제공/통보하고, AMF는 이를 기지국으로 전송할 수 있다. 이 경우 UDM은 해당 UE의 상대 UE (즉, UE가 UAV면 UAV-C이고, UE가 UAV-C면 UAV)에 대해서도 AMF로 상기 정보를 제공/통보함으로써, AMF가 이를 기지국으로 전송하도록 할 수도 있다. UE의 상대 UE에 대한 정보는 가입자 정보에 기반할 수 있다.
기지국이 상기의 정보를 Core Network으로부터 수신하면, 기지국은 해당 UE에 대해 PC5 기반 C2 communication (또는 PC5 communication, Direct communication)에 필요한 radio resource를 할당/제공하지 않는 것을 결정할 수 있다.
앞서 다양한 예시에 기초하여 설명한 본 명세서의 개시의 제1예 내지 제4예에서, Uu 기반의 C2 communication authorization가 수행되는 것에 관련하여, PC5 인터페이스를 이용하는 C2 communication을 지원하는 방안을 설명했다. 본 명세서의 개시에서 PC5 인터페이스를 이용하는 C2 communication에 관련하여 설명한 내용은, Uu 기반의 C2 communication re-authorization이 수행되는 경우에도 적용될 수 있다.
앞서 다양한 예시에 기초하여 설명한 본 명세서의 개시의 제1예 내지 제4예에서, PC5 기반 C2 communication에 관련된 동작은 이러한 동작을 수행하기 위한 PC5 동작 또는 이와 연관된 다른 PC5 동작 (예, Direct discovery)을 포함하는 것으로 해석될 수도 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 15는 본 명세서의 개시의 일 실시예에 따른 절차의 예를 나타낸다.
참고로, 도 15에 도시된 절차는 예시에 불과하며, 본 명세서의 개시의 범위는 도 15의 예시에 의해 제한되지 않는다. 예를 들어, 도 15에 도시된 UE, SMF, USS 는 도 1의 예시 내지 도 14의 예시에서 설명한 동작들을 수행할 수 있다. 참고로, 도 15의 예시에는 AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF 등이 도시되지 않았지만, 이는 설명의 편의를 위한 것이다. 즉, 도 15에 기초한 실시예에서도 AMF, UPF, PCF, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF 등이 본 명세서의 개시의 다양한 예시에서 설명한 동작을 수행할 수 있다.
예를 들어, 도 15의 예시에 대해, 도 1 내지 도 14의 예시에서 설명된 동작도 적용될 수도 있다. 예를 들어, 도 15의 예시에서 직접 설명되지 않은 동작, 내용 등이더라도, 본 명세서의 개시의 다양한 예시에서 설명된 동작, 내용 등이 적용될 수 있다.
단계(S1501)에서, UE (예: UAV)는 요청 메시지를 SMF에게 전송할 수 있다. 예를 들어, UE는 UAV-C와의 직접 C2 통신을 위한 인증을 요청할 수도 있다. 예를 들어, UE가 전송하는 요청 메시지는 직접 C2 통신을 위한 인증을 요청한다는 정보를 포함할 수 있다. 일례로, 인증 요청 메시지는 C2 aviation payload 정보를 포함할 수 있고, 이 정보는 직접 C2 통신을 위한 인증이라는 정보를 포함할 수 있다.
단계(S1502)에서, SMF는 USS에게 인증 요청 메시지를 전송할 수 있다. 예를 들어, SMF는 UAS NF/NEF를 거쳐 USS에게 인증에 관련된 메시지를 전송할 수 있다. SMF가 전송하는 인증 요청 메시지는 예를 들어, Nnef_Authentication_AuthenticateAuthorize 메시지일 수 있다. SMF는 이 요청 메시지를 UAS NF/NEF에게 전송하고, UAS NF/NEF는 이 요청 메시지를 Naf_Authentication_AuthenticateAuthorize 요청 메시지로 생성하여 USS에게 전송할 수 있다.
단계(S1503)에서, USS는 SMF에게 인증 응답 메시지를 전송할 수 있다. 여기서, 인증 응답 메시지는 예를 들어, Naf_Authentication_AuthenticateAuthorize response 메시지일 수 있다. USS가 직접 C2 인증을 성공적으로 수행한 경우, USS는 UAV-C의 어플리케이션 레이어 ID를 포함하는 인증 응답 메시지를 SMF에게 전송할 수 있다. UAV-C의 어플리케이션 레이어 ID는 UE에게 전달될 수 있다. 예를 들어, USS가 전송하는 Naf_Authentication_AuthenticateAuthorize response 메시지는 C2 인증 페이로드를 포함할 수 있고, C2 인증 페이로드는 직접 C2 페어링 정보를 포함할 수 있다. C2 페어링 정보는 UAV-C의 어플리케이션 레이어 ID를 포함할 수 있다.
SMF는 UAV의 애플리케이션 레이어 ID를 UE에게 전달할 수 있다.
만약 USS가 직접 C2 인증을 실패한 경우, USS는 직접 C2 인증이 실패했다는 정보를 포함하는 응답 메시지를 SMF에게 전송할 수 있다. 이 경우, SMF는 UE에게 PC5에 기초한 C2 통신을 수행하지 말 것을 알리는 정보를 전송할 수 있다.
단계(S1504)에서, SMF는 정보를 UE에게 전송할 수 있다. 예를 들어, SMF는 UAV-C의 어플리케이션 레이어 ID를 UE에게 전송할 수 있다. UE는 UAV-C의 어플리케이션 레이어 ID를 타겟 사용자 정보로 설정할 수 있다 예를 들어, UE는 UAV-C의 어플리케이션 레이어 ID를 타겟 사용자 정보로 설정하고, 타겟 사용자 정보를 포함하는 직접 통신 요청 메시지를 다른 UE (예: UAV-C)에게 전송할 수 있다. 이를 통해, UE는 UAV-C와 PC5 레퍼런스 포인트를 통한 C2 통신을 UAV-C와 수립할 수 있다.
본 명세서의 개시의 일 실시예에 따르면, Uu 기반 C2 communication authorization 결과에 따른 PC5 기반 C2 communication 허용 여부 설정 관련하여, 다음의 예시와 같은 동작이 수행될 수 있다. 예를 들어, Uu 기반 C2 communication authorization (또는 USS/네트워크와의 authorization) 결과에 따라, PC5 기반 C2 communication을 수행할 수 있는지 여부가 UE에게 지시되거나 또는 설정될 수 있다. 예를 들어, UE는 PC5 기반 C2 communication을 수행하기에 앞서 Uu 기반 C2 communication authorization (또는 USS/네트워크와의 authorization)을 수행할 수 있다. 예를 들어, Uu 기반 C2 communication authorization의 결과 (즉, 성공 또는 실패)와 PC5 기반 C2 communication을 수행할 수 있는지 여부에 대한 지시/설정 정보에 기초하여, UE는 PC5 기반 C2 communication을 수행할 수 있는지 여부를 결정할 수 있다.
본 명세서의 개시의 일 실시예에 따르면, Uu 기반 C2 communication revocation 수행에 따른 PC5 기반 C2 communication 허용 여부 설정 관련하여, 다음의 예시와 같은 동작이 수행될 수 있다. 예를 들어, Uu 기반 C2 communication revocation 수행 시, PC5 기반 C2 communication을 수행할 수 있는지 여부가 UE에게 지시되거나 또는 설정될 수 있다. 예를 들어, Uu 기반 C2 communication revocation이 수행될 수 있다. 예를 들어, PC5 기반 C2 communication을 수행할 수 있는지 여부에 대한 지시/설정 정보에 기초하여, UE는 PC5 기반 C2 communication을 수행/지속할 수 있는지 여부를 결정할 수 있다.
본 명세서의 개시의 다양한 예시에 따르면, 본 명세서는 다양한 효과를 가질 수 있다. 예를 들어, UAV와 UAV-C 간의 C2 통신을 수행하기 위한 인증이 효과적으로 수행될 수 있다. 예를 들어, UAV가 Uu를 통한 C2 communication authorization procedure를 통해 네트워크로부터 Direct C2 communication을 위한 정보, 즉 UAV-C와 PC5 unicast link를 형성하기 위한 정보를 제공받음으로써 Direct C2 communication을 수행할 수 있다. 예를 들어, Uu를 통한 C2 communication authorization 절차를 통해 (즉, USS/네트워크와 authorization을 수행하여) PC5를 통한 C2 communication을 authorize 하는 경우, Uu를 통한 C2 communication authorization 절차가 실패하면 PC5를 통한 C2 communication을 수행하지 않도록 할 수 있다.
본 명세서의 구체적인 예시를 통해 얻을 수 있는 효과는 이상에서 나열된 효과로 제한되지 않는다. 예를 들어, 관련된 기술 분야의 통상의 지식을 가진 자(a person having ordinary skill in the related art)가 본 명세서로부터 이해하거나 유도할 수 있는 다양한 기술적 효과가 존재할 수 있다. 이에 따라, 본 명세서의 구체적인 효과는 본 명세서에 명시적으로 기재된 것에 제한되지 않고, 본 명세서의 기술적 특징으로부터 이해되거나 유도될 수 있는 다양한 효과를 포함할 수 있다.
참고로, 본 명세서에서 설명한 단말(예: UE, UAV, UAV-C 등)의 동작은 앞서 설명한 도 1 내지 도 3의 장치에 의해 구현될 수 있다. 예를 들어, 단말(예: UE)은 도 2의 제1 장치(100) 또는 제2 장치(200)일 수 있다. 예를 들어, 본 명세서에서 설명한 단말의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 처리될 수 있다. 본 명세서에서 설명한 단말의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 실행가능한 명령어/프로그램(e.g. instruction, executable code)의 형태로 하나 이상의 메모리(104 또는 204)에 저장될 수 있다. 하나 이상의 프로세서(102 또는 202)는 하나 이상의 메모리(104 또는 204) 및 하나 이상의 송수신기(105 또는 206)을 제어하고, 하나 이상의 메모리(104 또는 204)에 저장된 명령어/프로그램을 실행하여 본 명세서의 개시에서 설명한 단말(예: UE)의 동작을 수행할 수 있다.
또한, 본 명세서의 개시에서 설명한 단말의 동작을 수행하기 위한 명령어들은 기록하고 있는 비휘발성 컴퓨터 판독가능 저장 매체에 저장될 수도 있다. 상기 저장 매체는 하나 이상의 메모리(104 또는 204)에 포함될 수 있다. 그리고, 저장 매체에 기록된 명령어들은 하나 이상의 프로세서(102 또는 202)에 의해 실행됨으로써 본 명세서의 개시에서 설명한 단말의 동작을 수행할 수 있다.
참고로, 본 명세서에서 설명한 네트워크 노드(예: AMF, SMF, UPF, PCF, USS, UDM, NEF, PGW-U, SMF+PGW-C, PGW-C, MME, SGW, DN, UAS NF 등) 또는 기지국(예: (R)AN, NG-RAN, gNB, 등)의 동작은 이하 설명될 도 1 내지 도 3의 장치에 의해 구현될 수 있다. 예를 들어, 네트워크 노드 또는 기지국은 도 2의 제1 장치(100) 또는 제2 장치(200)일 수 있다. 예를 들어, 본 명세서에서 설명한 네트워크 노드 또는 기지국의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 처리될 수 있다. 본 명세서에서 설명한 단말의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 실행가능한 명령어/프로그램(e.g. instruction, executable code)의 형태로 하나 이상의 메모리(104 또는 204)에 저장될 수 있다. 하나 이상의 프로세서(102 또는 202)는 하나 이상의 메모리(104 또는 204) 및 하나 이상의 송수신기(106 또는 206)을 제어하고, 하나 이상의 메모리(104 또는 204)에 저장된 명령어/프로그램을 실행하여 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행할 수 있다.
또한, 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행하기 위한 명령어들은 기록하고 있는 비휘발성(또는 비일시적) 컴퓨터 판독가능 저장 매체에 저장될 수도 있다. 상기 저장 매체는 하나 이상의 메모리(104 또는 204)에 포함될 수 있다. 그리고, 저장 매체에 기록된 명령어들은 하나 이상의 프로세서(102 또는 202)에 의해 실행됨으로써 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행할 수 있다.
이상에서는 바람직한 실시예를 예시적으로 설명하였으나, 본 명세서의 개시는 이와 같은 특정 실시예에만 한정되는 것은 아니므로, 본 명세서의 사상 및 특허청구범위에 기재된 범주 내에서 다양한 형태로 수정, 변경, 또는 개선될 수 있다.
상술한 예시적인 시스템에서, 방법들은 일련의 단계 또는 블록으로써 순서도를 기초로 설명되고 있지만, 설명되는 단계들의 순서에 한정되는 것은 아니며, 어떤 단계는 상술한 바와 다른 단계와 다른 순서로 또는 동시에 발생할 수 있다. 또한, 당업자라면 순서도에 나타낸 단계들이 배타적이지 않고, 다른 단계가 포함되거나 순서도의 하나 또는 그 이상의 단계가 권리범위에 영향을 미치지 않고 삭제될 수 있음을 이해할 수 있을 것이다.
본 명세서에 기재된 청구항은 다양한 방식으로 조합될 수 있다. 예를 들어, 본 명세서의 방법 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다. 또한, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다. 다른 구현은 다음과 같은 청구 범위 내에 있다.

Claims (17)

  1. Session Management Function (SMF)가 통신을 수행하는 방법에 있어서,
    User Equipment (UE)로부터 직접(direct) Command and Control (C2) 통신을 위한 인증(authorization) 요청 정보를 수신하는 단계;
    인증 요청 메시지를 Uncrewed Aerial System (UAS) Service Supplier (USS)에게 전송하는 단계;
    상기 직접 C2 통신을 위한 인증이 성공한 것에 기초하여, 상기 USS로부터 Uncrewed Aerial Vehicle (UAV) controller(UAV-C)의 어플리케이션 계층 ID를 수신하는 단계; 및
    상기 UAV-C의 어플리케이션 계층 ID를 상기 UE게 전송하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 UAV-C의 어플리케이션 계층 ID는 상기 UE에 의해, PC5에 기초한 유니캐스트 링크를 수립하기 위해 사용되는 것을 특징으로 하는 방법.
  3. 제2항에 있어서,
    상기 UAV-C의 어플리케이션 계층 ID는 타겟 사용자 정보(Target User Info)로 설정되는 것을 특징으로 하는 방법.
  4. 제3항에 있어서,
    상기 타겟 사용자 정보를 포함하는 직접 통신 요청 메시지가 상기 UE에 의해 전송되는 것을 특징으로 하는 방법.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서,
    상기 UAV-C의 어플리케이션 계층 ID는 직접 C2 페어링 정보에 포함되는 것을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 직접 C2 페어링 정보는 상기 USS에 의해 전송되는 Naf_Authentication_AuthenticateAuthorize response 메시지에 포함되는 것을 특징으로 하는 방법.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서,
    상기 직접 C2 통신은,
    UAV 컨트롤러와 UAV 사이의 PC5 참조 포인트를 통해 수립한 직접 C2 링크를 의미하는 것을 특징으로 하는 방법.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서,
    상기 직접 C2 통신을 위한 인증이 실패한 경우, 상기 직접 C2 통신을 수행하지 말 것을 알리는 정보가 상기 UE에게 전송되는 것을 특징으로 하는 방법.
  9. 무선 통신 시스템에서 동작하도록 구성되는 Session Management Function (SMF)에 있어서, 상기 SMF는:
    하나 이상의 송수신기;
    하나 이상의 프로세서; 및
    명령어(instructions)를 저장하고 상기 하나 이상의 프로세서와 동작 가능하도록 연결될 수 있는 하나 이상의 메모리를 포함하며,
    상기 명령어가 상기 하나 이상의 프로세서에 의해서 실행되는 것을 기반으로 수행하는 동작은 제1항 내지 제8항 중 어느 하나의 항에 따른 방법인 SMF.
  10. User Equipment (UE)가 통신을 수행하는 방법에 있어서,
    직접(direct) Command and Control (C2) 통신을 위한 인증(authorization) 요청 정보를 Session Management Function (SMF)에게 전송하는 단계,
    상기 인증 요청 정보는, 상기 SMF가 인증 요청 메시지를 Uncrewed Aerial System (UAS) Service Supplier (USS)에게 전송하는데 사용되고; 및
    상기 SMF로부터 Uncrewed Aerial Vehicle (UAV) controller(UAV-C)의 어플리케이션 계층 ID를 수신하는 단계를 포함하고,
    상기 UAV-C의 어플리케이션 계층 ID는 상기 직접 C2 통신을 위한 인증이 성공적인 것에 기초하여, 상기 USS에 의해 상기 SMF를 통해 UE에게 전송된 것을 특징으로 하는 방법.
  11. 제10항에 있어서,
    상기 UAV-C의 어플리케이션 계층 ID에 기초하여, 상기 UAV-C와 PC5에 기초한 유니캐스트 링크를 수립하는 단계를 더 포함하는 방법.
  12. 제11항에 있어서,
    상기 UAV-C의 어플리케이션 계층 ID로 설정된 타겟 사용자 정보(Target User Info)를 포함하는 직접 통신 요청 메시지를 상기 UAV-C에게 전송하는 단계를 더 포함하는 방법.
  13. 제10항 내지 제12항 중 어느 한 항에 있어서,
    상기 직접 C2 통신은,
    UAV 컨트롤러와 UAV 사이의 PC5 참조 포인트를 통해 수립한 직접 C2 링크를 의미하는 것을 특징으로 하는 방법.
  14. 제10항 내재 제13항 중 어느 한 항에 있어서,
    상기 직접 C2 통신을 수행하지 말 것을 알리는 정보를 상기 SMF로부터 수신하는 단계를 더 포함하는 방법.
  15. 무선 통신 시스템에서 동작하도록 구성되는 UE(User Equipment)에 있어서, 상기 UE는:
    하나 이상의 송수신기;
    하나 이상의 프로세서; 및
    명령어(instructions)를 저장하고 상기 하나 이상의 프로세서와 동작 가능하도록 연결될 수 있는 하나 이상의 메모리를 포함하며,
    상기 명령어가 상기 하나 이상의 프로세서에 의해서 실행되는 것을 기반으로 수행하는 동작은 제10항 내지 제14 항 중 어느 하나의 항에 따른 방법인 UE.
  16. 이동통신에서의 장치(apparatus)로서,
    적어도 하나의 프로세서; 및
    명령어(instructions)를 저장하고, 상기 적어도 하나의 프로세서와 동작가능하게(operably) 전기적으로 연결가능한, 적어도 하나의 메모리를 포함하고,
    상기 명령어가 상기 적어도 하나의 프로세서에 의해 실행되는 것에 기초하여 수행되는 동작은:
    직접(direct) Command and Control (C2) 통신을 위한 인증(authorization) 요청 정보를 Session Management Function (SMF)에게 전송하는 단계,
    상기 인증 요청 정보는, 상기 SMF가 인증 요청 메시지를 Uncrewed Aerial System (UAS) Service Supplier (USS)에게 전송하는데 사용되고; 및
    상기 SMF로부터 Uncrewed Aerial Vehicle (UAV) controller(UAV-C)의 어플리케이션 계층 ID를 수신하는 단계를 포함하고,
    상기 UAV-C의 어플리케이션 계층 ID는 상기 직접 C2 통신을 위한 인증이 성공적인 것에 기초하여, 상기 USS에 의해 상기 SMF를 통해 UE에게 전송된 것을 특징으로 하는 장치.
  17. 명령어들을 기록하고 있는 비일시적(non-transitory) 컴퓨터 판독가능 저장 매체(computer readable medium)로서,
    상기 명령어들은, 하나 이상의 프로세서들에 의해 실행될 때, 상기 하나 이상의 프로세서들로 하여금:
    직접(direct) Command and Control (C2) 통신을 위한 인증(authorization) 요청 정보를 Session Management Function (SMF)에게 전송하는 단계,
    상기 인증 요청 정보는, 상기 SMF가 인증 요청 메시지를 Uncrewed Aerial System (UAS) Service Supplier (USS)에게 전송하는데 사용되고; 및
    상기 SMF로부터 Uncrewed Aerial Vehicle (UAV) controller(UAV-C)의 어플리케이션 계층 ID를 수신하는 단계를 수행하도록 하고,
    상기 UAV-C의 어플리케이션 계층 ID는 상기 직접 C2 통신을 위한 인증이 성공적인 것에 기초하여, 상기 USS에 의해 상기 SMF를 통해 UE에게 전송된 것을 특징으로 하는 CRM.
PCT/KR2023/015402 2022-10-18 2023-10-06 직접 c2 인증 WO2024085512A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202263417283P 2022-10-18 2022-10-18
US63/417,283 2022-10-18
US202363443683P 2023-02-06 2023-02-06
US63/443,683 2023-02-06

Publications (1)

Publication Number Publication Date
WO2024085512A1 true WO2024085512A1 (ko) 2024-04-25

Family

ID=90737876

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/015402 WO2024085512A1 (ko) 2022-10-18 2023-10-06 직접 c2 인증

Country Status (1)

Country Link
WO (1) WO2024085512A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021163463A1 (en) * 2020-02-13 2021-08-19 Idac Holdings, Inc. Unmanned aerial vehicle authentication and authorization by unmanned aerial system traffic management over user plane
WO2021233548A1 (en) * 2020-05-20 2021-11-25 Lenovo (Singapore) Pte. Ltd. Managing a c2 communication mode for an unmanned aerial system
WO2022042830A1 (en) * 2020-08-26 2022-03-03 Lenovo (Singapore) Pte. Ltd. Managing the qos of an end-to-end application session
JP2022519564A (ja) * 2019-02-07 2022-03-24 アップル インコーポレイテッド ３ｇｐｐシステムにおける識別及び動作のためのｕａｓサービスの有効化
KR20220050937A (ko) * 2019-08-23 2022-04-25 아이디에이씨 홀딩스, 인크. 무인 항공기에 의해 네트워크에 엑세스하기 위한 인증 및 인가

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022519564A (ja) * 2019-02-07 2022-03-24 アップル インコーポレイテッド ３ｇｐｐシステムにおける識別及び動作のためのｕａｓサービスの有効化
KR20220050937A (ko) * 2019-08-23 2022-04-25 아이디에이씨 홀딩스, 인크. 무인 항공기에 의해 네트워크에 엑세스하기 위한 인증 및 인가
WO2021163463A1 (en) * 2020-02-13 2021-08-19 Idac Holdings, Inc. Unmanned aerial vehicle authentication and authorization by unmanned aerial system traffic management over user plane
WO2021233548A1 (en) * 2020-05-20 2021-11-25 Lenovo (Singapore) Pte. Ltd. Managing a c2 communication mode for an unmanned aerial system
WO2022042830A1 (en) * 2020-08-26 2022-03-03 Lenovo (Singapore) Pte. Ltd. Managing the qos of an end-to-end application session

Similar Documents

Publication Publication Date Title
WO2021034093A1 (ko) 릴레이를 위한 인증
WO2021029512A1 (ko) 어플리케이션 서버의 변경에 관련된 통신
WO2020184956A1 (ko) 멀티 액세스 프로토콜 데이터 유닛 세션 관리
WO2021241905A1 (ko) 로밍 네트워크에서 네트워크 슬라이스 별 인증 실패 시 효율적인 plmn 선택
WO2017138757A1 (ko) 무선 통신 시스템에서 다수의 통신 장치들을 이용하여 데이터를 송수신하기 위한 방법 및 이를 지원하는 장치
WO2021015598A1 (ko) 복수의 sim에 기초한 통신
WO2021049841A1 (ko) 비-3gpp 상의 ims 음성 세션을 3gpp 액세스로 이동시키기 위한 방안
WO2021096193A1 (ko) 릴레이 통신
WO2021025428A1 (ko) 복수의 sim에 기초한 발신자 정보 확인
WO2021040463A1 (ko) 3gpp ps data off에 관련된 통신
WO2021125691A1 (ko) 통신 경로 스위칭
WO2020218807A1 (ko) Ma pdu 세션을 위한 pmf 지원 방안
WO2022014981A1 (ko) 재난 상황 종료시 서비스 연속성을 지원하는 방법 및 이를 지원하는 장치
WO2021066346A1 (ko) 비-3gpp 상의 pdu 세션을 3gpp 액세스로 이동시키기 위한 방안
WO2021025308A1 (ko) 다중 usim을 지원하기 위한 amf의 처리 방안
WO2022215909A1 (ko) Pdu 세션 관리 방법
WO2021194214A1 (ko) 서비스 연속성을 위한 n14 인터페이스 지원 지시자
WO2020251226A1 (ko) 5g 이동통신 시스템에서 npn에 접속하는 방법 및 사용자 장치
WO2022225262A1 (ko) 중복(redundant) 전송을 위한 중복(redundant) pdu 세션관리 방법
WO2022211519A1 (en) A method for measuring performance for qos
WO2022005207A1 (ko) 멀티캐스트에 의한 통신 방법
WO2022071673A1 (ko) 소스 네트워크와 타겟 네트워크 사이에 n14 인터페이스가 없는 경우 홈 라우팅 된 pdu 세션에 대한 서비스 연속성 지원
WO2022014980A1 (ko) 재난 상황 종료시 서비스 연속성을 지원하기 위한 ui/ux 표시 방법 및 이를 지원하는 장치
WO2021167233A1 (ko) 네트워크 슬라이스와 관련된 통신
WO2022035257A1 (ko) 네트워크 오류 또는 시간 경과로 인한 nssaa 실패의 처리