Patent Description:
The subject matter disclosed herein relates generally to wireless communications and more particularly relates to authorizing and configuring pairing of unmanned aerial system.

In certain wireless communication systems, a User Equipment device ("UE") is able to connect with a fifth-generation ("<NUM>") core network (i.e., "5GC") in a Public Land Mobile Network ("PLMN"). Unmanned aerial vehicles ("UAVs") and controllers for UAVs may utilize wireless communication systems for communications.

TR <NUM> V0. <NUM> is a technical report for 3rd Generation Partnership Project Technical Specification Group Services and System Aspects, titled "Study on supporting Unmanned Aerial Systems (UAS) connectivity, Identification and tracking (Release <NUM>)", dated <NUM> July <NUM>.

Claims <NUM>, <NUM> and <NUM> each define an apparatus. In the following, any method and/or apparatus referred to as embodiments but nevertheless do not fall within the scope of the appended claims are to be understood as examples helpful in understanding the invention.

Disclosed are procedures for authorizing and configuring pairing of unmanned aerial system. Said procedures may be implemented by apparatus, systems, methods, and/or computer program products.

An apparatus for authorizing and configuring pairing of unmanned aerial system includes, in one embodiment, a transceiver that receives, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle ("UAV") operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier. The apparatus, in one embodiment, includes a processor that creates a <NUM> local area network ("LAN") group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group, configures the <NUM> LAN group based on at least at least one parameter associated with the UAV and updates a third network function with information for the <NUM> LAN group for establishing a protocol data unit ("PDU") session between the UAV and the UAV controller.

In another embodiment, an apparatus includes at transceiver that receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller. The transceiver, in further embodiments, receives, at the first network function from a third network function, a second notification comprising an authorization to establish a first connection for command and control ("C2") communication from a first device. The apparatus, in one embodiment, includes a processor that determines that the <NUM> LAN group is associated with the first connection based on the first notification and configures a fourth network function with at least one parameter for the <NUM> LAN group based on the parameters received in the first notification from the second network function to associate the first connection with a second connection from a second device.

Another apparatus, in one embodiment, includes a transceiver that receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller. The apparatus, in various embodiments, includes a processor that determines that the UAV needs updated user equipment ("UE") route selection policies ("USRPs") for command and control ("C2") operations and creates at least one URSP rule with a new connection capability for UAV C2 operations comprising at least one parameter of the <NUM> LAN group as a route selection descriptor.

Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network ("LAN"), wireless LAN ("WLAN"), or a wide area network ("WAN"), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider ("ISP")).

As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof' includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

Generally, the present disclosure describes systems, methods, and apparatus for authorizing and configuring pairing of unmanned aerial system. In certain embodiments, the methods may be performed using computer code embedded on a computer-readable medium. In certain embodiments, an apparatus or system may include a computer-readable medium containing computer-readable code which, when executed by a processor, causes the apparatus or system to perform at least a portion of the below described solutions.

In one embodiment, the proposed solution identifies how a request by an unmanned aerial vehicle ("UAV") to establish user plane connection via a third-generation partnership project ("3GPP") system is authorized by an aviation authority. The problem that is solved with this invention is to provide a solution on how an aviation authority authorizes the request by certifying that the UAV is authorized to perform a UAV operation from a paired UAV controller and how a UAV controller can be associated with a UAV within the 3GPP core network.

<FIG> depicts a wireless communication system <NUM> for authorizing and configuring pairing of unmanned aerial system, according to embodiments of the disclosure. In one embodiment, the wireless communication system <NUM> includes at least one remote unit <NUM>, a Fifth-Generation Radio Access Network ("<NUM>-RAN") <NUM>, a mobile core network <NUM>, and an unmanned aerial system ("UAS") <NUM>. The <NUM>-RAN <NUM> and the mobile core network <NUM> form a mobile communication network. The <NUM>-RAN <NUM> may be composed of a 3GPP access network <NUM> containing at least one cellular base unit <NUM> and/or a non-3GPP access network <NUM> containing at least one access point <NUM>. The remote unit <NUM> communicates with the 3GPP access network <NUM> using 3GPP communication links <NUM> and/or communicates with the non-3GPP access network <NUM> using non-3GPP communication links <NUM>. Even though a specific number of remote units <NUM>, 3GPP access networks <NUM>, cellular base units <NUM>, 3GPP communication links <NUM>, non-3GPP access networks <NUM>, access points <NUM>, non-3GPP communication links <NUM>, and mobile core networks <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, 3GPP access networks <NUM>, cellular base units <NUM>, 3GPP communication links <NUM>, non-3GPP access networks <NUM>, access points <NUM>, non-3GPP communication links <NUM>, and mobile core networks <NUM> may be included in the wireless communication system <NUM>.

In one implementation, the RAN <NUM> is compliant with the <NUM> system specified in the Third Generation Partnership Project ("3GPP") specifications. For example, the RAN <NUM> may be a NG-RAN, implementing NR RAT and/or LTE RAT. In another example, the RAN <NUM> may include non-3GPP RAT (e.g., Wi-Fi® or Institute of Electrical and Electronics Engineers ("IEEE") <NUM>-family compliant WLAN). In another implementation, the RAN <NUM> is compliant with the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE <NUM>-family standards, among other networks.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as the UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit ("WTRU"), a device, or by other terminology used in the art. In various embodiments, the remote unit <NUM> includes a subscriber identity and/or identification module ("SIM") and the mobile equipment ("ME") providing mobile termination functions (e.g., radio transmission, handover, speech encoding and decoding, error detection and correction, signaling and access to the SIM). In certain embodiments, the remote unit <NUM> may include a terminal equipment ("TE") and/or be embedded in an appliance or device (e.g., a computing device, as described above).

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit ("WTRU"), a device, or by other terminology used in the art.

The remote units <NUM> may communicate directly with one or more of the cellular base units <NUM> in the 3GPP access network <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the 3GPP communication links <NUM>. Similarly, the remote units <NUM> may communicate with one or more access points <NUM> in the non-3GPP access network(s) <NUM> via UL and DL communication signals carried over the non-3GPP communication links <NUM>. Here, the access networks <NUM> and <NUM> are intermediate networks that provide the remote units <NUM> with access to the mobile core network <NUM>.

