CN117917128A - System and method for safely and reliably commanding and controlling an unmanned aerial vehicle in flight via a public land mobile network - Google Patents

Abstract

Systems and methods for supporting multiple Unmanned Aerial Vehicle (UAV) service providers (multiple USSs) are described. The method may be performed by a wireless transmit/receive unit (WTRU) including a UAV Application Enabled (UAE) client located in the UAV, where the method is performed with the UAV in flight. The steps may include: sending a registration request to a UAE server, the registration request including an indication of multiple USS capabilities; receiving a registration response message, the registration response message including an indication that the UAE server supports multiple USS capabilities; receiving a multiple USS configuration request, the multiple USS configuration request comprising: a list of multiple USS configuration parameters, and allowed USSs, related to conditions under which the UAE client may initiate a USS change; sending a multi-USS configuration response; and executing the multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameter.

Description

System and method for safely and reliably commanding and controlling an unmanned aerial vehicle in flight via a public land mobile network

Cross Reference to Related Applications

The application claims the benefit of the following U.S. provisional applications: 63/324,887 submitted on 29 of 2022, 63/307,476 submitted on 7 of 2022, 8, and 63/230,405 submitted on 6 of 2021, all three of which provisional applications are incorporated herein by reference.

Background

Unmanned Aerial Vehicles (UAVs) can help address important challenges in transportation, commerce, and public services. The unmanned aerial vehicle system (UAS) includes a UAV and a UAV controller (UAV-C). The success of UAV tasks and human safety depend on a reliable, robust, and secure command and control (C2) communication link between UAV and UAV-C. Unreliable C2 links may lead to accidents, task aborts or failures, UAV flight aborts or UAV emergency landings. To avoid these and other adverse consequences, there is a need for systems and methods that: these systems and methods provide a reliable, robust, and secure C2 link for an in-flight UAS over an entire planned route, particularly if UAV operation is beyond the line of sight (BVLOS) of a human UAV controller. Disclosed, described, and claimed herein are systems and methods by which an in-flight UAV may maintain a reliable, robust, and secure C2 link with a UAV controller throughout a planned route.

There is also a need for enhancements to the application architecture for UAS applications. More specifically, there is a need to support multiple UAV service provider (USS) deployments and enhancements to the UAV Application Enablement (UAE) layer to support changes in USS and UAS Traffic Management (UTM) during flight. Since the various USSs supporting the UAV may be deployed in different Data Networks (DNs), including Edge Data Networks (EDNs), there is also a need to define how UAE layer requirements should assist UAS application traffic to traffic steering of different DNs/EDNs to avoid application service interruption in flight.

Disclosure of Invention

Methods, systems, and apparatus for reliable in-flight command and control of Unmanned Aerial Vehicles (UAVs) via Public Land Mobile Networks (PLMNs) are disclosed. Systems and methods for supporting multiple Unmanned Aerial Vehicle (UAV) service providers (multiple USSs) are described. The method may be performed by a wireless transmit/receive unit (WTRU) including a UAV Application Enabled (UAE) client located in the UAV, where the method is performed with the UAV in flight. The steps may include: sending a registration request to a UAE server, the registration request including an indication of multiple USS capabilities; receiving a registration response message, the registration response message including an indication that the UAE server supports multiple USS capabilities; receiving a multiple USS configuration request, the multiple USS configuration request comprising: a list of multiple USS configuration parameters related to conditions under which a UAE client may initiate a USS change, and allowed USSs; sending a multi-USS configuration response; and executing the multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameter.

A solution is described herein that supports multiple USS using enhanced UAE.

In one example, a UAE client may register with a UAE server. The process may begin when a UAE client sends a registration request to a UAE server that includes an indication of multiple USS capabilities. The UAE server may interact with a service USS (e.g., a default, primary/master USS for a UAV) for authentication and authorization checking, and may indicate UAE client multi-USS capabilities and/or UAE client context information (e.g., current location, service PLMN information, prescribed forward flight path). How the UAV current position may be determined is described in the examples below. The UAE server may also indicate to the service USS the UAE server multi-USS capabilities and possibly UAE server context information (e.g., current location and/or geographic area served, serving PLMN and coverage information, current/maximum served UAV capabilities, prescribed forward flight path). The UAE server may receive an acknowledgement message from the USS, which may include any of a list of allowed USS information (e.g., USSID, IP address, DN/EDN), multi-USS support policies (examples provided below). The acknowledgement message may also include USS change initiation information. The USS change initiation information may also include information about the UAE server and the UAE client, as well as the extent to which the USS allows the UAE layer (the UAE server and/or the UAE client) to initiate a change in the USS. The acknowledgement message may also include service USS information (e.g., USSID, IP address, DN/EDN) that may be different from the current service USS. The (e.g., new) serving USS and other authorized USS may be allocated based on a UAV geographic area, serving PLMN, time, and other operational constraints determined by the USS network (e.g., qoS requirements for UAV-USS communications, current traffic volume, or prescribed forward flight path). According to the above embodiment, the UAE server may notify the 5G core network (5 GC) of the new service USS information via the UAS NF. For example, the UAE server may send a new service USS, i.e., a list of authorized USSs, to the UAS NF (e.g., on behalf of the USS network). 5GCUAS NF may use this information to determine that the USS request is authorized for a particular service/operation (e.g., location tracking of UAV, revocation of UAV authorization). If the UAE server supports such capabilities, the UAE client receives a registration response from the UAE server that includes a success indication. The message may include any of a multi-USS supported acknowledgement, a list of allowed USS authorization information, current service USS information (e.g., new), USS change initiation information. If the current service USS information provided is new, the UAE client may configure the UE to use the new USS address by informing the application layer and/or lower layers to use the new service USS address (e.g., for network remote id, telemetry). Alternatively, a multi-USS capability exchange between the UAE layer and the USS network may be initiated/negotiated during a dedicated management procedure as shown below.

Procedures for initiating multiple USS support capability and multiple USS support configuration are described herein. More specifically, the following illustrates a method of multi-USS support enabled at a UAE server and a UAE client upon request from a USS. The UAE server may receive a multi-USS management request from a serving USS for managing support for the multi-USS. The request may include UAV (UAE client) identification information and multiple USS configuration parameters as described herein. The UAE server may send a response confirming support based on the support of such capabilities by the UAE client and server. The UAE client may receive a multi-USS configuration request from the UAE server that includes any of a list of allowed USS information, current service USS information (e.g., new), USS change initiation information, and multi-USS support policies. The policy may include parameters and/or rules as to whether the UAE client may initiate a change in USS (i.e., USS change initiation information parameter) and/or how the UAE client may handle the change in USS. For example, the policy may include rules for the UAV to communicate with new USSs from a list of allowed USSs without a responsive current service USS, or changes in USSs based on time of day, prescribed forward flight path or UAV geographic location, current service PLMN (e.g., when the UAV may be served by multiple PLMNs as described above), etc. The UAE client may store the multiple USS support configuration parameters and send a multiple USS support configuration response to the server. The server may store multiple USS support configuration parameters in the UAE client context. The UAE client may initiate selection and communication with a (e.g., new) service USS based on the multiple USS configuration parameters. USS can also be removed from the multi-USS configuration for the UAE server/UAE client by removing all multi-USS configuration parameters and providing the UAE server/UAE client with (e.g. only) a USS identifier for the USS in question.

