Method and apparatus for performing authorization for unmanned aircraft system service in a wireless communication system

Abstract

A communication scheme for converging IoT technology and a 5G communication system supporting a high data transmission rate beyond 4G systems and a system thereof are disclosed. The disclosure can be applied to intelligent services (e.g., services related to smart home, smart building, smart city, smart car, connected car, health care, digital education, retail business, security and safety, etc.) based on 5G communication technology and IoT-related technology. A method of performing authorization related to unmanned aerial system (UAS) services in a wireless communication system is disclosed.

Description

Technical Field

[0001] An unmanned aerial system (UAS) refers to a combination of an unmanned aerial vehicle (UAV) and a UAV controller (UAVC). A network device that performs UAS traffic management (UTM) functions provides UAS identification, UAS tracking, and authorization, enforcement, and regulation of UAS operations, and stores the information required for UAS operations.

[0002] This disclosure relates to wireless communication networks, and more specifically, to providing communication between UAV and UAVC and between UAS and UTM via 3GPP networks (5GS or 5G systems). Background Technology

[0003] To meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems, efforts have been made to develop improved 5G or near-5G communication systems. For this reason, 5G or near-5G communication systems are referred to as super-4G network communication systems or post-LTE systems. To achieve high data transmission rates, the implementation of 5G communication systems in millimeter-wave bands (e.g., the 60GHz band) is being considered. In 5G communication systems, technologies such as beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO are being discussed, aiming to reduce propagation path loss and increase propagation distance in the millimeter-wave band. Furthermore, technologies such as evolved small cells, advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), and interference cancellation have been developed to improve system networks. In addition, 5G systems have developed advanced coding and modulation (ACM) schemes, such as hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC), as well as advanced access technologies, such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA).

[0004] Meanwhile, the internet has evolved from a human-centric connectivity network (where people generate and consume information) to the Internet of Things (IoT), in which distributed components, such as objects, exchange and process information. The Internet of Everything (IoE) technology, combining big data processing technologies with IoT technologies through connections to cloud servers, has emerged. To realize IoT, technological factors such as sensing technologies, wired / wireless communications, network infrastructure, service interface technologies, and security technologies are required. Recently, technologies such as sensor networks for connecting objects, machine-to-machine (M2M) communication, and machine-type communication (MTC) have been researched. In the IoT environment, by collecting and analyzing data generated in connected objects, intelligent internet technology (IT) services that create new value in people's lives can be provided. IoT can be applied to areas such as smart homes, smart buildings, smart cities, smart cars, connected cars, smart grids, healthcare, smart appliances, and high-tech medical services through the integration of traditional information technology (IT) and various industries.

[0005] Therefore, various attempts are underway to apply 5G communication to IoT networks. For example, 5G communication technologies such as sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) are implemented using beamforming, MIMO, and array antenna schemes. Cloud RAN, as an application of big data processing technology, is an example of the convergence of 5G and IoT technologies.

[0006] The above information is presented as background information only to aid in understanding this disclosure. No determination or assertion is made regarding whether any of the above content can be applied to this disclosure as prior art. Summary of the Invention

[0007] Technical issues

[0008] A method is provided to efficiently send UAS information of UAV or UAVC as network-level information to UTM for use in verifying application-level information.

[0009] Solution to the problem

[0010] In a wireless communication system according to various embodiments, a method is provided in which a UE (UAV / UAVC) transmits application-level information through a control plane (CP), and the network transmits 3GPP network-level information simultaneously (transmitted concurrently) or continuously (cascaded) through the control plane (CP).

[0011] In a wireless communication system according to various embodiments, a method is provided in which the UAV transmits application-level information through the user plane (UP) using a public key between the UE (UAV) and the network, and the network simultaneously or continuously transmits 3GPP network-level information through the control plane (CP).

[0012] According to embodiments of this disclosure, a method for authorizing services to an unmanned aerial system (UAS) in a wireless communication system, performed by an Access and Mobility Management Function (AMF) entity, includes: authenticating a terminal based on the terminal's registration process with the network; determining whether the terminal needs to authenticate for the UAS service based on the terminal's subscription information; and, if the terminal needs to authenticate for the UAS service, providing the terminal's service-level identity and network-level identity to a server used to manage the UAS service.

[0013] According to embodiments of this disclosure, a method for authorizing unmanned aerial vehicle system (UAS) services performed by a session management function (SMF) entity in a wireless communication system includes: receiving a first request for flight authorization of a terminal authenticating for UAS services from an access and mobility management function (AMF) entity, and sending a second request for flight authorization of the terminal to a server for managing UAS services, the second request including the terminal's service-level identity, network-level identity, and location information.

[0014] According to embodiments of this disclosure, an Access and Mobility Management Function (AMF) entity for authorized UAS services in a wireless communication system includes a transceiver and a controller coupled to the transceiver. The controller is configured to control the following: performing authentication of a terminal based on the terminal's registration process with the network; determining whether the terminal needs authentication for the UAS service based on the terminal's subscription information; and, if the terminal needs authentication for the UAS service, providing the terminal's service-level identity and network-level identity to a server for managing the UAS service.

[0015] According to embodiments of this disclosure, a Session Management Function (SMF) entity for authorizing Unmanned Aircraft System (UAS) services in a wireless communication system includes a transceiver and a controller coupled to the transceiver. The controller is configured to control the reception of a first request for flight authorization of a terminal authenticating for UAS services from an Access and Mobility Management Function (AMF) entity, and to send a second request for flight authorization of the terminal to a server for managing UAS services. The second request includes the terminal's service-level identity, network-level identity, and location information.

[0016] Before proceeding with the detailed embodiments below, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “comprising” and “including” and their derivatives denote non-limiting inclusion; the term “or” is inclusive, indicating and / or; the phrases “associated with” and “associated with” and their derivatives may denote including, being included, interconnected with, containing, being contained, connected to or connected to, coupled to or coupled to, able to communicate with, cooperate with, intertwine, juxtapose, proximate, bound to or bound to, having, having the properties of, etc.; and the term “controller” means any device, system or part thereof that controls at least one operation, such device may be implemented in hardware, firmware or software or some combination of at least two of hardware, firmware or software. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether local or remote.

[0017] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed by computer-readable program code and contained in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable medium includes media that can permanently store data and media that can store data and subsequently overwrite it, such as rewritable optical discs or erasable memory devices.

[0018] This patent document provides definitions for certain words and phrases, and those skilled in the art should understand that, in many (if not most) cases, such definitions apply to the prior and future use of the words and phrases defined in this way.

[0019] Beneficial effects of the invention

[0020] This disclosure simplifies the process of sending information related to the UAS and reduces the latency between the information related to the UAS and the information sent from the network. Therefore, network devices performing UTM can reduce the latency of verifying information related to the UAS based on information sent from the network.

[0021] In the verification of location information, the reduction of the time delay between information increases the accuracy. Therefore, UTM can manage the location of UAVs more accurately. Attached Figure Description

[0022] To gain a more complete understanding of this disclosure and its advantages, reference is now made to the following description in conjunction with the accompanying drawings, wherein like reference numerals denote like parts:

[0023] Figure 1A illustrates the 5G system architecture;

[0024] Figure 1B illustrates the non-roaming reference architecture for location services;

[0025] Figure 1C This illustrates a roaming reference architecture for location services;

[0026] Figure 2A illustrates the traditional information transmission process;

[0027] Figure 2B illustrates the information transmission process according to various embodiments;

[0028] Figure 3 The process of transmitting application-level information and 3GPP network-level information through the control plane (CP) according to various embodiments is illustrated;

[0029] Figure 4 The process is illustrated according to various embodiments, in which the UE uses the generated public key to send application-level information through the user plane (UP) and 3GPP network-level information through the CP;

[0030] Figure 5 The process is illustrated according to various embodiments, in which the network uses the generated public key to send application-level information via UP and 3GPP network-level information via CP;

[0031] Figure 6A illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments;

[0032] Figure 6B illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments;

[0033] Figure 6C illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments;

[0034] Figure 6D illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments;

[0035] Figure 7A illustrates an embodiment of a regulatory method in a UAS service scenario according to various embodiments;

[0036] Figure 7B illustrates an embodiment of the regulatory method in a UAS service scenario according to various embodiments;

[0037] Figure 7C illustrates an embodiment of a regulatory method in a UAS service scenario according to various embodiments;

[0038] Figure 8A illustrates an embodiment of a method for sending identifiers (IDs) or other information via local broadcast between UAVs in a UAS service scenario according to various embodiments;

[0039] Figure 8B illustrates an embodiment of a method for sending identifiers (IDs) or other information via local broadcast between UAVs in a UAS service scenario according to various embodiments;

[0040] Figure 9 The initial network access process in a UAS service scenario according to various embodiments is illustrated;

[0041] Figure 10 The UAS identity authentication process in various UAS service scenarios is illustrated.

[0042] Figure 11 This illustrates the UAV flight planning authentication process in UAS service scenarios according to various embodiments;

[0043] Figure 12 The process of identifying UAS location information for the UAV flight planning authorization process in a UAS service scenario according to various embodiments is illustrated.

[0044] Figure 13 The process of authenticating additional UTM services in a UAS service scenario according to various embodiments is illustrated;

[0045] Figure 14 The process of identifying the location information of the UAS during the authentication process of the attached UTM service is illustrated in a UAS service scenario according to various embodiments;

[0046] Figure 15 This illustrates the enhanced process for application supervision in UAS service scenarios according to various embodiments;

[0047] Figure 16 The process of identifying the UAS location in an enhanced process for application monitoring is illustrated in various UAS service scenarios according to different embodiments;

[0048] Figure 17 The process of sending proximity-based service (ProSe) configuration information to a UTM for ID broadcasting and broadcast communication in a UAV service scenario according to various embodiments is illustrated.

[0049] Figure 18 This is a flowchart illustrating the process by which a network device in a wireless communication system performs Unmanned Aircraft System (UAS) traffic management (UTM) functions according to various embodiments;

[0050] Figure 19 This is a flowchart illustrating the process by which a UE transmits information from an unmanned aerial system (UAS) in a wireless communication system;

[0051] Figure 20 This is a flowchart illustrating the process by which a UE transmits information from an unmanned aerial system (UAS) in a wireless communication system;

[0052] Figure 21 This is a block diagram illustrating a network device performing UAS traffic management (UTM) functions according to various embodiments; and

[0053] Figure 22 This is a block diagram illustrating a user equipment (UE) according to various embodiments. Detailed Implementation

[0054] The following discussion covers Figures 1A to 1B. Figure 22 The various embodiments used to describe the principles of this disclosure in this patent document are merely exemplary and should not be construed in any way as limiting the scope of this disclosure. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0055] The advantages and features of this disclosure, as well as methods of implementing it, will become clear from the accompanying drawings and embodiments described in detail below. However, this disclosure is not limited to the embodiments described below and can be implemented in various different forms. The embodiments are provided to complete the disclosure and fully inform those skilled in the art of its scope, and the disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals denote the same elements.

[0056] It will be understood that each block and combination of flowchart illustrations can be implemented by computer program instructions. These computer program instructions can be loaded onto the processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create parts for implementing the functions specified in one or more flowchart blocks. These computer program instructions can also be stored in a computer-readable storage medium, which can direct the computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in a computer-usable or computer-readable storage medium produce an article of art including instructions for implementing the functions specified in one or more flowchart blocks. Computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable data processing apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable data processing apparatus, provide steps for implementing the functions specified in one or more flowchart blocks.

[0057] In this respect, each block can represent a module, code segment, or code section, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in a block may appear out of order. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved.

[0058] The term "unit" as used in these embodiments refers to a software or hardware component, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and a "unit" can function. However, a "unit" is not limited to software or hardware. A "unit" can be configured to reside in an addressable storage medium or to run on one or more processors. Thus, for example, a "unit" includes software components, object-oriented software components, components such as class components and task components, processors, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. The components and functions provided in a "unit" can be combined into a smaller number of components and "units" or divided into a larger number of components and "units." Furthermore, components and "units" can be implemented to run on one or more CPUs in a device or secure multimedia card. In these embodiments, a "unit" may include one or more processors.

[0059] The operating principles of this disclosure will be described in detail below with reference to the accompanying drawings. In describing this disclosure below, detailed descriptions of relevant known configurations or functions incorporated herein will be omitted where it is determined that such detailed descriptions may unnecessarily obscure the subject matter of this disclosure. The terminology used below is defined with reference to the functions in this disclosure and may vary depending on the user, the user's intent, or habit. Therefore, the definition of terminology should be based on the entire contents of this specification.

[0060] For ease of description, the following description uses terms for identifying access nodes, terms relating to network entities, terms relating to messages, terms relating to interfaces between network entities, and terms relating to each piece of identification information. Therefore, this disclosure is not limited to the terms provided below, and other terms indicating subjects with equivalent technical meanings may be used.

[0061] The UE may include user equipment (UE), mobile station (MS), cellular phone, smartphone, computer, multimedia system capable of performing communication functions, or unmanned aerial vehicle / UAV controller (UAVC). Of course, this disclosure is not limited thereto.

[0062] For ease of description, this disclosure uses the terms and names defined in the 5GP and NR standards, which are the latest standards among existing communication standards defined by the Third Generation Partnership Project (3GPP). However, this disclosure is not limited to the terms and names and can be applied equivalently to wireless communication networks conforming to other standards. Specifically, this disclosure can be applied to 3GPP 5GS / NR (the fifth-generation mobile communication standard).

[0063] The specific terminology used in the following description is provided to aid in understanding this disclosure, and the use of such terminology may be modified to other forms without departing from the technical spirit of this disclosure.

[0064] First, the terminology used in this specification will be defined.

[0065] Figure 1A illustrates the 5G system architecture.

[0066] For ease of description, terms used in the following description to identify access nodes, network entities, messages, interfaces between network entities, and individual pieces of identification information are used. Therefore, this disclosure is not limited to the terms provided below, and other terms indicating subjects with equivalent technical meanings may be used.

[0067] For ease of description, this disclosure uses the terms and names defined in the 3GPP Long Term Evolution (LTE) and New Radio (NR) standards. However, this disclosure is not limited to the foregoing terms and names and may be applied equivalently to systems based on other standards.

[0068] In this specification, a base station (BS) is a terminal node of a network that communicates directly with the UE. Specific operations performed by the BS can also be performed by its superior nodes. That is, it is clear that various operations performed to communicate with the UE in a network comprising multiple network nodes (including the BS) can be performed by the BS or by network nodes other than the BS. A "base station (BS)" may also be referred to as a "fixed station," "node B," "evolved node B (eNB)," "base transceiver system (BTS)," or "access point (AP)." A "terminal" can be fixed or portable and may also be referred to as a "user equipment (UE)," "mobile station (MS)," "user terminal (UT)," "mobile subscriber station (MSS)," "subscriber station (SS)," "advanced mobile station (AMS)," "wireless terminal (WT)," "machine-type communication (MTC) equipment," "machine-to-machine (M2M) equipment," and "device-to-device (D2D) equipment."

[0069] In the following text, downlink (DL) refers to communication from the BS to the UE, and uplink (UL) refers to communication from the UE to the BS. In the downlink, the transmitter can be part of the BS, and the receiver can be part of the UE. In the uplink, the transmitter can be part of the UE, and the receiver can be part of the BS.

[0070] The specific terminology used in the following description is provided to aid in understanding this disclosure, and the use of the specific terminology may be changed to other forms without departing from the technical spirit of this disclosure.

[0071] The embodiments may be supported by standard documents disclosed in at least one of IEEE 802, 3GPP, and 3GPP2 for wireless access systems. That is, steps or portions not described in the embodiments may be supported by these documents in order to clearly illustrate the technical concepts of this disclosure. Furthermore, all terms disclosed in this document may be defined as described in the standard documents.

[0072] For clarity, the following description is based on the 3GPP fifth generation (5G) system, but the technical features of this disclosure are not limited thereto.

[0073] The terms used in this document can be defined as follows.

[0074] - Evolved Packet System (EPS): Refers to network systems including Evolved Packet Core (EPC), LTE, and UTRAN. Evolved Packet Core (EPC) is a packet-switched core network based on Internet Protocol (IP), and UTRAN is an evolution network of Universal Mobile Telecommunications System (UMTS).