In some embodiments, the remote units <NUM> communicate with a remote host (e.g., in the data network <NUM> or in the data network <NUM>) via a network connection with the mobile core network <NUM>. For example, an application <NUM> (e.g., web browser, media client, telephone and/or Voice-over-Internet-Protocol ("VoIP") application) in a remote unit <NUM> may trigger the remote unit <NUM> to establish a protocol data unit ("PDU") session (or other data connection) with the mobile core network <NUM> via the <NUM>-RAN <NUM> (i.e., via the 3GPP access network <NUM> and/or non-3GPP network <NUM>). The mobile core network <NUM> then relays traffic between the remote unit <NUM> and the remote host using the PDU session. The PDU session represents a logical connection between the remote unit <NUM> and a User Plane Function ("UPF") <NUM>.

In order to establish the PDU session (or PDN connection), the remote unit <NUM> must be registered with the mobile core network <NUM> (also referred to as "attached to the mobile core network" in the context of a Fourth Generation ("<NUM>") system). Note that the remote unit <NUM> may establish one or more PDU sessions (or other data connections) with the mobile core network <NUM>. As such, the remote unit <NUM> may have at least one PDU session for communicating with the packet data network <NUM>. Additionally - or alternatively - the remote unit <NUM> may have at least one PDU session for communicating with the packet data network <NUM>. The remote unit <NUM> may establish additional PDU sessions for communicating with other data networks and/or other communication peers.

In the context of a <NUM> system ("5GS"), the term "PDU Session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between the remote unit <NUM> and a specific Data Network ("DN") through the UPF <NUM>. A PDU Session supports one or more Quality of Service ("QoS") Flows. In certain embodiments, there may be a one-to-one mapping between a QoS Flow and a QoS profile, such that all packets belonging to a specific QoS Flow have the same <NUM> QoS Identifier ("5QI").

In the context of a <NUM>/LTE system, such as the Evolved Packet System ("EPS"), a Packet Data Network ("PDN") connection (also referred to as EPS session) provides E2E UP connectivity between the remote unit and a PDN. The PDN connectivity procedure establishes an EPS Bearer, i.e., a tunnel between the remote unit <NUM> and a Packet Gateway ("PGW", not shown) in the mobile core network <NUM>. In certain embodiments, there is a one-to-one mapping between an EPS Bearer and a QoS profile, such that all packets belonging to a specific EPS Bearer have the same QoS Class Identifier ("QCI").

As described in greater detail below, the remote unit <NUM> may use a first data connection (e.g., PDU Session) established with the first mobile core network <NUM> to establish a second data connection (e.g., part of a second PDU session) with the second mobile core network <NUM>. When establishing a data connection (e.g., PDU session) with the second mobile core network <NUM>, the remote unit <NUM> uses the first data connection to register with the second mobile core network <NUM>.

The cellular base units <NUM> may be distributed over a geographic region. In certain embodiments, a cellular base unit <NUM> may also be referred to as an access terminal, a base, a base station, a Node-B ("NB"), an Evolved Node B (abbreviated as eNodeB or "eNB," also known as Evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a <NUM>/NR Node B ("gNB"), a Home Node-B, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The cellular base units <NUM> are generally part of a radio access network ("RAN"), such as the 3GPP access network <NUM>, that may include one or more controllers communicably coupled to one or more corresponding cellular base units <NUM>. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The cellular base units <NUM> connect to the mobile core network <NUM> via the 3GPP access network <NUM>.

The cellular base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector, via a 3GPP wireless communication link <NUM>. The cellular base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the cellular base units <NUM> transmit DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the 3GPP communication links <NUM>. The 3GPP communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The 3GPP communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the cellular base units <NUM>. Note that during NR operation on unlicensed spectrum (referred to as "NR-U"), the base unit <NUM> and the remote unit <NUM> communicate over unlicensed (i.e., shared) radio spectrum.

The non-3GPP access networks <NUM> may be distributed over a geographic region. Each non-3GPP access network <NUM> may serve a number of remote units <NUM> with a serving area. An access point <NUM> in a non-3GPP access network <NUM> may communicate directly with one or more remote units <NUM> by receiving UL communication signals and transmitting DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Both DL and UL communication signals are carried over the non-3GPP communication links <NUM>. The 3GPP communication links <NUM> and non-3GPP communication links <NUM> may employ different frequencies and/or different communication protocols. In various embodiments, an access point <NUM> may communicate using unlicensed radio spectrum. The mobile core network <NUM> may provide services to a remote unit <NUM> via the non-3GPP access networks <NUM>, as described in greater detail herein.

In some embodiments, a non-3GPP access network <NUM> connects to the mobile core network <NUM> via an interworking entity <NUM>. The interworking entity <NUM> provides an interworking between the non-3GPP access network <NUM> and the mobile core network <NUM>. The interworking entity <NUM> supports connectivity via the "N2" and "N3" interfaces. As depicted, both the 3GPP access network <NUM> and the interworking entity <NUM> communicate with the AMF <NUM> using a "N2" interface. The 3GPP access network <NUM> and interworking entity <NUM> also communicate with the UPF <NUM> using a "N3" interface. While depicted as outside the mobile core network <NUM>, in other embodiments the interworking entity <NUM> may be a part of the core network. While depicted as outside the non-3GPP RAN <NUM>, in other embodiments the interworking entity <NUM> may be a part of the non-3GPP RAN <NUM>.

In one embodiment, the UAS <NUM> comprises components, networks, hardware, software, and/or the like for conducting unmanned aircraft operations between a UAV <NUM>, e.g., a drone, and a UAV controller <NUM>. The UAV <NUM> may refer to an aircraft without a human pilot, crew, or passengers that is remotely controlled using a UAV controller <NUM>. A UAV controller <NUM> may refer to device that is configured to wirelessly send instructions to the UAV <NUM> for controlling the UAV, e.g., for controlling the speed, direction, orientation, and/or the like of the UAV, e.g., via the mobile network <NUM>, an access network <NUM>, <NUM>, and/or the like. The UAS operator <NUM> may be the person who operates the UAV <NUM> (e.g., via the UAV controller <NUM>) and who, typically, requests flight authorizations. The UAV <NUM> and UAV controller <NUM> may each be UEs in the wireless communication system <NUM> and/or may include an instance of a remote unit <NUM>. As such, the UAV <NUM> and/or the UAV controller <NUM> may communicate with an access network <NUM> to access services provided by a mobile core network <NUM>.

In some embodiments, the UAV <NUM> and/or the UAV-C controller <NUM> communicates with a FCFS <NUM> and/or a USS/UTM <NUM> function via a network connection with the mobile core network <NUM>. The USS/UTM <NUM>, in one embodiment, provides a set of overlapping USSs that assist UAV <NUM> operators <NUM> in conducting safe and compliant operations. The services may include deconfliction of flight plans, remote identification, and/or the like.

As described below, the UAV <NUM> and/or UAV controller <NUM> may establish a PDU session (or similar data connection) with the mobile core network <NUM> using the RAN <NUM>. The mobile core network <NUM> may then relay traffic between the UAV <NUM> and the UAV controller <NUM> and the packet data network <NUM> using the PDU session.

In certain embodiments, a non-3GPP access network <NUM> may be controlled by an operator of the mobile core network <NUM> and may have direct access to the mobile core network <NUM>. Such a non-3GPP AN deployment is referred to as a "trusted non-3GPP access network. " A non-3GPP access network <NUM> is considered as "trusted" when it is operated by the 3GPP operator, or a trusted partner, and supports certain security features, such as strong air-interface encryption. In contrast, a non-3GPP AN deployment that is not controlled by an operator (or trusted partner) of the mobile core network <NUM>, does not have direct access to the mobile core network <NUM>, or does not support the certain security features is referred to as a "non-trusted" non-3GPP access network. An interworking entity <NUM> deployed in a trusted non-3GPP access network <NUM> may be referred to herein as a Trusted Network Gateway Function ("TNGF"). An interworking entity <NUM> deployed in a non-trusted non-3GPP access network <NUM> may be referred to herein as a non-3GPP interworking function ("N3IWF"). While depicted as a part of the non-3GPP access network <NUM>, in some embodiments the N3IWF may be a part of the mobile core network <NUM> or may be located in the data network <NUM>.

In one embodiment, the mobile core network <NUM> is a <NUM> core ("5GC") or the evolved packet core ("EPC"), which may be coupled to a data network <NUM>, like the Internet and private data networks, among other data networks. A remote unit <NUM> may have a subscription or other account with the mobile core network <NUM>. Each mobile core network <NUM> belongs to a single public land mobile network ("PLMN").

The mobile core network <NUM> includes several network functions ("NFs"). As depicted, the mobile core network <NUM> includes at least one UPF ("UPF") <NUM>. The mobile core network <NUM> also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function ("AMF") <NUM> that serves the <NUM>-RAN <NUM>, a Session Management Function ("SMF") <NUM>, a Policy Control Function ("PCF") <NUM>, an Authentication Server Function ("AUSF") <NUM>, a Unified Data Management ("UDM") and Unified Data Repository function ("UDR").

The UPF(s) <NUM> is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Network ("DN"), in the <NUM> architecture. The AMF <NUM> is responsible for termination ofNAS signaling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The SMF <NUM> is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) IP address allocation & management, DL data notification, and traffic steering configuration for UPF for proper traffic routing.