A method for dynamically changing the current service USS enabled at a UAE server and a UAE client based on a request from the USS and/or based on a UAE client/server configuration is described herein. The UAE server may receive USS change requests from USSs. The request may include UAV (UAE client) identification information, new service USS information and USS change authorization information (e.g., tokens), change constraint parameters (e.g., delay before change, geographic location/region threshold for change). The UAE server may verify that the request is authorized. For example, the UAE server may verify that the multi-USS capability has been enabled for the UAV based on the UAE client context information (e.g., current location, time of day, current serving PLMN, prescribed forward flight path). The UAE server may request a UAV geographic location (e.g., via a UAS NF or Service Enabled Architecture Layer (SEAL) interface) from a location server in a UAV service PLMN. The UAE server may verify that the request was sent by the current service USS associated with the UAV (e.g., based on the UAE client context). If the request is sent by a different USS, the UAE server may verify that the requesting USS provides a valid authorization token (e.g., signed by the current serving USS). The UAE server may verify that the request USS is part of a list of allowed USSs in the UAE client context. The UAE server may update the list of USSs allowed in the UAE client context to include the new USS information. The UAE client may receive a USS change message from the UAE server that may include new service USS information. The UAE client may use the new USS information to update a list of USSs allowed in the multiple USS support parameters (e.g., set to current, added to the allowed list). If the request does not indicate new USS service information, the UAE client may select a new service USS based on the stored multiple USS configuration parameters. The UAE client may initiate communication with the new service USS based on the multiple USS configuration parameters/change requests. Alternatively, the UAE client may initiate a change in USS (e.g., without an explicit request from the UAE server) based on an application trigger from the application layer, based on multiple USS configuration parameters (e.g., losing communication with the current serving USS, entering an area/PLMN roaming requiring USS change based on USS change policy). The UAE client may consider USS change initiation information. The UAE client may send a USS change report message, which may include new service USS information, a reason code for the USS change (e.g., loss of USS connection, USS trigger, location/time/PLMN connection trigger). The UAE server may update USS information in the UAE client context (e.g., current service USS) accordingly. The UAE server may send a USS change response to the requesting USS, or alternatively a USS change notification message, which may include a new service USS and/or a reason code for the change provided by the UAE client. The notification message may be sent to the previous USS and/or the new USS. The UAE server may receive an acknowledgement from the USS for the USS change notification message.

Alternatively, the UAE server may initiate a change in USS (e.g., on behalf of USS) based on a multi-USS configuration parameter (e.g., USS change initiation info, multi-USS support policy) provided by the USS. For example, if the UAE server is allowed to initiate a change of USS according to a USS change initiation information parameter, the UAE server may select a new USS from the multi-USS configuration according to a policy (e.g., after determining that a USS change is required when the UAV enters/leaves the area of interest based on the UAV location received from the location server) and may instruct the client to change to a new serving USS, as according to the embodiments above.

Drawings

A more detailed understanding of the description may be derived from the following description, taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like elements, and in which:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

Fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A according to one embodiment;

FIG. 2 is a system diagram illustrating an exemplary UAS application layer functional model;

FIG. 3 is a high-level block diagram of a system for implementing embodiments;

Fig. 4 illustrates actions of a first User Equipment (UE) for registering an Unmanned Aerial Vehicle (UAV) having the capability to support communication via more than one Public Land Mobile Network (PLMN) for communication with a UAV Support Service (USS) according to an embodiment implemented in the system shown in fig. 3;

Figures 5A and 5B illustrate actions for Authorizing and Authenticating (AA) a first UE of a UAV to communicate with a USS by performing a USS-UAV authorization-authentication (UUAA) procedure, according to an embodiment;

Figure 6 illustrates actions of a registration and UUAA procedure by which a second UE of a UAV is authorized and authenticated for communication with USS, according to an embodiment;

Fig. 7 illustrates actions for authorizing command and control (C2) communications between a second UE of a UAV and a USS via a second PLMN, according to an embodiment;

Fig. 8 illustrates further actions for pairing a second UE of a UAV with a UAV controller (UAV-C) to handover a UAV C2 communication session from a first PLMN to a second PLMN, according to an embodiment;

figure 9 is a high level flow chart showing actions for switching a UAV from a first USS to a second USS according to an embodiment;

FIG. 10 is a block diagram illustrating an exemplary system for implementing embodiments;

figure 11 is a detailed flow diagram illustrating an action for switching a UAV from a first USS to a second USS according to an embodiment;

Figures 12A and 12B are flowcharts illustrating further actions for switching a UAV from a first USS to a second USS according to an embodiment;

figure 13 is a flowchart illustrating further actions for switching a UAV from a first USS to a second USS according to an embodiment; and

Figure 14 illustrates an exemplary procedure for UAE support for multiple USS operations.

Detailed Description

An unmanned aerial vehicle system (UAS) includes an Unmanned Aerial Vehicle (UAV) and a UAV controller (UAV-C). UASs are often equipped for direct point-to-point communication with each other using unlicensed industrial/scientific/medical (ISM) radio bands. However, communication in the ISM band has drawbacks. First, the range of radio frequency signals in the ISM band is limited. Furthermore, the communication channels in this band may be unreliable, unsafe, and unable to support data rates appropriate for command and control (C2) of the UAV. These drawbacks can adversely affect UAV flight operations.

For example, during UAV flight, a communication channel used to communicate with UAV-C may experience quality of service (QoS) degradation. This may result in the command and control signals being discarded. For example, due to an interruption within a 3GPP (communications provider) network, the UAV may lose connectivity with the UAV-C entirely. For example, a segment of the planned route of the UAV may be experiencing an interruption that would prevent the UAV from communicating with the UAV-C during that segment of the UAV route. In such cases, a UAV Support Service (USS) may communicate with the UAV. For example, the UAV may receive an indication from USS by which the UAV navigation system may reschedule the remainder of the UAV flight to avoid the interruption. During the re-planning process, the UAV may need to establish communication links with other network components to coordinate other related changes indicated by USS. These tasks are challenging for an in-flight UAV to perform.

USS may be operated by an entity that manages the airspace for UAS operation and provides an interface to Air Traffic Management (ATM) and Air Navigation Service Providers (ANSP). For any given geographic airspace, one or more USS may share the administrative responsibilities of different UAS operations. The UTM client functionality may be a UAS operator or UAS that accesses UTM services via USS.

A method of providing a reliable 3GPP network connection to a UAS is presented. The present invention enables the UAV to operate on routes that meet the minimum service level requirements of the connection, or alternatively apply emergency/emergency communication procedures. In some embodiments, emergency/emergency operation is applied. Embodiments of the present invention support line-of-sight (BVLOS) operation and provide high performance, secure, and reliable communications for communications between UAV and UAV-C.

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word discrete fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filter OFDM, filter Bank Multicarrier (FBMC), and the like.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN) 104, a Core Network (CN) 106, a Public Switched Telephone Network (PSTN) 108 (which may include a Public Land Mobile Network (PLMN) in some embodiments), the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a Station (STA), may be configured to transmit and/or receive wireless signals, and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptop computers, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones (including Unmanned Aerial Vehicles (UAVs)), medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronics devices, devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the internet 110, and/or the other networks 112. As an example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs (enbs), home node bs, home evolved node bs, next generation node bs, such as gNode B (gNB), new air interface (NR) node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or high speed Uplink (UL) packet access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or advanced LTE (LTE-a) and/or advanced LTE Pro (LTE-a Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may use NR to establish the air interface 116.

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., enbs and gnbs).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the wtrus 102c, 102d may utilize A cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A pro, NR, etc.) to establish A pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the internet 110 via the CN 106.

The RAN 104 may communicate with a CN 106, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that RAN 104 and/or CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, wiMAX, E-UTRA, or WiFi radio technology.

The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU102c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology. Multiple WTRU transceivers, such as a first transceiver and a second transceiver, may be provided within a single housing to include a first User Equipment (UE) and a second UE. Alternatively, the first UE may include a first WTRU transceiver and the second UE may include a second WTRU transceiver. A single WTRU transceiver may include a multi-mode transceiver for communicating with different wireless networks over different wireless links.

Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Although the transmit/receive element 122 is depicted as a single element in fig. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment. In a UAV embodiment, the processor 118 is configured to cooperate with the GPS chipset 136 to provide the current location of the WTRU, and thus the UAV, to a UAV controller (UAV-C), a network or one or more components thereof, a UAV service provider (USS) or a UAV traffic management system (UTM) or one or more components thereof.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photographs and/or video), universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, wireless communications devices, and the like,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographic position sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, and the like.

WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit for reducing and/or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which some or all signals are transmitted and received (e.g., associated with a particular subframe for UL (e.g., for transmission) or DL (e.g., for reception).

Fig. 1C is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with CN 106.

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be appreciated that any of these elements may be owned and/or operated by entities other than the CN operator.

The MME 162 may be connected to each of the evolved node bs 162a, 162B, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.

The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).

In representative embodiments, the other network 112 may be a WLAN.