[0075] -eNodeB: refers to the BS of the EPS network, which is installed outdoors and its coverage area is a macro cell.

[0076] - International Mobile Subscriber Identity (IMSI): Refers to a unique user identity assigned internationally by a mobile communication network.

[0077] - Public Land Mobile Network (PLMN): Refers to a network configured to provide mobile communication services to individuals, which can be divided for each operator.

[0078] -5G System (5GS): Refers to a system that includes a 5G access network (AN), a 5G core network, and user equipment (UE).

[0079] -5G Access Network (5G-AN) (or AN): refers to access networks that include next-generation radio access networks (NG-RAN) connected to the 5G core network and / or non-3GPP AN (non-5G access network).

[0080] - Next Generation Radio Access Network (NG-RAN) (or RAN): refers to a radio access network that shares the common feature of connectivity to 5GC and supports one or more of the following options:

[0081] 1) Independent new radio,

[0082] 2) A new radio serving as an anchor for supporting E-UTRA extensions.

[0083] 3) Standalone E-UTRA (e.g., eNodeB),

[0084] 4) Anchors that support new radio extensions.

[0085] -5G Core Network (5GC): Refers to the core network connected to the 5G access network.

[0086] - Network Function (NF): Refers to the processing functions adopted or defined by 3GPP within a network, which include defined functional behaviors and interfaces defined in 3GPP.

[0087] -NF Service: Refers to the functionality exposed by an NF through a service-based interface and consumed by other certified NFs.

[0088] - Network slice: refers to a logical network that provides specific network capabilities and characteristics.

[0089] - Network slice instance: refers to the set of NF instances that represent the network slices configured and the required resources (e.g., compute, storage, and networking resources).

[0090] - Protocol Data Unit (PDU) Connection Service: Refers to the service that provides PDU exchange between the UE and the data network.

[0091] -PDU connectivity service: refers to the service that provides PDU exchange between the UE and the data network.

[0092] -PDU session: refers to the association between the UE and the data network that provides PDU connection services. The association type can be Internet Protocol (IP), Ethernet, or unstructured.

[0093] - Non-access stratum (NAS): refers to the functional layer in the EPS and 5GS protocol stack used to exchange signaling and traffic messages between the UE and the core network. Its main function is to support the UE's mobility and session management process.

[0094] 5G systems are an evolution of fourth-generation LTE mobile communication technology and support extended LTE (eLTE) and non-3GPP (e.g., wireless local area network (WLAN)) access as new radio access technologies (RAT) that evolve through traditional mobile communication network structures or clean-state structures and as extensions of Long Term Evolution (LTE).

[0095] 5G systems are defined based on services, and the interactions between network functions (NFs) within a 5G system architecture can be indicated in two types.

[0096] - Reference point representation: Indicates the interaction between NF services within an NF described by a point-to-point reference point (e.g., N11) between two NFs (e.g., AMF and SMF).

[0097] - Service-based representation: Network functions within the control plane (CP) (e.g., AMF) allow other authenticated network functions to access their services. This representation includes the necessary point-to-point reference points.

[0098] Reference point representations can be used to indicate the 5G system architecture to which this disclosure can be applied.

[0099] The 5G system architecture can include various components, namely, network functions (NFs), and Figure 1 shows some of the functions corresponding to the authentication server function (AUSF), (core) access and mobility management function (AMF), session management function (SMF), policy control function (PCF), application function (AF), unified data management (UDM), data network (DN), user plane function (UPF), (radio) access network ((R)AN), and user equipment (UE).

[0100] The corresponding NF supports the following functions.

[0101] -AUSF stores the data used to authenticate UEs.

[0102] -AMF can provide access and manage mobility on a UE-by-UE basis, and each UE can essentially connect to one AMF.

[0103] Specifically, the AMF supports various functions such as signaling between CN nodes moving between 3GPP access networks, termination of the Radio Access Network (RAN) CP interface (i.e., N2 interface), termination of NAS signaling (N1), NAS signaling security (NAS encryption and integrity protection), AS security control, registration management (registration area management), connection management, idle mode UE reachability (including paging retransmission control and execution), mobility management control (subscription and policies), support for intra-system mobility and inter-system mobility, support for network slicing, SMF selection, lawful interception (for AMF events and interfaces to LI systems), provision of session management (SM) message transmission between UE and SMF, transparent proxy for SM message routing, access authentication, access authorization including roaming permission checks, provision of SMS message transmission between UE and SMF, Security Anchor Function (SAF), and / or Security Context Management (SCM).

[0104] Some or all of the functionality of AMF can be supported in a single instance of AMF.

[0105] -DN can be an operator service, internet access, or third-party service. DN sends downlink protocol data units (PDUs) to the UPF or receives PDUs sent by the UE from the UPF.

[0106] The PCF receives information about packet flows from the application server and provides the functionality to determine policies for mobility management and session management. Specifically, the PCF supports the following functions: supporting a unified policy framework for controlling network operations, providing policy rules to allow CP functions (e.g., AMF, SMF, etc.) to enforce policy rules, and implementing a front-end for accessing relevant subscription information to determine policies within the User Data Storehouse (UDR).

[0107] -SMF can provide session management functions, and if the UE has multiple sessions, the corresponding sessions can be managed by different SMFs.

[0108] Specifically, the SMF supports the following functions: session management (e.g., establishing, modifying, and releasing sessions including the maintenance of tunnels between UPF and AN nodes), allocating and managing UE IP addresses (including selective authentication of UE IP addresses), selecting and controlling UP functions, configuring traffic redirection to route traffic from UPF to appropriate destinations, terminating interfaces for policy control functions, attempting the control portion of policies and Quality of Service (QoS), lawful interception (for SM events and LI system interfaces), terminating the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information (sending N2 to AN via AMF), determining the SSC mode of a session, and roaming.

[0109] Some or all of the functionality of SMF can be supported in a single instance of SMF.

[0110] - The UDM stores user subscription data and policy data. The UDM consists of two parts: the application front-end (FE) and the user data repository (UDR).

[0111] The FE includes the UDM-FE for handling location management, subscription management, and credentials, and the PCF for controlling policies. The UDR stores the data required for the functions provided by the UDM-FE and the policy profiles required by the PCF. The data stored in the UDR includes user subscription data and policy data, including subscription IDs, security credentials, access and mobility-related subscription data, and session-related subscription data. The UDM-FD supports functions such as accessing subscription information stored in the UDR, processing authentication certificates, processing user identities, authentication, registering access / managing mobility, managing subscriptions, and managing SMS.

[0112] -UPF transmits downlink PDUs received from DN to UE via (R)AN, and transmits uplink PDUs received from UE to DN via (R)AN.

[0113] Specifically, the UPF supports the following functions: anchor points for intra / inter-RAT mobility, external PDU session points for interconnecting with the data network, packet routing and forwarding, user plane components for attempting packet inspection and policy rules, lawful interception, reporting traffic usage, uplink classifiers to support routing traffic flows to the data network, branch points to support multi-homed PDU sessions, handling user plane QoS (e.g., packet filtering, gating, uplink / downlink rates), uplink traffic authentication (SDF mapping between Serving Data Flows (SDFs) and QoS flows), tagging transport-level packets within uplink and downlink, buffering downlink packets, and triggering downlink data notifications. Some or all of the UPF's functions can be supported in a single instance of a UPF.

[0114] -AF interoperates with the 3GPP core network to provide services (e.g., support for applications that affect traffic routing, exposure of access network capabilities, and interaction with policy frameworks used for control policies).

[0115] -(R)RAN stands for New Radio Access Network, which supports both Evolved UTRA (E-UTRA), an evolution of 4G radio access technology, and New Radio (NR) access technologies (such as gNB). In the attached diagram, NR-RAN refers to a radio access network that supports New Radio Access (NR) technology.