The PCF <NUM> is responsible for unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR. The AUSF <NUM> acts as an authentication server.

The UDM is responsible for generation of Authentication and Key Agreement ("AKA") credentials, user identification handling, access authorization, subscription management. The UDR is a repository of subscriber information and can be used to service a number of network functions. For example, the UDR may store subscription data, policy-related data, subscriber-related data that is permitted to be exposed to third party applications, and the like. In some embodiments, the UDM is co-located with the UDR, depicted as combined entity "UDM/UDR" <NUM>.

In various embodiments, the mobile core network <NUM> may also include an Network Exposure Function ("NEF") (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function ("NRF") (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces ("APIs")), or other NFs defined for the 5GC. In certain embodiments, the mobile core network <NUM> may include an authentication, authorization, and accounting ("AAA") server.

In various embodiments, the mobile core network <NUM> supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network <NUM> optimized for a certain traffic type or communication service. A network instance may be identified by a S-NSSAI, while a set of network slices for which the remote unit <NUM> is authorized to use is identified by NSSAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF and UPF <NUM>. In some embodiments, the different network slices may share some common network functions, such as the AMF <NUM>. The different network slices are not shown in <FIG> for ease of illustration, but their support is assumed.

Although specific numbers and types of network functions are depicted in <FIG>, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network <NUM>. Moreover, where the mobile core network <NUM> comprises an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like.

While <FIG> depicts components of a <NUM> RAN and a <NUM> core network, the described embodiments for using a pseudonym for access authentication over non-3GPP access apply to other types of communication networks and RATs, including IEEE <NUM> variants, GSM, GPRS, UMTS, LTE variants, CDMA <NUM>, Bluetooth, ZigBee, Sigfoxx, and the like. For example, in an <NUM>/LTE variant involving an EPC, the AMF <NUM> may be mapped to an MME, the SMF mapped to a control plane portion of a PGW and/or to an MME, the UPF <NUM> may be mapped to an SGW and a user plane portion of the PGW, the UDM/UDR <NUM> may be mapped to an HSS, etc..

As depicted, a remote unit <NUM> (e.g., a UE) may connect to the mobile core network (e.g., to a <NUM> mobile communication network) via two types of accesses: (<NUM>) via 3GPP access network <NUM> and (<NUM>) via a non-3GPP access network <NUM>. The first type of access (e.g., 3GPP access network <NUM>) uses a 3GPP-defined type of wireless communication (e.g., NG-RAN) and the second type of access (e.g., non-3GPP access network <NUM>) uses a non-3GPP-defined type of wireless communication (e.g., WLAN). The <NUM>-RAN <NUM> refers to any type of <NUM> access network that can provide access to the mobile core network <NUM>, including the 3GPP access network <NUM> and the non-3GPP access network <NUM>.

To solve the problem of authorizing and configuring pairing of unmanned aerial system, described above, the present disclosure proposes solutions that identify how a request by an unmanned aerial vehicle ("UAV") to establish user plane connection via a third-generation partnership project ("3GPP") system is authorized by an aviation authority. The problem that is solved with this invention is to provide a solution on how an aviation authority authorizes the request by certifying that the UAV <NUM> is authorized to perform a UAV operation from a paired UAV controller <NUM> and how a UAV controller <NUM> can be associated with a UAV <NUM> within the 3GPP core network.

In an embodiment of a conventional solution, the UAV <NUM> provides within a container in non-access stratum ("NAS") signaling the identifier of a UAV controller <NUM> to which the UAV <NUM> is to be paired, or the UAV controller <NUM> can provide the identifier of the UAV <NUM> to which it is to be paired. The UTM/USS <NUM> uses the information to ascertain if the UAV <NUM> is authorized to be controlled by that UAV controller <NUM>. The disadvantage, however, with this approach is that it requires appropriate configuration from the UAS operator <NUM> to ensure the correct UAV identifier and UAV Controller identifier are configured to the UAV <NUM> and the UAV controller <NUM>, respectively. Note that in such an embodiment, the UAS operator <NUM> receives the UAV identifiers when registering the UAV <NUM> and UAV controller <NUM> to a USS provider.

In another conventional embodiment, the UTM/USS <NUM> is used to associate/pair a UAV <NUM> with a UAV controller <NUM>. Each UAV <NUM> provides its identity to the UTM/USS <NUM>. The UTM/USS <NUM> authorizes the request and allocates a universally traceable identifier ("UTID") that is used by the UAVs <NUM> when establishing a PDU session with the PLMN. The disadvantage with this approach, however, is that it is proposed that the UTM/USS <NUM> is to be the main function to associate a UAV <NUM> with its UAV controller <NUM>. However, the main function of the UTM/USS <NUM> is to allow a civil aviation authority to provide authorization for flights and track location of UAVs <NUM>.

In certain embodiments, the solution proposed herein overcomes the shortcomings in the conventional solutions by using a Flight Coordination Subsystem ( "FCSF") <NUM> located in the 3GPP core network where upon receiving an authorization of a UAV's flight operation creates a <NUM> LAN group for the UAV <NUM> and the associated UAV controller <NUM>. In one embodiment, the FCSF <NUM> sends a notification to the <NUM> core network of the newly created <NUM> LAN group that is stored in the subscription profile in the UDM/UDR <NUM>. The UDM/UDR <NUM> then notifies the PCF <NUM> that a new <NUM> LAN group has been created. The PCF <NUM> creates updated UE route selection policies ("URSP") and rules for the UAV <NUM> and the UAV controller <NUM> that are used to establish a PDU session for UAV operation.

<FIG> depicts one embodiment of a network architecture <NUM> for authorization of pairing and connectivity setup for a UAV <NUM> and a UAV controller <NUM>. In the depicted architecture <NUM>, the UAS operator <NUM> owns, manages, maintains, administers, or the like, the UAS <NUM> that contains a UAV controller <NUM> and a UAV <NUM>. The UAV controller <NUM> and UAV <NUM>, in one embodiment, are paired via a UAV <NUM> reference point when both connect via the 3GPP core network <NUM>.

In one embodiment, the UAS operator <NUM> requests flight authorization for a UAS <NUM> via a UAV <NUM> reference point to the FCSF <NUM> that is part of the 3GPP core network <NUM>. The FCSF <NUM>, in further embodiments, interfaces with a UTM/USS <NUM> via a UAV <NUM> reference point. The UTM/USS <NUM> may be a separate function with an interface defined outside of 3GPP. It is noted that, in one embodiment, an implementation-based interface may be used between the UAS operator <NUM> and FCSF <NUM> instead of a standardized UAV <NUM> reference point, which is out of scope of 3GPP.

In one embodiment, at the time the UAS operator <NUM> registers the UAS <NUM>, which is composed of a UAV controller ("UAV-C") <NUM> and UAV(s) <NUM>, to the UTM/USS <NUM>, the UAS operator <NUM> may provide the UAV-C <NUM> and UAV(s) <NUM> external identifiers (e.g., a generic public subscription identifier ("GPSI"), a mobile station international subscriber directory number ("MSISDN"), and/or the like). In further embodiments, the UTM/USS <NUM> assigns a UAS registration identifier for the UAS <NUM>. If the 3GPP network <NUM> has deployed an optional FCSF <NUM>, the FCSF <NUM> may assign a 3GPP-level UAS identifier corresponding to the UAS registration identifier. In an alternative embodiment, the FCSF <NUM> may be aware of the UAS external identifiers and provide them to the UTM/USS <NUM>.

In one embodiment, when a UAS operator <NUM> submits a request for flight authorization, the UAS operator <NUM> includes the 3GPP-level UAS identifier or UAS registration identifier and may include external identifiers for the UAV <NUM> and UAV-C <NUM> to the FCSF <NUM>. In one embodiment, the FCFS <NUM> may identify external identifiers for the UAV <NUM> and UAV-C <NUM>, if not provided by the UAS operator <NUM>. In certain embodiments, the FCFS <NUM> forwards the request for flight authorization to the UTM/USS <NUM>. The UTM/USS <NUM>, in response to the flight authorization request, may authorize the request, ensuring that the UAV-C <NUM> is allowed to control the UAV <NUM> and assigning a flight authorization identifier. The flight authorization identifier may also be used as authorization for pairing.

In one embodiment, when the UAS <NUM> establishes a user plane connection via the 3GPP system <NUM>, e.g., a PDU session. the UAV <NUM> may indicate that connectivity is required for UAV operation. This indication may be a combination of a specific data network name ("DNN'), a single - network slice selection assistance information ("S-NSSAI"), and/or or a new indication.

In one embodiment, the SMF <NUM> determines that the request is for UAV operation and sends a request to the FCSF <NUM>. The FCSF <NUM>, in certain embodiments, determines the external identifier of the UAV <NUM> and the flight authorization identifiers that are authorized for this UAV <NUM> and forwards the request to the UTM/USS <NUM>.

In one embodiment, when the UTM/USS <NUM> receives the authorization request, the UTM/USS <NUM> authorizes the request to ensure that the UAV controller <NUM> that is linked or associated with the provided external identifier can pair with the UAV <NUM> that is associated with the provided external identifier and is linked to the flight authorization identifier.

In one embodiment, when the FCSF <NUM> receives the authorization approval, the FCSF <NUM> configures a <NUM> LAN in the 3GPP system allowing the UAV-C <NUM> and UAV <NUM> to communicate as shown in <FIG>. The FCSF <NUM>, in one embodiment, acts as an application function and provides configuration parameters to setup a <NUM> LAN group. The connection between the UAV-C <NUM> and the UAV <NUM> may be via UAV <NUM>, which is supported by associating the PDU session of the UAV <NUM> with the PDU session of the UAV-C <NUM>, as described in more detail below.

<FIG> depicts one embodiment of a flow diagram <NUM> for pairing a UAV <NUM> and a UAV-C <NUM> using a <NUM> LAN group. In the depicted embodiments, the UAV <NUM>, and the UAV-C <NUM> each access the RAN <NUM> to establish a PDU session via a user plane function <NUM>, which is anchored by a PDU session anchor <NUM>. As shown in <FIG>, the PDU sessions of the UAV <NUM> and the UAV-C <NUM> are associated, linked, paired, or the like via a <NUM> LAN group for facilitating communications between the UAV <NUM> and the UAV-C <NUM>.

<FIG> depict one embodiment of a signal flow diagram <NUM> for authorizing and configuring pairing of unmanned aerial system. Referring to <FIG>, at step <NUM>, a UAS operator <NUM> initiates (see messaging <NUM>) a UAS registration procedure with an FCFS <NUM> located within the 3GPP core network. The FCSF <NUM>, in one embodiment, interfaces with a USS/UTM <NUM>. The UAS operator <NUM>, in certain embodiments, provides information about the UAS system such as external identifiers for the UAV <NUM> and the UAV-C <NUM> (e.g., MSISDN, GPSI, or the like), the UAS model, the UAS type, and/or the like.

At step <NUM>, in one embodiment, the FCSF <NUM> assigns (see block <NUM>) a 3GPP identifier (e.g., a 3GPP-level UAS identifier) for the UAS <NUM> and associates it to the external identifier of the UAV <NUM> and UAV-C <NUM>.

At step <NUM>, in one embodiment, the FCSF <NUM> forwards (see messaging <NUM>) the registration request to a USS/UTM <NUM>. The FCSF <NUM> may include the external identifiers of the UAV <NUM> and UAV-C <NUM> of the UAS <NUM>.

At step <NUM>, in one embodiment, the USS/UTM <NUM> assigns (see block <NUM>) a UAS registration identifier that is valid for the UAS system <NUM>, e.g., for the UAV <NUM> and UAV-C <NUM> pair. At step <NUM>, in one embodiment, the USS/UTM <NUM> provides (see messaging <NUM>) a registration acknowledgment, which may include the UAS registration identifier.

At step <NUM>, in one embodiment, the FCSF <NUM> stores (see block <NUM>) the association between the UAS registration identifier and the 3GPP-level UAS identifier. At step <NUM>, in one embodiment, the FCSF <NUM> sends (see messaging <NUM>) the registration acknowledgment to the UAS operator <NUM>, including the 3GPP-level UAS identifier.

In one embodiment, at step <NUM>, the UAS operator <NUM> requests (see messaging <NUM>) flight authorization for the UAS <NUM>. In one embodiment, the request includes the flight details, the 3GPP-Level UAS identifier, and/or the external identifiers of the UAV <NUM> and UAV-C <NUM>.

Referring to <FIG>, in one embodiment, at step <NUM>, if the external identifiers for the UAV <NUM> and UAV-C <NUM> are provided in step <NUM>, the FCSF <NUM> identifies (see block <NUM>) the external identifiers of the UAV <NUM> and UAV-C <NUM>, e.g., using the UAS registration identifier.

In one embodiment, at step <NUM>, the FCSF <NUM> sends (see messaging <NUM>) a flight authorization request to the USS/UTM <NUM>, including the information provided by the UAS operator <NUM> in step <NUM> and the external identifiers of the UAS <NUM>, e.g., the external identifiers for the UAV <NUM> and UAV-C <NUM>.

In one embodiment, at step <NUM>, the USS/UTM <NUM> ensures (see block <NUM>) that the UAV-C <NUM> is authorized to pair with the UAV <NUM> and whether the flight path complies with civil aviation regulations. In such an embodiment, the USS/UTM <NUM> assigns a flight authorization identifier, which may be used as authorization for pairing and also authorization for UAV operations.

In one embodiment, at step <NUM>, the USS/UTM <NUM> provides (see messaging <NUM>) the flight authorization acknowledgement, including the flight authorization identifier to the FCSF <NUM>. In one embodiment, at step <NUM>, based on the authorization result, the FCSF <NUM> stores the association of the flight authorization identifier and the external identifiers, and configures (see block <NUM>) a <NUM>-LAN group, which is described in more detail below. In one embodiment, at step <NUM>, the FCSF <NUM> sends (see messaging <NUM>) the flight authorization acknowledgement to the UAS operator <NUM>.

Referring to <FIG>, at step <NUM>, in one embodiment, the UAV <NUM> is triggered (see block <NUM>) for flight operation. In such an embodiment, the UAV <NUM> is already registered with the 3GPP system.

In one embodiment, at step <NUM>, the UAV <NUM> sends (see messaging <NUM>) a request for a PDU session to an AMF <NUM>, including an indication for UAV operation. The indication may be a specific DNN, a specific S-NSSAI, and/or another indication. The UAV <NUM> may determine the PDU session parameters based on updated URSP rules provided by the PCF <NUM> based on the <NUM> LAN group created by the FCSF <NUM> in step <NUM>.

In one embodiment, at step <NUM>, the AMF <NUM> selects an SMF <NUM> and sends (see messaging <NUM>) a create SM context request message according to a PDU session establishment procedure, e.g., the PDU session establishment procedure described in TS <NUM>.

In one embodiment, at step <NUM>, the SMF <NUM> obtains (see block <NUM>) the SM subscription data of the UAV <NUM> from the UDM <NUM>. The SMF <NUM>, in such an embodiment, determines from the subscription data that the FCSF <NUM> needs to be contacted and that the UAV <NUM> is part of a <NUM> LAN group. In one embodiment, at step <NUM>, the SMF <NUM> sends (see messaging <NUM>) a UAV operation request to the FCSF <NUM>. In one embodiment, at step <NUM>, the FCSF <NUM> determines (see block <NUM>) the external identifier of the UAV <NUM> and the associated flight authorization identifier.

Referring to <FIG>, in one embodiment, at step <NUM>, the FCSF <NUM> sends (see messaging <NUM>) a UAV operation request to the USS/UTM <NUM>, including the external identifier of the UAV <NUM> and the associated flight authorization identifier.

At step <NUM>, in one embodiment, the USS/UTM <NUM> verifies (see block <NUM>) that the UAV <NUM> is authorized for the flight according to the flight authorization identifier and the external identifiers and determines remote identification and tracking information ("RITI").

In one embodiment, at step <NUM>, the USS/UTM <NUM> provides (see messaging <NUM>) the authorization to the FCSF <NUM>. At step <NUM>, in one embodiment, the FCSF <NUM> forwards (see messaging <NUM>) the authorization to the SMF <NUM>.

At step <NUM>, in one embodiment, based on the authorization, the SMF <NUM> configures (see block <NUM>) a group-level N4 session for the <NUM>-LAN group, e.g., as described in TS <NUM> (this step may also be performed after step <NUM>).

At step <NUM>, in one embodiment, the SMF <NUM> stores (see block <NUM>) the authorization data and, at step <NUM>, sends (see messaging <NUM>) a PDU session acknowledgement to the UAV <NUM>, including the RITI.

In certain embodiments, steps <NUM>-<NUM> as depicted in <FIG> may be repeated for the UAV-C <NUM>. In such an embodiment, the SMF <NUM> configures the UAV-C <NUM> to be in the same <NUM>-LAN group as the UAV <NUM>.

<FIG> depicts one embodiment of a signal flow diagram <NUM> for configuring a <NUM> LAN group for authorizing and configuring pairing of unmanned aerial system. In one embodiment, when the FCSF <NUM> receives the flight authorization acknowledgement from the USS/UTM <NUM>, including the flight authorization identifier, and optionally the external identifiers (see step <NUM> of <FIG>), the FCSF <NUM> configures a <NUM> LAN group for the UAS <NUM> (e.g., the UAV <NUM> and the UAV-C <NUM> pair).

The FCSF <NUM>, in further embodiments, assigns the flight authorization identifier as an external group identifier for the <NUM> LAN (<NUM> virtual network) group that includes the list of UAVs <NUM> with their external identifiers as members of this group. The FCSF <NUM>, in certain embodiments, also configures <NUM> LAN group data, including DNN, S-NSSAI, and an applicable application identifier, e.g., an identifier for the application that is used in the UAV <NUM> for UAV operation. The FCSF <NUM>, in certain embodiments, determines these parameters based on implementation or based on the UAS model and UAS type, which the FCSF <NUM> receives or is made aware of during the UAS registration procedure.

In one embodiment, once the FCSF <NUM> has the available data, it updates the UDM <NUM> with the <NUM> LAN group information. The UDM <NUM>, in some embodiments, checks whether the UAVs <NUM> are permitted to form a <NUM> LAN group, assigns an internal group identifier for the <NUM> LAN group, and converts the external identifiers to subscription permanent identifiers.

The UDM <NUM>, in further embodiments, stores the group data as subscription information in the UDR <NUM>.

In one embodiment, if the SMF <NUM> has subscribed to receive notification for group updates, the UDM <NUM> informs the SMF <NUM>. The SMF <NUM> may configure a group level N4 session if there are existing PDU sessions active. In further embodiments, if the PCF <NUM> has subscribed to receive notifications for subscription updates from the UDR <NUM>, the UDR <NUM> informs the PCF <NUM>. The PCF <NUM> may use this information to configure updated URSP rules for the UAV <NUM> and UAV-C <NUM>. In one embodiment, the UAV <NUM> uses the URSP rules when the UAV <NUM> requests user plane resources for UAV operation.

In one embodiment, the URSP rules can be configured as follows:.

As shown in <FIG>, in one embodiment, at step <NUM>, the FCSF <NUM> receives (see block <NUM>), from the USS/UTM <NUM>, an authorization for flight operation including a flight authorization identifier and external identifiers for the UAS <NUM>, e.g., for the UAV <NUM>-UAV-C <NUM> pair.

In further embodiments, at step <NUM>, the FCSF <NUM> configures (see block <NUM>) a <NUM> LAN group for the UAVs <NUM>, setting the flight authorizations identifier as the external group identifier and the external identifiers as a list of members of the <NUM> LAN group.

In one embodiment, at step <NUM>, the FCSF configures (see block <NUM>) <NUM> VN group data for the <NUM> LAN group, which may include a DNN, a S-NSSAI, an applicable application identifier (e.g., the application used in the UAV <NUM> for UAV operation), and/or the like. The FCSF <NUM> may determine these parameters based on an implementation and/or based on the UAS model and type. In one embodiment, the FCSF <NUM> receives or determines the UAS model and type during the UAS registration procedure.

In step <NUM>, in one embodiment, the FCSF <NUM> updates (see messaging <NUM>) the UDM <NUM> by invoking the Nudm_ParameterProvision_Create service operation, including the <NUM> LAN group information. In step <NUM>, in one embodiment, the UDM <NUM> checks (see block <NUM>) if the UAVs <NUM> are permitted to form a <NUM> LAN group from the UDR <NUM>.

In one embodiment, in step <NUM>, the UDM <NUM> assigns (see block <NUM>) an internal group identifier for the <NUM> LAN group and converts the external identifiers to SUPIs. At step <NUM>, in one embodiment, the UDM <NUM> stores the group data as subscription information in the UDR <NUM> by invoking the Nuder_DM_Create service operation (or Nudr_DM_Update if it is an existing field in the database) (see messaging <NUM>).

At step <NUM>, in one embodiment, if the SMF145 has subscribed to receive notifications for <NUM> LAN group updates, the UDM <NUM> informs the SMF <NUM> (see block <NUM>). At step <NUM>, in one embodiment, the UDM <NUM> invokes (see messaging <NUM>) the Nudm_SDM_Notification service operation providing the <NUM> LAN group information to the SMF <NUM>. In one embodiment, at step <NUM>, the SMF <NUM> configures (see block <NUM>) a Group Level N4 session if there are existing PDU sessions active.

In one embodiment, at step <NUM>, if the PCF <NUM> has subscribed to receive notifications for subscription updates from the UDR <NUM>, the UDR <NUM> informs (see block <NUM>) the PCF <NUM>. At step <NUM>, in one embodiment, the UDR <NUM> invokes (see messaging <NUM>) the Nudr_SDM_Notification service operation providing the <NUM> LAN group information to the SMF <NUM>. At step <NUM>, in one embodiment, the PCF <NUM> may use the <NUM> LAN group information to configure updated URSP rules for the UAV <NUM> and UAV-C <NUM>.

<FIG> depicts a user equipment apparatus <NUM> that may be used for authorizing and configuring pairing of unmanned aerial system, according to embodiments of the disclosure. In various embodiments, the user equipment apparatus <NUM> is used to implement one or more of the solutions described above. The user equipment apparatus <NUM> may be one embodiment of the remote unit <NUM>, the UE <NUM>, the UAV <NUM>, and/or the UAV controller <NUM>, described above. Furthermore, the user equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>.

In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the user equipment apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. In some embodiments, the transceiver <NUM> communicates with one or more cells (or wireless coverage areas) supported by one or more base units <NUM>. In various embodiments, the transceiver <NUM> is operable on unlicensed spectrum. Moreover, the transceiver <NUM> may include multiple UE panel supporting one or more beams. Additionally, the transceiver <NUM> may support at least one network interface <NUM> and/or application interface <NUM>. The application interface(s) <NUM> may support one or more APIs. The network interface(s) <NUM> may support 3GPP reference points, such as Uu, N1, PC5, etc. Other network interfaces <NUM> may be supported, as understood by one of ordinary skill in the art.

In certain embodiments, the processor <NUM> may include an application processor (also known as "main processor") which manages application-domain and operating system ("OS") functions and a baseband processor (also known as "baseband radio processor") which manages radio functions.

In some embodiments, the memory <NUM> stores data related to authorizing and configuring pairing of unmanned aerial system. For example, the memory <NUM> may store various parameters, panel/beam configurations, resource assignments, policies, and the like as described above. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the user equipment apparatus <NUM>.

In some embodiments, all, or portions of the output device <NUM> may be integrated with the input device <NUM>.

The transceiver <NUM> communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver <NUM> (or portions thereof) at particular times in order to send and receive messages.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. One or more transmitters <NUM> may be used to provide UL communication signals to a base unit <NUM>, such as the UL transmissions described herein. Similarly, one or more receivers <NUM> may be used to receive DL communication signals from the base unit <NUM>, as described herein. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the user equipment apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. In one embodiment, the transceiver <NUM> includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

In various embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface <NUM> or other hardware components/circuits may be integrated with any number of transmitters <NUM> and/or receivers <NUM> into a single chip. In such embodiment, the transmitters <NUM> and receivers <NUM> may be logically configured as a transceiver <NUM> that uses one more common control signals or as modular transmitters <NUM> and receivers <NUM> implemented in the same hardware chip or in a multi-chip module.

<FIG> depicts a network apparatus <NUM> that may be used for authorizing and configuring pairing of unmanned aerial system, according to embodiments of the disclosure. In one embodiment, network apparatus <NUM> may be one implementation of a RAN node, such as the base unit <NUM>, the RAN node <NUM>, or gNB, described above. Furthermore, the base network apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>.

In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the network apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the network apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more remote units <NUM>. Additionally, the transceiver <NUM> may support at least one network interface <NUM> and/or application interface <NUM>. The application interface(s) <NUM> may support one or more APIs. The network interface(s) <NUM> may support 3GPP reference points, such as Uu, N1, N2, N3, UAV <NUM>, UAV <NUM>, UAV <NUM>, and/or the like. Other network interfaces <NUM> may be supported, as understood by one of ordinary skill in the art.

For example, the processor <NUM> may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. In certain embodiments, the processor <NUM> may include an application processor (also known as "main processor") which manages application-domain and operating system ("OS") functions and a baseband processor (also known as "baseband radio processor") which manages radio function.

In various embodiments, the network apparatus <NUM> is an FCFS, described above. In such embodiments, the transceiver (<NUM>) receives, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle ("UAV") operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier.

In one embodiment, the processor (<NUM>) creates a <NUM> local area network ("LAN") group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group, configures the <NUM> LAN group based on at least at least one parameter associated with the UAV, and updates a third network function with information for the <NUM> LAN group for establishing a protocol data unit ("PDU") session between the UAV and the UAV controller.

In various embodiments, the network apparatus <NUM> is an SMF, described above. In such embodiments, the transceiver <NUM> receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller.

In further embodiments, the transceiver <NUM> receives, at the first network function from a third network function, a second notification comprising an authorization to establish a first connection for command and control ("C2") communication from a first device.

In one embodiment, the processor <NUM> determines that the <NUM> LAN group is associated with the first connection based on the first notification and configures a fourth network function with at least one parameter for the <NUM> LAN group based on the parameters received in the first notification from the second network function to associate the first connection with a second connection from a second device.

In various embodiments, the network apparatus <NUM> is a PCF, described above. In such embodiments, the transceiver <NUM> receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller.

In one embodiment, the processor <NUM> determines that the UAV needs updated user equipment ("UE") route selection policies ("USRPs") for command and control ("C2") operations and creates at least one URSP rule with a new connection capability for UAV C2 operations comprising at least one parameter of the <NUM> LAN group as a route selection descriptor.

In some embodiments, the memory <NUM> stores data related to authorizing and configuring pairing of unmanned aerial system. For example, the memory <NUM> may store parameters, configurations, resource assignments, policies, and the like, as described above. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the network apparatus <NUM>.

As another, non-limiting, example, the output device <NUM> may include a wearable display separate from, but communicatively coupled to, the rest of the network apparatus <NUM>, such as a smart watch, smart glasses, a heads-up display, or the like.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. One or more transmitters <NUM> may be used to communicate with the UE, as described herein. Similarly, one or more receivers <NUM> may be used to communicate with network functions in the NPN, PLMN and/or RAN, as described herein. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the network apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers.

<FIG> is a flowchart diagram of a method <NUM> for authorizing and configuring pairing of unmanned aerial system. The method <NUM> may be performed by an FCFS of a network equipment apparatus <NUM>, described herein. In some embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the method <NUM> includes receiving <NUM>, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle ("UAV") operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier.

In further embodiments, the method <NUM> includes creating <NUM> a <NUM> local area network ("LAN") group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group.

In some embodiments, the method <NUM> includes configuring <NUM> the <NUM> LAN group based on at least at least one parameter associated with the UAV. In certain embodiments, the method <NUM> includes updating <NUM> a third network function with information for the <NUM> LAN group for establishing a protocol data unit ("PDU") session between the UAV and the UAV controller. The method <NUM> ends.

<FIG> is a flowchart diagram of a method <NUM> for authorizing and configuring pairing of unmanned aerial system. The method <NUM> may be performed by an SMF of a network equipment apparatus <NUM>, described herein. In some embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the method <NUM> includes receiving <NUM>, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller.

In one embodiment, the method <NUM> includes receiving <NUM>, at the first network function from a third network function, a second notification comprising an authorization to establish a first connection for command and control ("C2") communication from a first device. In further embodiments, the method <NUM> includes determining <NUM> that the <NUM> LAN group is associated with the first connection based on the first notification.

In some embodiments, the method <NUM> includes configuring <NUM> a fourth network function with at least one parameter for the <NUM> LAN group based on the parameters received in the first notification from the second network function to associate the first connection with a second connection from a second device. The method <NUM> ends.

<FIG> is a flowchart diagram of a method <NUM> for authorizing and configuring pairing of unmanned aerial system. The method <NUM> may be performed by a PCF of a network equipment apparatus <NUM>, described herein. In some embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In certain embodiments, the method <NUM> includes determining <NUM> that the UAV needs updated user equipment ("UE") route selection policies ("USRPs") for command and control ("C2") operations. In one embodiment, the method <NUM> includes creating <NUM> at least one URSP rule with a new connection capability for UAV C2 operations comprising at least one parameter of the <NUM> LAN group as a route selection descriptor. The method <NUM> ends.

A first apparatus for authorizing and configuring pairing of unmanned aerial system may include an FCFS of a network equipment apparatus <NUM>, described herein. In some embodiments, the apparatus may include a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the first apparatus includes a transceiver that receives, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle ("UAV") operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier.

In further embodiments, the first apparatus includes a processor that creates a <NUM> local area network ("LAN") group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group, configures the <NUM> LAN group based on at least at least one parameter associated with the UAV, and updates a third network function with information for the <NUM> LAN group for establishing a protocol data unit ("PDU") session between the UAV and the UAV controller.

In one embodiment, the UAV and the UAV controller are each associated with the first identifier, the first identifier for the UAV and the UAV controller used to facilitate communications between the UAV and the UAV-controller within the <NUM> LAN group.

In one embodiment, the at least one parameter comprises at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV. In certain embodiments, the information of the <NUM> LAN group includes the second identifier of the <NUM> LAN group, the first identifier of the UAV and the UAV controller, and at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV.

In one embodiment, the third network function comprises a unified data management ("UDM") function that is updated with the <NUM> LAN group information using a Nudm_ParameterProvision_Create service operation.

A first method for authorizing and configuring pairing of unmanned aerial system may be performed by an FCFS of a network equipment apparatus <NUM>, described herein. In some embodiments, the first method may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the first method includes receiving, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle ("UAV") operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier.

In one embodiment, the first method includes creating a <NUM> local area network ("LAN") group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group.

In one embodiment, the first method includes configuring the <NUM> LAN group based on at least at least one parameter associated with the UAV. In one embodiment, the first method includes updating a third network function with information for the <NUM> LAN group for establishing a protocol data unit ("PDU") session between the UAV and the UAV controller.

In certain embodiments, the UAV and the UAV controller are each associated with the first identifier, the first identifier for the UAV and the UAV controller used to facilitate communications between the UAV and the UAV-controller within the <NUM> LAN group.

In one embodiment, the at least one parameter comprises at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV.

In one embodiment, information of the <NUM> LAN group includes the second identifier of the <NUM> LAN group, the first identifier of the UAV and the UAV controller, and at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV.

A second apparatus for authorizing and configuring pairing of unmanned aerial system may include an SMF of a network equipment apparatus <NUM>, described herein. In some embodiments, the second apparatus may include a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the second apparatus includes a transceiver that receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller. In further embodiment, the transceiver receives, at the first network function from a third network function, a second notification comprising an authorization to establish a first connection for command and control ("C2") communication from a first device.

In one embodiment, the second apparatus includes a processor that determines that the <NUM> LAN group is associated with the first connection based on the first notification and configures a fourth network function with at least one parameter for the <NUM> LAN group based on the parameters received in the first notification from the second network function to associate the first connection with a second connection from a second device.

In one embodiment, the parameters received in the first notification comprise at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV. In some embodiments, the first connection between the UAV and UAV controller comprises a C2 connection.

In one embodiment, the processor determines that the <NUM> LAN group is used for the C2 connection based at least in part on the parameters received in the first notification. In some embodiments, the processor configures a group level N4 protocol data unit ("PDU") session to receive notifications for <NUM> LAN group updates.

A second method for authorizing and configuring pairing of unmanned aerial system may be performed by an SMF of a network equipment apparatus <NUM>, described herein. In some embodiments, the second method may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the second method includes receiving, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller. In certain embodiments, the second method includes receiving, at the first network function from a third network function, a second notification comprising an authorization to establish a first connection for command and control ("C2") communication from a first device.

In one embodiment, the second method includes determining that the <NUM> LAN group is associated with the first connection based on the first notification. In various embodiments, the second method includes configuring a fourth network function with at least one parameter for the <NUM> LAN group based on the parameters received in the first notification from the second network function to associate the first connection with a second connection from a second device.

In one embodiment, the parameters received in the first notification comprise at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV.

In one embodiment, the first connection between the UAV and UAV controller comprises a C2 connection. In one embodiment, the second method includes determining that the <NUM> LAN group is used for the C2 connection based at least in part on the parameters received in the first notification. In one embodiment, the second method includes configuring a group level N4 protocol data unit ("PDU") session to receive notifications for <NUM> LAN group updates.

A third apparatus for authorizing and configuring pairing of unmanned aerial system may include a PCF of a network equipment apparatus <NUM>, described herein. In some embodiments, the third apparatus may include a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the third apparatus includes a transceiver that receives, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller. In one embodiment, the third apparatus includes a processor that determines that the UAV needs updated user equipment ("UE") route selection policies ("USRPs") for command and control ("C2") operations and creates at least one URSP rule with a new connection capability for UAV C2 operations comprising at least one parameter of the <NUM> LAN group as a route selection descriptor.

In one embodiment, the parameters received in the first notification comprise at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV. In one embodiment, the at least one URSP rule comprises a specific connection capability in a traffic descriptor.

In one embodiment, the at least one USRP rule comprises one of an application identifier and a traffic filter in a traffic descriptor that is mapped to an application in the UAV that is used for UAV operation. In some embodiments, the at least one USRP rule comprises a new indicator indicating UAV operation in a traffic descriptor.

A third method for authorizing and configuring pairing of unmanned aerial system may be performed by a PCF of a network equipment apparatus <NUM>, described herein. In some embodiments, the third method may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the third method includes receiving, at a first network function from a second network function, a first notification comprising parameters of a <NUM> local area network ("LAN") group of a mobile wireless communication network, the <NUM> LAN group facilitating communications between a UAV and a UAV-controller.

In further embodiments, the third method includes determining that the UAV needs updated user equipment ("UE") route selection policies ("USRPs") for command and control ("C2") operations. In some embodiments, the third method includes creating at least one URSP rule with a new connection capability for UAV C2 operations comprising at least one parameter of the <NUM> LAN group as a route selection descriptor.

In one embodiment, the parameters received in the first notification comprise at least one of a data network name ("DNN"), a single network slice selection assistance information ("S-NSSAI"), and an application identifier associated with the UAV. In further embodiments, the at least one URSP rule comprises a specific connection capability in a traffic descriptor.

In some embodiments, the at least one USRP rule comprises one of an application identifier and a traffic filter in a traffic descriptor that is mapped to an application in the UAV that is used for UAV operation. In certain embodiments, the at least one USRP rule comprises a new indicator indicating UAV operation in a traffic descriptor.

Claim 1:
An apparatus (<NUM>), comprising:
a transceiver (<NUM>) arranged to receive, at a first network function of a mobile wireless communication network, a first authorization of unmanned aerial vehicle, UAV, operations and a second authorization for associating a UAV-controller with the UAV, the first and second authorizations associated with a first identifier; and
a processor (<NUM>) arranged to:
create a <NUM> local area network, LAN, group within the mobile wireless communication for facilitating communications between the UAV and the UAV-controller and associating a second identifier with the <NUM> LAN group;
configure the <NUM> LAN group based on at least at least one parameter associated with the UAV; and
update a third network function with information for the <NUM> LAN group for establishing a protocol data unit, PDU, session between the UAV and the UAV controller.