A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, via a combination of a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).

The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).

WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, since the STA (supporting only 1MHz mode of operation) is transmitting to the AP, all available frequency bands may be considered busy even if most available frequency bands remain idle.

The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Fig. 1D is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include gnbs 180a, 180b, 180c, although it will be appreciated that RAN 104 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one implementation, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, gnbs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from gnbs 180a, 180b, 180 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from transmission to transmission, from cell to cell, and/or from part of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slices, interworking between DC, NR, and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

The CN 106 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it should be appreciated that any of these elements may be owned and/or operated by entities other than the CN operator.

The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and so on. The AMFs 182a, 182b may provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi. In some embodiments, the AMF 182a and/or AMF 182b also communicate with USS or UAV Traffic Management (UTM) systems.

The SMFs 183a, 183b may be connected to AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 106 via an N4 interface. SMFs 183a, 183b may select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.

The UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the local DNs 185a, 185b.

In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-d, base stations 114a-B, evolved node bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN 185a-B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.

The simulation device may be designed to conduct one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more emulation devices can perform one or more or all of the functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device can be directly coupled to another device for testing purposes and/or perform testing using over-the-air wireless communications.

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test laboratory and/or a test scenario in a non-deployed (e.g., test) wired and/or wireless communication network in order to enable testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and/or receive data.

The following abbreviations may be referred to in the present application.

AA: authentication and authorization

AMF: access and mobility management functions

BVLOS: beyond the line of sight

C2: command and control

CAA: civil aviation bureau

CN: core network

FAA: federal aviation administration

GPSI: universal public subscription identifier

ISM: industrial, scientific and medical use

MOPS: minimum performance criteria

MUSIM: multi-user identification module

NAS: non-access stratum

NASA: aviation and aerospace agency of the United states

NEF: network exposure function

NF: network function

PCF: policy control function

PDU: packet data unit

PLMN: public land mobile network

RAN: radio access network

SMF: session management function

UAS: unmanned aerial vehicle system

UAS NF: UAS network function

UAV (unmanned aerial vehicle): unmanned aerial vehicle

UAV-C: UAV controller

USS: UAS service provider

UTM: UAS traffic management

UUAA: USS UAV authorization/authentication

UUAA-MM: UUAA mobility management

UUAA-SM: UUAA Session management

The WTRU: wireless transmitting/receiving unit

Turning now to fig. 2-14, embodiments of secure and reliable command and control of an in-flight UAV via a public land mobile network such as described above are shown.

For purposes of this specification, unmanned aerial vehicle systems (UASs) include Unmanned Aerial Vehicles (UAVs) and UAV controllers (UAV-C). UAS relies on command and control (C2) communication links to carry remote command and telemetry messages between UAVs and UAVs-C. The C2 communication link may be established in an unlicensed ISM band. However, operation in this band has drawbacks. One disadvantage is the limited communication range of ISM band signals. Other drawbacks include unreliability of ISM band communication links, lack of security, and low data rates. Many UAV applications require that the UAV operate in a range that extends well beyond the visual line of sight (BVLOS). ISM band C2 communication links are unsuitable for those applications due to their limited range. Embodiments of the present invention use Public Land Mobile Networks (PLMNs) for C2 communications between UAVs and UAVC to achieve an extended operating range. In particular, embodiments of the present invention leverage advanced capabilities of 3GPP systems, including 5G capabilities implemented using PLMN to support C2 communications between UAVs and UAVC. In these embodiments, a reliable, robust, and secure C2 communication link is particularly important for secure and successful UAV operation.

UASs that rely on PLMNs for C2 communications may experience unexpected degradation of quality of service (QoS), network disruption, or other connectivity issues in one or more segments of a UAV planned flight route. To avoid the adverse consequences of such problems, systems and methods are provided for facilitating handover of UAV-UAVC C2 communications from a first PLMN to a second PLMN when a first PLNM does not meet given criteria. Methods for supporting communication or coordination activities that may be required for such a handoff are also provided. The disclosed embodiments relate to ensuring that UASs communicate throughout their routes on PLMNs that meet network connection minimum service level requirements.

In recent years, the number of UAVs has grown rapidly, and applications for UAVs are expanding to various industries. Various regulatory authorities, including FAA/NASA and industry communities, have developed models and requirements for UAV Traffic Management (UTM) to ensure safe and secure operation of UAVs in unregulated air spaces. Thus, the UTM system may include a network of UAS service providers (USSs) that may communicate with the UAV and with each other to avoid collisions between UAV flights and to provide other types of support for UAV operators.

During UAV flight, the communication link established between the UAV and USS may become unreliable or unavailable. A reduction in quality of service (QoS), such as a low data rate or high latency of the PLMN, may result in an interruption of communication between the UAV and USS. For example, USS may have limited service availability in some areas, or the USS may need to perform load balancing due to increased UAV traffic management load. USS may have reached its maximum capability by servicing the maximum allowed number of UAVs that it can manage and thus cannot support the addition of another UAV. Furthermore, UAVs are not all identical. UAVs can be used in many different ways with different capabilities, different flight characteristics, different operational models, and cost constraints. Not all USS may be equipped or adapted to a given UAV or UAV mission. For certain UAV tasks and/or UAV types, or for UAV operations within a particular geographic region, some USSs may be more fully equipped/adapted than other USSs.

The UAV may experience a loss of performance capability due to instability of the communication link with the USS, or unavailability or inappropriateness of a given USS for communication with the UAV. There is a need for systems and methods that support the ability of UAVs to maintain reliable, robust, and secure communications with UTMs or USSs throughout their routes. Embodiments of the present invention provide such support by a method for handing over a UAV from a first USS to a second USS in the event of an accident or emergency, and maintaining their operation within constraints, e.g., within approved operational concepts.

Before the UAV can communicate with the UAV-C, the UAV and UAV-C must be paired. It is desirable to securely perform pairing authorization of the UAV and UAV-C before establishing a C2 connection between the UAV and UAV-C. Unauthorized pairing of UAV and UAV-C may pose serious risks to UAS security and public safety. PLMNs implementing the 3GPP standards may include network functions that support USS/UTM and UAV-C pairing for authentication and authorization prior to enabling a data connection between the UAV and UAVC. The 3GPP system can also provide network functionality for UTM/USS to revoke UAV and UAV-C pairing authority in order to disconnect the UAV from UAVC. Methods according to embodiments of the present invention leverage these PLMN functions and capabilities to support reliable, robust, and secure communications between UAVs and UAVC.

FIG. 2 illustrates a simplified UAS application layer functional model 200 for providing support for UAV applications according to embodiments. The UAE layer 210 includes a UAE client 214 that resides in the UE and can provide APIs to UAS client applications 212 and interface with a UAE server 224 that provides APIs to UAS server applications (e.g., USSs) 222.

The UAS application Server 220, also referred to herein as a USS, includes a UAS application specific Server 222, a UAS server 224, and one or more SEAL servers 226. The UAE layer may also include a service-enabled architecture layer (SEAL) client 216. The UAE server 224 may also interface with the 3GPP network system 230 directly via a Network Exposure Function (NEF) API 225 or via a SEAL service 227. The UAS application specific client 212 communicates with a UAS application specific server via an interface UA-APP 213. The UAE client 214 communicates with the UAE server 224 via interfaces U1-AE 215. The SEAL client communicates with the SEAL server via interface SEAL-UU 217.

Fig. 3 is a high-level block diagram of a system including a plurality of Public Land Mobile Networks (PLMNs) for implementing embodiments of the invention described and disclosed herein. The system includes at least a first PLMN310 and a second PLMN 320. Each of PLMNs 310 and 320 may have a 5G core Service Based Architecture (SBA). Each of PLMNs 310 and 320 may communicate with UAV 330. The UAV 330 is equipped with a first User Equipment (UE) 332 and a second UE 334. Each PLMN310 and 320 includes a first UAS network function (UAS-NF) 312 and a second UAS-NF 322 for communicating with USS or UTM 340.

Figure 4 illustrates actions for registering a UAV according to an embodiment implemented in the system shown in figure 3.