[0116] The gNB supports the following functions: managing radio resources (i.e., radio bearer control, radio admission control, connection mobility control, dynamic resource allocation to the UE in uplink / downlink (i.e., scheduling), compressing Internet Protocol (IP) headers, encrypting user data streams and performing integrity protection, selecting the AMF in the UE annex when no route to the AMF is determined based on the information provided to the UE, user plane data routing to the UPF, control plane information routing to the AMF, setting up and releasing connections, scheduling and sending paging messages (generated from the AMF), scheduling and sending system broadcast messages (generated from Operations and Maintenance (O&M)), performing mobility measurements and scheduling and configuring measurement reports, transport-level packet marking in the uplink, managing sessions, supporting network slicing, managing QoS streams and performing mapping to data radio bearers, supporting UEs in inactive mode, distributing NAS messages, selecting NAS nodes, sharing radio access networks, dual connectivity, and tight interoperability between NR and E-UTRA.

[0117] -UE refers to User Equipment. UE can be an unmanned aerial vehicle (UAV) / UAV controller (UAVC), terminal, mobile device (ME), mobile station (MS), etc. Furthermore, UE can be a portable device, such as a laptop, mobile phone, personal digital assistant (PDA), smartphone, or multimedia device, or it can be a non-portable device, such as a personal computer (PC) or in-vehicle equipment.

[0118] In the specification, the Unstructured Data Storage Network Function (UDSF), Structured Data Storage Network Function (SDSF), Network Exposure Function (NEF), and NF Repository Function (NRF) can interact with UDSF, NEF, and NRF as needed.

[0119] - The NEF provides components for, for example, third-party, internal / repeated exposure, application functions, and for securely exposing edge computing services and capabilities provided by 3GPP network functions. The NEF (Exposed Based on Other Network Functions) receives information from other network functions. The NEF can store the received information as structured data through an interface standardized as a data storage network function. The stored information can be re-exposed by the NEF to other network functions and application functions, and can be used for other purposes, such as analysis.

[0120] - NRF supports service discovery functionality. NRF receives NF discovery requests from NF instances and provides the NF instances with information about the discovered NF instances. Furthermore, NRF maintains a list of available NF instances and the services they support.

[0121] -SDSF is an optional feature used to support the storage and retrieval of information in any NEF-structured data format.

[0122] -UDSF is an optional feature used to support the storage and retrieval of information in the form of unstructured data from NF.

[0123] Meanwhile, for ease of description, the specification shows a reference model in the case where the UE accesses a DN through a PDU session, but this disclosure is not limited thereto.

[0124] A UE can simultaneously access two (i.e., local and central) data networks through multiple PDU sessions. In this case, two SMFs can be selected for different PDU sessions. However, each SMF can have the ability to control both the local UPF and the central UPF within a PDU session.

[0125] In addition, the UE can access two (i.e., local and central) data networks simultaneously in a single PDU session.

[0126] In the 3GPP system, the conceptual link connecting NFs within a 5G system is defined as a reference point. The reference points included in the 5G system architecture are listed below.

[0127] -N1: Reference point between UE and AMF

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

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

[0130] -N4: Reference point between SMF and UPF

[0131] -N5: Reference point between PCF and AF

[0132] -N6: Reference point between UPF and data network

[0133] -N7: Reference point between SMF and PCF

[0134] -N24: Reference point between the PCF within the surveyed network and the PCF within the home network.

[0135] -N8: Reference point between UDM and AMF

[0136] -N9: Reference point between the two core UPFs

[0137] -N10: Reference point between UDM and SMF

[0138] -N11: Reference point between AMF and SMF

[0139] -N12: Reference point between AMF and AUSF

[0140] -N13: Reference point between UDM and Authentication Server Functionality (AUSF)

[0141] -N14: Reference point between the two AMFs

[0142] -N15: Reference point between PCF and AMF in non-roaming scenarios, and reference point between PCF and AMF within the surveyed network in roaming scenarios.

[0143] -N16: Reference point between two SMFs (reference point between the SMF in the visited network and the SMF in the home network in a roaming scenario)

[0144] -N17: Reference point between AMF and EIR

[0145] -N18: Reference point between any NF and UDSF

[0146] -N19: Reference point between NEF and SDSF

[0147] Wireless communication systems according to various embodiments may include the 5GS LCS architecture described in the architecture reference model in Section 4.2 of 3GPP TS 23.273.

[0148] Figure 1B shows the non-roaming reference architecture for location services. Figure 1C Shows the roaming reference for location services.

[0149] Figure 1B and Figure 1C The 5G architecture shown may also include LMF and GMLC.

[0150] Table 1 shows GMLC, LMF, and AMF, which are shown in Figure 1B and... Figure 1C NF is shown in the figure.

[0151] Table 1

[0152]

[0153]

[0154]

[0155] According to various embodiments, UAS refers to a combination of UAV and UAVC. A UAV is an aircraft without an onboard human pilot, controlled by a ground-based UAVC, and sometimes has a predetermined automatic navigation function.

[0156] The 3GPP network can provide communication between UAVs and UAVCs. The 3GPP network provides all communication for command and control (C2) between UAVs and UAVCs, as well as communication for uplink / downlink data between the UAS and the 3GPP network or network server.

[0157] A network device that performs UAS traffic management (UTM) provides UAS identification, UAS tracking, and authorization, enforcement, and oversight of UAS operations. The UTM is used to store the data required for UAS operations.

[0158] When a request is received from an authorized user, such as an air traffic control organization or a public safety-related organization, the network device performing UTM can provide the ID or metadata of the UAV or UAVC. For example, a network device performing UTM could be an example of a network device performing an Application Function (AF). AFs, according to various embodiments, interoperate with the 3GPP core network to provide services (e.g., supporting applications that influence traffic routing, access network capability exposure, and interaction with policy frameworks used for control policies).

[0159] Network devices implementing UTM can receive the necessary information directly from UAV / UAVC or from the 3GPP network. Information received directly from the 3GPP network by UTM is guaranteed by the network operator and is therefore reliable. Thus, network devices implementing UTM can verify information received from UAV / UAVC (hereinafter referred to as application-level information) based on information received from the 3GPP network (hereinafter referred to as network-level information), thereby identifying whether the information is spoofed.

[0160] Application-level information includes GPS measurement locations taken by UAV or UAVC, and 3GPP network-level information includes cell reference measurement locations.

[0161] Figure 2A illustrates the traditional information transmission process.

[0162] As shown in Figure 2A, in S110, when the UAV / UAVC (UE) sends application-level information including GPS-based location information to the network device performing UTM (AF) via the 3GPP network in a conventional UAS, in S120, the network device performing UTM requests the location information of the UAV / UAVC (UE) from the 3GPP network to check the authenticity of the application-level information, and receives a response to the request in S130.

[0163] During this process, application-level information is transmitted between the UAV / UAVC and the network device performing UTM via the User Plane (UP), while network-level information is transmitted between the 3GPP network and the network device performing UTM via the Control Plane (CP). At this time, the network device performing UTM receives GPS_T0 as application-level information based on time T0 at time T2, and LCS_T3 as 3GPP network-level information based on time T3 at time T4.

[0164] As described above, using the conventional technique shown in Figure 2A, in step 1 (S100 and S110), the UAV / UAVC (UE) can send application-level information to the UTM (AF) via the 3GPP network through the UP. For example, the application-level information may include information related to the Global Positioning System (GPS).

[0165] Furthermore, to check the accuracy of the application-level information received from the UAV / UAVC (UE), the network device performing UTM (AF) can request 3GPP network-level information from the 3GPP network via the CP in step 2 (S120), and in response, receive the 3GPP network-level information in step 3 (S130). For example, the 3GPP network-level information may include information related to location services (LCS).

[0166] In other words, the network device performing UTM(AF) needs to perform the three-step process shown in Figure 2A (steps 1 to 3) in order to verify the application-level information based on the 3GPP network-level information. As a result, the information transmission process may be complex and may produce a delay between the application-level information and the 3GPP network-level information received by the network device performing UTM(AF).

[0167] Figure 2B illustrates the information transmission process according to various embodiments.

[0168] Methods for sending and receiving information in a UAS according to various embodiments are used to verify application-level information received by a network device performing a UTM (AF) from a UAV / UAVC (UE) via a network using 3GPP network-level information received from the network, and to reduce verification time by receiving application-level information and 3GPP network-level information simultaneously or continuously via the UTM.

[0169] Methods for sending and receiving information in a UAS according to various embodiments may include various methods for a network device performing UTM to simultaneously or continuously receive application-level information and 3GPP network-level information over a network.

[0170] As shown in Figure 2B, a network device performing UTM can simultaneously acquire GPS_T0, which is application-level information based on time T0, and LCS_T1, which is 3GPP network-level information based on time T1, at time T2.

[0171] Although the prior art shown in Figure 2A has a three-step process, the information transmission method according to the embodiment shown in Figure 2B can send reliable UAS information by only step 1 without steps 2 and 3, wherein the network device performing UTM(AF) requests 3GPP network-level information from the 3GPP network via CP and receives 3GPP network-level information in response.

[0172] For example, AF can be an external server or a server managed by the network operator. This depends on whether the network operator provides UTM services. In the comparison between Figure 2A and Figure 2B, in Figure 2B, the same information can be obtained by simply going through step 1 without going through steps 2 and 3 of Figure 2A.

[0173] In other words, the prior art shown in Figure 2A has a three-step process, but the method according to the embodiment shown in Figure 2B has only a one-step process, so the information transmission process is simpler than that of the prior art.

[0174] According to the prior art shown in Figure 2A, since application-level information is acquired at time T2 and 3GPP NW-level information is acquired at time T4, the final acquisition time of 3GPP network-level information and application-level information is time T4. However, in the information transmission method according to the embodiment shown in Figure 2B, since application-level information and NW-level information are acquired at time T2, 3GPP network-level information and application-level information can be acquired at time T2 (earlier than time T4).

[0175] When using the technology provided in Figure 2A, the reference time difference between application-level information and 3GPP network-level information can be reduced. When using the prior art shown in Figure 2A, the reference time for application-level information is time T0, and the reference time for 3GPP network-level information is time T3. Therefore, the reference time difference between the two pieces of information is T3 - T0, i.e., (D1 + 2 * D2). However, when using the technology provided in Figure 2B, the reference time for application-level information is time T0, and the reference time for 3GPP network-level information is time T1. Therefore, the reference time difference between the two pieces of information is T1 - T0, i.e., (1 * D1). For example, D1 is the delay between the 3GPP network and the UAS, which is a few milliseconds. However, since UTM communicates with multiple 3GPP networks, D2 is the delay between the 3GPP network and the server of the network device performing UTM, which is tens to hundreds of milliseconds.

[0176] In the case of location information, the reference time difference refers to the difference in location; therefore, the method provided in Figure 2B can verify location information more accurately compared to the prior art shown in Figure 2A. When the difference between 3GPP network-level location information (e.g., LCS) and application-level location information (e.g., GPS) is large, UAVs abuse this difference, and network devices performing UTM are highly likely to fly in areas that are preset as flight restricted zones.

[0177] The information transmission method according to this disclosure may include the three methods shown in Figure 2.

[0178] In Case 1 shown in Figure 2B, the UE (UAV / UAVC) directly adds application-level information to the CP-based process of sending 3GPP network-level information to network devices performing UTM.

[0179] For example, fields that include application-level information can be added to NAS messages, which are higher-level control plane messages.

[0180] As shown in Case 1 of Figure 2B, according to various embodiments, the UAV / UAVC (UE) can send an NW information request requesting 3GPP network-level information and application-level information to the 3GPP NW through the CP, and the 3GPP NW can simultaneously send a 3GPP network-level information response and application-level information corresponding to the received NW information request to the network device performing UTM through the CP.

[0181] In Case 2 shown in Figure 2B, the key generated by the UE is used by both the User Plane (UP) and the CP. The UP sends application-level information to the network device performing the AF, and the CP simultaneously or continuously sends 3GPP network-level information to the network device performing the AF.

[0182] Figure 2B shows the traffic for UP and CP separately to distinguish them, but UP and CP traffic can be sent simultaneously or continuously.

[0183] As shown in Case 2 of Figure 2B, according to various embodiments, the UAV / UAVC (UE) can use the generated public key to send application-level information to the 3GPP NW via UP and send a 3GPP-level information request to the 3GPP NW via CP. The 3GPP network can use the public key to send application-level information to the network device performing UTM via UP simultaneously or continuously and respond to the network device performing UTM with the 3GPP-level information request corresponding to the 3GPP-level information request via CP.

[0184] In Case 3 shown in Figure 2B, the UE is modified to insert a request for 3GPP network-level information into the process in which the UE sends application-level information to the 3GPP network through the Cellular Internet of Things (CIoT) 5GS optimization process of sending user traffic using the Non-Access Stratum (NAS), and the network receiving the message generates a public key, and simultaneously or continuously executes the UP traffic transmission process including application-level information and the CP traffic transmission process including 3GPP network-level information.

[0185] Figure 2B illustrates scenario 3, which utilizes the CP optimization process of CIoT. A method for transmitting application-level data (UP data) via CP to send small amounts of traffic has been defined, and functionality can be added to support LCS for simultaneously or continuously transmitting CP and UP tags / indicators.

[0186] Figure 2B shows the traffic of UP and CP respectively to divide them, but the traffic of UP and CP is sent simultaneously or continuously.

[0187] As shown in Case 3 of Figure 2B, according to various embodiments, the UAV / UAVC (UE) can send a Location Service Indicator (LCS Indicator) and application-level information to the 3GPP NW through the CP, and the 3GPP NW can use the generated key to send application-level information to the network device performing UTM simultaneously or continuously through the UP and send 3GPP network-level information responses to the network device performing UTM through the CP.

[0188] Figure 3 The process of sending application-level information and 3GPP network-level information through the control plane (CP) according to various embodiments is illustrated.

[0189] like Figure 3 As shown, a system according to various embodiments may include a UE, an NR-RAN, a network device that performs AMF (hereinafter referred to as AMF), a network device that performs LMF (hereinafter referred to as LMF), a network device that performs V-GMLC (hereinafter referred to as V-GMLC), a network device that performs H-GMLC (hereinafter referred to as H-GMLC), a network device that performs NEF (hereinafter referred to as NEF), and a network device that performs AF (UTM) (hereinafter referred to as AF(UTM)).

[0190] Figure 3 A method for sending application-level information and 3GPP network-level information together via CP using the 5GC-MO-LR procedure is shown.

[0191] In Operation 301, the UE (UAV / UAVC) establishes a radio connection to the network by sending a service request. This process can be omitted if the UE has already established a radio connection.

[0192] Operation 301: If the UE is in CM-IDLE state, the UE initiates a UE-triggered service request as defined in Clause 4.2.3.2 of TS 23.502

[19] in order to establish a signaling connection with the AMF.

[0193] For example, when the UE is in CM-IDLE state, the UE initiates a UE-triggered service request as defined in Clause 4.2.3.2 of TS 23.502

[19] in order to establish a signaling connection with the AMF.

[0194] In operation 302, the UE makes a Mobile Initiated Location Request (MO-LR) via an uplink (UL) NAS TRANSPORT message, and application-level information, such as the application ID (service-level ID) and application location (e.g., GPS-based UE location), is included in the NAS message.

[0195] Operation 302: The UE sends an MO-LR request message included in a UL NAS TRANSPORT message. The MO-LR request may optionally include an LPP location message. Different types of location services may be requested: UE location estimation, UE location estimation to be sent to an LCS client or AF, or location assistance data. If the UE is requesting its own location or sending its own location to an LCS client or AF, the message carries QoS information for the LCS request (e.g., accuracy, response time, LCS QoS class), the maximum age of the requested location, and the type of location requested (e.g., "current location," "current or last known location"). If the UE is requesting that its location be sent to an LCS client, the message may include the identity of the LCS client or AF and may include the address of the GMLC, through which the LCS client or AF can be accessed (via NEF). Additionally, it may include the service identity indicating which MO-LR service the UE is requesting from the LCS client. The message may also include a pseudonym indicator to indicate that the pseudonym can be assigned by the network and transmitted to the LCS client as the UE's identity. If the UE requests location assistance data instead, the embedded LPP message specifies the type of assistance data and the location method for applying the assistance data.

[0196] For an LCS 5GC-MO-LR requesting a location transfer to an LCS client or AF, the AMF can assign a GMLC address (V-GMLC address) stored in the AMF. If the V-GMLC address is unavailable, the AMF can reject the location request. The AMF verifies the UE's subscription profile and decides whether to allow the requested service.

[0197] In operation 303, AMF selects the desired location management function (LMF).

[0198] Operation 303: As described in Clause 5.1 of TS 23.273, AMF selects LMF.

[0199] In Operation 304, the AMF sends a location request to the LMF. At this point, the application ID and application location, as application-level information, may be included or omitted.

[0200] Operation 304: The AMF invokes the Nlmf_Location_DetermineLocation service operation to the LMF. The service operation includes the LCS-related identifier, serving cell identity, client type, indication of whether location estimation or location-aided data is requested, and any embedded LPP messages in the MO-LR request. If the UE's location is requested, the service request may include an indication of whether the UE supports LPP, the requested QoS, and the supported GAD shape. If location-aided data is requested, the embedded LPP message may convey the requested type of location-aided data. If any procedure in Clauses 6.11.1 or 6.11.2 of TS 23.273 is used, the service operation includes the AMF identity. Once the AMF selects an LMF, the AMF may continue to use that LMF for the duration of the session.

[0201] In operation 305, the LMF, AMF, RAN, and UE perform the UE positioning procedure as needed. This procedure varies depending on the required location accuracy and latency constraints.

[0202] Operation 305: If the UE is requesting its own location, the action described in Clause 6.11 is performed. If the UE requests location assistance data instead, the LMF transmits the data to the UE as described in Clause 6.11.1 of TS 23.273. The LMF determines the exact location assistance data to transmit based on the data type specified by the UE, the UE's location capabilities, and the current cell.

[0203] In operation 306, the LMF sends information to the AMF based on the required location accuracy and latency constraints. Similar to operation 304, the application ID and application location may be included or omitted in this process.

[0204] Operation 306: When a location estimate that best satisfies the requested QoS has been obtained, or when the requested location assistance data has been transmitted to the UE, the LMF returns an Nlmf_Location_DetermineLocation response to the AMF. The service operation includes the LCS-related identifier, the location estimate (if obtained), the duration and accuracy of the location estimate, and may include information about the positioning method.

[0205] If a location estimate is not successfully obtained, or if the requested location assistance data cannot be successfully transmitted to the UE, the failure reason is included in the service operation.

[0206] In Operation 307, the AMF sends an Ngmlc_Location_LocationUpdateNotify request to the Gateway Mobile Location Center (GMLC). At this point, the application ID and application location may need to be included.

[0207] Operation 307: If a location estimate is successfully obtained, the AMF invokes the Ngmlc_Location_LocationUpdateNotify service operation to the V-GMLC allocated in Operation 302. The service operation carries the UE's identity, the event that triggered the location estimate (5GC-MO-LR) and the location estimate, the duration of the location estimate, the obtained accuracy indication, and the LCS QoS class requested by the target UE. Additionally, the service operation may include a pseudonym indicator, the LCS client's identity, AF ID, GMLC address, and the service identity specified by the UE (if available).

[0208] In roaming scenarios, during operation 308, the V-GMLC sends a message to the H-GMLC. In this case, the application ID and application location may need to be included.

[0209] Operation 308: If the UE did not request the transmission of its location to the LCS client or AF in Operation 302, then operations 308 to 311 are skipped. If the V-GMLC and H-GMLC are the same NF instance, this operation is skipped. Otherwise, the V-GMLC calls the Ngmlc_Location_LocationUpdateNotify service operation to the H-GMLC (the V-GMLC can query the UE's UDM to obtain the address of the H-GMLC), including the information received from the V-GMLC.

[0210] Although not shown in the figure, if Figure 3 A wireless communication system that includes an external client may include Operation 309a.

[0211] Operation 309a: If the pseudonym indicator is included in the MO-LR location information, the H-GMLC assigns a pseudonym to the UE. If the H-GMLC cannot access the identified LCS client, operations 309a and 410a are skipped. Otherwise, based on the LCS QoS class requested by the target UE, the GMLC transmits the location information to the LCS client, carrying the UE's identity or pseudonym, the event that caused the location estimation (5GC-MO-LR), the service identity (if available), the location estimation, and the duration of the location estimation. If the LCS QoS class requested by the UE is guaranteed, the GMLC sends the result to the LCS client only if the result has been indicated to satisfy the requested accuracy. If the LCS QoS class requested by the UE is best-effort, the GMLC sends any results received by the GMLC to the LCS client, with appropriate indication if the requested accuracy is not satisfied.

[0212] In Operation 309b-1, H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service request to NEF. At this point, the application ID and application location may need to be included.

[0213] Operation 309b-1: If the AF ID is included in step 1, the H-GMLC allocates a NEF address based on local configuration or via the NRF and invokes the Ngmlc_Location_LocationUpdateNotify service request to the NEF carrying the AF ID. The location information parameters sent in this service operation are the same as those in Operation 309a.

[0214] In Operation 309b-2, the NEF sends location information to the AF. At this point, the application ID and application location may need to be included.

[0215] Operation 309b-2: If the NEF cannot access the identified AF, then operations 309b-2 and 310b-1 are skipped. Otherwise, the NEF transmits the location information to the identified AF.

[0216] Although not shown in the figure, if Figure 3 The wireless communication system includes an external client, and may include operation 310a.

[0217] Operation 310a: If the LCS client (for temporary or permanent reasons) does not support MO-LR or cannot process UE location estimation—for example, the LCS client does not know the service identity, or the UE has not registered with the LCS client, or the LCS client does not have the corresponding UE data—then the LCS client can return a location information confirmation message with an appropriate error reason to the H-GMLC. Otherwise, the LCS client processes the location estimation according to the service identity and sends a signaling confirmation message to the GMLC or H-GMLC notifying that the UE location estimation has been successfully processed.

[0218] Subsequently, responses to the request message are sent to the NEF, H-GMLC, V-GMLC, AMF, and UE via operations 310b-1, 310b-2, 311, 312, and 313. In the non-roaming scenario, H-GMLC is V-GMLC, therefore operation 311 is omitted.

[0219] Operation 310b-1: If the AF cannot process the UE's location estimation, for example, if the UE is not registered with the AF or the AF does not have the corresponding data for the UE, the AF can return a location information confirmation message with an appropriate error reason to the NEF. Otherwise, the AF processes the location estimation according to the service identity and sends a signaling notification to the NEF that a location information confirmation message has been successfully processed for the UE's location estimation.

[0220] Operation 310b-2: NEF sends an Ngmlc_Location_LocationUpdateNotify service response with location information confirmation to H-GMLC.

[0221] Operation 311: If the V-GMLC and H-GMLC are the same NF instance, skip this operation. If the identified LCS client or AF is inaccessible, the H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the V-GMLC. Otherwise, the response may include an acknowledgment. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, or if not, include the corresponding error reason obtained in step 10. Additionally, the H-GMLC may log billing information for both the UE and interworking revenue charges.

[0222] Operation 312: If the V-GMLC receives MO-LR location information confirmation from the H-GMLC, and the identified LCS client or AF is inaccessible, the V-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the AMF. Otherwise, the response may include confirmation. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, and if not, include the corresponding error reason obtained in Operations 309 or 310. Furthermore, the V-GMLC may log billing information for both the UE and interworking revenue charges.

[0223] If the V-GMLC receives a LocationUpdateNotify request from the AMF, and the V-GMLC does not need to send it to any LCS client or AF, the V-GMLC can record the charging information for the UE and respond to the LocationUpdateNotify request to the AMF.

[0224] Operation 313: The AMF sends an MO-LR response message included in the DL NAS TRASPORT message. This response carries any location estimate requested by the UE, including an indication received from the E-SMLC regarding whether the obtained location estimate meets the requested accuracy, or an indication that the location estimate was successfully transmitted to the identified LCS client or AF. If the location estimate was successfully transmitted to the identified LCS client or AF, the MO-LR response message may specify whether the identified LCS client or AF has successfully processed the UE's location estimate; otherwise, it includes the corresponding error reason obtained in Operation 313. Additionally, the AMF may log billing information.

[0225] like Figure 3 As shown, the methods for sending and receiving information according to various embodiments may include application-level information, such as application ID and application location (e.g., GPS-based UE location), in messages sent by the UE to the AF via the CP.

[0226] For example, such as Figure 3 As shown, the application ID and application location can be sent by the UE to the AF (UTM) via CP-based messages sent by the UE through the AMF, GMLC and NEF.

[0227] Specifically, application-level information, such as application ID and application location (e.g., GPS-based UE location), can be included in the UL NAS TRASPORT message sent from the UE to the AMF, the application ID and application location can be included in the Ngmlc_Location_LocationUpdateNotify request message sent from the AMF to the GMLC, the application ID and application location can be included in the Ngmlc_Location_LocationUpdateNotify service request message sent from the GMLC to the NEF, and the application ID and application location can be included in the location information sent from the NEF to the AF (UTM).

[0228] In other words, the UE can send application-level information (e.g., application ID and application location) and 3GPP network-level information (e.g., location information) to the UTM simultaneously through messages sent to the AF via the CP.

[0229] Figure 4 The diagram illustrates a process, according to various embodiments, in which the UE uses the generated public key to send application-level information via the user plane (UP) and 3GPP network-level information via the CP.

[0230] The methods for sending and receiving information according to various embodiments can use a public key to simultaneously or continuously send application-level information and 3GPP network-level information to the UTM via UP and CP, respectively.

[0231] Figure 4 An example is shown where the public key is generated by the UE. Figure 5 An example of a case where a public key is generated by NW is shown.

[0232] Figure 4 The process is illustrated in which the UE uses the generated key to send 3GPP network-level information and application-level information simultaneously or continuously via CP and UP, respectively.

[0233] like Figure 4 As shown, wireless communication systems according to various embodiments may include UE, NR-RAN, AMF, LMF, V-GMLC, H-GMLC, UPF, NEF, and AF (UTM).

[0234] In Operation 401, the UE generates a public key. This public key is needed to identify the correlation between information sent via the UP and information sent via the CP, and can be configured by, for example, concatenating the UE's current time and application ID. Because service requests are made as needed, the UE has a radio connection to the network. In Operation 402-1, the UE sends the key, application ID, and application location to the AF via the UP.

[0235] In operation 402-2, the UE sends a mobile-initiated location request via a UL NAS TRANSPORT message. This includes the previously generated key. This process can be performed simultaneously with or consecutively with operation 402-1.

[0236] Operation 402-2: The UE sends an MO-LR request message included in a UL NAS TRANSPORT message. The MO-LR request may optionally include an LPP location message. Different types of location services may be requested: UE location estimation, UE location estimation to be sent to an LCS client or AF, or location assistance data. If the UE is requesting its own location or sending its own location to an LCS client or AF, the message carries QoS information for the LCS request (e.g., accuracy, response time, LCS QoS class), the maximum duration of the requested location, and the type of location requested (e.g., "current location," "current or last known location"). If the UE is requesting that its location be sent to an LCS client, the message may include the identity of the LCS client or AF and may include the address of the GMLC through which the LCS client or AF can be accessed (via NEF). Additionally, it may include a service identity indicating which MO-LR service the UE is requesting from the LCS client. The message may also include a pseudonym indicator to indicate that a pseudonym can be assigned by the network and transmitted to the LCS client as the UE's identity. If the UE requests location assistance data instead, the embedded LPP message specifies the type of assistance data and the location method for applying the assistance data.

[0237] For an LCS 5GC-MO-LR requesting location transmission to an LCS client or AF, the AMF can assign a GMLC address (V-GMLC address) stored in the AMF. If the V-GMLC address is unavailable, the AMF can reject the location request. The AMF verifies the UE's subscription profile and decides whether to allow the requested service.

[0238] In operation 403, the AMF selects the desired LMF.

[0239] Operation 403: As described in Clause 5.1 of TS 23.273, AMF selects LMF.

[0240] In Operation 404, the AMF sends a location request to the LMF. At this point, the key may or may not be included.

[0241] Operation 404: The AMF invokes the Nlmf_Location_DetermineLocation service operation to the LMF. The service operation includes the LCS-related identifier, serving cell identity, client type, indication of whether location estimation or location-aided data is requested, and any embedded LPP messages in the MO-LR request. If the UE's location is requested, the service request may include an indication of whether the UE supports LPP, the requested QoS, and the supported GAD shape. If location-aided data is requested, the embedded LPP message may convey the requested type of location-aided data. If any procedure in Clause 6.11.1 or 6.11.2 of TS 23.273 is used, the service operation includes the AMF identity. Once the AMF selects an LMF, the AMF may continue to use that LMF for the duration of the session.

[0242] In operation 405, the LMF, AMF, RAN, and UE perform the UE positioning procedure as needed. This procedure varies depending on the required location accuracy and latency constraints.

[0243] Operation 405: If the UE is requesting its own location, the action described in Clause 6.11 is performed. If the UE instead requests location assistance data, the LMF transmits the data to the UE as described in Clause 6.11.1 of TS 23.273. The LMF determines the exact location assistance data to transmit based on the data type specified by the UE, the UE's location capabilities, and the current cell.

[0244] In operation 406, the LMF sends information to the AMF based on the required location accuracy and delay time constraints. Similar to operation 404, operation 406 may include or omit the key.

[0245] Operation 406: When a location estimate that best satisfies the requested QoS has been obtained, or when the requested location assistance data has been transmitted to the UE, the LMF returns an Nlmf_Location_DetermineLocation response to the AMF. The service operation includes the LCS-related identifier, the location estimate (if obtained), the duration and accuracy of the location estimate, and may include information about the positioning method.

[0246] If a location estimate is not successfully obtained, or if the requested location assistance data cannot be successfully transmitted to the UE, the failure reason is included in the service operation.

[0247] In Operation 407, the AMF sends Ngmlc_Location_LocationUpdateNotify to the GMLC. At this point, the key may need to be included.

[0248] Operation 407: If a location estimate is successfully obtained, the AMF invokes the Ngmlc_Location_LocationUpdateNotify service operation to the V-GMLC allocated in step 2. The service operation carries the UE's identity, the event that triggered the location estimate (5GC-MO-LR) and the location estimate, the duration of the location estimate, the obtained accuracy indication, and the LCS QoS class requested by the target UE. Additionally, the service operation may include a pseudonym indicator, the LCS client's identity, AF ID, GMLC address, and the service identity specified by the UE (if available).

[0249] In roaming situations, during operation 408, the V-GMLC sends this message to the H-GMLC. At this point, the key may need to be included.

[0250] Operation 408: If the UE did not request the transmission of its location to the LCS client or AF in Operation 402-2, then operations 408 to 411 are skipped. If the V-GMLC and H-GMLC are the same NF instance, this operation is skipped. Otherwise, the V-GMLC calls the Ngmlc_Location_LocationUpdateNotify service operation to the H-GMLC (the V-GMLC can query the UE's UDM to obtain the H-GMLC's address), including the information received from the V-GMLC.

[0251] Although not shown in the figure, if Figure 4 A wireless communication system that includes an external client may include Operation 409a.

[0252] Operation 409a: If the pseudonym indicator is included in the MO-LR location information, the H-GMLC assigns a pseudonym to the UE. If the H-GMLC cannot access the identified LCS client, operations 409a and 410a are skipped. Otherwise, based on the LCS QoS class requested by the target UE, the GMLC transmits the location information to the LCS client, carrying the UE's identity or pseudonym, the event that caused the location estimation (5GC-MO-LR), the service identity (if available), the location estimation, and the duration of the location estimation. If the LCS QoS class requested by the UE is guaranteed, the GMLC sends the result to the LCS client only if the result has been indicated to satisfy the requested accuracy. If the LCS QoS class requested by the UE is best-effort, the GMLC sends any results received by the GMLC to the LCS client, with appropriate indication if the requested accuracy is not satisfied.

[0253] In Operation 409b-1, the H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service request to the NEF. At this point, the key may need to be included.

[0254] Operation 409b-1: If the AF ID is included in step 1, the H-GMLC assigns a NEF address based on local configuration or via the NRF and invokes the Ngmlc_Location_LocationUpdateNotify service request carrying the AF ID to the NEF. The location information parameters sent in this service operation are the same as those in Operation 409a.

[0255] In Operation 409b-2, the NEF sends location information to the AF. At this point, the key may need to be included.

[0256] Operation 409b-2: If the NEF cannot access the identified AF, then operations 409b-2 and 410b-1 are skipped. Otherwise, the NEF transmits the location information to the identified AF.

[0257] Although not shown in the figure, if Figure 4 The wireless communication system includes an external client, which may include operation 410a.

[0258] Operation 410a: If the LCS client (for temporary or permanent reasons) does not support MO-LR or cannot process UE location estimation—for example, the LCS client does not know the service identity, or the UE has not registered with the LCS client, or the LCS client does not have the corresponding UE data—then the LCS client can return a location information confirmation message with an appropriate error reason to the H-GMLC. Otherwise, the LCS client processes the location estimation according to the service identity and sends a signaling confirmation message to the GMLC or H-GMLC notifying that the UE's location estimation has been successfully processed.

[0259] Subsequently, responses to the request message are sent to the NEF, H-GMLC, V-GMLC, AMF, and UE via operations 410b-1, 410b-2, 411, 412, and 413. In the non-roaming scenario, H-GMLC is V-GMLC, therefore operation 411 is omitted.

[0260] Operation 410b-1: If the AF cannot process the UE's location estimation, for example, if the UE is not registered with the AF or the AF does not have the corresponding data for the UE, the AF can return a location information confirmation message with an appropriate error reason to the NEF. Otherwise, the AF processes the location estimation according to the service identity and sends a signaling confirmation message to the NEF notifying it that the UE's location estimation has been successfully processed.

[0261] Operation 410b-2: NEF sends an Ngmlc_Location_LocationUpdateNotifyy service response with location information confirmation to H-GMLC.

[0262] Operation 411: If the V-GMLC and H-GMLC are the same NF instance, skip this operation. If the identified LCS client or AF is inaccessible, the H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the V-GMLC. Otherwise, the response may include an acknowledgment. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, or if not, include the corresponding error reason obtained in step 10. Furthermore, the H-GMLC may log billing information for both the UE and interworking revenue charges.

[0263] Operation 412: If the V-GMLC receives MO-LR location information confirmation from the H-GMLC, and the identified LCS client or AF is inaccessible, the V-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the AMF. Otherwise, the response may include confirmation. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, and if not, include the corresponding error reason obtained in Operations 309 or 310. Furthermore, the V-GMLC may log billing information for both the UE and interworking revenue charges.

[0264] If the V-GMLC receives a LocationUpdateNotify request from the AMF, and the V-GMLC does not need to send it to any LCS client or AF, the V-GMLC can record the charging information for the UE and respond to the LocationUpdateNotify request to the AMF.

[0265] Operation 413: The AMF sends an MO-LR response message included in the DL NAS TRANSPORT message. This response carries any location estimates requested by the UE, including an indication of whether the obtained location estimate received from the E-SMLC meets the requested accuracy, or an indication of whether the location estimate was successfully transmitted to the identified LCS client or AF. If the location estimate was successfully transmitted to the identified LCS client or AF, the MO-LR response message may specify whether the identified LCS client or AF has successfully processed the UE's location estimate; otherwise, it includes the corresponding error reason obtained in Operation 313. Additionally, the AMF may log billing information. Figure 4 As shown, in the methods of sending and receiving information according to various embodiments, the UE can use a public key generated by the UE to send the application ID and application location to the AF (UTM) simultaneously or continuously via the UP, and send location information (e.g., 3GPP network-level information) to the AF (UTM) via the CP.

[0266] Specifically, the UE can simultaneously or continuously send the key, application ID, and application location to the AF (UTM) via the UPF through the UP, and send the key and local information (e.g., 3GPP network-level information) to the UTM via messages sent to the AF through the CP.

[0267] For example, such as Figure 4 As shown, the UE sends UE-generated keys and application-level information, such as application ID and application location, via UP-based messages sent to the AF (UTM) through the UPF.

[0268] Simultaneously or continuously, the UE sends a Mobile Initiated Location Request (MO-LR) via a UL NAS TRANSPORT message and sends a UE-generated key via a CP-based message sent to the AF (UTM) via the AMF, GMLC, and NEF.

[0269] Specifically, the MO-LR and key can be included in the UL NAS TRANSPORT message sent to the AMF, the key generated by the UE can be included in the Ngmlc_Location_LocationUpdateNotify request message sent from the AMF to the GMLC, the key can be included in the Ngmlc_Location_LocationUpdateNotify service request message sent from the GMLC to the NEF, and the location information and key can be included in the CP-based message sent from the NEF to the AF (UTM).

[0270] In other words, the UE can simultaneously or continuously send the key generated by the UE and application-level information, such as application ID and application location, to the AF (UTM) via the UPF, and send 3GPP network-level information, such as location information and the key generated by the UE, to the AF (UTM).

[0271] Figure 5 The process of sending application-level information via UP and 3GPP-level information via CP using a public key generated by the network, according to various embodiments, is illustrated.

[0272] according to Figure 5 The methods for sending and receiving information in the various embodiments shown may also include SMF.

[0273] Figure 5 The process of using a key generated by the network to simultaneously or continuously transmit 3GPP network-level information and application-level information via CP and UP, respectively, is illustrated.

[0274] In Operation 501, the UE sends the PDU session ID and data (application ID and application location) via a UL NAS TRANSPORT message, and also sends an MO-LR request. Prior to this, the UE establishes a radio connection with the network by making service requests as needed.

[0275] Operation 501: The UE sends an MO-LR request message included in a UL NAS TRANSPORT message. The MO-LR request may optionally include an LPP location message. Different types of location services may be requested: UE location estimation, UE location estimation to be sent to an LCS client or AF, or location assistance data. If the UE is requesting its own location or sending its own location to an LCS client or AF, the message carries QoS information for the LCS request (e.g., accuracy, response time, LCS QoS class), the maximum duration of the requested location, and the type of location requested (e.g., "current location," "current or last known location"). If the UE is requesting that its location be sent to an LCS client, the message may include the identity of the LCS client or AF and may include the address of the GMLC, through which the LCS client or AF can be accessed (via NEF). Additionally, it may include a service identity indicating which MO-LR service the UE is requesting from the LCS client. The message may also include a pseudonym indicator to indicate that a pseudonym can be assigned by the network and transmitted to the LCS client as the UE's identity. If the UE requests location assistance data instead, the embedded LPP message specifies the type of assistance data and the location method for applying the assistance data.

[0276] For an LCS 5GC-MO-LR requesting location transmission to an LCS client or AF, the AMF can assign a GMLC address (V-GMLC address) stored in the AMF. If the V-GMLC address is unavailable, the AMF can reject the location request. The AMF verifies the UE's subscription profile and decides whether to allow the requested service.

[0277] In Operation 502-0, the AMF receiving the NAS message performs an integrity check on the PDU session ID and data, and generates a key. This key is needed to identify the correlation between information sent via the UP and information sent via the CP, and can be configured by concatenating, for example, the AMF's current time and the UE's 3GPP ID (network-level ID).

[0278] In Operation 502-1, the AMF sends an Nsmf_PDUSession_MessageTransfer containing existing data and keys to the SMF.

[0279] In Operation 502-2, the SMF sends an Nnef_NIDD_Delivery request containing the key (key, application ID, and application location) to the NEF.

[0280] In Operation 502-3, the NEF sends an Nnef_NIDD_DeliveryNotify request containing the key, application ID, and application location to the AF. In Operations 502-4 and 502-5, responses to the requests from the NEF and SMF are sent.

[0281] In operation 503, AMF is selected as LMF. This procedure is executed simultaneously with operation 502-1.

[0282] Operation 503: As described in Clause 5.1 of TS 23.273, AMF selects LMF.

[0283] In Operation 504, the AMF sends a location request to the LMF. At this point, the key may or may not be included.

[0284] Operation 504: The AMF invokes the Nlmf_Location_DetermineLocation service operation to the LMF. The service operation includes the LCS-related identifier, serving cell identity, client type, indication of whether location estimation or location-aided data is requested, and any embedded LPP messages in the MO-LR request. If the UE's location is requested, the service request may include an indication of whether the UE supports LPP, the requested QoS, and the supported GAD shape. If location-aided data is requested, the embedded LPP message may convey the requested type of location-aided data. If any procedure in Clauses 6.11.1 or 6.11.2 of TS 23.273 is used, the service operation includes the AMF identity. Once the AMF selects an LMF, the AMF may continue to use that LMF for the duration of the session.

[0285] In Operation 505, the LMF, AMF, RAN, and UE perform the UE positioning procedure as needed. This procedure varies depending on the required location accuracy and latency constraints.

[0286] Operation 505: If the UE is requesting its own location, the action described in Clause 6.11 is performed. If the UE instead requests location assistance data, the LMF transmits the data to the UE as described in Clause 6.11.1 of TS 23.273. The LMF determines the exact location assistance data to transmit based on the data type specified by the UE, the UE's location capabilities, and the current cell.

[0287] In operation 506, the LMF sends information to the AMF based on the required location accuracy and delay time constraints. Similar to operation 504, operation 506 may include or omit the key.

[0288] Operation 506: When a location estimate that best satisfies the requested QoS has been obtained, or when the requested location assistance data has been transmitted to the UE, the LMF returns an Nlmf_Location_DetermineLocation response to the AMF. The service operation includes the LCS-related identifier, the location estimate (if obtained), the age of the location estimate, and its accuracy, and may include information about the positioning method.

[0289] If a location estimate is not successfully obtained, or if the requested location assistance data cannot be successfully transmitted to the UE, the failure reason is included in the service operation.

[0290] In Operation 507, the AMF sends Ngmlc_Location_LocationUpdateNotify to the GMLC. At this point, the key may need to be included.

[0291] Operation 507: If a location estimate is successfully obtained, the AMF invokes the Ngmlc_Location_LocationUpdateNotify service operation to the V-GMLC allocated in Operation 501. The service operation carries the UE's identity, the event that triggered the location estimate (5GC-MO-LR) and the location estimate, the duration of the location estimate, the obtained accuracy indication, and the LCS QoS class requested by the target UE. Additionally, the service operation may include a pseudonym indicator, the LCS client's identity, AF ID, GMLC address, and the service identity specified by the UE (if available).

[0292] In roaming situations, during operation 508, the V-GMLC sends a message to the H-GMLC. In this case, the key may need to be included.

[0293] Operation 508: If the UE did not request the transmission of its location to the LCS client or AF in Operation 501, then operations 508 to 511 are skipped. If the V-GMLC and H-GMLC are the same NF instance, this operation is skipped. Otherwise, the V-GMLC calls the Ngmlc_Location_LocationUpdateNotify service operation to the H-GMLC (the V-GMLC can query the UE's UDM to obtain the H-GMLC's address), including information received from the V-GMLC.

[0294] Although not shown in the figure, if Figure 5 A wireless communication system that includes an external client may include Operation 509a.

[0295] Operation 509a: If the pseudonym indicator is included in the MO-LR location information, the H-GMLC assigns a pseudonym to the UE. If the H-GMLC cannot access the identified LCS client, operations 509a and 510a are skipped. Otherwise, based on the LCS QoS class requested by the target UE, the GMLC transmits the location information to the LCS client, carrying the UE's identity or pseudonym, the event that caused the location estimation (5GC-MO-LR), the service identity (if available), the location estimation, and the duration of the location estimation. If the LCS QoS class requested by the UE is guaranteed, the GMLC sends the result to the LCS client only if the result has been indicated to satisfy the requested accuracy. If the LCS QoS class requested by the UE is best-effort, the GMLC sends any results received by the GMLC to the LCS client, with appropriate indication if the requested accuracy is not satisfied.

[0296] In Operation 509b-1, the H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service request to the NEF. At this point, the key may need to be included.

[0297] Operation 509b-1: If step 1 includes an AF ID, the H-GMLC assigns a NEF address based on its local configuration or via the NRF and invokes the Ngmlc_Location_LocationUpdateNotify service request carrying the AF ID to the NEF. The location information parameters sent in this service operation are the same as those in Operation 509a.

[0298] In Operation 509b-2, the NEF sends location information to the AF. At this point, the key may need to be included.

[0299] Operation 509-2: If the NEF cannot access the identified AF, then operations 509b-2 and 510b-1 are skipped. Otherwise, the NEF transmits the location information to the identified AF.

[0300] Although not shown in the figure, if Figure 5 The wireless communication system includes an external client, which may include Operation 510a.

[0301] Operation 510a: If the LCS client (for temporary or permanent reasons) does not support MO-LR or cannot process UE location estimation—for example, the LCS client does not know the service identity, or the UE has not registered with the LCS client, or the LCS client does not have the corresponding UE data—then the LCS client can return a location information confirmation message with an appropriate error reason to the H-GMLC. Otherwise, the LCS client processes the location estimation according to the service identity and sends a signaling confirmation message to the GMLC or H-GMLC notifying that the UE location estimation has been successfully processed.

[0302] Subsequently, responses to the request message are sent to the NEF, H-GMLC, V-GMLC, AMF, and UE via operations 510b-1, 510b-2, 511, 512, and 513. In the non-roaming scenario, H-GMLC is V-GMLC, therefore operation 511 is omitted.

[0303] Operation 510b-1: If the AF cannot process the UE's location estimation, for example, if the UE is not registered with the AF or the AF does not have the corresponding data for the UE, the AF can return a location information confirmation message with an appropriate error reason to the NEF. Otherwise, the AF processes the location estimation according to the service identity and sends a signaling notification to the NEF that a location information confirmation message has been successfully processed for the UE's location estimation.

[0304] Operation 510b-2: NEF sends an Ngmlc_Location_LocationUpdateNotify service response with location information confirmation to H-GMLC.

[0305] Operation 511: If the V-GMLC and H-GMLC are the same NF instance, skip this operation. If the identified LCS client or AF is inaccessible, the H-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the V-GMLC. Otherwise, the response may include an acknowledgment. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, or if not, include the corresponding error reason obtained in step 10. Furthermore, the H-GMLC may log billing information for both the UE and interworking revenue charges.

[0306] Operation 512: If the V-GMLC receives MO-LR location information confirmation from the H-GMLC, and the identified LCS client or AF is inaccessible, the V-GMLC sends an Ngmlc_Location_LocationUpdateNotify service response with an appropriate error reason to the AMF. Otherwise, the response may include confirmation. This message may specify whether the identified LCS client or AF has successfully processed the UE's location estimation, or if not, the corresponding error reason obtained in Operations 309 or 310. Furthermore, the V-GMLC may record billing information for both the UE and interworking revenue charges.

[0307] If the V-GMLC receives a LocationUpdateNotify request from the AMF, and the V-GMLC does not need to send it to any LCS client or AF, the V-GMLC can record the charging information for the UE and respond to the LocationUpdateNotify request to the AMF.

[0308] Operation 513: The AMF sends an MO-LR response message included in the DL NAS TRANSPORT message. This response carries any location estimate requested by the UE, including an indication received from the E-SMLC regarding whether the obtained location estimate meets the requested accuracy, or an indication whether the location estimate was successfully transmitted to the identified LCS client or AF. If the location estimate was successfully transmitted to the identified LCS client or AF, the MO-LR response message may specify whether the identified LCS client or AF has successfully processed the UE's location estimate; otherwise, it may specify the corresponding error reason obtained in Operation 313. Additionally, the AMF may log billing information.

[0309] like Figure 5 As shown, in the methods of sending and receiving information according to various embodiments, the UE can use the public key generated by the NW to send the application ID and application location to the AF (UTM) simultaneously or continuously via the UP, and send local information (e.g., 3GPP network-level information) to the AF (UTM) via the CP.

[0310] Specifically, the UE can simultaneously or continuously send the key, application ID, and application location to the AF (UTM) via the SMF through the UP, and send the key and location information (e.g., 3GPP network-level information) to the AF (UTM) via the message sent to the AF via the CP.

[0311] For example, such as Figure 5 As shown, the UE transmits keys and application-level information generated by the AMF, such as application ID and application location, via UP-based messages sent to the AF (UTM) through the SMF. In this case, the process for transmitting UP information via the CP is defined as a special process for IoT, and the use of this process is described.

[0312] At the same time, the UE sends a Mobile Initiated Location Request (MO-LR) via a UL NAS TRANSPORT message, and sends a key generated by the AMF via a CP-based message sent to the AF (UTM) via GMLC and NEF.

[0313] Specifically, MO-LR can be included in the UL NAS TRANSPORT message sent from the UE to the AMF, the key generated by the AMF can be included in the Ngmlc_Location_LocationUpdateNotify request message sent from the AMF to the GMLC, the key can be included in the Ngmlc_Location_LocationUpdateNotify service request message sent from the GMLC to the NEF, and the location information and key can be included in the CP-based message sent from the NEF to the AF (UTM).

[0314] In other words, the UE can simultaneously or continuously send the key generated by the NW and application-level information (e.g., application ID and application location) to the AF (UTM) via the SMF, and send 3GPP network-level information (e.g., location information) and the key generated by the NW to the AF (UTM).

[0315] According to various embodiments, UAS service scenarios may include at least one of an authorization method, a monitoring method, or a method of sending an identifier (ID) or other information via local broadcast.

[0316] Figure 6A illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments, Figure 6B illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments, Figure 6C illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments, and Figure 6D illustrates an embodiment of the authorization method in a UAS service scenario according to various embodiments.

[0317] Figures 6A to 6D illustrate a first UAS service scenario according to various embodiments, showing four types of authorization situations.

[0318] Figure 6A: 3GPP Licensing. 3GPP NW begins providing services.

[0319] Figure 6B: UTM Authorization. The 3GPP NW provides authorization information to the UTM, and the UTM identifies the authorization information at the application level to perform authorization. The UTM binds the 3GPP ID and the application ID. After authorization, UAS-UTM communication is allowed. No comparison between GPS information and LCS is required here.

[0320] Figure 6C: UTM Allows Flight Planning. UTM allows flight planning based on whether the UAS has sufficient authorization and location information at the 3GPP level. Once flight planning is allowed, C2 traffic is permitted. A 3GPP ID is required for additional identification, and 3GPP LCS information is required for location verification.

[0321] Figure 6D: Refers to the steps for providing / verifying the route as an additional / supplementary function. A 3GPP ID is required for additional identification, and 3GPP LCS information is required for location verification.

[0322] (1) Figure 6A illustrates the initial network access authentication and authorization process, in which authentication and authorization are performed between the UE and the 3GPP network through initial network access.

[0323] As shown in Figure 6A, UAV and UAVC can send Subscriber Identity Module (SIM) and Internet Protocol (IP) to the CN. UAV or UAVC types can be subscribed to by 3GPP network operators. Network operators can then prepare and provide the required services based on this type.

[0324] CN can perform UAV / UAVC 3GPP certification. 3GPP network operators use CN certification to identify whether to provide network services to the corresponding UAV or UAVC.

[0325] For example, the CN can identify whether it has subscribed to the UAV / UAVC type through the SIM, and can notify whether UAV / UAVC is supported through capability signaling.

[0326] (2) Figure 6B illustrates the UAS authentication process, in which application-level information and 3GPP network-level information are sent to provide UAS identification to the UTM. As shown in Figure 6B, the application-level information may include the application ID, and the 3GPP network-level information may include the 3GPP ID.

[0327] In the existing technology, only traffic that transmits International Mobile Equipment Identity (IMEI), International Mobile Station Identity (IMSI), Subscriber Identity (MSISDN), IP address (IPaddr), and UTM-level ID is allowed to the UTM. However, as shown in Figure 6B, application-level information (application ID1 and application ID2) and 3GPP network-level information (3GPP ID1 and 3GPP ID2) can also be sent.

[0328] For example, a UE that supports UAS can send the GPSI (General Public Subscription Identifier) ​​and the verification results of the application ID and 3GPPID (or the verification results of LCS and GPS) to the UTM.

[0329] In addition, UEs that do not support UAS can send the application ID, GPSI, and GPS to the UTM, and then the UTM can request GPSI verification and LCS from the NEF.

[0330] (3) Figure 6C shows the UAV flight planning authorization process, in which information about the UAV and UAVC is sent to the UTM, and the UTM authorizes the operation of the UAS based on this.

[0331] As shown in Figure 6C, application-level information may include application location information, and 3GPP network-level information may include 3GPP location information. In this case, both application-level location information and 3GPP network-level location information can be sent to the UTM.

[0332] In the prior art, UAV-UAVC traffic can only be transmitted for IMEI, MSISDN, IMSI, Ipaddr, LCS or UTM level IDs after UAS authentication in Figure 6B or UAV flight planning permission in Figure 6C. However, as shown in Figure 6C, UAV-UAVC traffic can be transmitted for command and control (C2) and UAS-generated data after UAV flight planning permission in Figure 6C.

[0333] Meanwhile, UEs that support UAS can send verification results of GPSI, application ID, and 3GPP ID, as well as verification results of LCS and GPS, to UTM.

[0334] In addition, UEs that do not support UAS can send the application ID, GPSI, and GPS to the UTM, and then the UTM can request GPSI verification and LCS from the NEF.

[0335] A UE that supports UAS can set traffic filters for UAV / UAVC traffic in the UPF. For example, a UE that supports UAS may need to set traffic filters for UAV traffic in the UPF and selectively set traffic filters for UAVC traffic in the UPF.

[0336] At the same time, since it is impossible to guarantee UAV-UTM, UEs that do not support UAS cannot be implemented in UPF.

[0337] UEs that support UAS can allow the activation of PDU sessions, while UEs that do not support UAS can activate the corresponding DN's PDU session without any UPF procedure.

[0338] (4) Figure 6D shows the authentication process for the additional UTM service (Additional UTM Service Authentication).

[0339] For example, additional UTM services may include flight monitoring and collision avoidance services.

[0340] As shown in Figure 6D, application-level information can include application location information, and 3GPP network-level information can include 3GPP location information. At this point, both application-level location information and 3GPP network-level location information can be sent to the UTM. As shown in Figure 6D, based on the UTM's subscription service information, connections for traffic paths (additional information) for other services can be configured at the user plane level, and communication with the UAS can be allowed through application-level IP / port filters.

[0341] Figure 7A illustrates an embodiment of the regulatory method in a UAS service scenario according to various embodiments, Figure 7B illustrates an embodiment of the regulatory method in a UAS service scenario according to various embodiments, and Figure 7C illustrates an embodiment of the regulatory method in a UAS service scenario according to various embodiments.

[0342] According to various embodiments, when using 3GPP auth in a UAS service scenario, UAV-UTM traffic and UAVC-UTM traffic can be allowed, but under certain circumstances, UAV-UAVC traffic can be allowed or disallowed through UPF control.

[0343] Figures 7A to 7C illustrate a second UAS service scenario according to various embodiments, showing how the UTM supervises UAS operations through three types. As shown in Figures 7A to 7C, application-level information may include application location information, and 3GPP network-level information may include 3GPP location information.

[0344] (1) As shown in Figure 7A, application-level location information and 3GPP network-level location information can be sent to the UTM. If it is determined that the two pieces of information do not match, the information provided by the UAS is classified as untrusted, and the UAS operation is regulated.

[0345] UTM can trigger oversight of UAS operations based on the location of the UAV or UAVC. When oversight is triggered, UTM can consider the UAV or UAVC to be unauthorized and perform takeover control operations.

[0346] Takeover control operations may include disallowing UAV-UAVC traffic, sending route modification or route modification notifications to UAVC, and sending route modification information to UAV.

[0347] For example, when the NW's LCS information does not match the UAV or UAVC's GPS (untrusted area control), the UTM can disallow UAV-UAVC traffic, send a notification to the UAVC and send a route modification to the UAV so that the UAV can be moved continuously according to the LCS information until the GPS and LCS match each other.

[0348] (2) As shown in Figure 7B, application-level location information and 3GPP network-level location information can be sent to the UTM.

[0349] If two pieces of information are determined to match, the information provided by the UAS can be classified as trustworthy. If the UAS location information is determined to correspond to entry into a restricted area managed by the UTM or an area with a high collision risk, the UTM will supervise the UAS operation.

[0350] (3) As shown in Figure 7C, in cases other than (1) or (2), the corresponding UAS operation can be supervised by a request from an external execution organization.

[0351] Information related to law enforcement by external enforcement organizations is always accessible.

[0352] Figure 8A illustrates an embodiment of a method for sending identifiers (IDs) or other information via local broadcast between UAVs in a UAS service scenario according to various embodiments, and Figure 8B illustrates an embodiment of a method for sending identifiers (IDs) or other information via local broadcast between UAVs in a UAS service scenario according to various embodiments.

[0353] For example, a UAV can broadcast its ID and use that broadcast ID to prevent collisions, and can also use broadcast communication to provide other UAVs with information such as ID, status, and flight plans.

[0354] Figures 8A and 8B illustrate a third UAS service scenario according to various embodiments, showing a method for receiving not only the D2D_ID broadcast but also detailed information broadcasts between UAVs belonging to different PLMNs when the UAV sends its own D2D_ID via a local broadcast using a D2D scheme.

[0355] As shown in Figure 8A, the UE can receive the D2D_ID from its own 3GPP network, periodically broadcast the D2D_ID to its vicinity, and use the_ID to prevent collisions. The UTM can store the D2D_ID, application-level ID, GPSI, IP address, or NIDD ID.

[0356] When D2D_ID is an application-level ID, or after being converted to a Layer 2 ID, communication between UAVs can be performed directly. When D2D_ID is a Layer 2 ID, the application-level ID can be identified after parsing via UTM.

[0357] In addition, UAVs can provide information such as ID, status, and flight plan via broadcast communication. Information provided through D2D communication can prevent collisions, or it can be used for policy checks.

[0358] As shown in Figure 8B, when a UE belonging to the same PLMN receives a D2D_ID, the UE can request and receive additional information from the corresponding UE. At this time, using the common ProSe function, the UE can know each other's D2D configuration information in detail, and thus perform information exchange based on the corresponding configuration and the other party's D2D configuration.

[0359] However, UEs belonging to different PLMNs cannot receive configuration information through the common ProSe function, therefore the UEs need to obtain information through the UTM. Thus, the UTM can know the D2D_ID and configuration information of each UE.

[0360] Even UEs belonging to different PLMNs can exchange detailed information via local broadcast communication as needed, by identifying the D2D configuration information for each D2D_ID through the UTM. When the D2D configuration information is unknown, the UE can obtain the D2D_ID from a UE in another PLMN through periodic frequency searches. However, to identify the detailed information, the UE needs the D2D configuration information; therefore, if the PLMNs are different, the D2D configuration information needs to be identified via the UTM.

[0361] As mentioned above, UAVs can send and receive information via local broadcast communication transmission services.

[0362] For example, in V2X, broadcast communication can be performed by specifying the entity corresponding to "from" or "to" based on the Layer 2 ID.

[0363] In addition, local broadcast communication transmission services between UAVs or between UAVs and UAVCs (or between people) can also be Layer 2 IDs.

[0364] At the same time, when considering the situation within a PLMN where another PLMN frequency is periodically monitored via broadcast communication, it is necessary to identify another PLMN configuration used for local broadcast communication.

[0365] As shown in Figure 8B, in the case of PLMNs, the connection to the UTM is based on the D2D broadcast ID, and the transmission of additional information requires a direct connection duplex path via UAV-UTM-UAVC or UAV / UAVC / UAVC-UAVC.

[0366] Figure 9 The initial network access process in a UAS service scenario according to various embodiments is illustrated.

[0367] Figure 9 The process corresponding to the scenario in Figure 6A is shown, and the case where the UAV / UAVC has authentication / authorization to the 3GPP network is also shown.

[0368] In Operation 910, UAV / UAVC can perform authentication with 3GPP networks based on the SIM.

[0369] UAV / UAVC can send registration messages to UDM. For example, the registration message may include UE capabilities, and UE capabilities may include "UAS-capable" and "UE type = UAV or UAV controller".

[0370] For example, "supports UAS" can mean that the corresponding UE supports UAS-related functions and can be configured in the UE.

[0371] For example, "UE type = UAV or UAV controller" can be configured as a type field in the USIM and can be managed by the service provider to segment and divide the UE's ID.

[0372] After SIM-based authentication, the UAV / UAVC can receive subscription information from the UDM. For example, the subscription information may include "UAS-capable support", "LCS support", and "combined delivery support".

[0373] For example, “Combined delivery support” can use CP for CIoT, but it can also mean that CP data can be sent using the NIDD procedure defined for sending UP data, and can be configured in the UE.

[0374] When the UE's subscription / capability / type information is identified as supporting UTM, communication between UAV / UAVC and UTM can be supported in three types.

[0375] (1) The first type is communication between UAV / UAVC and UTM through the control plane.

[0376] like Figure 9 As shown in Operation 923, the UAV / UAVC can send the application ID and 3GPP ID to the UTM(AF) via the AMF / UDM (Operation 921).

[0377] (2) The second type is communication between UAV / UAVC and UTM via the user plane. In this case, UAV / UAVC communicates with UTM via UPF.

[0378] like Figure 9 As shown, in operation 943, the UAV / UAVC can send the key and application ID to the UTM (AF) via the UPF (operation 941).

[0379] Simultaneously or sequentially, in Operation 953, the UAV / UAVC can send the key and 3GPP ID to the UTM(AF) via the AMF / UDM (Operation 951).

[0380] (3) The third type is communication optimized using CIoT. In this case, the UAV / UAVC communicates with the UTM via the NEF. The NEF and UTM use the GPSI corresponding to the 3GPP ID through the Non-IP Data Transfer (NIDD) configuration process.

[0381] like Figure 9 As shown in Operation 965, UAV / UAVC can send the application ID and 3GPP ID to PCF / NEF via AMF / UDM and SMF (Operations 961 and 963).

[0382] In Operations 971 to 973, NEF and UTM can be configured through the Non-IP Data Transfer (NIDD) process, and the 3GPP ID can also be sent in Operation 971. Therefore, the 3GPP ID and NIDD allocation can be implicitly sent in Operation 980.

[0383] In NIDD setup step S971, the 3GPP ID is used. Therefore, S980 is bound to the 3GPP ID, and the data sent through it can include and transmit the 3GPP ID without requiring separate mention.

[0384] For example, because a 3GPP ID is used when configuring NIDD, traffic using the established API or tunnel can be implicitly bound to the 3GPP ID. Therefore, there may not be a separate operation for 3GPP ID traffic.

[0385] Figure 10 The UAS authentication process in various UAS service scenarios is illustrated.

[0386] Figure 10 The scenario in Figure 6B illustrates UAV / UAVC performing authentication in UTM.

[0387] (1) First, the 3GPP ID (IMEI, GPSI / MSISDN, IMSI and IP address) as 3GPP network-level information, and the application ID as application-level information, can also be directly added to the CP's secondary authorization or DN authorization process.

[0388] like Figure 10 As shown, UAV / UAVC can send the application ID and 3GPPID to UTM(AF) via AMF / UDM (Operation 1011) (Operation 1013).

[0389] In other words, 3GPP NW can send application information and 3GPP information to UTM(AF) through CP.

[0390] (2) Second, a method can be used to send the application ID as application-level information and the 3GPP ID as 3GPP network-level information simultaneously or continuously via UP and CP based on the public key generated by the UE.

[0391] like Figure 10 As shown, the UAV / UAVC can send the key and application ID (AF) to the UTM via the UPF (Operation 1021) based on the public key generated by the UE (Operation 1023).

[0392] Simultaneously or continuously, the UAV / UAVC can send the key and 3GPP ID to the UTM(AF) via AMF / UDM (Operation 1031) (Operation 1033).

[0393] In other words, 3GPP NW can send keys and application information to UTM(AF) simultaneously or continuously via UP, and send keys and 3GPP ID to UTM(AF) via CP.

[0394] (3) Third, when the application ID is sent via application-level information during CIoT 5GS optimization, a 3GPPID, AMF, or SMF is specified to generate a public key. The key and application ID are sent to the UTM via the NEF through the NIDD path, and the key and 3GPP ID are sent to the UTM via the CP path. In this case, if the 3GPP ID used in the NIDD establishment process is the same as the 3GPP ID to be sent via a separate CP path, the transmission process using a separate CP path can be omitted. This is because traffic transmission using NIDD means that the 3GPP ID has already been included in the transmission process, since NIDD is bound to the 3GPP ID.

[0395] like Figure 10 As shown, when the UAV / UAVC sends the application ID and 3GPP ID via the AMF or SMF (Operation 1041 or 1043), the AMF or SMF can generate a public key and can send the public key and application ID to the UTM(AF) simultaneously or continuously via the PCF / NEF (Operation 1045) (Operation 1047), and send the public key and 3GPPID to the UTM(AF) via the PCF / NEF (Operation 1051) (Operation 1053).

[0396] In this case, if the 3GPP ID used during NIDD establishment is the same as the 3GPP ID to be sent via a separate CP path, the transmission process using a separate CP path can be omitted.

[0397] For example, 3GPP NW can use NAS to simultaneously send application information and 3GPP information via UP (NIDD), and can use the public key provided by NW. Meanwhile, since the 3GPP ID is used to configure the NIDD, the 3GPP ID can be used instead of the key. Traffic transmission using the NIDD means that the 3GPP ID is already included in the transmission process, because the NIDD is bound to the 3GPP ID.

[0398] Figure 11 The UAV flight planning certification process in a UAS service scenario is illustrated according to various embodiments.

[0399] Figure 11 The process of UAV / UAVC certifying UTM flight planning is shown in the scenario of Figure 6C.

[0400] The flight planning information sent to the UTM consists of UAV information and UAVC information, which will be described in detail below. UAV information may include a unique identity (application ID or 3GPP ID), UE capabilities, manufacturer and model, serial number, takeoff weight, current location, owner ID, owner address, owner contact information, owner certificate, takeoff location, mission type, route data, and operational status (UAV data, which may include: a unique identity (which could be a 3GPP identity), UAV UE capabilities, brand and model, serial number, takeoff weight, location, owner identity, owner address, owner contact information, owner certificate, takeoff location, mission type, route data, and operational status).

[0401] UAVC information may include ID (Application ID or 3GPP ID), UE capabilities, current location, owner ID, owner address, owner contact, owner certificate, UAV operator ID, UAV operator license, UAV operator certificate, UAV pilot ID, UAV pilot license, UAV pilot certificate, and flight plan (UAV controller data, which may include: unique identity (which may be a 3GPP identity), UAV controller UE capabilities, location, owner identity, owner address, owner contact details, owner certificate, UAV operator identity, UAV operator license, UAV operator certificate, UAV pilot identity, UAV pilot license, UAV pilot certificate, and flight plan).

[0402] When the UTM authorizes the UAV flight plan, it sends an authorization response to the 3GPP network and allows PDU session traffic between the UAV and UAVC. The traffic path between the UAV and UAVC can be at the flow level with specified source / destination IP / port, the route filter level with specified source / destination IP only, the forwarding filter level with specified source / destination MAC address, the PDU session level, or the DN level with specified DNN / NSSI.

[0403] Information can be transmitted to the UTM in the following three ways.

[0404] (1) First, the 3GPP ID, which is not only 3GPP network-level information, but also UAV / UAVC information and application ID, which are application-level information, can be directly added to the CP's secondary authorization or DN authorization process.

[0405] like Figure 11 As shown, UAV / UAVC performs secondary authorization by sending UAV / UAVC information (operation 1115) to UTM(AF) via CP through AMF / UDM (operation 1111) and PCF / NEF (operation 1113).

[0406] It can be assumed that dynamic information such as all locations and flight plans can be reflected in the DN authorization information used for PDU session establishment.

[0407] Application-level location verification can be performed based on 3GPP-level location.

[0408] (2) Second, a method can be used to send UAV / UAVC information and application ID as application-level information and 3GPP ID as 3GPP network-level information simultaneously or continuously through UP and CP based on the public key generated by the UE.

[0409] like Figure 11 As shown, the public key generated by the UE can be used to simultaneously or continuously send the key and 3GPP ID to the UTM(AF) via the CP through the AMF / UDM, and send the key, UAV / UAVC information and application ID to the UTM(AF) via the UP through the UPF (Operation 1131).

[0410] After UAV / UAVC information is sent to the UTM DNN simultaneously or continuously via UP and CP, DN authorization can be performed for the C2 DNN during PDU session establishment.

[0411] Application-level location verification can be performed based on 3GPP-level location.

[0412] (3) Third, when sending UAV / UAVC information and application ID through application-level information during the CIoT 5GS optimization process, a 3GPP ID is specified, and a public key is generated by AMF or SMF. The key, UAV / UAVC information and application ID are sent to UTM via NEF through the NIDD path, and the key and 3GPP ID are sent to UTM through the CP path.

[0413] like Figure 11 As shown, when UAV / UAVC sends UAV / UAVC information, application ID, and 3GPP ID via AMF or SMF (operation 1141 or 1143), AMF or SMF can generate a public key and simultaneously or continuously send the public key, UAV / UAVC information, and application ID to UTM(AF) via PCF / NEF (operation 1145) (operation 1147), and send the public key and 3GPP ID to UTM(AF) via PCF / NEF (operations 1151 to 1153) (operation 1155).

[0414] In this case, when the 3GPP ID used during NIDD setup is the same as the 3GPP ID to be sent via a separate CP path, the transmission process using a separate CP path can be omitted. For example, a 3GPP NW can use NAS to simultaneously send application information and 3GPP information via UP (NIDD), and can use the public key provided by the NW. Furthermore, since the 3GPP ID is used to configure NIDD, it can be used instead of the key. Traffic transmission using NIDD means that the 3GPP ID is already included in the transmission process, because the NIDD is bound to the 3GPP ID.

[0415] After the UAV / UAVC information is sent to the UTM DNN via NIDD UP, DN authorization can be performed for the C2DNN during PDU session establishment.

[0416] Application-level location verification can be performed based on 3GPP-level location.

[0417] Figure 12 The process of identifying UAS location information for the UAV flight planning authorization process in a UAS service scenario according to various embodiments is illustrated.

[0418] Figure 12 It shows in Figure 11 The process involves verifying location information and ID. Similar to... Figure 11 There are three possible methods.

[0419] (1) First, the application ID and application location, as application-level information, can be directly added to the location request process initiated by the CP's mobile.

[0420] like Figure 12 As shown, 3GPP NW can send application information and 3GPP information to UTM(AF).

[0421] Application information may include application ID and application location / position, and 3GPP information may include 3GPP ID and 3DPP location.

[0422] For example, UAV / UAVC can send the application ID, application location, 3GPP ID and 3GPP location to UTM(AF) via AMF / UDM (Operation 1211) and PCF / NEF (Operation 1213) as an LCS response (res.) (Operation 1215).

[0423] (2) Second, a method can be used to send application ID and application location as application-level information and 3GPP ID as 3GPP network-level information simultaneously or continuously via UP and CP based on the public key generated by the UE.

[0424] like Figure 12 As shown, 3GPP NW can simultaneously send application information and 3GPP information through CP and UP (including NIDD), and can use the public key generated by the UE.

[0425] For example, the key (e.g., application ID and application time) and application location can be sent via UP, and the key (e.g., application ID and application time), 3GPP ID and 3GPP location can be sent via CP.

[0426] like Figure 12 As shown, the public key generated by the UE can be used to simultaneously or continuously perform the following operations: sending the key, 3GPP ID, and corresponding LCS response operation (Operation 1225) to the UTM (AF) via CP, AMF / UDM, and PCF / NEF (Operations 1221 to 1223); and sending the key, application ID, application time, and application location to the UTM (AF) via UP, UPF (Operation 1231) (Operation 1233).

[0427] (3) Third, when the application ID and application location are sent through application-level information during the CIoT 5GS optimization process, the LCS, AMF or SMF are specified to generate a public key. The key, application ID and application location are sent to the UTM via the NEF through the NIDD path, and the key, 3GPP ID and 3GPP location are sent to the UTM through the CP path.

[0428] For example, LCS information may include 3GPP ID and 3GPP location.

[0429] like Figure 12 As shown, 3GPP combined message delivery can be performed. For example, when an LCS indication is added to the UP delivery NAS message for NIDD, the AMF, SMF, or another NF can generate a public key, and the 3GPP NW can insert this public key into the UP-based application ID and application location, as well as the CP-LCS information, and send it to the NEF.

[0430] like Figure 12 As shown, when the UAV / UAVC specifies the LCS when sending the application ID, application location and 3GPP ID via the NAS message in operation 1241, the AMF, SMF or another NF can generate a public key and send the key, application ID and application location to the UTM(AF) (operation 1243) (operation 1245) simultaneously or continuously via the PCF / NEF (operation 1263) and send the public key and LCS response to the UTM(AF) (operation 1265) via the PCF / NEF (operation 1263).

[0431] Figure 13 The process of authenticating additional UTM services in a UAS service scenario according to various embodiments is illustrated.

[0432] Figure 13 The process of authenticating an additional UTM service is illustrated in the scenario shown in Figure 6D. Figure 11 As shown, after authentication, control over the information transmission path between UAV / UAVC and UTM can be applied at various levels. For example... Figure 11 As shown, three methods can be applied to verify the identification information.

[0433] (1) In the first method, not only the 3GPP ID as 3GPP network-level information, but also the UTM service authorization (Auth.) information and application ID as application-level information can be directly added to the CP's secondary authorization or DN authorization process.

[0434] like Figure 13 As shown, 3GPP NW can perform secondary authorization for additional UTM service authentication through CP, and can perform application-level location verification based on 3GPP-level location.

[0435] like Figure 13As shown, UAV / UAVC performs secondary authorization by sending UAV / UAVC information to UTM(AF) via CP through AMF / UDM (Operation 1311) and PCF / NEF (Operation 1313) (Operation 1315).

[0436] (2) In the second method, a method can be used to send additional UTM service authorization information and application ID as application-level information, and 3GPP ID as 3GPP network-level information, simultaneously or continuously via UP and CP, based on the public key generated by the UE.

[0437] like Figure 13 As shown, after performing additional UTM service authentication through the UTM DNN, DN authorization can be performed on the additional DNN during PDU session establishment, and then application-level location can be verified based on 3GPP-level location.

[0438] like Figure 13 As shown, the public key generated by the UE can be used to simultaneously or continuously send the key and 3GPP ID to the UTM(AF) via the CP via the AMF / UDM and PCF / NEF (Operation 1321 and Operation 1323), and send the key, additional UTM service authentication and application ID to the UTM(AF) via the UP via the UPF (Operation 1331) (Operation 1333).

[0439] (3) In the third method, when the 3GPP ID is specified when sending additional UTM service authorization information and application ID via application-level information during the CIoT 5GS optimization process, the AMF or SMF generates a public key. The key, UAV / UAVC information, and application ID are sent to the UTM via the NEF through the NIDD path, and the key and 3GPP ID are sent to the UTM through the CP path. In this case, if the 3GPP ID used in the NIDD establishment process is the same as the 3GPP ID to be sent through a separate CP path, the transmission process using a separate CP path can be omitted.

[0440] like Figure 13 As shown, after performing additional UTM service authentication via NIDD UP, DN authorization can be performed on the additional DNN during PDU session establishment, and then application-level location can be verified based on 3GPP-level location.

[0441] like Figure 13As shown, when the UAV / UAVC sends additional UTM service authentication, application ID, and 3GPP ID via AMF or SMF (Operation 1341 or 1343), AMF or SMF can generate a public key and simultaneously or continuously send the public key, additional UTM service authentication, and application ID to the UTM(AF) via PCF / NEF (Operation 1345) (Operation 1347), and send the public key and 3GPP ID (e.g., GPSI or IP address) to the UTM(AF) via PCF / NEF (Operation 1353) (Operation 1355).

[0442] In this case, when the 3GPP ID used during NIDD setup is the same as the 3GPP ID to be sent via a separate CP path, the transmission process using a separate CP path can be omitted. For example, 3GPP NW can use NAS to simultaneously send application information and 3GPP information via UP(NIDD), and can use the public key provided by NW. Furthermore, since the 3GPPID is used to configure NIDD, the 3GPP ID can be used instead of the key.

[0443] Using NIDD for traffic transmission means that the 3GPP ID has been included in the transmission process because the NIDD is bound to the 3GPP ID.

[0444] Figure 14 The process of identifying the location information of the UAS during the authentication of the attached UTM service is illustrated in various UAS service scenarios according to different embodiments.

[0445] Figure 14 It shows in Figure 13 The process involves verifying location information and ID. Three methods can be used for this purpose.

[0446] (1) In the first method, the application ID and application location, which are application-level information, can be directly added to the location request process initiated by the CP's mobile.

[0447] like Figure 14 As shown, 3GPP NW can send application information and 3GPP information to UTM(AF).

[0448] Application information may include application ID and application location, and 3GPP information may include 3GPP ID and 3DPP location.

[0449] For example, UAV / UAVC can send the application ID, application location, 3GPP ID, and 3GPP location to UTM(AF) via AMF / UDM (Operation 1411) and PCF / NEF (Operation 1413) as an LCS response (Operation 1415).

[0450] (2) In the second method, a method can be used to send the application ID and application location as application-level information and the 3GPP ID as 3GPP network-level information simultaneously or continuously through UP and CP based on the public key generated by the UE.

[0451] like Figure 14 As shown, 3GPP NW can simultaneously send application information and 3GPP information through CP and UP (including NIDD), and can use keys generated by the UE.

[0452] For example, the key (e.g., application ID and application time) and application location can be sent via UP, and the key (e.g., application ID and application time), 3GPP ID and 3GPP location can be sent via CP.

[0453] like Figure 14 As shown, the public key generated by the UE (operation 1441) can be used to simultaneously or continuously perform the LCS response operation (operation 1435) corresponding to sending the key, 3GPP ID and 3GPP location to the UTM(AF) via AMF / UDM and PCF / NEF (operations 1431 to 1433) through CP, and to send the key, application ID, application time and application location to the UTM(AF) via UPF through UP (operation 1443).

[0454] (3) In the third method, when the LCS is specified when the application ID and application location are sent through application-level information during the CIoT optimization process, the method of generating a public key using AMF or SMF, sending the key, application ID and application location to UTM via NEF through the NIDD path, and sending the key, 3GPP ID and 3GPP location to UTM via the CP path can be used.

[0455] For example, LCS information may include 3GPP ID and 3GPP location.

[0456] like Figure 14 As shown, 3GPP combined message delivery can be performed. For example, when an LCS indication is added to the UP delivery NAS message for NIDD, the AMF, SMF, or another NF can generate a public key, and the 3GPP NW can insert this public key into the UP-based application ID and application location, as well as the CP-LCS information, and send it to the NEF.

[0457] like Figure 14As shown, when the UAV / UAVC specifies the LCS (Operation 1453) when sending the Application ID, Application Location and 3GPP ID via the NAS message, the AMF, SMF or another NF can generate a public key and send the key, Application ID and Application Location to the UTM(AF) simultaneously or continuously via the PCF / NEF (Operation 1455) (Operation 1457), and send the public key and LCS response to the UTM(AF) via the PCF / NEF (Operations 1471 to Operations 1473) (Operation 1457).

[0458] Figure 15 This illustrates the enhanced process for application supervision in UAS service scenarios according to various embodiments.

[0459] Figure 15 The process supporting the scenarios shown in Figures 7A to 7C is illustrated.

[0460] In Operation 1510, the UAV can send additional UTM service authentication to the UTM via the UP.

[0461] After service authentication is complete, monitoring can be performed in operation 1520, and modification / notification can be performed in operation 1530.

[0462] In Operation 1520, the UAV periodically monitors its location and status and reports it to the UTM.

[0463] For example, to ensure that the location meets the requirements for real-time updates, reports can be sent to the UTM more frequently during rapid flight.

[0464] In Operation 1530, the UTM can control the route of the UAV, or it can maintain the connection through which the UTM notifies the UAVC of route modifications, regardless of the command and control (C2) connection between the UAV and the UAVC.

[0465] UTM can send regulatory results to 3GPP NW via CP.

[0466] 3GPP NW can deactivate the PDU session of C2 DN through CP.

[0467] For example, when applying regulatory oversight, a request from UTM can activate the traffic path between the corresponding UAV and the corresponding UAVC via NEF.

[0468] For example,

[0469] Area control:

[0470] 1) UTM can trigger the supervision of UAS operations based on UAV location.

[0471] 2) When regulation is triggered, UTM can send route modification or route modification notification to UAVC and route modification to UAV.

