CONCESION DE CONECTIVIDAD ENTRE UN UAV Y UN UAV-C.

Abstract

Apparatus, methods, and systems for enabling connectivity between a UAV and a UAV-C are disclosed. One method (700) includes receiving (702), in a network function, a first request from a first USS. The first request indicates replacing a first UAV-C with a first UAV, and the first request includes an IP address of the first UAV, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. The method (700) also includes transmitting (704) a second request to a policy control function. The second request includes a request to activate policies to enable connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information.

Description

CONNECTIVITY GRANT BETWEEN A UAV AND A UAV-C. Rcnr Ln / eznz / e / YiAi CROSS REFERENCE TO RELATED APPLICATIONS The present application claims priority to United States Patent Application Serial Number 63 / 184,421 entitled APPARATUS, METHODS, AND SYSTEMS FOR PROVIDING MATCHING POLICIES TO REPLACE A UAV CONTROLLER and filed on May 5, 2021 by Dimitrios Karampatsis et al., which is incorporated herein by reference in its entirety. FIELD OF INVENTION The subject matter disclosed herein generally refers to wireless communications and more particularly to enabling connectivity between a UAV and a UAVC. BACKGROUND OF THE INVENTION In certain wireless communication networks, UAVs can be used within a system. In such networks, various UAS actions may not function efficiently and / or with sufficient capacity. BRIEF DESCRIPTION OF THE INVENTION Methods for enabling connectivity between a UAV and a UAV-C are disclosed. Devices and systems also perform the functions of the methods. One modality of a method includes receiving, in a network function, a first request from a first USS. The first request indicates replacing a first UAV-C with a first UAV, and the first request includes the IP address of the first UAV, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. In some modalities, the method includes transmitting a second request to a policy control function. The second request includes a request to activate policies to enable connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. An apparatus for enabling connectivity between a UAV and a UAV-C includes user equipment. In some configurations, the apparatus includes a receiver to receive a first request from a first UAV-C. The first request requests the replacement of a first UAV-C with a first UAV and includes the IP address of the first UAV, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. In several configurations, the apparatus includes a transmitter to send a second request to a policy control function. The second request includes a request to activate policies to enable connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. Another method for enabling connectivity between a UAV and a UAV-C involves receiving, in a policy control function, a second request from a network function. This second request includes a request to activate policies that allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers. In some versions, the method includes transmitting an initial response to the network function. This initial response includes an acknowledgment of the second request. Another device for enabling connectivity between a UAV and a UAV-C includes user equipment. In some configurations, this equipment includes a receiver to receive a second request for a network function. The second request includes a request to activate policies that allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers. In several configurations, the equipment includes a transmitter to send an initial response to the network function. The initial response includes an acknowledgment of the second request. BRIEF DESCRIPTION OF THE DRAWINGS A more detailed description of the modalities briefly described above will be provided with reference to specific modalities illustrated in the accompanying figures. Understanding that these figures represent only some modalities and should therefore not be considered limiting in scope, the modalities will be described and explained with additional specificity and detail using the accompanying figures, in which: Figure 1 is a schematic block diagram illustrating one modality of a wireless communication system to enable connectivity between a UAV and a UAV-C; Figure 2 is a schematic block diagram illustrating one modality of an apparatus that can be used to enable connectivity between a UAV and a UAV-C; Figure 3 is a schematic block diagram illustrating one modality of an apparatus that can be used to enable connectivity between a UAV and a UAV-C; Figure 4 is a schematic block diagram illustrating one mode of a system for informing a 5GC about a replaced UAV-C; Figure 5 is a schematic block diagram that illustrates another modality of a system for informing a 5GC about a replaced UAV-C; Figure 6 is a schematic block diagram illustrating one mode of a system in which an SMF determines when to request policies for UAS operations from a PCF; Figure 7 is a flowchart illustrating one modality of a method for enabling connectivity between a UAV and a UAV-C; and Rcnr Ln / eznz / e / YiAi Figure 8 is a flowchart that illustrates another modality of a method for enabling connectivity between a UAV and a UAV-C. DETAILED DESCRIPTION OF THE INVENTION As will be appreciated by an expert in the field, the aspects of modalities can be embodied as a system, apparatus, method, or program product. Consequently, modalities can take the form of a complete hardware modality, a complete software modality (including firmware, resident software, microcode, etc.), or a modality that combines software and hardware aspects, all of which are generally referred to herein as a “circuit,” “module,” or “system.” Furthermore, modalities can take the form of a program product embedded in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transient, and / or non-transmitting. It is possible that the storage devices do not embody signals.In some models, storage devices only use signals to access the code. Some of the functional units described in this specification may be labelled as modules to further emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, readily available semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented on programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, or the like. Modules can also be implemented in code and / or software for execution by various types of processors. An identified code module may, for example, include one or more physical or logical blocks of executable code that can be, for example, organized as an object, procedure, or function. However, the executables of an identified module need not be physically located together; they may include disparate instructions stored in different locations that, when logically combined, comprise the module and achieve the module's stated purpose. In fact, a code module can be a single instruction, or many instructions, and can even be distributed across several different code segments, among different programs, and across various memory devices. Similarly, operational data can be identified and illustrated within modules, and can be incorporated in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single data set or distributed Rcnr Ln / eznz / e / YiAi in different locations, even on different computer-readable storage devices. When a module or parts of a module are implemented in software, the software parts are stored on one or more computer-readable storage devices. Any combination of one or more computer-readable media may be used. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device that stores the code. The storage device may be, for example, without limitation, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of storage devices would include the following: an electrical connection having one or more wires, a laptop floppy disk, a hard disk, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc with read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this document, a computer-readable storage medium may be any tangible medium capable of containing or storing a program for use by or in connection with an instruction-executing system, apparatus, or device. The code to perform operations for different modalities can be any number of lines long and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or similar, and conventional procedural programming languages ​​such as C or similar, and / or machine languages ​​such as assembly language. The code can run entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In this latter scenario, the remote computer can connect to the user's computer through any type of network, including a local area network (“LAN”) or a wide area network (“WAN”), or the connection can be made to an external computer (e.g., via the Internet using an Internet service provider). Reference throughout this specification to a modality, modality, or similar language means that a particular feature, structure, or characteristic described together with Rcnr Ln / eznz / e / YiAi The modality is included in at least one modality. Therefore, occurrences of the phrases “in a modality,” “in a modality,” and similar language throughout this specification may, but do not necessarily, all refer to the same modality, but mean “one or more but not all modalities” unless expressly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated list of items does not imply that any or all of the items are mutually exclusive unless expressly specified otherwise. The terms “a,” “an,” and “the” also mean “one or more” unless expressly specified otherwise. Furthermore, the peculiarities, structures, or characteristics of the modalities can be combined in any suitable way. In the following description, several specific details are provided, such as programming examples, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a comprehensive understanding of the modalities. An expert in the field will recognize, however, that the modalities can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid complicating aspects of a modality. Aspects of the modalities are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the modalities. It is understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data-processing apparatus to produce a machine, such that the instructions, which are executed through the processor of the computer or other programmable data-processing apparatus, create means to implement the functions / actions specified in the schematic flowcharts and / or block diagrams or schematic blocks. The code can also be stored on a storage device that can be directed by a computer, another programmable data processing device, or other devices that operate in a particular way, so that the instructions Rcnr Ln / eznz / e / YiAi stored on the storage device produce a manufactured item that includes the instructions which implement the function / action specified in the schematic flowcharts and / or block diagrams or schematic blocks. The code can also be loaded into a computer, other programmable data processing device, or other devices to cause a series of operational steps to be performed on the computer, other programmable device, or other devices to produce a computer-implemented process such that the code which is executed on the computer or other programmable device provides processes to implement the functions / actions specified in the flowchart and / or block diagram(s). The schematic flowcharts and / or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various modalities. In this sense, each block in the schematic flowcharts and / or schematic block diagrams can represent a module, segment, or portion of code, which includes one or more executable code instructions to implement the specified logical function or functions. It should also be noted that, in some alternative implementations, the functions annotated in the block may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed considerably concurrently; the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods can be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, in the illustrated figures. Although various arrow and line types can be used in flowcharts and / or block diagrams, it is understood that they do not limit the scope of the corresponding modes. In fact, some arrows or other connectors can be used to indicate only the logical flow of the illustrated mode. For example, an arrow might indicate a waiting or monitoring period of unspecified duration between the listed steps of the represented mode. It should also be noted that each block in block diagrams and / or flowcharts, and combinations of blocks within block diagrams and / or flowcharts, can be implemented through special-purpose hardware-based systems that perform the specified functions or actions, or combinations of special-purpose hardware or code. The description of the elements in each figure may refer to elements in previous figures. Like numbers refer to similar elements in all figures, including alternative forms of similar elements. Rcnr Ln / eznz / e / YiAi Figure 1 shows one embodiment of a wireless communication system 100 for enabling connectivity between a UAV and a UAV-C. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Although a specific number of remote units 102 and network units 104 are depicted in Figure 1, a person skilled in the art will recognize that any number of remote units 102 and network units 104 can be included in the wireless communication system 100. In one configuration, remote units 102 may include computing devices such as desktop computers, laptops, personal digital assistants (“PDAs”), tablet computers, smartphones, smart televisions (e.g., internet-connected televisions), television set-top boxes, video game consoles, security systems (including security cameras), vehicle-onboard computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones (e.g., UAV 106, UAV-C 108), or similar devices. In some configurations, remote units 102 include wearable devices such as smartwatches, fitness trackers, head-mounted optical displays, or similar devices.Furthermore, remote units 102 may be referred to as subscriber units, mobile units, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user equipment (“UE”), user terminals, a device, or other terminology used in the art. Remote units 102 may communicate directly with one or more network units 105 via UL communication signals. In some configurations, remote units 102 may communicate directly with other remote units 102 via sidelink communication. The 104 network units can be distributed across a geographical region. In some modalities, a 104 network unit may also be referred to as and / or may include one or more of an access point, an access terminal, a base, a base station, a location server, a core network (“CN”), a radio network entity, a Node B, an evolved Node B (“eNB”), a 5G Node B (“gNB”), a home Node B, a relay node, a device, a core network, an air server, a radio access node, an access point (“AP”), a new radio (“NR”), a network entity, an access and mobility management function (“AMF”), a unified data management (“UDM”), a unified data repository (“UDR”), a UDM / UDR, a policy control function (“PCF”), a radio access network (“RAN”), a network segment selection function (“NSSF”), an operations, administration, and management function (“OAM”), a session management function (“SMF”),a user plane function (“UPF”), an application function, an authentication server function (“AUSF”), security anchor functionality (“SEAF”), non-3GPP trusted gateway function, Rcnr Ln / eznz / e / YiAi (“TNGF”) or any other terminology used in the art. 104 network units are generally part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding 104 network units. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, such as the Internet and public switched telephone networks, among others. These and other elements of radio access and core networks are not illustrated, but are generally well known to those experienced in the art. In one implementation, the wireless communication system 100 complies with the NR protocols standardized in the third generation partnership project (“3GPP”), where the network unit 104 transmits using an OFDM modulation scheme on the downlink (“DL”) and the remote units 102 transmit on the uplink (“UL”) using either a single carrier frequency division multiple access scheme (“SCFDMA”) or an orthogonal frequency division multiplexing (OFDM) scheme.More generally, however, the Wireless 100 communication system may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Long-Term Evolution (LTE) variants, Code Division Multiple Access 2000 (CDMA2000), Bluetooth®, ZigBee, Sigfoxx, among others. This disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. Network units 104 can serve a number of remote units 102 within a service area, such as a cell or cell sector, via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and / or spatial domains. In several modes, a 104 network unit can receive, in a network function, a first request from a first UAS. The first request indicates replacing a first UAV-C with a first UAV, and the first request includes the IP address of the first UAV, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. In some modes, the 104 network unit can transmit a second request to a policy control function. The second request includes a request to activate policies to allow connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. As a result, the 104 network unit can be used to enable connectivity between a UAV and a UAV-C. In certain modes, a network unit 104 can receive a second request from a network function during a policy control function. This second request includes a request to activate policies that allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers. In some modes, the network unit 104 can transmit an initial response to the network function. This initial response includes an acknowledgment of the second request. Consequently, the network unit 104 can be used to enable connectivity between a UAV and a UAV-C. Figure 2 shows one modality of an apparatus 200 that can be used to enable connectivity between a UAV and a UAV-C. The apparatus 200 includes one modality of the remote unit 102 (e.g., UAV 106, UAV-C 108). In addition, the remote unit 102 may include a processor 202, a memory 204, an input device 206, a display 208, a transmitter 210, and a transceiver 212. In some modalities, the input device 206 and the display 208 are combined into a single device, such as a touchscreen. In certain configurations, the remote unit 102 may not include any input device 206 and / or display 208. In various configurations, the remote unit 102 may include one or more of: the processor 202, the memory 204, the transmitter 210 and the transceiver 212, and may not include the input device 206 and / or the display 208. In one configuration, the processor 202 can include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 202 can be a microcontroller, a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processing unit, a field-programmable gate array (FPGA), or a similar programmable controller. In some configurations, the processor 202 executes instructions stored in memory 204 to perform the methods and routines described herein. The processor 202 is communicatively coupled to memory 204, input device 206, display 208, transmitter 210, and receiver 212. Memory 204, in one form, is a computer-readable storage medium. In some forms, memory 204 includes volatile computer storage media. For example, memory 204 may include RAM, which includes dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some forms, memory 204 includes non-volatile computer storage media. For example, memory 204 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. Rcnr Ln / eznz / e / YiAi volatile and non-volatile. In some modes, memory 204 also stores program code and related data, such as an operating system or other driver algorithms that operate on the remote unit 102. Input device 206, in one configuration, may include any known computer input device, including a touchpad, button, keyboard, stylus, microphone, or similar device. In some configurations, input device 206 may be integrated with display 208, for example, as a touchscreen or similar touch display. In some configurations, input device 206 includes a touchscreen so that text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some configurations, input device 206 includes two or more different devices, such as a keyboard and a touchpad. Display 208, in one embodiment, may include any known electronically controlled display or display device. Display 208 may be designed to emit visual, audible, and / or haptic signals. In some embodiments, Display 208 includes an electronic display capable of emitting visual data to a user. For example, Display 208 may include, but is not limited to, a liquid crystal display (“LCD”), a light-emitting diode (“LED”) display, an organic light-emitting diode (“OLED”) display, a projector, or a similar display device capable of emitting images, text, or the like to a user. As another, non-limiting example, Display 208 may include a wearable display such as a smartwatch, smart glasses, a head-up display, or the like.In addition, the 208 display can be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a laptop computer, a personal computer, a vehicle dashboard, or similar devices. In certain configurations, the 208 display includes one or more speakers to produce sound. For example, the 208 display can produce an audible alert or notification (e.g., a beep or buzzer). In some configurations, the 208 display includes one or more haptic devices to produce vibrations, movement, or other haptic feedback. In some configurations, all or portions of the 208 display can be integrated with the 206 input device. For example, the 206 input device and the 208 display can form a touchscreen or similar display. In other configurations, the 208 display can be located near the 206 input device. Although only one 210 transmitter and one 212 receiver are illustrated, the 102 remote unit can have any suitable number of 210 transmitters and 212 receivers. The 210 transmitter and 212 receiver can be any suitable type of transmitter and receiver. In one configuration, the 210 transmitter and 212 receiver can be part of a transceiver. Figure 3 shows one modality of a 300 device that can be used for Rcnr Ln / eznz / e / YiAi enables connectivity between a UAV and a UAV-C. Apparatus 300 includes a mode of network unit 104. In addition, network unit 104 may include a processor 302, a memory 304, an input device 306, an output device 310, and a transceiver 312. As can be seen, the processor 302, memory 304, input device 306, display 308, transmitter 310, and receiver 312 may be substantially similar to the processor 202, memory 204, input device 206, display 208, transmitter 210, and receiver 212 of remote unit 102, respectively. In certain modes, receiver 312 may receive a first request from a first USS. The first request indicates replacing a first UAV-C with a first UAV, and the first request includes the first UAV's IP address, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. In several modes, transmitter 310 may transmit a second request to a policy control function. The second request includes a request to activate policies to allow connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. In some modes, receiver 312 may receive a second request from a network function. The second request includes a request to activate policies that allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers. In several modes, transmitter 310 may transmit a first response to the network function. The first response includes an acknowledgment of the second request. It should be noted that one or more of the modalities described here may be combined into a single modality. In certain modalities, 3GPP allows unmanned aerial systems (“UASs”) that include an unmanned aerial vehicle controller (“UAV”) and a UAV to operate (e.g., conduct UAV operations) through a fifth-generation (“5G”) mobile communication network. To admit a UAS into a 3GPP system, there may be: 1) a UAS network function (“UASNF”) that: A) exposes UAS traffic management (“UTM”) and / or location information from the UAS service provider (“USS”) about the UAV using the 3GPP Location Service (“LOS”) and / or presence reporting information from an AMF, and B) interfaces with a UTM and / or USS for UAV authentication and authorization—authorizing a UAV to conduct UAV operations across the 3GPP network; and / or 2) a UAS that includes a UAV and its controller that: A) establishes user plane connectivity with a UTM and / or USS to provide remote identification and tracking information, B) establishes user plane connectivity between a UAV controller (“UAV-C”) and a UAV for command and control (“C2”), and C) a Rcnr Ln / eznz / B / YiAi requires that the UAS has already been registered with a USS provider with a procedure. In addition, the UAS must have a valid flight authorization provided by a USS provider with a procedure. In some configurations, a UAV is authorized to access a 5G mobile communication network to conduct UAV operations. More specifically, the network may perform the following: 1) UAV USS authorization and / or authentication (“UUAA”) to verify that a UAV has a valid registration with a UAS service provider (“USS”); and / or 2) C2 authorization: authorizes a UAV to establish user plane connectivity through the 3GPP system for UAV operations (e.g., O2). In several modes, when the UAV requests a Protocol Data Unit (PDU) session for O2, the SMF determines whether the PDU session requires authorization from the UAV and sends an authorization request to the USS through a UAS network function (NF). The UAV includes a request for UAV pairing information (e.g., UAV-C, UAV pairing information) within a transparent container in the PDU session, which the SMF forwards to the USS through the UAS NF. The USS authorizes the request and sends authorization information, including pairing information, in its response to the SMF. The PCF's SMF request policies incorporate the authorization information provided by the USS. Based on the policy and charge control (PCC) rules provided by the PCF, the SMF configures the UPF with routing rules (e.g., to ensure that traffic for C2 is only between the UAV and the UAV-C). In certain modes: 1) a USS action may be performed if the UAV did not provide any pairing information within the PDU session request; 2) the USS action may be performed if the USS determines that the pairing information has changed; and / or 3) the USS action may be performed if the USS determines that the flight authorization information has changed. In one mode, once a USS determines that a C2 UAV controller needs to be replaced, the USS determines the new pairing information and invokes an Nnef service operation request to establish a session with the required Quality of Service (QoS) and provide authorization information, including specific pairing information, to a new C-UAV to the UAS NF. The service operation can be an NnefAFsessionWithQoSCreate service operation. In some modes, a new service operation can be defined. In the Nnef_AFsessionWithQoS_Create operation, the USS includes: 1) an Internet protocol (“IP”) address of the UAV; 2) a QoS reference; 3) flow descriptors; and / or 4) UAS authorization information, including pairing information (for example, a UAV-C address). The authorization information can be included in a UAS container. Rcnr Ln / eznz / B / YiAi The UAS container can be a container specifically for C2 communications. In several modes, authorization information can be included within the flow descriptors. In certain configurations, when a Network Exposure Function (“NEF”) receives a request, the NEF identifies a PCF serving the UAV and instructs the PCF to derive policies for the session. The NEF includes authorization information in the request. The PCF determines the PCC rules for the UAV based on the authorization information sent to the SMF serving the UAV. The PCC rule instructs the SMF to allow access only to the new UAVC. Figure 4 is a schematic block diagram illustrating one mode of a System 400 for informing a 5GC about a replaced UAV-C. The System 400 includes a UAV 402, a UPF 404, an SMF 406, a PCF 408, a UAS NF 410, and a USS 412. Each System 400 communication can include one or more messages. In an initial communication 414, the UAV 402 establishes user plane connectivity for C2 operation with the UPF 404. USS 412 determines 416 that the UAV-C controlling UAV 402 needs to be replaced (for example, if the UAV is malfunctioning) or that traffic flows related to valid flight information have changed. In a second optional communication 418, USS 412 may also initiate a procedure to revoke the authorization of the previous UAV-C. In a third communication 420, the USS 412 sends an Nnef_AFSessionWithQoS_Create request including in the request: the UAV's IP address, flow descriptors that identify the traffic flows for the C2 operation that require PCC rules, and / or a QoS reference and authorization information that includes pairing information (e.g., the address of the replaced UAV-C). UAS NF 410 authorizes 422 the request. In a fourth communication 424, the UAS NF 410 identifies the PCF serving the UAV (for example, based on the UAV's IP address) and triggers an Npcf_Policy_Authorization_Create request that includes the information provided by the USS 412 in the third communication 420. In a fifth communication 426, PCF 408 acknowledges the request. In a sixth communication 428, the UAS NF 410 acknowledges the request sent in the third communication 420. PCF 408 determines 430 updates of the PCC rules for the session (e.g., identified by the flow descriptor) allowing access to the UAV-C. In a seventh 432 communication, PCF 408 identifies the SMF 406 serving the UAV and invokes a service operation Npcf_SMPolicyControl_UpdateNotify including rules Rcnr Ln / eznz / e / YiAi PCC. In an eighth communication 434, the SMF 406 acknowledges the request. SMF 406 identifies the PDU session 436 based on the UAV address and configures UPF 404 based on PCC rules. In a ninth communication 438, SMF 406 sends N4 rules to UPF 404. UPF 404 enables 440 connectivity for C2 (e.g., based on the provided flow descriptors) only with the address of the replaced UAV-C In a second scenario, once the USS determines that a C2 UAV controller needs to be replaced, the USS determines the pairing information. The USS then acts as a Data Network (DN) Authorization, Authentication, and Accounting (AAA) (“DN-AAA”) and sends a request to update the DN's authorization data. In this case, the USS invokes an N33_Auth_Update request, which includes a new DN authorization index and new UAS authorization information, including updated pairing information. The authorization information can be included in a UAS authorization container. The UAS container can be a container specifically for C2 communications. The UAS NF provides the authorization update to the SMF. Based on the new authorization index from the DN or based on authorization information from the UAS, the SMF is triggered to request updated PCC rules from the PCF, including the new authorization information in the request. In one mode, the SMF identifies that the PCF requires PCC rules if a policy control request trigger for a PDU session is met. In another mode, the PCF provides a new policy control trigger to indicate to the SMF that interaction with the PCF is necessary if the SMF receives new authorization information from the UAS included in a UAS container. Figure 5 is a schematic block diagram illustrating another mode of a 500 system for reporting to a 5G (“5GC”) core network about a UAV-C. The 500 system includes a UAV 502, a UPF 504, an SMF 506, a PCF 508, a UAS NF 510, and a USS 512. Each communication in the 500 system can include one or more messages. In an initial communication 514, the UAV 502 establishes user plane connectivity for C2 operation with the UPF 504. USS 512 determines 516 that the UAV-C controlling UAV 502 needs to be replaced (for example, if the UAV is behaving badly). In a second communication, 518, the USS 512 sends an N33_Auth_Update request including in the request: the UAV's IP address, flow descriptors that identify traffic requiring PCC rules, a new DN authorization index, and / or QoS reference and authorization information that includes peering information (e.g., the Rcnr Ln / eznz / e / YiAi direction of the replaced UAV-C). The UAS NF 510 authorizes 520 the request. In a third communication 522, the UAS NF 510 acknowledges the request sent in the second communication 518. In a fourth communication 524, the UAS NF 510 identifies the SMF 506 serving the UAV 502 (for example, based on the UAV's IP address) and triggers a NuasnfAuthorizationUpdate request that includes the information provided by the USS 512 in the second communication 518. SMF 506 determines 526 that a policy control trigger is met due to a new DN authorization index or due to new authorization data received. In a fifth communication (528), SMF 506 requests updated PCC rules from the PCF by invoking an Npcf SMPolicyControl Update request. SMF 506 includes the authorization information received in the fourth communication (524). PCF 508 determines 530 updates of the PCC rules for the session identified by the flow descriptor allowing access to the UAV-C. In a sixth communication 532, PCF 508 provides PCC rules to SMF 506 in the response. SMF 506 identifies the PDU session based on the UAV address and configures UPF 504 based on PCC rules. In a seventh communication 536, SMF 506 sends N4 rules to UPF 504. UPF 504 enables 538 connectivity for C2 (e.g., based on the flow descriptors provided) only to the direction of the replaced UAV-C. A third method can identify when an SMF requires policies from a PCF. For UAS operations, the SMF may need to request PCF policies during UUAA or C2 authorization procedures. In both cases, the SMF receives authorization information from the USS through the UAS NF. In some configurations, a new policy control trigger can be used to allow an SMF to determine when new PCC rules are required from the SMF. The PCF provides a policy control trigger during PDU session establishment that, when UAS-related authorization information is received by the SMF, prompts the SMF to request PCC rules from the PCF. The UAS-related authorization information can be contained within a UAS container. The UAS container can be a container specifically for UUAA or C2 communications. Figure 6 is a schematic block diagram illustrating one configuration of a System 600 in which an SMF determines when to request policies for UAS operations from a PCF. The System 600 includes a UAV 604, a UPF 604, an SMF 606, and a PCF 608. Each Rcnr Ln / eznz / e / YiAi one of the communications of the 600 system may include one or more messages. In an initial communication 610, UAV 602 requests the establishment of a new PDU session by invoking a PDU session establishment request. SMF 606 selects 612 from PCF 608. In a second communication 614, SMF 606 establishes a procedure for associating SM policies with PCF 608. PCF 608 defines the 616 SM PDU session policies and PCC rules. Based on subscription information, PCF 608 determines that a policy control trigger is needed for UAS operation for the PDU session. In a third communication, 618, PCF 608 provides SM PDU session policies and PCC rules in an SM policy association response. The SM PDU session policies include a policy control trigger for UAS. SMF 606 stores 620 SM PDU session policies for the PDU session. In a fourth communication 622, SMF 606 accepts the establishment of the PDU session, At a later time, SMF 606 determines that a policy control trigger for UAS is met. This can happen in the following cases: 1) when SMF 606 receives UAS authorization information from the USS during a UUAA procedure; and / or 2) when SMF 606 receives authorization information from the USS during a C2 authorization procedure. In a fifth communication 626, if a policy control trigger for UAS is met, SMF 606 requests updated PCC rules by invoking a service operation Npcf_SMPolicyControl_Update. PCF 608 determines the updated PCC rules. In a sixth communication 630, PCF 608 provides PCC rules in a response to the fifth communication 626. The procedure in Figure 6 can provide policy control triggers that can also be carried out during PDU session modification or based on AF triggers. Figure 7 is a flowchart illustrating one embodiment of a 700 method for enabling connectivity between a UAV and a UAV-C. In some embodiments, the 700 method is performed by a device, such as the 104 network unit. In certain embodiments, the 700 method can be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or similar. In several modes, the 700 method includes receiving 702, in a network function, a Rcnr Ln / eznz / e / YiAi first request from a first USS. The first request indicates replacing a first UAV-C with a first UAV, and the first request includes an IR address of the first UAV, a requested QoS, flow descriptors that identify the traffic, UAV-to-UAV-C pairing information, or some combination thereof. In some modes, method 700 includes transmitting a second request to a policy control function. The second request includes a request to activate policies to allow connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. In certain modes, UAV-to-UAV-C pairing information is identified based on an address of the second UAV-C. In some modes, Method 700 further involves authorizing the first request before transmitting the second request. In several modes, Method 700 further involves receiving an initial response from the policy control function, in which the initial response includes an acknowledgment of the second request. In one mode, Method 700 further comprises the transmission of a second response to the first application function, wherein the second response comprises an acknowledgment of the first request. In certain modes, the USS comprises an application function. In some modes, the UAV-to-UAV-C pairing information comprises information indicating that connectivity from the first UAV is permitted only to the second UAV-C. Figure 8 is a flowchart illustrating another mode of an 800 method for enabling connectivity between a UAV and a UAV-C. In some modes, the 800 method is performed by a device, such as the 104 network unit. In certain modes, the 800 method can be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or similar. In several modes, method 800 includes receiving a second request from a first network function. The second request includes a request to activate policies to allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers. In some modes, method 800 includes determining first policy rules for the first UAV based on the second request. The first policy rules allow user plane connectivity between the first UAV and the second UAV-C. In certain modes, method 800 includes identifying a second network function that serves the first UAV. In several modes, method 800 includes transmitting a third request to the second network function, in which the third request comprises the first policy rules. In certain forms, the 800 method also includes policy determination Rcnr Ln / eznz / e / YiAi and payload rules for the first device, wherein the policy and payload rules comprise information that connectivity from the first device is permitted only to the second UAV-C. In some modes, Method 800 further comprises transmitting a third request to a session management function, wherein the third request comprises a request to activate policies that permit connectivity between the first UAV and the second UAV-C while blocking connectivity to the other UAV controllers. In several modes, Method 800 further comprises receiving a third response, wherein the third response comprises an acknowledgment of the third request. In one embodiment, an apparatus comprises: a receiver for receiving a first request from a first USS, wherein the first request indicates replacing a first UAV-C of a first UAV, and the first request comprises an IR address of the first UAV, a requested QoS, flow descriptors identifying the traffic, UAV-to-UAV-C pairing information, or some combination thereof; and a transmitter for transmitting a second request to a policy control function, wherein the second request comprises a request to activate policies to allow connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information. In certain modes, UAV-to-UAV-C pairing information is identified based on an address of the second UAV-C. In some versions, the device also includes a processor to authorize the first request before transmitting the second request. In several modes, the receiver also receives an initial response from the policy control function, in which the initial response includes an acknowledgment of the second request. In one mode, the transmitter also transmits a second response to the first application function, and the second response comprises an acknowledgment of the first request. In certain modalities, the USS includes an application function. In some modes, UAV-to-UAV-C pairing information includes information indicating that connectivity from the first UAV is only permitted to the second UAV-C. In one embodiment, a method in a network function comprises: receiving a first request from a first USS, wherein the first request indicates replacing a first UAV-C of a first UAV, and the first request comprises an IP address of the first UAV, a requested QoS, flow descriptors identifying the traffic, UAV-to-UAV-C pairing information, or some combination thereof; and transmitting a second request to a policy control function, wherein the second request comprises a request to activate Rcnr Ln / eznz / e / YiAi policies to allow connectivity between the first UAV and a second UAV-C based on UAV-to-UAV-C pairing information. In certain modes, UAV-to-UAV-C pairing information is identified based on an address of the second UAV-C. In some forms, the method also involves authorizing the first request before transmitting the second request. In several modalities, the method also includes receiving an initial response from the policy control function, in which the initial response includes an acknowledgment of the second request. In one embodiment, the method further comprises the transmission of a second response to the first application function, wherein the second response comprises an acknowledgment of the first request. In certain modalities, the USS includes an application function. In some modes, UAV-to-UAV-C pairing information includes information indicating that connectivity from the first UAV is only permitted to the second UAV-C. In one embodiment, an apparatus comprises: A receiver for receiving a second request from a network function, wherein the second request comprises a request to activate policies to allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers; and a transmitter for transmitting a first response to the network function, wherein the first response comprises an acknowledgment of the second request. In certain modalities, the apparatus further comprises a processor to determine the policy and loading rules for the first device, wherein the policy and loading rules comprise information that connectivity of the first device is only permitted to the second UAV-C. In some modes, the transmitter also transmits a third request to a session management function, and the third request comprises a request to activate policies that allow connectivity between the first UAV and the second UAV-C while blocking connectivity with the other UAV controllers. In several modalities, the receiver also receives a third response, and the third response includes an acknowledgment of the third request. In one embodiment, a method in a policy control function comprises: Receiving a second request from a network function, wherein the second request comprises a request to activate policies to allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers; and transmitting a first Rcnr Ln / eznz / e / YiAi network function response, wherein the first response comprises an acknowledgment of the second request. In certain modalities, the method also includes the determination of the policy and loading rules for the first device, where the policy and loading rules include information that connectivity from the first device is only permitted to the second UAV-C. In some modalities, the method further comprises the transmission of a third request to a session management function, wherein the third request comprises a request to activate policies that allow connectivity between the first UAV and the second UAV-C while blocking connectivity with the other UAV controllers. In several modalities, the method also involves receiving a third response, in which the third response includes an acknowledgment of the third request. The embodiments can be implemented in other specific ways. The embodiments described herein should be considered in all respects as illustrative and not restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All modifications that fall within the meaning and range of equivalence of the claims shall be encompassed within their scope.

Claims

CLAIMS 1. An apparatus, characterized in that it comprises: a receiver for receiving a first request from a first unmanned aerial system (UAS) service provider (USS) function, wherein the first request indicates replacing a first unmanned aerial vehicle (UAV-C) controller of a first unmanned aerial vehicle (UAV), and the first request comprises an Internet protocol (IP) address of the first UAV, a requested quality of service (QoS), traffic-identifying flow descriptors, UAV-to-UAV-C pairing information, or some combination thereof; and a transmitter for transmitting a second request to a policy control function, wherein the second request comprises a request to activate policies to enable connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information.

2. The apparatus according to claim 1, characterized in that the UAV-to-UAV-C pairing information is identified based on an address of the second UAV-C.

3. The apparatus according to claim 1, characterized in that it further comprises a processor for authorizing the first request before transmitting the second request.

4. The apparatus according to claim 1, characterized in that the policy control function is determined based on the IP address of the first UAV.

5. The apparatus according to claim 1, characterized in that the transmitter further transmits a second response to the first application function, and the second response comprises an acknowledgment of the first application.

6. The apparatus according to claim 1, characterized in that the USS comprises an application function.

7. The apparatus according to claim 1, characterized in that the UAV-to-UAV-C pairing information comprises information indicating that connectivity of the first UAV is only permitted to the second UAV-C.

8. A method in a network function, the method characterized in that it comprises: receiving a first request from a first unmanned aerial system (UAS) service provider (USS) function, wherein the first request indicates replacing a first unmanned aerial vehicle (UAV-C) controller of a first unmanned aerial vehicle (UAV), and the first request comprises an Internet protocol (IP) address of the first UAV, a requested quality of service (QoS), flow descriptors identifying traffic, UAV-to-UAV-C pairing information, or some combination thereof; and transmitting a second request to a policy control function, wherein the second request comprises a request to activate policies to enable connectivity between the first UAV and a second UAV-C based on the UAV-to-UAV-C pairing information.

9. The method according to claim 8, characterized in that the UAV-to-UAV-C pairing information is identified based on an address of the second UAV-C.

10. The method according to claim 8, characterized in that it further comprises authorizing the first application before transmitting the second application.

11. An apparatus, characterized in that it comprises: a receiver for receiving a second request from a first network function, wherein the second request comprises a request to activate policies to allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers; a processor for: determining first policy rules for the first UAV based on the second request, wherein the first policy rules allow user plane connectivity between the first UAV and the second UAV-C; and identifying a second network function serving the first UAV; and a transmitter for transmitting a third request to the second network function, wherein the third request comprises the first policy rules.

12. The apparatus according to claim 11, characterized in that the processor further determines policy and payload rules for the first device, and the policy and payload rules comprise information that connectivity of the first device is only permitted to the second UAV-C.

13. The apparatus according to claim 12, characterized in that the second network function comprises a session management function.

14. The apparatus according to claim 13, characterized in that the receiver further receives a third response, and the third response comprises an acknowledgment of the third request.

15. A method in a policy control function, the method characterized in that it comprises: receiving a second request from a first network function, wherein the second request comprises a request to activate policies to allow connectivity between a first UAV and a second UAV-C while blocking connectivity with other UAV controllers; determining first policy rules for the first UAV based on the second request, wherein the first policy rules allow user plane connectivity between the first UAV and the second UAV-C; identifying a second network function serving the first UAV; and transmitting a third request to the second network function, wherein the third request comprises the first policy rules.

Images