At act 412, UE1 410 of the UAV transmits a registration request to AMF1 420 of the first PLMN (not shown). The registration request includes an indication that UE1 is equipped to communicate over more than one PLMN. In some embodiments, UE1 410 sends a registration request message along with the CAA-level UAV ID along with an indication of supporting multi-PLMN connection capabilities (e.g., multi-PLMN connections for redundant application connections that are dedicated to a portion of MUSIM capabilities or more applications).

In some embodiments, one or more UEs of the UAV include a processor configured to provide functionality, such as the ability to perform network registration functions, to one or more UEs of the UAV. For example, in some embodiments, the processor is configured to impart the capability for one or more UEs to transmit and receive formatted network registration request messages from the network in response to or in support of the network registration request. In some embodiments, the processor is configured to include in such transmissions an indication of UE capabilities, e.g., capabilities for transmission via more than one PLMN and/or more than one channel of a PLMN.

In one embodiment, the first UE performs a primary authentication procedure if the first UE has not been authenticated. For example, at act 413, UE1 410 communicates with AMF1 420 of the first PLMN to perform a conventional master authentication procedure with a 3GPP authentication function (AUSF, not shown in the figure) and a Unified Data Management (UDM) 430 to authenticate UE1 to the first PLMN.

At act 414, AMF1 420 processes the registration request. In some embodiments, AMF1 420 performs actions to verify that the UAV is authorized for multi-PLMN support based on the UE subscription (e.g., UUAA across multiple PLMNs). As a result of the processing, AMF1 may determine at act 3 that UE1 410 is authorized to communicate with multiple PLMNs to perform UUAA procedures with the multiple PLMNs, and that the UAV is equipped with more than one UE.

At act 415, AMF1 transmits an indication of the registration request granted to UE 1. For example, in the case where UE1 is authorized for multi-PLMN support, AMF1 sends a registration accept 414 with a pending UUAA indication. If the multi-PLMN support is not authorized, the AMF may send a registration accept but include an indication that the multi-PLMN is not authorized. In this scenario, the UE may prohibit UUAA from originating with the second PLMN.

At act 416, UE1 performs a first UUAA procedure to authenticate the UAV to the USS. For example, in some embodiments, AMF 1420 initiates and successfully completes UUAA-MM procedures for the UAV, and the AMF stores the successful UUAA results. The AMF updates the UE1 context so that UUAA is no longer pending and the UE supports multi-PLMN connections.

In some embodiments, the UE supports multiple USIM capabilities. In those embodiments, the registration request message indicates multiple USIM capabilities. In some embodiments, the UE has been authorized for multi-PLMN communications to provide redundant application connectivity. In those embodiments, action 2 need not be performed.

Fig. 5A and 5B illustrate further actions in support of switching UAV communications from a first PLMN to a second PLMN according to an embodiment. To be consistent with fig. 4, block number references 410, 420, 430, 440, and 450 are continued in this figure. As described above with respect to fig. 4, for UE1 that requires UUAA, an indication of support for multiple PLMNs is forwarded. AMF (AMF 1 420) receives the request and in response triggers UUAA-MM procedures, as shown in action 1 421.

At act 421, AMF1 420 responds to the registration request of UE1 410 by transmitting a request for authentication of UE1 410 and USS to UAS NF1 440 of PLMN 1, e.g., via Nnref _auth_req 422 indicating GPSI 1, CAA level UAVID, and also including an indication that UE1 supports multiple PLMNs. In some embodiments, AMF1 sends a message 422 to UAS NF1, whereby AMF1 invokes Nnef _authreq service operation. The message includes GPSI 1, CAA level UAV ID (e.g., UAV permanent ID), and an indication of multi-PLMN support.

At act 441, in response to receiving the authorization request, the UAS NF1 440 transmits an authentication request Authenticate Req to the USS 450 indicating GPSI 1, CAA-level UAV ID, and indicating that UE1 supports multiple PLMNs. USS 450 receives and processes authentication requests. For example, the UAS NF1 440 forwards an authentication request to the USS 450 including GPSI 1, CAA level UAV ID, multi-PLMN support.

In some embodiments, multiple authentication messages are exchanged back and forth between the UAV 410 and USS 450 according to any requirement of the authentication method relied upon.

At act 451, USS 450 transmits a response "Authenticate Resp" to UAS NF1 449 indicating GPSI 1 and including authentication message "Authenticate Msg".

At act 442, in response to the received authentication message, the UAS NF1 440 transmits an authentication response Nnef _auth_resp to the AMF1 420, which indicates GPSI 1 and includes the authentication message Authentication Msg. For example, in some embodiments, the UAS NF1 440 forwards the information received from the USS 450 in act 451 to the AMF1 420.

At act 423, AMF1 420 transmits a NAS MM transport authentication message to UE1 410. In some embodiments, the message provided by AMF1 is a final authentication message to UAV UE1, providing a final authentication result to UE1 410.

At act 417, UE1 transmits a NAS MM transport authentication message to AMF1 420. At act 424, in response to the received NAS MM transmit an authentication message, AMF1 420 transmits to UAS NF1440 a Nnef _auth_req message indicating GPSI 1, CAA level UAV ID, and including the authentication message.

At act 443, the UAS NF1 440 transmits a Authenticate _req message to the USS 450 indicating the GPSI 1, CAA level UAV ID, and including an authentication message. This exemplary process continues on fig. 5B, as described below.

At act 452, USS 450 transmits a Authenticate _resp message to UAS NF1 440 indicating the GPSI 1, UUAA result (success/failure), authorized CAA level UAV ID 1 (new CAA level UAV ID is assigned from USS to UE 1), and token (token may be bound to any of GPSI 1, PLMN 1, CAA level UAV ID).

At act 444, the UAS NF1 440 transmits a Nnef _auth_resp message to the AMF1 420 indicating the GPSI, CAA level UAV ID1 and including an authentication message indicating the success or failure of the authentication, and if successful, transmits the token.

At act 425, AMF1 420 transmits a NAS MM transport authentication message to UE1410 in response to receiving the Nnef _auth_resp message.

At act 418, UE1 cooperates with AMF1 420 to perform a UE Configuration Update (UCU) procedure based on token AMF1 received from USS via UAS NF 1. For example, in one embodiment, the token received from the USS in the previous action is provided to the UE1 during the UCU procedure. The token confirms to the UAV that the USS supports and has authorized the use of the multi-PLMN connection. Upon receipt of the token, the UAV may initiate UUAA via a second PLMN (PLMN 2), as described below with respect to fig. 6.

At act 419, in some embodiments of the invention, UE1 410 cooperates with AMF1 420 to perform network-initiated de-registration.

In some embodiments, if UUAA-MM failed during reauthentication and reauthorization and there were PDU sessions established using UAS services, and AMF 1 could trigger these PDU session releases with appropriate cause values.

Fig. 6 illustrates further actions for switching UAV communications from a first PLMN to a second PLMN according to an embodiment. In a provisioning action 611, the UE2 610 of the UAV sends a registration request message to the AMF2 620 of PLMN 2, the registration request message including an indication that the UE supports registration with multiple PLMNs and including a token received via PLMN 1. For example, in some embodiments, UE2 performs a process similar to that shown in fig. 4, but includes the token and multi-registration PLMN support indication previously received via PLMN 1.

At act 621, AMF2 620 is triggered to execute UUAA via the second PLMN (PLMN 2). In some embodiments, act 1 is performed after the registration is authorized, whereupon AMF2 triggers UUAA-MM procedures (with multi-PLMN support).

At act 622, AMF 2 transmits a Nnef _auth_req message to UAS NF 2 640 of PLMN 2 indicating GPSI 2, CAA level UAV ID 1 and including the above token.

At act 641, UAS NF2 640 transmits a Authenticate Req message to the USS indicating GPSI 2, CAA level UAVID 1, and including the token. In some embodiments UASNF2 forwards an authentication request including GPSI 2, CAA level UAV ID 1, and tokens for multi-PLMN support. In some embodiments, the token, USS, and UAV are used to skip multiple round trip authentication messages for UUAA executing on PLMN 1 (fig. 4).