[0472] 3) The UTM can perform takeover control and execute the process of disallowing UAV-UAVC traffic, sending a notification to the UAVC and sending a route modification to the UAV.

[0473] Untrusted area control:

[0474] 1) When the NW's LCS information and the UAV's GPS do not match, the UTM may not authorize (unauthorized) the UAS C2DNN.

[0475] 2) When the NW's LCS information and the UAV's GPS do not match after UAS C2 DNN authorization, a notification can be sent to the UAVC within a predetermined time period.

[0476] 3) When the limit is exceeded, the UTM can consider the UAV unauthorized and execute takeover control. For example, takeover control may include disallowing UAV-UAVC traffic, sending notifications to the UAVC, and sending route modification instructions to the UAV.

[0477] For example, when the NW's LCS information does not match the UAV's or UAVC's GPS (untrusted area control), the UTM can use the LCS information to control the UAV to continue moving until the GPS and LCS match.

[0478] Figure 16 The process of identifying the UAS location in an enhanced process for application monitoring is illustrated in various UAS service scenarios according to different embodiments.

[0479] Figure 16 It shows in Figure 15 The process of updating location information during the process. For this purpose, the following three methods can be applied.

[0480] (1) In the first method, the application ID and application location, which are application-level information, can be directly added to the location request process initiated by the CP's mobile.