At act 651, USS 650 transmits to UAS NF2 640 a Authenticate _resp message indicating GPSI 2 and optionally including CAA-level UAV ID 2, and an authentication message including UUAA results. In some embodiments, USS 650 sends an authentication_resp comprising GPSI 2, CAA level UAVID 2 (which is optional in some embodiments), an authentication message, UUAA results. In some embodiments, USS 650 sends an optional new CAA level UAV ID 2 for privacy reasons, or alternatively the same CAA level UAV ID 1 may be reused.

At act 642, the UAS NF2 640 transmits a Nnef _auth_resp message to the AMF2 620 indicating GPSI 2, CAA level UAV ID 2, and including an authentication message indicating success or failure.

At act 623, AMF2 620 transmits a NAS MM transport authentication message to UE2 610. In some embodiments, this is the final authentication message provided to the UAV, thereby providing the final authentication result.

At act 613, UE2 cooperates with AMF2 to perform network-initiated de-registration. In some embodiments, in the case of a successful UUAA MM procedure, AMF2 triggers the UE configuration update procedure 612 to deliver the authorization information from USS to UAV.

In some embodiments, if UUAA-MM fails during reauthentication and reauthorization, there is a PDU session established using the UAS service. AMF2 may trigger these PDU session releases with appropriate cause values. In some embodiments, the UUAA MM procedure for UE2 is optimized by using tokens, i.e., action 4 (multiple rounds of authentication and authorization message exchange) shown in fig. 4 can be avoided, and USS sends Nnef _auth_resp, which Nnef _auth_resp includes GPSI2 and optional CAA level UAV ID 2, authentication message, and UUAA results.

In some embodiments, UUAA SM procedures for multiple PLMNs are performed. In those embodiments, UUAA procedures are triggered by the SMF during PDU session establishment, where multiple PLMNs are authorized by the USS. SMF 1 needs to learn the UE multi-PLMN support capability in the PDU session request. Similar to UUAA MM, SMF 1 shares multi-UE support information to UAS NF 1, which forwards it to USS. In such embodiments, the USS stores a mapping between CAA-level UAV ID and UAV IP address.

The UAS NF1 acknowledges successful authentication/authorization for the PDU session for UE 1. Similar to UUAAMM, during the UUAA SM procedure via UAS NF1, USS shares the token to SMF1 via an accept message. SMF1 transmits the authentication/authorization result and forwards the token to the UAV (e.g., in a PDU session accept message). UE2 shares the token with SMF 2 and UAS NF2 triggers optimal authentication/authorization for the PDU session of UE2 by sharing the token to USS. Before granting the UAV authorization to use PLMN 2 in response to the UAS NF2, the USS may verify that the token is associated with the authorized PLMN (PLMN 1). The SMF 2 transmits the authentication/authorization result from the UAS NF2 to the UE 2.

The PDU session prior to handover is configured to allow communication of UE1 with USS while C2 communication with UE2 is on standby/pending. In the case of a handover, a PDU session modification request is invoked that allows UAS NF 2 to retrieve the information of UE2, and SMF2 forwards the PDU session modification command to complete pairing between UE2 and UAV-C and enable communication with USS via the secondary PLMN.

Fig. 7 illustrates acts for providing UAVC pairs to UE2 710 in a standby or pending mode for providing a method for switching UAV communications from a first PLMN to a second PLMN, according to an embodiment.

At act 71, UE2 of the UAV sends a Protocol Data Unit (PDU) session establishment request for C2 communication to SMF2 720 of PLMN 2. In embodiments where the UE2 provides optional pairing information (UAV-C ID), the UAV-C ID is the same UAV-C ID as that provided for the UE 1.

In some embodiments, an alternative act 712 is performed. In such embodiments, at act 1b, UE2 710 explicitly indicates to SMF2 720 that the PDU session establishment request is for a standby C2 communication connection, e.g., using knowledge of existing C2 connections on PLMN 1.

At action 721, SMF2 720 sends a Nnef _auth_request message to UAS NF2 730. For example, SMF2 forwards a request for authorization of a C2 connection.

At action 731, the UAS NF2 730 sends an n33_auth_request message to USS 740. In some embodiments, UAS NF2 730 forwards information received from SMF 2 720 that includes an indication for a standby connection (if provided).

At action 741, in response to processing the received n33_auth_request message, USS 740 sends an n33_auth_resp message to UAS NF2 730 indicating authorization for the C2 connection in standby mode. In some embodiments, the USS partially grants C2, i.e., an indication that a connection is granted through C2 (e.g., partial grant, grant pending/pending), that the actual pairing with UAV-C has not been granted (e.g., UAV-C IP address is not provided, configured for PDU session), and the connection is a "armed" connection for C2.

At act 732, UAS NF2 730 sends an indication to SMF2 720 to accept establishment of the PDU session, including an indication to authorize C2 communications in standby mode. For example, in some embodiments, the UAS NF2 forwards an indication of the partially authorized C2 connection in the PDU session establishment acceptance.

At act 721, SMF2 720 sends a PDU session establishment accept message 721 to UE2 710 indicating authorization for C2 communication in standby/pending mode. In some embodiments, UE2 710 has received a connection for C2 as an indication of standby. Thus, UE2 710 prohibits the use of the PDU session labeled "armed" until it becomes active after the PDU session is modified (i.e., the grant pairing as described below).

Fig. 8 illustrates actions of UE2 and UAV-C pairing authority in a method for switching UAV communications from a first PLMN to a second PLMN, according to an embodiment.

At act 831, SMF1 830 of PLMN 1 sends a QoS degradation indication to UAS NF1 869. This is a network initiated QoS degradation indication sent to UAS NF1 to send a handover request to USS 880.

At act 861, in response to receiving the QoS degradation indication, the UAS NF1 860 sends a QoS degradation indication to the USS 880. For example, in one embodiment, UAS NF1 forwards the indication received in act 1.

At act 881, and upon processing the indication, USS 880 transmits USS-initiated pairing authorization for the C2 communication to UAS NF2 870. In one embodiment, this action is performed after the handover procedure triggers USS-initiated C2 authorization (i.e., pairing authorization) to activate the standby PDU session.

In some embodiments (act 871), the UAS NF2 sends a response in the form of an ack message to the USS after activating the PDU session modification procedure to inform the USS that the PDU session modification procedure is activated.

At act 872, the UAS NF2 870 sends a PDU session modification request to the SMF2 840 indicating UAVC IP address.

At act 841, SMF2 840 sends a PDU session modification command to UE2 820, which may be done by paging UE2 820 with a paged + service request. For example, in some embodiments, UE2 may be paged 820 prior to PDU session modification, followed by a traffic request procedure (if MUSIM is used, paging reasons may be utilized to alert the UE of the activation of the PDU session).

At act 821, pairing of the UE 2820 with the UAV-C is completed. In some embodiments, pairing between UE2 and UAV-C is completed when the PDU session modification procedure is completed, after which UE2 may use the PDU session on PLMN 2.

At act 882, USS 880 sends a UE pairing revocation to UAS NF2 870 indicating GPSI1, CAA level UAVID 1, and PDU session IP address. In some embodiments, at the UE1 side, USS 880 triggers a mirroring action through pairing that is not authorized to be configured for PDU sessions. In some embodiments, the PDU session for the C2 connection is maintained, but UE1 810 prohibits its use when using the PDU session on PLMN 2.

At act 862, the UAS NF1 retrieves UUAA stored contexts for UE 1. Based on the analysis of the stored UUAA context, UAS NF1 may determine a target (AMF 1 or SMF 1) for sending a notification to unpair.

At act 811, pairing authority for UE1 and UAV-C is revoked. Note that in embodiments of the present invention, the network initiated PDU session with UE1 is not released. In some embodiments, the revocation message includes an indication that only the pairing is revoked, and not the connection itself (the PDU session is not released, e.g., the PDU session may be marked as "armed", "partially authorized").

The method including the actions shown and described above enables secure transfer of UAV C2 communication with UAV-C via a first PLMN to UAV-C via a second PLMN (or USS in some embodiments) in response to degraded QoS in the communication link provided by the first PLMN, thereby maintaining the ability of the UAV to communicate with UAV-C or USS over its entire route via a robust, reliable and secure C2 communication link.

To provide reliable and uninterrupted in-flight UAS service, a single UAV flight mission may require support from multiple USSs. The reason for the multi-USS support stems from the fact that the UAV flight plan spans an area not controlled/covered by a single USS, once BVLOS UAV moves out of coverage of the serving USS, it may have some connectivity issues (QoS degradation) and no longer be able to provide updates, such as (amount of operation, flight path, collision avoidance with other operations, etc.), or due to operational cost constraints.

For mission critical services, a particular USS may not be able to support such services in certain particular areas. Another reason for supporting multiple USSs is that if a current service USS becomes unavailable (e.g., an interrupt), a failover mechanism is required to mitigate any potential UAS operation interruption caused by such USS failures. Thus, handover from one USS to another USS is a viable solution in order to avoid any communication interruption. In such cases, the UAV and its controller (UAV-C) should be notified of the alternate USS. The UAV needs to be authenticated and authorized by all relevant USSs and the 3GPP network should be informed about the handover between USSs, i.e. as shown in fig. 9, the alternative USS has taken over the service for the operation of the main USS (USS 1) so that the location information can be transferred to the specified USS.

Figure 9 is a high level flow chart showing actions for switching a UAV from a first USS to a second USS according to an embodiment. At 910, an event affecting C2 communication between the UAV and USS is detected, or an indication of such event is received. At 915, a USS-USS handover is initiated in response to detecting the event or receiving the indication.

In one embodiment, at 920, the PLMN element initiates a handover (handoff). For example, when the service/primary USS (herein named USS 1) does not respond/experience a communication problem, a handover may be initiated by the 3GPP network. In this case, the 3GPP network can send a request to the service/primary USS for handover. In the event that the primary USS is not reachable by the 3GPP network, the 3GPP network may use information about the secondary USS (e.g., as obtained from USS1 during the previous UUAA procedure) to proactively contact the secondary USS (referred to herein as USS 2) to initiate a handover procedure with USS 2. When the USS2 is notified of the handover request, the 3GPP network performs appropriate actions to update the UAV connection to enable communication with the USS 2. In some embodiments, the update is communicated over a control plane, PDU session modification procedure, and a notification is provided to the UAV that new authorization data for USS2 exists.

In an alternative embodiment, at 925, the USS initiates a handover. For example, in some embodiments, after monitoring for an interruption in communication services or for load balancing, USS1 initiates a handover procedure when USS1 determines that it is no longer able to continue to provide services to the UAS or that it needs to perform load balancing. In some embodiments, USS1 will satisfy some mission critical constraints. In those embodiments, USS1 communicates with other available USSs and requests a handover/handoff. After the handover procedure is completed, two options are provided to the 3GPP network: maintaining sending the location update to USS1, USS1 forwarding information to USS2 (proxy method); or directly send the location information to USS2 (non-proxy approach).

In the proxy approach, after the USS change, USS1 may remain the primary attachment point to the 3GPP network for location update information and send the IP address of USS2 to the network as an endpoint to receive location information from the network during the entire UAV flight. The enhanced location tracking provides a different USS IP address, i.e. the IP address (USS 2) receiving the location information is different from the address (USS 1) originating the request from the network. Thus, for location updates, USS1 always performs a subscription to a service from the network, but the network transparently sends updates to the specified IP address (e.g., USS2IP address).

Thus, the primary USS initiates the handover at 935, or the secondary USS initiates the handover at 940. In embodiments where the primary USS initiates the handover, the primary USS may act as a proxy for the secondary USS at 945 such that the identity/address of the secondary USS is not disclosed.

In some embodiments, the handover is initiated by USS2. For example, the handover initiation may be from an alternative USS (USS 2 in fig. 9), e.g. as part of some health check procedure, which sends periodic messages to the master USS, and in response, which does not receive any acknowledgement from USS1 due to a failure. In such cases, USS2 performs the handover and is responsible for the UAV connected to USS 1. USS2 may follow the same procedure as discussed previously for the non-proxy approach to inform the network and UAV of its IP address for location update. The network (UAS NF) may receive a request from USS2 for location information about the UAV served by USS1 in a given area. The network may receive authorization information for USS2 to perform such operations. During the UUAA procedure of the applicable UAV, authorization information (an alternative or alternative USS indicating that USS2 is authorized) may be received from USS 1. Alternatively, the authorization information may be received from USS2 (e.g., as a token in a location request). The network returns a filtered list of UAV identities and ancillary information (e.g., GPSI, UAVID, location) served by USS1 to USS2. USS2 may then initiate a handover procedure for each applicable UAV.

In an alternative embodiment, the secondary USS (USS 2) unilaterally initiates the handover at 950, i.e., the primary USS does not participate in the handover. In this embodiment, USS1 informs the network of the IP address of USS2 and USS1 shares the token with the network to show that USS2 is now authorized to serve the UAV after the handover, and thus, location update information may be sent to USS2.USS2 may obtain the location directly from the network. In this method, the UAV is notified of the new service USS2 via messaging over the network. For example, when USS2 takes over traffic management services for a UAV, it informs the UAV of its IP address, either by involving a 3GPP network (e.g., NAS transport) or by the application layer.

When the service/primary USS (herein named USS 1) does not respond/experience a communication problem, a handover may be initiated by the 3GPP network. The 3GPP network may send a request for handover to the service/primary USS. In the event that the primary USS is not reachable by the 3GPP network, the 3GPP network may use information about the secondary USS (e.g., as obtained from USS1 during the previous UUAA procedure) to proactively contact the secondary USS (referred to herein as USS 2) to initiate a handover procedure with USS 2. When the USS2 is notified of the handover request, the 3GPP network performs appropriate actions to update the UAV connection to enable communication with the USS 2. There may be an update on the control plane, a PDU session modification procedure, and a notification to the UAV that there is new authorization data for USS 2.

Fig. 10 is a block diagram of a system 1000 for implementing embodiments. The system 1000 includes a PLMN1040 equipped with a UAS-NF component 1030. The UAV 1050 includes a UE 1052 configured for UAV communication with the UAS-NF 1030 of the PLMN 1040. The system includes at least a first USS1010 and a second USS1020.

The following figures illustrate the flow of method acts according to various embodiments of the invention. The method begins with a registration, UUAA MM procedure of a multi-USS capable UAV, followed by a handover between USSs, and the procedure ends with PDU session modification and reconfiguration.

Figure 11 is a flowchart illustrating registration actions performed as part of a method for switching a UAV UE 1110 from a first USS1150 to a second USS1160, according to an embodiment.

At act 1112, the UE 1110 sends a registration request 1112 to a first AMF 1150 of the first PLMN. The registration request includes an indication that the UE 1110 is equipped to support multiple USSs. In some embodiments, the request message provides the UAV ID at CAA level and an indication that multiple USSs are supported when registering with the UAS service.

At act 1113, the UE 1110 cooperates with the UDM 1130 of the first PLMN to perform a primary authentication procedure. In some embodiments, if the UE has not been authenticated, the UE 1110 performs legacy master authentication. The AMF 1120 of the first PLMN processes the registration request.

At act 1121, AMF 1120 may determine that UE 1110 is authorized and equipped to communicate with multiple USSs. In some embodiments, AMF 1120 verifies that the UAV is authorized for multi-USS support capability based on the subscription information and also determines whether UUAA MM is required.

At act 1122, the AMF 1120 sends an indication of the AMF registration accept 1122 to the UE 1110.

At act 1114, the UE 1110 cooperates with the first USS1140 to perform a UUAA-MM procedure as shown in fig. 12. Upon successful completion UUAA-MM procedures for the UAV (described below with respect to fig. 12), AMF 1120 stores the successful UUAA results and updates the UE context indicating UUAA is no longer pending, the UE capabilities supporting multiple USS capabilities, and the optional authorized CAA level UAV ID received from USS1, and triggers the UE configuration update procedure to deliver UUAA results and UUAA authorization payload containing UAV configuration to the UE. In some embodiments, the AMF also delivers the authorized CAA-level UAV ID it receives from the USS.

Fig. 12A and 12B are flowcharts illustrating further actions for switching the UAV UE 1110 from the first USS1150 to the second USS1160, according to an embodiment. For consistency, the reference numerals for items 1110, 1120, 1130, 1140, 1150, and 1160 are omitted from FIG. 11.