[0481] like Figure 16 As shown, 3GPP NW can send application information and 3GPP information to UTM(AF).

[0482] Application information may include application ID and application location, and 3GPP information may include 3GPP ID and 3DPP location.

[0483] For example, UAV / UAVC can send the application ID, application location, 3GPP ID, and 3GPP location to UTM(AF) via AMF / UDM (Operation 1611) and PCF / NEF (Operation 1613) as an LCS response (Operation 1615).

[0484] (2) In the second method, a method can be used to send the application ID and application location as application-level information and the 3GPP ID as 3GPP network-level information simultaneously or continuously through UP and CP based on the public key generated by the UE.

[0485] like Figure 16 As shown, 3GPP NW can simultaneously send application information and 3GPP information through CP and UP (including NIDD), and can use keys generated by the UE.

[0486] For example, the key (e.g., application ID and application time) and application location can be sent via UP, and the key (e.g., application ID and application time), 3GPP ID and 3GPP location can be sent via CP.

[0487] like Figure 16 As shown, the public key generated by the UE can be used to simultaneously or continuously perform the LCS response operation (operation 1625) corresponding to sending the key, 3GPP ID and 3GPP location to the UTM(AF) via AMF / UDM and PCF / NEF (operations 1621 to 1623) through CP (operation 1631), and to send the key, application ID, application time and application location to the UTM(AF) via UPF (operation 1631) through UP (operation 1633).