At act 1123, an AMF 1120 is triggered to perform UUAA for a multi-USS support capable UE 1110. In some embodiments, for UEs requiring UUAA (capable of supporting multiple USSs), the AMF triggers UUAA-MM procedure.

At act 1124, the AMF 1120 sends a Nnef _authreq message to the UAS NF 1140 indicating GPSI, CAA level UAV ID, and indicating that the UE supports multiple USSs. In some embodiments, the AMF invokes Nnef _authreq service operations including GPSI, CAA-level UAV ID, and multi-USS support. The UAS NF resolves the USS address based on the CAA-level UAV ID or uses the USS address provided by the UE.

At act 1141, UAS-NF 1140 sends Authenticate _Req to USS1 1150 indicating GPSI, CAA level UAV ID, and indicating support of multiple USSs by the UAV. The message includes the GPSI, CAA level UAV ID, and multiple USS support capabilities of the UAV.

At act 1151, USS1 1150 sends an authentication response to UAS-NF 1140 indicating the GPSI and including an authentication message. In some embodiments, this is a final authentication response comprising: GPSI, UUAA results (success/failure), and may include an authorized CAA level UAVID. In some embodiments, USS1 provides other authorized USS information (IP address), if known, as well as the token. And finally authenticating the message. The UAS NF stores this information to enable any authorized USS to begin querying the UAV's location before, during, or after the USS handoff.

At act 1142, the UAS NF 1140 sends Nnef _auth_resp, which indicates GPSI and includes an authentication message, to the AMF 1120. In some embodiments, the authentication response forwards the information received from the USS in act 4a along with the authorized USS information and the token 1.

At act 1125, the AMF 1120 sends a NAS MM transport including an authentication message to the UE 1110.

At act 1115, the UE 1110 sends a NAS MM transport authentication message to the AMF 1120. In some embodiments, this is a final authentication message that provides a final authentication result. Information about all authorized USSs and token 1 shared by USS1 is also provided to UE 1110 (e.g., during UCU). In some embodiments, if UUAA-MM fails during reauthentication and reauthorization and there are PDU sessions established using the UAS service, AMF 1 may trigger these PDU session releases with the appropriate cause value.

In other embodiments, the method continues with the actions discussed below.

At act 1126, the AMF1120 sends Nnef _auth_req to the UAS NF 1140 indicating the GPSI, CAA level UAV ID and including an authentication message.

At act 1143, the UAS NF 1140 sends a Authenticate _req to USS1 1150 indicating the GPSI, CAA level UAV ID, and including an authentication message.

At act 1152, USS1 1150 (shown in fig. 12B) sends an authentication response to UAS NF 1140 indicating GPSI, CAA-level UAV-ID and including an authentication message and an indication of UUAA result and USS2IP indicator and first token. At act 1144, the UAS NF 1140 may store the USS1 and USS2 information.

At act 1145, UAS NF 1140 sends to AMF 1120 a Nnef _auth_resp and USS2 information indicating the GPSI, CAA level UAV ID and including an authentication message indicating the success or failure of the authentication, and a first token.

At act 1127, the AMF 1120 sends a NAS MM transport authentication message to the UE 1110.

At act 1116, the UE 1110 cooperates with the AMF 1120 to perform a UE configuration update procedure using USS2 information and the first token.

At act 1117, the UE 1110 cooperates with the AMF 1120 to perform a PLMN-initiated de-registration procedure with respect to USS 1.

As discussed herein, UUAA MM procedures are performed such that multiple USSs are authorized by the 3GPP network. The UAS NF stores information for multiple USSs. In the case of handover, a change in UUAASM procedure may be required. The SMF needs to learn the UE multi-USS support capability in the PDU session request. Similar to UUAA MM, during the UUAA SM procedure with the master USS, USS1 sends the token and USS2 information to the SMF in an accept message. In this way, the SMF knows the authorized USS. The PDU session prior to handover is configured to allow communication with USS 1. In case of handover, there is a PDU session modification request that allows the SMF to retrieve the information of USS2 and to enable communication with the secondary USS.

Once the token is shared with the UAS NF and arrives all the way to the UAV with the authorized USS information, USS2 can communicate with the network after the handover procedure, as USS1 sends a handover notification to the network and receives confirmation that USS2 can service the UAV.

Figure 13 is a flowchart illustrating further actions for switching a UAV from a first USS1360 to a second USS1370 according to an embodiment.

At act 1351, the UAS NF 1350 stores the USS1 1360 info and the USS2 1370 info. The UAS NF 1350 stores information about USS1 1360 and USS2 1370 to enable authorized USSs to begin querying the location of the UAV before, during, or after USS handoff.

At act 1361, USS1 1360 cooperates with USS2 1370 to effect a handover of the UAV from the first USS1 to USS 2. In some embodiments, a handover procedure may be initiated and related communications may occur between USS1 and USS 2.

At act 1362, USS1 1360 sends a handover notification to UAS NF 1350 including an indication of the GPSI, CAA level UAV ID, and USS21370 information. In one embodiment, after a successful handover procedure, USS1 1360 notifies UAS NF 1350 by a handover notification Msg that includes GPSI, CAA level UAV id, and USS21370 information.

At act 1352, the UAS NF 1350 retrieves UUAA the context and USS2 1370 information. Since the UAS NF 1350 previously stored information for all authorized USSs provided by USS1 1360 during the UUAA MM procedure, it now retrieves the information.

At act 1353, the UAS NF 1350 sends a handover confirmation Handoffack to USS1 1360. After act 4, the UAS NF 1350 sends an acknowledgement for the handover to USS1 1360 and it has updated USS information for UAV location update. In some embodiments, USS1 1360 may forward a notification to USS2 1370 to trigger action 6.

At act 1371, USS2 1370 sends to UAS NF 1350 a handle_notification including the GPSI, CAA level UAV ID, UAV IP address, and an indication of the second token (token 2). If USS2 information has not been provided, USS2 information is provided to indicate which USS (if one or more) will take over. The notification message includes (GPSI, CAA level UAV ID, UAV and token 2). The UAS NF 1350 validates any USS2 1370 information and tokens previously stored to ensure that USS2 is now authorized to service the UAV (e.g., communicate with the UAV, receive location updates from the network).

At act 1354, the UAS NF 1350 retrieves USS2 1300 information. In one embodiment, upon obtaining the handle_notification message, the UAS NF 1350 retrieves information about the authorized USS2 information.

At action 1355, the UAS NF 1350 sends a PDU session modification command 1355 to the SMF 1330 of PLMN 1. For example, the UAS NF 1350 triggers a PDU session modification procedure (e.g., via PCF) to authorize communication between the UAV and the new USS2 IP address. The SMF 1330 may configure the UPF accordingly to forward traffic only between the UAV and the authorized USS 2. As part of the PDU modification command (NAS signaling), the new IP address of USS2 1370 may be forwarded to the UAV.

At act 1331, the SMF 1330 sends a PDU session modification command to the UE 1310.

At act 1356, the UAS NF 1350 sends a Handoff_notification_Resp to the USS2 1370 including GPSI, PDU session information, and an indication of the UAV IP address. In some embodiments, the IP address is the IP address of the PDU session used for USS communication (which is not affected by this action if dedicated to C2 is used).

At act 1311, the UE 1310 sends an indication of connection establishment with USS2 1370 to USS2 1370 and includes a first token (token 1). By using the updated USS information and the token 1 shared with the UE, the UAV may prove that it is authorized to communicate with USS2, and the connection between the UAV and USS2 may be securely established.

Support for multiple USS call flows is described herein. Figure 14 illustrates an exemplary procedure for UAE support for multiple USS operations.

In fig. 14, at act 1411, the UAE client 1410 sends a registration request to the UAE server 1420, which includes an indication of multiple USS capabilities.

At act 1421, the UAE server 1420 may perform authentication and authorization checks and may interact with the USS in-process and indicate the multi-USS capabilities and identification information of the UAE client.

At act 1422, the UAE client 1410 may receive a registration response from the UAE server 1420 with an indication of authorization for multiple USS support.