[0488] (3) In the third method, when the LCS is specified when the application ID and application location are sent through application-level information during the CIoT optimization process, the method of generating a public key using AMF or SMF, sending the key, application ID and application location to UTM via NEF through the NIDD path, and sending the key, 3GPP ID and 3GPP location to UTM via the CP path can be used.

[0489] For example, LCS information may include 3GPP ID and 3GPP location.

[0490] like Figure 16 As shown, 3GPP combined message delivery can be performed. For example, when an LCS indication is added to the UP delivery NAS message for NIDD, the AMF, SMF, or another NF can generate a public key, and the 3GPP NW can insert this public key into the UP-based application ID and application location, as well as the CP-LCS information, and send it to the NEF.

[0491] like Figure 16 As shown, when the UAV / UAVC specifies the LCS (Operation 1641) when sending the application ID, application location and 3GPP ID via the NAS message, the AMF, SMF or another NF can generate a public key and send the key, application ID and application location to the UTM(AF) simultaneously or continuously via the PCF / NEF (Operation 1643) (Operation 1645), and send the public key and LCS response to the UTM(AF) via the PCF / NEF (Operation 1663) (Operation 1665).

[0492] Figure 17 The process of sending proximity-based service (ProSe) configuration information to a UTM for ID broadcasting and broadcast communication in a UAV service scenario according to various embodiments is illustrated.