At act 1431, the UAE server 1420 may receive a multi-USS management request from the service USS1430 to manage support for the multi-USS. The request may include at least one of UAV (UAE client) identification information and multiple USS configuration parameters. If the request is to add a configuration, the UAE server 1430 may store configuration parameters associated with the USS in the UAE client context. If the request is to remove the configuration, the UAE server checks that the configuration is associated with the request USS before deleting the configuration from the UAE client context and sending the request to the UAE client.

At act 1423, the UAE client 1410 may receive a multiple USS configuration request from the UAE server 1420. The request may be to add or delete a multiple USS configuration.

At act 1412, if the request is to add (or delete) a configuration, the UAE client 1410 may store (or delete) the configuration associated with USS 1430. In the case of removing a multi-USS configuration, if the request is associated with a USS (e.g., including a USS identifier, FQDN of the USS) that matches the USS associated with (e.g., "owns") the configuration, the UAE client 1410 may remove the configuration.

At act 1413, the UAE client 1410 may send a multi-USS support configuration response to the UAE server 1420 to confirm the addition/removal of the configuration.

At act 1424, the UAE server 1420 may send a multi-USS management response to the USS1430 indicating the enablement or disablement of the multi-USS capability.

At act 1432, the UAE server 1420 may receive a multi-USS change request 1432 from the USS1430 that includes at least one of a UAV, a new USS identity, and authorization information. The UAE server may also verify that the request is authorized before sending the change request to the UAE client 1410, as described above.

At act 1425, the UAE client 1410 may receive a multiple USS change request from the UAE server 1420.

At act 1414, the UAE client 1410 may perform a change of USS based on the change request and/or the multi-USS configuration. The UAE layer may inform the application to initiate a communication based on the new USS information.

At act 1415, the UAE client 1410 may send a multiple USS change response/notification to the UAE server 1420 to indicate the change in USS. The UAE client may include the new USS information, the reason for the USS change, in the notification message.

At act 1426, the UAE server 1420 may send a multi-USS change response/notification to the USS1430 to indicate the change in USS. The UAE server may include the new USS information, the reason for the USS change, in the notification message.

Table 1 shows an example of USS configuration including multiple USS parameters. For example, the unified USS configuration may include multiple USS configuration components as well as other configuration components (e.g., C2 handover configuration).

Table 1: unified USS configuration

Different types of UAVs may be associated with different USSs, thereby being given different capabilities in a particular home USS (e.g., in such a manner, ioT devices communicate over a dedicated RAT). The home USS is a USS that "owns" the configuration for a particular UAV (i.e., a USS that is allowed to add/delete/modify the configuration). The home USS may correspond to an entity that maintains UAV subscription and/or performs UAV authentication and authorization procedures. The UAE layer ensures that the operation for USS configuration can be completed under the condition that the USS is requested to have USS configuration.

All UAVs belonging to a particular USS (home USS) may have a particular secondary USS (part of the list of allowed USSs) and for all UAVs having that USS as a home USS, a configuration (change initiation flag, change policy, and C2 handover parameters) may be set for each secondary USS.

An alternative multiple USS configuration is shown in table 2, which depicts an exemplary USS change policy rule.

Table 2: USS configuration with exemplary USS change policy template

The USS change policy may include a list of rules. The initiation rules may indicate whether a UAE initiated USS change is authorized for a given USS. Changing USS rules may indicate conditions/criteria for USS changes to occur and target USS to be selected when such conditions/criteria are met.

For example, initiating a USS change may be allowed by USS-1, but not for any other USS. In such cases, the initiation rules may be set to:

initiating a rule: USS-1= > true

Initiating rules (inclusion rules): * = > false

In one example, when the UAV enters a given areaX, a change from USS-1 to USS-2 may be triggered:

change USS rules: USS-1:location area= > USS-2

In another example, a change from USS-1 to any USS may be triggered in an emergency, such as due to a loss of connection with USS-1:

change USS rule (emergency): USS-1:event:connection loss = >

“Any Allowed USS”

The method including the actions shown and described above enables secure transfer of the UAV from the first USS to the second USS, thereby maintaining the ability of the UAV to maintain a robust, reliable, and secure C2 communication link throughout its route. The present invention thus provides for safe and reliable command and control of an unmanned aerial vehicle in flight via a public land mobile network.

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and non-transitory computer readable storage media. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (20)

1. A method performed by a wireless transmit/receive unit (WTRU) comprising a UAV Application Enabled (UAE) client in an in-flight UAV for supporting a plurality of Unmanned Aerial Vehicle (UAV) system service providers (multi USSs), the method comprising:

Sending a registration request to a UAE server, wherein the registration request comprises an indication of multiple USS (user equipment) capability;

Receiving a registration response message, wherein the registration response message comprises an indication that the UAE server supports multiple USS (user equipment) capability;

receiving a multiple USS configuration request, the multiple USS configuration request comprising: a list of multiple USS configuration parameters related to conditions under which the UAE client initiates a USS change, and allowed USSs;

Sending a multi-USS configuration response; and

And executing the multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameter.

2. The method of claim 1, wherein the multiple USS change notification is further based on receiving a multiple USS change request from a UAE server.

3. The method of claim 1, wherein the multi-USS configuration request is a request to delete a first multi-USS configuration, and the method further comprises: if the delete request is associated with a USS that matches a USS associated with the UAE, the first multiple USS configuration is removed.

4. The method of claim 3, wherein the USS associated with the UAE maintains a subscription to the UAV.

5. The method of claim 3, wherein the USS associated with the UAE previously authenticated and authorized the UAV.

6. The method of claim 1 wherein the multi-USS configuration request is a request to add a second multi-USS configuration, and further comprising storing the second multi-USS configuration.

7. The method of claim 1 wherein the multiple USS change notification includes a cause for the multiple USS change.

8. The method of claim 1 wherein the multiple USS configuration parameter comprises rules for initiating USS changes, wherein only a first USS is capable of initiating a change.

9. The method of claim 1 wherein the multiple USS configuration parameter comprises a rule that allows any allowed USS to initiate a USS change when a connection with a first USS is lost.

10. The method of claim 1, wherein the condition for the UAE client to initiate a USS change comprises the UAE client moving from a first geographic area associated with a first USS to a second geographic area associated with a second USS.

11. An Unmanned Aerial Vehicle (UAV), comprising:

a wireless transmit/receive unit (WTRU) comprising a UAV Application Enabled (UAE) client for supporting a plurality of UAV system (UAS) service providers (multi USSs), the WTRU configured to:

Sending a registration request to a UAE server, wherein the registration request comprises an indication of multiple USS (user equipment) capability;

Receiving a registration response message, wherein the registration response message comprises an indication that the UAE server supports multiple USS (user equipment) capability;

receiving a multiple USS configuration request, the multiple USS configuration request comprising: a list of multiple USS configuration parameters related to conditions under which the UAE client initiates a USS change, and allowed USSs;

Sending a multi-USS configuration response; and

And executing the multi-USS change and sending a multi-USS change notification based on the multi-USS configuration parameter.

12. The UAV of claim 11, wherein the multi-USS change notification is further based on receiving a multi-USS change request from a UAE server.

13. The UAV of claim 11, wherein the multi-USS configuration request is a request to delete a first multi-USS configuration, and the WTRU is further configured to: if the delete request is associated with a USS that matches a USS associated with the UAE, the first multiple USS configuration is removed.

14. The UAV of claim 13, wherein the USS associated with the UAE maintains a subscription for the UAV.

15. The UAV of claim 13, wherein the USS associated with the UAE previously authenticated and authorized the UAV.

16. The UAV of claim 11, wherein the WTRU is further configured to initiate communication based on the USS change.

17. The UAV of claim 11, wherein the multi-USS change notification includes a cause for the multi-USS change.

18. The UAV of claim 11, wherein the multiple USS configuration parameter includes rules for initiating USS changes, wherein only a first USS can initiate a change.

19. The UAV of claim 11, wherein the multiple USS configuration parameter includes a rule that allows any allowed USS to initiate a USS change when a connection with a first USS is lost.

20. The UAV of claim 11, wherein the condition for the UAE client to initiate a USS change comprises the UAE client moving from a first geographic area associated with a first USS to a second geographic area associated with a second USS.