[0493] Figure 17 The process supporting the scenarios shown in Figures 8A to 8B is illustrated. The UTM needs to store the UE's D2D_ID and D2D configuration, which can also be supported through three methods.

[0494] (1) In the first method, the application ID, which is application-level information, can be directly added to the ProSe configuration request process that notifies the 3GPP ID, D2D_ID and D2D_Conf information, which are 3GPP network-level information.

[0495] like Figure 17 As shown, 3GPP NW can send application information and 3GPP information to UTM(AF). The application information may include the application ID, and the 3GPP information may include the 3GPP ID, D2D_ID, and D2D configuration.

[0496] For example, UAV / UAVC can send the application ID, D2D_ID, 3GPP ID and D2D_Conf as ProSe configuration to UTM(AF) via AMF / UDM (Operation 1711) and ProSe / NEF (Operation 1713) (Operation 1715).

[0497] (2) In the second method, a method can be used to send application ID as application-level information, 3GPP ID, D2D_ID and D2D_Conf information as 3GPP network-level information, simultaneously or continuously via UP and CP based on the public key generated by the UE.

[0498] like Figure 17 As shown, 3GPP NW can simultaneously send application information and 3GPP information through CP and UP (including NIDD), and can use keys generated by the UE.

[0499] For example, the key (e.g., application ID and application time) and D2D_Conf can be sent via UP, and the key (e.g., application ID and application time), 3GPP ID and D2D_Conf can be sent via CP.

[0500] (3) In the third method, when the application ID is sent through application-level information during the CIoT 5GS optimization process, the ProSe instruction is specified, the AMF or SMF generates a public key, and sends the key and application ID to the UTM via the NEF through the NIDD path, and sends the key, 3GPP ID, D2D_ID and D2S configuration to the UTM through the CP path.

[0501] like Figure 17 As shown, it can perform the information transmission of 3GPP combinations.

[0502] For example, when a D2D indicator is added to the UP delivery NAS message for NIDD, the AMF, SMF, NEF, or another NF can generate a public key, and the 3GPP NW can insert this public key into the UP-based application ID, the CP-based 3GPPID, D2D_ID, and D2D_Conf information, and send it to the NEF.

[0503] like Figure 17 As shown, when the UAV / UAVC specifies ProSe (Operation 1741) when sending the Application ID, D2D_ID and 3GPP ID via NAS message, the AMF, SMF or another NF can generate a public key and send the key and Application ID to the UTM(AF) simultaneously or continuously via PCF / NEF (Operation 1743) (Operation 1745), and send the public key, 3GPP ID, D2D_ID and D2D_Conf information to the UTM(AF) via PCF / NEF (Operation 1761) (Operation 1763).

[0504] For example, it is necessary to send the D2D_ID to UTM in Operation 1745. This is because both the UAS and 3GPP NW know the D2D_ID, so both can send the same D2D_ID to the network device performing UTM, and the network device performing UTM can determine that this information is reliable. In other words, the application may need to send both the application ID and D2D_ID to the network device performing UTM, and 3GPP may need to send both the 3GPP ID and D2D_ID to the network device performing UTM.

[0505] In other words, the correlation between two transmissions can mean that the binding between the application ID and the 3GPP ID can be determined to be reliable, and a separate public key can be provided for the correlation, or the public key can be the 3GPP ID.

[0506] For example, in Operation 1745, the Application ID and D2D_ID are required, and the 3GPP ID or key is used to link with CP-level information. The 3GPP ID may not exist if the key is present. D2D information sent at the application level can be verified as 3GPP-level information. The 3GPP ID and D2D_ID can be sent to the UTM using only the Application ID and key, but verification with the corresponding UTM known to be the same / different from the application may be weak.

[0507] Figure 18 This is a flowchart illustrating the process by which a network device in a wireless communication system performs Unmanned Aircraft System (UAS) traffic management (UTM) functions according to various embodiments.

[0508] In Operation 1800, network devices performing UTM can simultaneously or continuously acquire application-level information related to the UE and network-level information related to the network.

[0509] Network-level information can be received from network devices that perform network exposure functions (NEF) included in the wireless communication system.

[0510] For example, application-level information and network-level information can be received simultaneously from the network device performing NEF through the control plane (CP).

[0511] For example, application-level information and public keys can be received from a network device (UPF) performing user-plane functions or a network device performing NEF through the user plane (UP), and network-level information and public keys can be received from a network device performing NEF through the control plane (CP).

[0512] According to various embodiments, the public key can be generated by a UE or network device that performs a wireless communication system including another NF.

[0513] For example, the public key generated by the UE and application-level information can be received from the network device performing the UPF via the user plane (UP).

[0514] In addition, the public key and application-level information generated by the network device executing another NF can be received from the network device executing NEF via the user plane (UP).

[0515] In Operation 1810, network devices performing UTM can verify application-level information based on network-level information.

[0516] Figure 19 This is a flowchart illustrating the process by which a UE transmits information from an unmanned aerial system (UAS) in a wireless communication system.

[0517] In Operation 1900, the UE can recognize application-level information.

[0518] In Operation 1910, the UE can send a request message, including application-level information, to the network device performing the Access and Mobility Management Function (AMF).

[0519] The request message, according to various embodiments, may include information requesting network-level information and may be sent via the control plane (CP).

[0520] Application-level and network-level information can be obtained simultaneously or continuously from network devices that perform UAS traffic management (UTM) functions included in the wireless communication system.

[0521] Based on request messages, application-level information and network-level information can be simultaneously sent from network devices performing network exposure functions (NEF) in wireless communication systems to network devices performing UAS traffic management (UTM) functions via the control plane (CP).

[0522] The public key can be generated by the network device performing AMF based on a request message. In this case, the public key and application-level information can be sent from the network device performing Network Exposure Function (NEF) in the wireless communication system to the network device performing UAS Traffic Management (UTM) via the user plane (UP), and the key and network-level information can be sent from the network device performing NEF to the UTM via the control plane (CP).

[0523] Figure 20 This is a flowchart illustrating the process by which a UE transmits information from an unmanned aerial system (UAS) in a wireless communication system.

[0524] In Operation 2000, the UE can recognize application-level information.

[0525] In Operation 2010, the UE can generate a public key.

[0526] In Operation 2020, the UE can send public keys and application-level information to network devices performing User Plane Functions (UPF) via the User Plane (UP).

[0527] Public keys and application-level information can be sent from the User Plane Function (UPF) to network devices performing UAS traffic management (UTM) functions via the User Plane (UP).

[0528] In Operation 2030, the UE can send a request for a public key and network-level information to the network device performing the Access and Mobility Management Function (AMF) via the control plane (CP).

[0529] Based on this information, public keys and network-level information can be transmitted from network devices performing Network Exposure Function (NEF) in wireless communication systems to network devices performing UAS Traffic Management (UTM) functions via the control plane (CP).

[0530] Figure 21 This is a block diagram illustrating a network device 2100 that performs UAS traffic management (UTM) functions according to various embodiments.

[0531] like Figure 21 As shown, a network device implementing UTM according to various embodiments may include a transceiver 2110, a controller 2120, and a storage unit 2130 (e.g., a memory). In this disclosure, the controller 2120 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0532] These components will be described in turn below.

[0533] Transceiver 2110 according to various embodiments can send signals, information and data to another network entity and receive signals, information and data from another network entity according to various embodiments.

[0534] According to various embodiments, transceiver 2110 can receive application-level information or 3GPP network-level information from a network entity, and receive a public key generated by the UE or the network entity.

[0535] In addition, in UAS service scenarios, transceiver 2110 can receive messages related to ID broadcast / broadcast communication from network entities through authorization / monitoring / local broadcast.

[0536] For example, transceiver 2110 can receive network-level information from network devices included in a wireless communication system that perform network exposure functions (NEF).

[0537] Transceiver 2110 can simultaneously receive application-level and network-level information from network devices performing NEF via the control plane (CP).

[0538] The public key can be generated by a UE or network device that performs another NF in a wireless communication system.

[0539] In this scenario, transceiver 2110 can receive application-level information and public keys generated by user equipment from network devices performing user plane functions (UP) via the user plane (UP).

[0540] In addition, transceiver 2110 can receive application-level information and public keys generated by network devices performing NEF from the user plane (UP) of the network device performing NEF.

[0541] In addition, transceiver 2110 can receive network-level information and public keys from network devices performing NEF via the control plane (CP).

[0542] According to various embodiments provided in this disclosure, the controller 2120 according to various embodiments can control the overall operation of network devices performing UTM.

[0543] For example, controller 2120 can control the signal flow between blocks to perform operations according to the flowchart above.

[0544] At least one controller 2120 according to various embodiments can simultaneously or continuously acquire application-level information related to the UE and network-level information related to the network.

[0545] At least one controller 2120 according to various embodiments can verify application-level information based on network-level information.

[0546] According to various embodiments, the memory 2130 may store at least one of the information transmitted and received by the transceiver 2110 and the information generated by the controller 2120. For example, the memory 2130 provides UAS identification, UAS tracking, UAS operation authorization, execution, and supervision, and stores information required for UAS operation. Furthermore, the memory 2130 may store D2D_ID, application-level ID, GPSI, IP address, or NIDD ID.

[0547] For example, memory 2130 may include a memory and may store data for operating a network device performing UTM according to various embodiments, such as basic programs, applications, and configuration information. Furthermore, the memory may include at least one type of storage medium selected from flash memory, hard disk, multimedia card micro, card-type memory (e.g., SD memory, XD memory, etc.), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static RAM (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable ROM (EEPROM). The processor can use various programs, contents, and data stored in the memory to perform various operations.

[0548] Although not shown, each network entity according to the embodiments may also include at least one of a transceiver, a controller, or a memory.

[0549] Figure 22This is a block diagram illustrating a user equipment (UE) according to various embodiments.

[0550] The UE may include an unmanned aerial vehicle (UAV) or a UAV controller (UAVC).

[0551] like Figure 22 As shown, the UE 2200 according to various embodiments may include a transceiver 2210, a controller 2220, and a memory 2230. In this disclosure, the controller 2220 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0552] These components will be described in turn below.

[0553] Transceiver 2210 according to various embodiments can send signals, information and data to another network entity and receive signals, information and data from another network entity according to various embodiments.

[0554] According to various embodiments, transceiver 2210 can send application-level information or 3GPP network-level information to network entities, and can send public keys generated by the UE.

[0555] In addition, in UAS service scenarios, transceiver 2210 can send messages related to ID broadcast / broadcast communication to network entities through authorization / monitoring / local broadcast.

[0556] According to the various embodiments provided in this disclosure, the controller 2220 according to the various embodiments can control the overall operation of the UE.

[0557] For example, controller 2220 can control the signal flow between blocks to perform operations according to the flowchart above.

[0558] According to various embodiments, the controller 2220 can recognize application-level information.

[0559] According to various embodiments, controller 2220 can perform control to send request messages, including application-level information, to network devices that perform access and mobility management functions (AMF).

[0560] In this case, the request message may include information requesting network-level information and may be sent via the control plane (CP).

[0561] According to various embodiments, application-level information and network-level information can be simultaneously or continuously acquired by network devices included in wireless communication systems that perform unmanned aerial system (UAS) traffic management (UTM) functions.

[0562] For example, application-level information and network-level information can be simultaneously sent from network devices performing network exposure functions (NEF) in wireless communication systems to network devices performing UAS traffic management (UTM) functions via the control plane (CP) based on request messages.

[0563] For example, the public key can be generated by the network device performing AMF based on a request message. In this case, the public key and application-level information can be sent from the network device performing Network Exposure Function (NEF) in the wireless communication system to the network device performing UAS Traffic Management (UTM) via the user plane (UP), and the key and network-level information can be sent from the network device performing NEF to the network device performing UTM via the control plane (CP).

[0564] According to various embodiments, the controller 2220 can generate a public key.

[0565] According to various embodiments, the controller 2220 can perform control to send public keys and application-level information via the user plane (UP) to a network device performing user plane functions (UPF). In this case, public keys and application-level information can be sent from the user plane function (UPF) to a network device performing UAS traffic management (UTM) functions via the user plane (UP).

[0566] According to various embodiments, the controller 2220 can control the transceiver 2210 to send a request for a public key and network-level information to a network device performing Access and Mobility Management (AMF) functions via the control plane (CP). In this case, based on this information, the public key and network-level information can be sent via the control plane (CP) from a network device performing Network Exposure Function (NEF) functions included in a wireless communication system to a network device performing UAS Traffic Management (UTM) functions.

[0567] According to various embodiments, the memory 2230 may store at least one of the information sent and received by the transceiver 2210 and the information generated by the controller 2220.

[0568] For example, according to various embodiments, memory 2230 can store data for UE operation, such as basic programs, applications, and configuration information. Furthermore, the memory can include at least one type of storage medium selected from flash memory, hard disk, multimedia card micro, card-type memory (e.g., SD memory, XD memory, etc.), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static RAM (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable ROM (EEPROM). The processor can use various programs, contents, and data stored in the memory to perform various operations.

[0569] The methods of the embodiments set forth in the claims or specification of this disclosure may be implemented in hardware, software, or a combination of hardware and software.

[0570] In a software implementation, a computer-readable storage medium may be provided for storing one or more programs (software modules). The one or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. The one or more programs may include instructions for allowing the electronic device to perform methods according to the embodiments set forth in the claims or specification of this disclosure.

[0571] The program (software module or software) can be stored in non-volatile memory, including random access memory, flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, compact disc ROM (CD-ROM), digital versatile disc (DVD), other types of optical storage devices, or magnetic tape cartridges. Alternatively, the program can be stored in memory configured with a combination of some or all of the listed components. Furthermore, the number of configured memories can be multiple.

[0572] Furthermore, the program can be stored in an attachable storage device that can be accessed by the electronic device via a communication network (such as the Internet, intranet, local area network (LAN), wireless LAN (WLAN), and storage area network (SAN) or a combination thereof). The storage device can access the device implementing the embodiment via an external port. Additionally, a separate storage device within the communication network can access the device implementing the embodiment.

[0573] In the detailed embodiments described above, the number of elements included in this disclosure is expressed in a singular or plural form according to the presented detailed embodiments. However, the singular or plural form was chosen for the sake of describing the suitability of the presented situation, and the various embodiments are not limited to a single element or multiple elements thereof. Furthermore, multiple elements represented in the specification may be configured as a single element, or a single element in the specification may be configured as multiple elements.

[0574] Furthermore, although specific embodiments of this disclosure have been described in detail herein, various modifications may be made without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the embodiments, but rather should be defined by the appended claims and their equivalents.

[0575] It should be understood that this disclosure is not intended to be limited to the various embodiments and terminology used herein, but includes various modifications, equivalents, and / or substitutions of the corresponding embodiments. When describing the drawings, similar reference numerals may be used to denote similar elements. Singular expressions may include plural expressions unless they are clearly different in the context. In this disclosure, the expressions “A or B,” “at least one of A and / or B,” “A, B, or C,” or “at least one of A, B, and / or C” may include all available combinations of the listed items. The expressions “first” or “second” may modify the corresponding elements regardless of their order or importance and are used only to distinguish one component from another, without limiting the corresponding components. When any (e.g., first) component is stated to be “(functionally or communicatively) coupled” or “connected” to another (e.g., second) component, any component may be directly coupled to the other component or may be connected through yet another component (e.g., a third component).

[0576] As used in this disclosure, the term "module" can include a unit comprising hardware, software, or firmware, and may be compatible with terms such as "logic," "logic block," "component," or "circuit." A module can be an integrated component, the smallest unit performing one or more functions, or a portion thereof. For example, a module can be implemented as an application-specific integrated circuit (ASIC).

[0577] Various embodiments of this disclosure can be implemented by software (e.g., a program) including instructions stored in a machine-readable (e.g., computer-readable) storage medium (e.g., internal or external memory). According to various embodiments, a device can load stored instructions from the storage medium and operate according to the loaded instructions, and may include an auxiliary BS or UE. When the instructions are executed by a processor (e.g., Figure 21 When the controller 2120 or 2220 of 22 is executed, the processor may directly execute the function corresponding to the instruction, or the function may be executed by other components under the control of the processor. Instructions may include code generated or executed by a compiler or interpreter.

[0578] Machine-readable storage media may be provided in the form of non-volatile storage media. The term "non-volatile" means that the storage medium does not contain signals and is tangible, but does not include semi-permanent storage and temporary storage that distinguishes data in the storage medium.

[0579] The methods according to various embodiments can be provided in a state included in a computer program product. The computer program product can be traded as a product between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., a compact disk read-only memory (CD-ROM)) or through an app store (e.g., the Play Store). TM Online distribution. In the case of online distribution, at least some of the computer program products may be temporarily stored in storage media such as the memory of a manufacturer's server, an app store server, or a relay server, or may be temporarily generated.

[0580] Each of the components (e.g., modules or programs) according to various embodiments may be configured as a single entity or multiple entities, and some of the corresponding sub-components may be omitted, or other sub-components may be further included in the various embodiments. Alternatively or additionally, some components (e.g., modules or programs) may be integrated into one entity and perform the functions equivalently or similarly to those performed by the corresponding components prior to integration. Operations performed by modules, programs, or other elements according to various embodiments may be performed sequentially, in parallel, repeatedly, or heuristically. At least some operations may be performed according to others, may be omitted, or may include other operations.

[0581] According to reference Figure 1 to Figure 22 The methods described in the various embodiments may include methods performed by a combination of one or more drawings according to the various embodiments.

[0582] For example, Figure 1 to Figure 22 The diagram illustrates operations related to methods for sending and receiving application-level information or 3GPP network-level information, and may include methods that combine one or more figures according to various embodiments.

[0583] Although this disclosure has been described with reference to various embodiments, various changes and modifications will be apparent to those skilled in the art. This disclosure is intended to include such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method performed by an Access and Mobility Management Function (AMF) entity in a wireless communication system, the method comprising: Receive a registration request message from the User Equipment (UE) including the identifier ID of the Unmanned Aerial Vehicle (UAV), where the UE is the UAV or a UAV controller associated with the UAV; Receive UE subscription data from the Unified Data Management (UDM); Perform UAV certification; as well as If the UE has valid over-the-air subscription information or the UE has provided the UAV ID, determine the authentication and authorization required for the Unmanned Aerial Vehicle System Flow Management (UTM) to support the UAV.

2. A method performed by an Unmanned Aerial System-Network Function (UAS-NF) entity in a wireless communication system, the method comprising: The Access and Mobility Management Function (AMF) receives an authentication request message, which includes a General Public Subscription Identifier (GPSI) and an Unmanned Aerial Vehicle (UAV) Identifier ID. as well as Send an authentication request message, including GPSI and UAV ID, to the Unmanned Aerial Vehicle System Traffic Management (UTM) entity.

3. The method according to claim 2, wherein, The authentication request message also includes user location information.

4. The method according to claim 3, wherein, User location information is the community ID.

5. A method performed by an authorization of a Network Exposure Function (NEF) entity in a wireless communication system, the method comprising: Receive an authentication request message from the Session Management Function (SMF), including the UAV identifier ID of the unmanned aerial vehicle (UAV). as well as Send an authentication request message to the Unmanned Aerial Vehicle System Traffic Management (UTM) entity.

6. A method executed by an authorization of a Session Management Function (SMF) entity in a wireless communication system, the method comprising: Receive an authentication request message from the unmanned aerial vehicle (UAV), the authentication request message including the UAV identifier ID and information related to command and control (C2) communication; Perform the certification process for Unmanned Aerial Vehicle (UAV) flow management UTM entities; and Receive authorization information for C2 communication from the UTM entity, including the IP address of the UAV controller UAVC.

7. The method according to claim 6, wherein, Information related to C2 communications includes flight authorization information.

8. The method according to claim 6, wherein, The authentication request message also includes Unmanned Aerial System (UAS) information. The UAS information includes the cell ID that indicates the location of the UAV.

9. A method performed by a Session Management Function (SMF) entity in a wireless communication system, the method comprising: Receive a request message for command and control C2 communication from the user equipment (UE), the request message including the unmanned aerial vehicle (UAV) identifier ID; Send an authentication request message, including the UAV's address, to the Unmanned Aerial Vehicle System Traffic Management (UTM) entity; and Receive authorization information for C2 communication from the UTM entity, including the IP address of the UAV controller UAVC.

10. The method according to claim 9, wherein, The address of a UAV is its IP address.

11. The method according to claim 9, wherein, The authorization information also includes the location information of the UAV. The location information of the UAV is the cell ID.

Images