Managing unmanned aerial system service supplier instances

Abstract

A method is provided that is performed by a configuration unit, the configuration unit being communicatively coupled to a communications network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV) and a UAV controller (UAV-C), the method including the steps of receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS; acquiring UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof; and determining a mapping of the UAS-specific information to one or more of the plurality of USSs based on the received USS information and the acquired UAS-specific information.

Description

[Technical field]

[0001] The subject matter disclosed herein generally relates to the field of managing unmanned aerial system service supplier instances. This document defines a method, configuration units, and a system. [Background technology]

[0002] The following abbreviations are relevant to the field of this document: 3GPP(registered trademark) 3rd Generation Partnership Project UAV unmanned aerial vehicle USS UAS Service Supplier UAS Unmanned Aerial System C2 Command and Control UTM UAS Traffic Management LUN Local USS network DNAI Data Network Access Identifier UAV-C or UAVC UAV Controller SP / ASP Service Provider / Application Service Provider AF Application Features NF Network Function NEF network publishing function SCEF Service Capability Exposure Function FQDN Fully Qualified Domain Name CAA Civil Aviation Authority UUAA USS UAV Permit / Certification UAES UAS Application Enabler Server SEAL Service Enabler Architecture Layer UAEC UAS Application Enabler Client CAPIF Common API Framework UASASS UAS Application Specific Server UASASC UAS Application Specific Client DNN Data Network Name FIMS Flight Information Management System

[0003] An Uncrewed Aerial System (UAS) is a combination of an Uncrewed Aerial Vehicle (UAV) and a UAV Controller (UAV-C). A UAV is an aircraft without a human pilot on board; instead, in some cases, the UAV may be controlled by an operator via the UAV-C. The UAV-C may be a remote pilot or a UAS operator. The UAV-C may be a remote autonomous system. The UAV may also have some degree of autonomous flight capability. The communication requirements of a UAS cover both command and control (C2) and uplink and downlink data between the UAS components towards both the serving 3GPP network and the network server.

[0004] The USS is an entity that assists UAS operators in meeting UAS Traffic Management (UTM) operational requirements that enable safe and efficient use of airspace. The USS serves as a communications bridge between coalition UTM actors that assists operators' ability to meet regulatory and operational requirements for UAS operators, and provides operators with information regarding planned operations in or around the airspace volume so that they can verify their ability to perform their missions safely and efficiently. Summary of the Invention [Problem to be solved by the invention]

[0005] What is needed is a method and apparatus for managing USS instances. [Means for solving the problem]

[0006] Disclosed herein is a methodology for managing unmanned aerial system service supplier instances, the methodology may be implemented by an apparatus, a system, a method, or a computer program product.

[0007] A method is provided that is performed by a configuration unit. The configuration unit is communicatively coupled to a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV) and a UAV controller (UAV-C). The method includes receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS. The method further includes obtaining UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof. The method further includes determining a mapping of the UAS-specific information to one or more of the plurality of USSs based on the received USS information and the obtained UAS-specific information.

[0008] The determined mapping of the UAS-specific information to one or more of the multiple USSs tends to provide improved management of USS instances. In particular, the determined mapping may be used to facilitate handover of a flying UAV from one USS instance to another USS instance. Determining the mapping may include selecting one or more of the multiple USSs to provide one or more services specified by the USS service requirements to the UAV as the UAS flies within the UAV registration area, the selection being based on the received USS information and the obtained UAS-specific information.

[0009] Information specifying the service area of ​​the USS may be received from an application unit selected from a group of application units consisting of a USS, a UAS traffic management module, a UAV, a UAV-C, a UAS application specific server, and a UAS operator.

[0010] The information specifying the service area of ​​the USS may include one or more of the following group: information specifying a geographical range of services provided by the USS, information specifying a geographical range of services provided by the USS within the registration area of ​​the UAV, information specifying a time period during which services are provided by the USS, information specifying a time period during which services are provided by the USS within the registration area of ​​the UAV, and information specifying a network topology of the USS.

[0011] The method may further include configuring multiple user plane communication paths for the UAS based on the determined mapping of the UAS to the multiple USSs and the information specifying the service areas of the USSs. Each user plane communication path may include a Data Network Access Identifier (DNAI). The configuration of multiple user plane communication paths for the UAS tends to facilitate smooth handover from one USS instance to another USS instance.

[0012] The method may further include configuring one or more policies for the UAS based on the mapping of the UAS to the multiple USSs and the information specifying a service area of ​​the USS, the one or more policies may include one or more policies selected from a group of policies consisting of USS switching criteria, a priority of USSs with overlapping service areas, and a primary USS for the UAS, and transmitting the one or more policies to a control function of the UAS and / or the communication network.

[0013] The method may further include transmitting the determined mapping to one or more network functions of the communications network and / or the UAS.

[0014] The determination of the mapping of the UAS to the multiple USSs may be based on the planned and / or expected route of the UAV. The multiple USSs may comprise one or more Local USS Networks (LUNs).

[0015] The method may further include using a coverage area of ​​the USS network to detect a trigger event to initiate a change of USS, and in response to detecting the trigger event, determining whether a second USS is available to service the UAV when the UAV is in communication with the first USS. The method may further include sending a request for a UAV handover to the second USS network in response to determining that the second USS is available to service the UAV.

[0016] The method may further include sending a command to the UAS, the command being a command to transition to receiving one or more services from the second USS network.

[0017] The method may further include receiving a confirmation that the UAV has handed over to the second USS network.

[0018] The constituent unit may be a unit selected from a group of units consisting of an Uncrewed Aerial System Application Enabler Server (UAES), which is a server remote from the UAS, a UAV-C, a network publishing function, a network function, an application function, a service capability publishing function, and a UAV.

[0019] A configuration unit for communicating with a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV), the configuration unit comprising a receiver and a processor. The receiver is arranged to receive, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS. The processor is arranged to obtain UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof. The receiver is further arranged to determine a mapping of the UAS to one or more of the plurality of USSs based on the received USS information and the obtained UAS information.

[0020] There is further provided a system comprising a configuration unit and an application unit as described herein, wherein the configuration unit may be arranged to receive information specifying a service area of ​​the USS from the application unit, and the application unit may be an application unit selected from a group of application units consisting of a USS, a UAS traffic management module, a UAV, a UAV-C, a UAS application specific server, and a UAS operator.

[0021] A method is further provided that is performed by a configuration unit. The configuration unit is communicatively coupled to a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV) and a UAV controller (UAV-C). The method includes receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS. The method further includes obtaining UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof. The method further includes selecting one or more of the plurality of USSs based on the received USS information and the obtained UAS-specific information.

[0022] The selecting step may include selecting one or more of the plurality of USSs to provide one or more services specified by the USS service requirements to the UAV when the UAV flies within the UAV registration area. The selection may be based on the received USS information and the obtained UAS-specific information.

[0023] To illustrate how the advantages and features of the present disclosure can be obtained, the present disclosure will be described with reference to specific apparatus and methods illustrated in the accompanying drawings. Each of these drawings illustrates only certain aspects of the present disclosure and therefore should not be considered as limiting its scope. The drawings may be simplified for clarity and are not necessarily drawn to scale.

[0024] A method and apparatus for managing unmanned aerial system service supplier instances will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0025] [Figure 1] FIG. 1 is a plan view of the geographic coverage of multiple USS instances. [Diagram 2] FIG. 1 illustrates the deployment of multiple USSs on different edge / cloud platforms. [Diagram 3] FIG. 1 illustrates a logical 3GPP architecture for UAS support. [Figure 4] FIG. 1 illustrates a high-level architecture of an application layer functional model for supporting UAS. [Figure 5a] FIG. 1 is a messaging diagram illustrating an example of multi-USS support at the UAS enabler layer. [Figure 5b] FIG. 1 is a messaging diagram illustrating an example of multi-USS support at the UAS enabler layer. [Figure 6a] FIG. 1 is a messaging diagram illustrating an example of network-based multi-USS configuration and switching. [Figure 6b]FIG. 1 is a messaging diagram illustrating an example of network-based multi-USS configuration and switching. [Figure 7] FIG. 2 illustrates a user equipment device that may be used in accordance with any of the examples presented herein. [Figure 8] FIG. 2 illustrates a network node that may be used to implement the methods described herein. [Figure 9] FIG. 2 illustrates a method performed by a configuration unit. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] As will be appreciated by those skilled in the art, aspects of the present disclosure may be embodied as a system, apparatus, method, or program product. Thus, the arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, microcode, etc.), or a form combining software and hardware aspects.

[0027] For example, the disclosed methods and apparatus may be implemented as hardware circuits comprising custom very-large-scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and systems may also be implemented in programmable hardware such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0028] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transitory, and / or non-transmittable. The storage devices may not embody signals. In certain arrangements, the storage devices use only signals to access the code.

[0029] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device that stores the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical or semiconductor system, apparatus, or device, or any suitable combination of the above.

[0030] More specific examples of storage devices (non-exhaustive list) include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the context of this document, a computer-readable storage medium may be any tangible medium that contains or can store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0031] Throughout this specification, reference to a particular method or apparatus example, or similar language, means that the particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the methods and apparatus described herein. Thus, references to a particular method or apparatus example, or similar language, may, but do not necessarily, all refer to the same example, but mean "one or more examples, but not all examples," unless expressly specified otherwise. The terms "including," "comprising," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise. An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a," "an," and "the" also refer to "one or more," unless expressly specified otherwise.

[0032] As used herein, a list with the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using "one or more of" includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes only one or only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes one or only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C, and combinations thereof" includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C.

[0033] Furthermore, the features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, and the like, to provide a thorough understanding of the present disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatuses may be implemented without one or more specific details or with other methods, components, materials, and the like. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the present disclosure.

[0034] Aspects of the disclosed methods and apparatus are described below with reference to schematic flow chart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products. It will be understood that each block of the schematic flow chart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flow chart illustrations and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate a machine such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the schematic flow chart illustrations and / or schematic block diagrams.

[0035] The code may also be stored in a storage device that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner to produce an article of manufacture containing instructions that implement the functions / acts specified in the schematic flow chart illustrations and / or schematic block diagrams.

[0036] The code may also be loaded into a computer, other programmable data processing device, or other device to cause a series of operational steps performed on the computer, other programmable device, or other device to generate a computer-implemented process such that the code executing on the computer or other programmable device provides a process for implementing the functions / acts specified in the schematic flow chart illustrations and / or schematic block diagrams.

[0037] The schematic flow chart diagrams and / or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products. In this regard, each block in the schematic flow chart diagrams and / or schematic block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions of code for implementing a specified logical function(s).

[0038] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks of the illustrated figures, or portions thereof.

[0039] The description of an element in each figure may refer to an element in a previous figure. Like numbers refer to like elements in all figures.

[0040] The present disclosure relates generally to the field of managing unmanned aerial system service supplier instances, and in particular to providing continuity of UAV application services in scenarios where two or more USS instances (deployed at the edge or in the cloud) from different service providers may provide services during a UAV flight.

[0041] An Unmanned Aerial System (UAS) is a combination of an Unmanned Aerial Vehicle (UAV) and a UAV controller (which may be, for example, a remote pilot or a UAS operator). A UAV is an aircraft without a human pilot on board, for example, in some cases, a UAV may be controlled from an operator via a UAV controller. UAVs also have some degree of autonomous flight capability. The communication requirements of a UAS cover both command and control (C2) and uplink and downlink data between UAS components towards both the serving 3GPP network and the network server.

[0042] A USS is an entity that assists UAS operators in meeting UTM operational requirements that enable safe and efficient use of airspace. The USS serves as a communications bridge between coalition UTM actors that assists the operator's ability to meet regulatory and operational requirements for UAS operators and provides information to operators regarding planned operations in or around the airspace volume so that the operator can confirm their ability to perform their mission safely and efficiently. An airspace volume may be defined as the airspace over a defined or designated geographic area. An airspace volume may be defined by a maximum and / or minimum operating height.

[0043] The U.S.S. A service that enables authorized UTM parties to discover active USSs and their available services within the USS network; A service that provides aircraft owners with the ability to register data relating to their UAS; · Services for USS registration, Services for message security to ensure that data is protected and exchanged only with authorized users; Other value-added services that support UTM participants as market forces create opportunities to meet their business needs. may be provided.

[0044] In some scenarios, the USS is a component of a USS network. The term "USS network" refers to a federation of interconnected USSs that exchange information on behalf of participating operators. The USS network shares operational intent data, airspace constraint information, and other relevant details across the network to ensure shared situational awareness of UTM participants.

[0045] Each USS may have several geographic areas and times that it provides service in. Each of these different areas is called a "USS instance" of that USS.

[0046] FIG. 1 shows a plan view of the geographical scope of multiple USS instances A1, A2, B, C, D1, D2, and E. As an example, a Local USS Network (LUN) can be defined for USS instance B. The LUN of USS instance B comprises USS instances A1, C, and E. The LUN of USS instance C comprises only USS instance B. If an instance does not intersect with other instances, such as D1 or D2, the LUN is empty. It should also be noted that one USS may have two separate instances. In FIG. 1, A1 and A2 are different instances from USS A, and such instances may or may not overlap. For example, the two instances D1 and D2 of USS D do not overlap.

[0047] UAV 100 is shown in a current position within USS B, a point also covered by USS C. Vector 110 indicates the velocity of UAV 100 as it approaches the boundary of USS B and moves toward the center point of USS C. The dashed line indicates the path 120 of flight of UAV 100 since the flight began at location 130 within USS A1.

[0048] In a multi-USS scenario, each USS may be physically located in a different cloud, and it is also possible for a USS to be deployed at the edge. In such a multi-USS scenario, interaction with the communication network is preferably designated to support a UAS session that requires interaction with more than one USS, for example for UAV mobility to different geographic areas covered by different edge clouds.

[0049] FIG. 2 illustrates the deployment of multiple USSs in different edge / cloud platforms. Two USSs are deployed in different edges / clouds and clustered in different LUNs. A first LUN 210 includes USS#1 212, USS#1.1 214, and USS#1.2 216. A second LUN 220 includes USS#2 222, USS#2.1 224, and USS#2.2 226. Each USS instance (214, 212, 216, 224, 222, 226) has a respective Data Network Access Identifier (DNAI) (232, 234, 236, 238, 240, and 242). In such a deployment, the interaction between the UAV and the 5GS may be via different DNAIs. The UAV / UAV-C may travel anywhere permitted, following the intended UAV route, according to the desires, constraints, and / or requirements of the UAS operator.

[0050] However, in such a configuration, provisioning of the USS address on the UAV may not be sufficient to capture the expected changes and trigger a transition to a different USS. To understand the possible switching requirements, on the UE side, LUN related information and addresses, as well as the geographic area / address corresponding to the USS of the LUN may be required.

[0051] In fact, a UAV may request a USS switch (i.e., from receiving one or more services from a first USS to receiving one or more services (and / or other services) from a second USS different from the first USS) during flight. A USS switch may be referred to as a USS handover. Such a switch may be performed dynamically or even proactively to avoid service interruptions. Conventional deployments do not support a way by which the network can recognize an expected switch to enable dynamic traffic steering of UAS application traffic to a different DNAI. In known deployments, a USS switch may be implemented via an AMF that triggers a new authorization, but such an approach has the problem of not allowing continuity of application services during flight.

[0052] Typically, different USSs do not necessarily provide the same services. Different USSs may be deployed by different Service Providers (SPs) that provide different services. When switching USSs during flight, the UAS needs to be handed over from a source USS to a target USS that meets its service requirements and preferably provides similar performance as the source USS. The source USS is the current USS used by the UAV, and the USS handover results in the UAV switching USS from the source USS to the target USS.

[0053] The switch of USS may apply LUN mapping since the new LUN is a set of USSs in the overlap area with respect to the target USS. As a result, the source USS needs to interact with a different USS for notifications related to the UAS switch. Such changes also affect the UAV and UAS operator side.

[0054] The LUN information captures areas of overlap, which tends to reduce service loss by proactively transitioning the UAV to the target USS before it leaves the service area of ​​the source USS. For example, as shown in FIG. 1, UAV 100 is in USS B and also in the area covered by USS C. If it is determined that UAV 100 is in an area covered by both B and C and is moving toward the border of B into a portion of C not covered by USS B, a USS handover from B to C may be initiated before UAV 100 leaves USS B. In such a case, the network supports the handover by proactively steering the UAV's traffic to the new USS / DNAI (i.e., USS C).

[0055] The current assumption in 3GPP SA2 (3GPP TS 23.502 v17.2.1) regarding DNAI change is to check if the source Application Function (AF) can serve the target DNAI. If it cannot and a change of AF instance is required, the source AF determines a suitable target AF for the target DNAI and performs the AF transition or handover. However, a mechanism is needed to facilitate the determination of a target AF for a target DNAI.

[0056] 3 illustrates a logical 3GPP architecture for UAS support as described in 3GPP TS 23.256 v17.0.0, which specifies aspects of authorization for UAS attachment, identification, and tracking. The logical 5GS architecture for UAVs includes a UE 310, which may be a UAV, a NG Radio Access Network (NG-RAN) 320, another Access Network (AN) 330, which may or may not be a Radio Access Network (RAN), a 5G Core (5GC) 340, an Evolved Packet Core (EPC) 350, a UAS Network Function (NF) or Network Exposure Function (NEF) 360, a data network 370, a USS 375, and a Third Party Authorized Entity (TPAE) 380. The UAV 310 communicates with at least one of the access networks 320 and 330 using a wireless communication protocol. The NG-RAN 320 communicates with the 5GC 340 using an N3 interface. The (R)AN 330 communicates with the EPC 350 using an S1 interface. The 5GC 340 communicates with the UAS NF 360 using, for example, any one of the N29, N30, and N51 interfaces. The USS 375 resides in the data network 370. The UAS NF 360 communicates with the USS 375 using an N33 interface. In addition, the 5GC 340 communicates with the data network 370 using an N6 interface, and the EPC 350 interfaces with the data network 370 using an SGi interface. The USS 375 may communicate with external entities, such as the TPAE 380, using the data network 370.

[0057] The new functionality described herein may reside in the UAS NF360 supported by the NEF or SCEF+NEF. The UAS NF360 provides external exposure of services to the USS375. The UAS NF360 utilizes existing NEF / SCEF exposed services for UAV310 authentication / authorization, UAV flight authorization, UAV-UAVC pairing authorization, and related revocation, location reporting, and control of QoS traffic filtering for C2 communication. A dedicated NEF may be deployed to provide only UAV NF360 functionality, i.e., to support UAS specific functions / APIs and NEF functions / APIs designated for capability exposure towards the USS375. To support re-authentication requests by the USS375, the UAS NF360 stores information on whether the re-authentication is directed towards the AFM or SMF / SMF+PGW-C, and the address of the serving AMF or SMF / SMF+PGW-C.

[0058] Furthermore, it is assumed that the UAV is registered with the USS before connecting to the 3GPP system or using plain Internet connectivity through the 3GPP system. Before registering UAS services with the 3GPP system, the UAV is provisioned with a CAA-level UAV identity. One or more USSs may exist within a particular region and may manage the UAV via one or more 3GPP networks. It should be noted that according to 3GPP Release 17, it is assumed that the UAV is served by a single USS for the duration of the connection between the USS and the UAV.

[0059] In 3GPP TS 23.256 v17.0.0, the 5GC 340 optionally receives the address or USS fully qualified domain name of the USS 375 in addition to the CAA-level UAV ID to discover the USS 372 on behalf of the UAV 310. The USS 375 is provided in the UUAA registration from the UE to the AMF and also in the UUAA_MM procedure when the AMF invokes a USS authentication request to the UAS NF.

[0060] Additionally, in 3GPP SA6, an application layer functional model is specified to support UAS operation and integration with 5GS. The UAE server has the functions of location acquisition, QoS coordination, and C2 selection / switching support.

[0061] FIG. 4 shows a high-level architecture of an application layer functional model for supporting UAS. The UAV 410 has an associated UAS Application Enabler Client (UAEC) 412 and a UAS Application Specific Client (UASASC) 414. Similarly, the UAV Controller (UAV-C) 420 has an associated UAS Application Enabler Client (UAEC) 422 and a UAS Application Specific Client (UASASC) 424. The 5GS 430 provides wireless communication for the UAV 410 and UAV-C 420 and facilitates communication with the respective UAE Servers (UAES) 432, 434. The communication may be facilitated by a northbound API. The UAV 410 and UAV-C 420 may communicate directly via the 5GS 430 or by a direct wireless connection. The UAES 432 may reside in a UAS Application Specific Server (UASASS) and communicates with the UAS operator 440 using the UAE Server API (defined in 3GPP TS 23.255 v 17.1.0). The UAES 434 communicates with at least one USS 451 via a UAS Traffic Management (UTM) 450 that may be hosted within the UASASS. The UAESs 432, 434 may use the UAE Server API to communicate with their respective UASASSs 440, 450.

[0062] The UAE server 432 or 434 is: Performing group-based QoS management for a UAS (i.e., a pair of a UAV and a UAV-C) by using a service enabler architecture layer API; receiving a C2 operational mode configuration from a UAS application specific server (e.g., USS / UTM) and further configuring the UAS UE (i.e., UAV / UAV-C); Triggering a C2 communication mode switch with the UAS UE; receiving and storing a selected C2 communication mode from the UAS UE; Monitoring the real-time status of the UAS UE by using the Service Enabler Architecture Layer API; and / or Support UAV application message communication between UAVs Provides server-side UAS application layer support functions such as:

[0063] The UAE clients 412, 422 support interactions with UAS application-specific clients. The UAE clients provide application layer support functions with the client-side UAS, including receiving and storing C2 operating mode configurations, selecting primary and secondary C2 communication modes based on the configurations, and switching C2 communications in emergency scenarios.

[0064] The UAS application specific servers 440, 450 provide server side functionality corresponding to UAS applications (e.g., USS / UTM). The UAS application specific servers utilize the UAE servers for UAS application layer support functions. If CAPIF is supported, the UAS application specific servers act as API callers for CAPIF as specified in 3GPP TS 23.222 v17.5.0. The UAS application specific servers can be UTM / USS or can be the UAS operator (if the UAS operator is different from the UAV pilot).

[0065] The UAS application-specific clients 414, 424 provide client-side functionality that serves UAS applications (e.g., clients that interact with USS / UTM). The UAS application-specific clients utilize the UAE client for UAS application layer support functions.

[0066] In general, the present disclosure provides a mechanism to support proactive / dynamic USS switching for UAS to facilitate UAV mobility by provisioning more detailed and specific USS information to the UAS and the underlying communication network. Such functionality may be supported by the UAE layer (SA6) or by a Core Network (CN) function. The Core Network function may be any of the UAS NF, NEF, and SMF.

[0067] A Flight Information Management System (FIMS) in UAS Traffic Management (UTM) configures the LUNs, specifically LUN#1 of USS1, USS2, UUS3, LUN#2 of USS2: USS1, USS4. FIMS provides this information via the USSREQ_API (specified in the NASA / FAA specifications for UTM). In summary, the method proceeds as follows: 1. Before registering for UAS services in the 3GPP system, the UAV (and UAV-C) is provisioned with the UAV identity and USS#1 address at CAA level by the UTM / UAS operator, the geographic area and time validity of USS#1, the LUN identity and information (list of USSs that overlap with USS#1), the area of ​​intersection / overlap between two or more USSs in the LUN (and their addresses). 2. The UAV / UAV-C registers with the 3GPP system (using the USS#1 ID, and optionally also the USS#1 information / geographical area / LUN information based on step 1). Alternatively, the UAEC of the UAV (or UAV-C) may also subscribe to the UAE layer service after registering with the 3GPP system (using the USS#1 information / geographical area / LUN information based on step 1). 3. The UAE layer / 3GPP system provisions the user plane paths / DNAI for all USSs in the LUN to the UASSS (USS / UTM and / or UAS operator). 4. Optionally, the UAV / UAV-C UE is provisioned with a USS remapping / switching policy that identifies the criteria under which USS remapping is done and the priority of USS remapping within the LUN, in addition to the policies / parameters (e.g. QoS policies, radio parameters, etc.) of the list of services offered by all USSs within the LUN. Such criteria take into account USS performance in the target area reaching a lower threshold, availability of better performing USSs providing the same services, load / limitations of the target USS. 5. The UAV is cleared to fly and the flight begins.

[0068] After the above steps, the method can take one of two routes: 6. On the network / server side, a trigger event is captured, e.g., expected / predicted position deviation of the UAV based on position tracking from the LCS or SEAL LMS service (or from the UAV). 7. The Core Network (CN) Function / UAE Server indicates that USS#1 intersects with USS#2 in the current area. 8. The CN Function / UAE server checks if this offers the same service and asks for permission from the source / target USS and / or UAV. 9. The source / target USS and / or UAV sends the authorization to the CN function / UAE server and also sends the target USS LUN information with the geographic area covered by the other USS. 10. The CN Function / UAE Server (AF) checks whether it can serve the target DNAI corresponding to the target USS. If a change of AF instance is required, the AF determines the appropriate target AF for the target DNAI. The decision of the target AF for the target DNAI and the AF transition to the target AF is based on the target USS and LUN information in the target area. The CN Function / UAE Server then recommends the use of the target USS to the UAV / UAV-C and / or UTM / UAS operator to ask for confirmation before the AF transition (to confirm that it can provide coverage to the target area or to decide to select another USS from the target LUN that may be more robust to UAV mobility). The CN Function / UAE Server performs the AF transition to the target USS / AF. As a result, a USS switch command is sent to the UAS to instruct the application in the UAV to establish a connection to a different USS address. 11. After the switch command, the UAV establishes communication with the new USS (via the user plane) and to facilitate this, the USS may trigger UAV re-authentication (e.g., assign a new CAA-level UAV ID, new security credentials for user plane connection). In another alternative specific to SA2, the target USS triggers USS re-authentication using the UAV's IP address (i.e., without a switch command to the UAV). During re-authentication, the UAV obtains a new CAA-level UAV ID, USS address, etc. The CN function / UAE server may also translate the new USS into a different DNAI and acting as an AF may affect traffic steering by requesting a change in the DNAI.

[0069] Instead of the previous Route 1, Route 2 follows steps 1 to 5 above as follows: At the UE side, a trigger event is captured that indicates the location to the edge of the coverage area. b. The UAV sends a request to the 3GPP network / UAE server to change to the target USS in the current area / time (based on the knowledge that USS#1 intersects with USS#2 at its current / expected position). c. The CN function / UAE server checks if it offers the same service and seeks permission from the source / target USS. d. The source / target USS sends authorization to the CN facility / UAE server and also sends the target USS LUN information with the geographical area covered by the other USS. e. Same as step 10. f. Same as step 11.

[0070] 5a is a messaging diagram illustrating an example of multi-USS support at the UAS enabler layer. The system shown in FIG. 5a comprises a UAV UE 503 and associated UASC 501 and UAEC 502. The system further comprises a UAV-C UE 508 and associated UASC 506 and UAEC 507. The system further comprises a 5GC 510, a UAES 520, a USS#1 531, a USS#2 532, and a USS#3 533.

[0071] In this embodiment, the UAES 520 is a constituent unit, and the UAV 503 and UAV-C 508 each deploy a UAEC 502, 507, respectively.

[0072] Prior to registering UAS services in the 3GPP system in 541, the UAV 503 (and UAV-C 508) is provisioned with CAA level UAV identity and USS#1 address by the UTM / UAS operator, geographic area and time validity of USS#1, LUN identity and information (list of USSs that overlap with USS#1 531), areas of intersection / overlap between two or more USSs in the LUN (and their addresses). In this step, the UAE server 520 may play a role by providing policies from the UTM to the UAV 503 / UAV-C 508.

[0073] The UAS registers with the 5GS per TS 23.256 (543), after which UAE layer services can be initiated via two alternative methods 542 or 544.

[0074] At 542, the USS#1 531, or the UTM acting as the UASSS, requests / subscribes to receive UAE server services. In such a subscription request, the USS#1 531 may provide one or more of an indication that the UAS is expected to operate in an area where multiple USSs are available (e.g., using a multi-USS flag), the USS ID and address of each USS in the area in which the UAS is expected to operate, the ID of the UAV 503 / UAV-C 508 or the ID of the CAA, the time validity and validity area of ​​the subscription, the preferred slice ID (S-NSSAI / ENSI) for UAS communications, and / or the exposure level required for the northbound services / APIs. The UAES 520 sends a response indicating a positive or negative result.

[0075] Instead of step 542, at 544, the UAV-C 508, or the RPIC, or the UAS (if a separate entity) may request / subscribe to receive the services of the UAE server 520 via the UAEC 507 (the UASC 506 sends a subscription request to the UAEC 507, which forwards the subscription request to the UAES 520). In such a subscription request, the UASC 506 may provide one or more of an indication that the UAS is expected to be operated in an area where multiple USSs are available (e.g., using a multi-USS flag), a USS ID and address, the ID of the UAV 503 / UAV-C 508 or the ID of the CAA, the UAEC IDs of the UAV 503 and UAV-C 508, the time validity and validity area of ​​the subscription, and / or a preferred slice ID (S-NSSAI / ENSI) for UAS communications. The UAES 520 sends a response to the UAEC 507 indicating a positive or negative outcome.

[0076] At 545, the UAV503 operator or USS, after joining, transmits additional information regarding the USS geographic area, the LUN of the USS, a list of USSs within the LUN, the geographic areas of other USSs, topological areas corresponding to the USSs and LUNs, the expected mission, permissible areas / routes the UAV503 may travel, and the capabilities of the UAV503.

[0077] At 546, the UAES 520 obtains UP route information for all DNs in its coverage. Such information may be obtained via the user plane (from the UPF / global DN) or alternatively may query the 5GC 510 (PCF / UDM via NEF) for a list of DNAIs corresponding to different authorized USSs for multiple areas or areas covering expected / authorized UAV 503 routes. Such a query request may indicate USS addresses / AF IDs, routing profiles (for UAS apps) and request UP information (e.g., DNAIs, DNNs, S-NSSAIs) for multiple possible application locations (with service areas). The 5GC 510 then provides a list of DNAIs for application profiles corresponding to different USSs along with USS IDs / addresses and optionally topological areas (e.g., list of cells) per USS.

[0078] At 547, the UAES 520 maps each USS (AF) with one or more DNAIs for all USSs in the LUN. The USSs may also be mapped to topological areas (cells). Then, for each LUN or for the area of ​​interest of the UAV 503 (e.g., based on permissible routes),<USS x, DNAI y> We can map and store all pairs of .

[0079] At 548, the UAES 520 optionally provides per USS UP route information to the source USS and optionally (as the source USS may not be aware of the other USSs) to the UAV 503 operator / UAV-C 508. The UAES 520 shall be able to request approval from the target USS to provide details before sending UP information for the other USSs.

[0080] At 549, the UAS operator (which can be UAV-C508 or an app on a server) provides the UAES520 (via the UAEC) with a service profile for the UAV503 based on the operation / expected capabilities of the UAV503 (e.g., commercial drone, PS drone).

[0081] At 550, the UAES 520 provisions the UAV 503 / UAV-C 508 with policies / parameters regarding communication over 5GC (for both PC5 / Uu). Such policies / parameters may be similar to those defined for V2X (TS 23.287), but additional parameters may relate to different policies per USS (including alternate USS / LUNs) and policies related to whether to transition to a different USS in case of overlapping coverage / insufficient support of the serving USS. These policies may also include prioritization of USSs in case more than one USS is available within the target area.

[0082] At 551, UAV 503 is authorized to fly and flight begins / UAV 503-UAV 503C are both connected to 5GS / establish a PDU session.

[0083] The above steps are the same for Figures 5a and 5b. Figure 5a shows a first arrangement in which steps 541 to 551 are followed by the following:

[0084] At 552, the UAES 520 tracks the location of the UAV 503 by subscribing to the 5GC 510 / LMF, or by subscribing to the SEAL, or by periodically requesting the actual / projected / predicted location of the UAV 503. The UAES 520 generates trigger events that indicate the UE has moved into an area where the USS overlaps with another USS or where the USS is not supported.

[0085] In 553, if there is an overlap, the UAES 520 checks whether the performance of the serving USS is affected (by requesting a QoS sustainability analysis or by requesting a DN / USS performance analysis for the target area) or if no serving USS is supported in the target area, checks what is the best available USS and whether this can provide the same service. The criteria for the best available USS is mainly the location of the UAV 503, but can also be the priority of the USS in the target area (based on policy) and that the capabilities (services) provided by the target USS are comparable.

[0086] At 554, the UAES 520 sends a Request / Confirmation Request message to the source USS (or target USS) indicating the requirement of a USS transition for the UAS, to the target USS, or simply to provide an indication of the need for the change. This message may include the UAS ID, serving and target USS addresses, cause of the change, expected time / location of the change. Such a message may additionally or alternatively be sent to the UAS operator (UAV-C 508 or the UAS operator as a server side) or UTM to confirm the transition to the target USS.

[0087] At 555, the participating USSs authorize the transition with UTM / FIMS support, provide a response indicating the outcome (success / failure / negotiation by proposing another USS), and provide LUN / USS list information for the target USS.

[0088] In 556, the UAES 520 translates this into a UP route change and interacts with the SMF via the NEF as the AF to affect the UP route (switch to the target DNAI). In particular, the UAE server (acting as the AF) checks whether it can serve the target DNAI corresponding to the target USS based on the mapping of USS to DNAI performed in step 3b. If a change of AF instance is required, the AF determines the appropriate target AF for the target DNAI. The decision of the target AF for the target DNAI and the AF transition to the target AF is based on the confirmed target USS in the target area. The CN function / UAE server then performs the AF transition to the target USS / AF.

[0089] At 557, the UAES 520 also sends a USS remapping notification / command to the UAS (UAV 503 and / or UAV-C 508) via the UAEC, and then at 558, the USS transition is performed.

[0090] FIG. 5b shows a second arrangement which replaces steps 542 to 557 above, in which steps 541 to 551 are the same as in FIG. 5a, but in contrast to the rest of FIG. 5a, FIG. 5b proceeds as follows.

[0091] At 571, the UAV 503 / UASC captures a position deviation / mobility event where the USS overlaps with another USS or heads towards an area where the USS is not supported.

[0092] In 572, if there is an overlap, the UAEC checks if the performance of the serving USS is affected or if the serving USS is not supported in the target area, and checks what is the best available USS and if this can provide the same service (based on a pre-configured list of USS). The criteria for the best available USS is mainly the location of the UAV 503, but can also be the priority of the USS in the target area (based on policy) and the equivalent capabilities (services) provided by the target USS.

[0093] At 573, the UAEC sends a request / notification to the UAES 520 to switch the USS to the exact target USS or simply to indicate that the serving USS is not available or not preferred (not expected to be available or not expected to be preferred).

[0094] At 574, the UAES 520 sends a request / confirmation request message to the source USS (or target USS) indicating the requirement for a USS transition of the UAS, to the target USS, or simply to provide the need for the change. This message includes the UAS ID, serving and target USS addresses, the cause of the change, and the expected time / location of the change. Such a message may also (or alternatively) be sent to the UAS operator (UAV-C 508 or the UAS operator as a server side) or UTM to confirm the transition to the target USS.

[0095] At 575, the participating USS allows the transition from one USS to another with the support of UTM / FIMS and provides a response to the UAES 520 indicating the outcome (success / failure / negotiation by proposing another USS) and provides LUN / USS list information for the target USS.

[0096] In 576, the UAES 520 converts the received response message into a UP route change and interacts with the SMF via the NEF as an AF to affect the UP route (switch to the target DNAI). In particular, the UAE Server (UAES) 520 (acting as an AF) checks whether it can serve the target DNAI corresponding to the target USS based on the mapping of USS to DNAI performed in step 3b. If an AF instance change is required, the AF determines the appropriate target AF for the target DNAI. The decision of the target AF for the target DNAI and the AF transition to the target AF is based on the confirmed target USS in the target area. The CN function / UAE Server then performs the AF transition to the target USS / AF.

[0097] At 577, the UAES 520 also sends a USS remapping response / command to the UAS (UAV 503 and / or UAV-C 508) via the UAEC, and then at step 577, the USS transition is performed.

[0098] Figure 6a is a messaging diagram illustrating an example of network-based multi-USS configuration and switching. The system of Figure 6a includes a UASC 606, a UAV-C 608, a UASC 601, a UAV UE 603, a Session Management Function (SMF) 614, a Policy Control Function (PCF) 616, a Unified Data Repository 618, a UAS Network Function (NF) or Network Publishing Function (NEF) 620, a USS#1 631, and a USS#2 632. In the following USS handover, transition, or remapping example, USS#1 631 is the source USS and USS#2 632 is the target USS.

[0099] At 641, the UAS registers with the 5GS based on TS23.256, which can be done according to either step 542 or 544 discussed above in relation to Figure 5a.

[0100] At 642, USS#1 first subscribes to the NEF620 using its own AF service ID and, optionally, a corresponding DNAI list. Such a subscription can be either not bound to a specific UAV or for a specific application profile. In addition, other USSs can also subscribe individually using their own AF service ID and, optionally, a corresponding DNAI list. In this subscription, the USS address / FQDN and, optionally, the DNAI and geographical area are sent to the 5GC.

[0101] At 643, USS#1, or the UTM, or the UAS operator (AF) sends an AF request to the UAS NF / NEF620 using a list of pairs of <AF service ID, DNAI or geographical / topological area> related to the LUN ID and the UAS (each AF service ID corresponding to a different USS within the LUN). If USS#1 recognizes the IP address of the UAV603 (i.e., the UAV having an ongoing session with the USS or C2 communication), the USS includes the IP address of the UAV603.

[0102] At 644, the UAS NF / NEF620 sends a message containing a list of pairs of <AF service ID, DNAI or geographical / topological area> related to the UAS to the PCF616 via the UDR618. The UAS NF / NEF620 can also convert the mapping to DNAI instead of the area if this information is not in the AF request. The PCF616 groups the list of AF service IDs and the list of DNAIs for the target UAV. When the NEF620 receives the IP address of the UAV, the NEF620 discovers the PCF616 serving the UAV (which can be done based on the IP address) and sends the list of AF service IDs and the corresponding DNAIs directly to the PCF616.

[0103] At 645, the PCF 616 sends the UAS policies to the UAV-C 608 before flight. These policies include per-USS provisioning policies / parameters for all USSs in the LUN, USS switching policies (criteria / thresholds for triggering switching in the UAV), and priorities between USSs (when two or more USSs cover overlapping areas). The UAV flight is then authorized and begins.

[0104] At 646, the PCF 616 sends traffic rules for the UAV for multiple USSs (list of AF service IDs) to the SMF 614. The SMF 614 may group the list of AF service IDs and the list of DNAIs for the target UAV PDU session.

[0105] At 647, the SMF 614 determines a DNAI for the UAV based on the location of the UAV and based on the DN performance analysis to consume (if the USS has access to more than one DNAI).

[0106] At 648, the SMF 614 joins the LMF / AMF for LCS monitoring.

[0107] At 649, the SMF 614 captures DNAI changes for the UAV (based on position monitoring).

[0108] The above steps are the same for Figures 6a and 6b. Figure 6a shows a first arrangement where steps 641 to 649 are followed by the following:

[0109] At 650, the AF subscribes to notifications from the SMF 614 (via the NEF 620) about DNAI changes. This subscription is a group message. The AF subscribes with a list of AF service IDs and the corresponding DNAI.

[0110] At 651, the SMF 614 sends the captured DNAI changes to the NEF 620 / UASNF.

[0111] At 652, the NEF620 / UASNF checks whether it can serve the target DNAI corresponding to the target USS based on the mapping of USS to DNAI performed in step 2. If a change of AF instance is required, the AF determines the appropriate target AF for the target DNAI. The decision of the target AF for the target DNAI and the AF transition to the target AF is based on the confirmed target USS in the target area (if confirmation is required, the NEF620 / UASNF first requests confirmation from the source / target USS or UTM).

[0112] The UAS NF / NEF 620 then performs AF transition to the target USS / AF at 653. More specifically, the NEF 620 updates the old AF service ID to the new AF service ID (for the target USS) for the UAV application. The NEF 620 may send a trigger request / notification to one or both AFs (for both USSs) to indicate the USS switch.

[0113] At 654, the USS transition is carried out.

[0114] FIG. 6b shows a second arrangement, in which steps 641 to 649 are the same as in FIG. 6a, but in contrast to the rest of FIG. 6a, FIG. 6b proceeds as follows.

[0115] At 662, the AF subscribes to notifications to the SMF 614 about DNAI changes. This subscription is a group message. The AF subscribes with a list of AF service IDs and the corresponding DNAI.

[0116] In 663, the SMF 614 recognizes the list AF service IDs in the LUN and the policy / priority for USS reselection and sends the change in DNAI for the UAV to the involved AFs (serving and target). The SMF 614 may check whether it can serve the target DNAI corresponding to the target USS based on the mapping of USS to DNAI performed in step 2. If a change in AF instance is required, the AF determines the appropriate target AF for the target DNAI. The decision of the target AF for the target DNAI and the AF transition to the target AF is based on the confirmed target USS in the target area.

[0117] At 654, USS2 performs reauthorization based on current procedures such as in TS 23.256.

[0118] This document describes new capabilities to support dynamic / proactive in-flight adaptation of USS without impacting UAV performance / connectivity. It also describes the use and exchange of LUN information and USS geographical area in the 5GS enabler layer to support dynamic / proactive in-flight adaptation. Interaction between AFs via 5GS is provided to support dynamic translation of UAV mobility events into a set of UP paths / DNAIs for traffic steering. SMF / PCF / NEF extensions allow grouping of AF service IDs and mapping to DNAIs per group of USS / LUNs and publishing notifications to all involved AFs serving UAV applications.

[0119] FIG. 7 illustrates a user equipment device 700 that may be used according to any of the examples presented herein. The user equipment device 700 may be a UE 310, a UAV 410, a UAV-C 420, a UAV UE 503, a UAV-C UE 508, a UAV UE 603, or a UAV-C UE 608. The user equipment device 700 is used to implement one or more of the solutions described above. The user equipment device 700 may also include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. If the UE 700 is a UAV, the UE 700 also includes functionality for performing flight, which may include a propulsion system, a flight control system, and one or more cameras.

[0120] The input devices 715 and the output devices 720 may be combined into a single device, such as a touch screen. The user equipment device 700 may not include any input devices 715 and / or output devices 720. The user equipment device 700 may include one or more of the processor 705, the memory 710, and the transceiver 725 and may not include the input devices 715 and / or the output devices 720.

[0121] As shown, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735. The transceiver 725 may communicate with one or more cells (or wireless coverage areas) supported by one or more base stations. The transceiver 725 may be operable in an unlicensed spectrum. Additionally, the transceiver 725 may include multiple UE panels supporting one or more beams. In addition, the transceiver 725 may support at least one network interface 740 and / or application interface 745. The application interface 745 may support one or more APIs. The network interface 740 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 740 may be supported as will be appreciated by those skilled in the art.

[0122] The processor 705 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 705 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field programmable gate array ("FPGA"), or similar programmable controller. The processor 705 may execute instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

[0123] The processor 705 may control the user equipment device 700 to implement the UE operations described above. The processor 705 may include an application processor (also known as a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also known as a “baseband radio processor”) that manages radio functions.

[0124] Memory 710 may be a computer-readable storage medium. Memory 710 may include volatile computer storage media. For example, memory 710 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). Memory 710 may include non-volatile computer storage media. For example, memory 710 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. Memory 710 may include both volatile and non-volatile computer storage media.

[0125] The memory 710 may store data related to implementing the traffic category fields as described above. The memory 710 may also store program code and associated data, such as an operating system or other controller algorithms running on the device 700.

[0126] The input devices 715 may include any known computer input devices, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. The input devices 715 may be integrated with the output devices 720, for example, as a touch screen or similar touch-sensitive display. The input devices 715 may include a touch screen so that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. The input devices 715 may include two or more different devices, such as a keyboard and a touch panel.

[0127] Output device(s) 720 may be designed to output visual, audible, and / or tactile signals. Output device(s) 720 may include electronically controllable displays or display devices capable of outputting visual data to a user. For example, output device(s) 720 may include, without limitation, liquid crystal displays ("LCD"), light emitting diode ("LED") displays, organic LED ("OLED") displays, projectors, or similar display devices capable of outputting images, text, and the like to a user. As another non-limiting example, output device(s) 720 may include wearable displays separate from but communicatively coupled to the remainder of user equipment device 700, such as smart watches, smart glasses, head-up displays, and the like. Additionally, output device(s) 720 may be components of a smartphone, personal digital assistant, television, tablet computer, notebook (laptop) computer, personal computer, vehicle dashboard, and the like.

[0128] The output device(s) 720 may include one or more speakers for playing sounds. For example, the output device(s) 720 may generate an audible alert or notification (e.g., a beep or chime). The output device(s) 720 may include one or more haptic devices for generating vibration, movement, or other haptic feedback. All or a portion of the output device(s) 720 may be integrated with the input device(s) 715. For example, the input device(s) 715 and the output device(s) 720 may form a touchscreen or similar touch-sensitive display. The output device(s) 720 may be located near the input device(s) 715.

[0129] The transceiver 725 communicates with one or more network functions of a mobile communications network via one or more access networks. The transceiver 725 operates under the control of the processor 705 to transmit messages, data, and other signals and to receive messages, data, and other signals. For example, the processor 705 may selectively activate the transceiver 725 (or a portion thereof) at a particular time to transmit and receive messages.

[0130] The transceiver 725 includes at least a transmitter 730 and at least one receiver 735. The one or more transmitters 730 may be used to provide UL communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 735 may be used to receive DL communication signals from the base unit. Although only one transmitter 730 and one receiver 735 are shown, the user equipment device 700 may have any suitable number of transmitters 730 and receivers 735. Furthermore, the transmitter 730 and receiver 735 may be any suitable type of transmitter and receiver. The transceiver 725 may include a first transmitter / receiver pair used to communicate with a mobile communication network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communication network over an unlicensed radio spectrum.

[0131] A first transmitter / receiver pair may be used to communicate with a mobile communications network over a licensed radio spectrum, and a second transmitter / receiver pair used to communicate with a mobile communications network over an unlicensed radio spectrum may be combined into a single transceiver unit, e.g., a single chip that performs functions for use in both the licensed and unlicensed radio spectrum. The first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, a particular transceiver 725, transmitter 730, and receiver 735 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 740.

[0132] The one or more transmitters 730 and / or the one or more receivers 735 may be implemented and / or integrated in a single hardware component, such as a multi-transceiver chip, a system on a chip, an application specific integrated circuit ("ASIC"), or other type of hardware component. The one or more transmitters 730 and / or the one or more receivers 735 may be implemented and / or integrated in a multi-chip module. Other components, such as a network interface 740 or other hardware components / circuits, may be integrated in a single chip with any number of transmitters 730 and / or receivers 735. The transmitters 730 and receivers 735 may be logically configured as a transceiver 725 using one or more common control signals, or as modular transmitters 730 and receivers 735 implemented in the same hardware chip or multi-chip module.

[0133] 8 illustrates a network node 800 that may be used to implement the methods described herein. The network node 800 may be any one of the network nodes described herein, in particular, a configuration unit, a core network function, a UAS NF360, a UAES434, a UAES432, a UAES520, a NEF620. The network node 800 may include a controller 805, a memory 810, an input device 815, an output device 820, and a transceiver 825.

[0134] The input devices 815 and the output devices 820 may be combined into a single device, such as a touch screen. The network node 800 may not include any input devices 815 and / or output devices 820. The network node 800 may include one or more of the controller 805, the memory 810, and the transceiver 825 and may not include the input devices 815 and / or the output devices 820.

[0135] As shown, the transceiver 825 includes at least one transmitter 830 and at least one receiver 835, where the transceiver 825 communicates with one or more remote units 105. In addition, the transceiver 825 may support at least one network interface 840 and / or an application interface 845. The application interface 845 may support one or more APIs. The network interface 840 may support 3GPP reference points such as Uu, N1, N2, and N3. As will be appreciated by one of ordinary skill in the art, other network interfaces 840 may be supported.

[0136] The controller 805 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the controller 805 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. The controller 805 may execute instructions stored in the memory 810 to perform the methods and routines described herein. The controller 805 is communicatively coupled to the memory 810, the input device 815, the output device 820, and the transceiver 825.

[0137] Memory 810 may be a computer-readable storage medium. Memory 810 may include volatile computer storage media. For example, memory 810 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). Memory 810 may include non-volatile computer storage media. For example, memory 810 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. Memory 810 may include both volatile and non-volatile computer storage media.

[0138] The input devices 815 may include any known computer input devices including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. The input devices 815 may be integrated with the output devices 820, for example as a touch screen or similar touch-sensitive display. The input devices 815 may include a touch screen so that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. The input devices 815 may include two or more different devices, such as a keyboard and a touch panel.

[0139] The output device 820 may be designed to output visual, audible, and / or tactile signals. The output device 820 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 820 may include, but is not limited to, an LCD, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 820 may include a wearable display separate from but communicatively coupled to the rest of the network node 800, such as a smart watch, smart glasses, a head-up display, and the like. Additionally, the output device 820 may be a component of a smartphone, a personal digital assistant, a television, a tablet computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0140] The output device(s) 820 may include one or more speakers for playing sounds. For example, the output device(s) 820 may generate an audible alert or notification (e.g., a beep or chime). The output device(s) 820 may include one or more haptic devices for generating vibration, movement, or other haptic feedback. All or a portion of the output device(s) 820 may be integrated with the input device(s) 815. For example, the input device(s) 815 and the output device(s) 820 may form a touchscreen or similar touch-sensitive display. The output device(s) 820 may be located near the input device(s) 815.

[0141] The transceiver 825 includes at least a transmitter 830 and at least one receiver 835. The one or more transmitters 830 may be used to communicate with a UE, as described herein. Similarly, the one or more receivers 835 may be used to communicate with a network function in the PLMN and / or RAN, as described herein. Although only one transmitter 830 and one receiver 835 are shown, the network node 800 may have any suitable number of transmitters 830 and receivers 835. Furthermore, the transmitters 830 and receivers 835 may be any suitable type of transmitter and receiver.

[0142] FIG. 9 illustrates a method performed by a configuration unit 900. The configuration unit 900 may comprise a UAS NF360, a UAES434, a UAES432, a UAES520, a NEF620, or a network node 800. The configuration unit 900 is communicatively coupled to a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV) and a UAV controller (UAV-C). The method includes receiving 910, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS. The method further includes obtaining 920 UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof. The method further includes determining 930 a mapping of the UAS-specific information to one or more of the plurality of USSs based on the received USS information and the obtained UAS-specific information.

[0143] The determined mapping of the UAS-specific information to one or more of the multiple USSs tends to provide improved management of the USS instances. In particular, the determined mapping may be used to facilitate handover from one USS instance to another in flight.

[0144] In some alternative examples, determining the mapping may include selecting one or more of the multiple USSs based on the received USS information and the obtained UAS-specific information.

[0145] Indeed, a method performed by a configuration unit is also provided, the configuration unit being communicatively coupled to a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV) and a UAV controller (UAV-C), the method including the steps of receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS, obtaining UAS-specific information, the UAS-specific information including a UAV registration area, a USS service requirement, or a combination thereof, and selecting one or more of the plurality of USSs based on the received USS information and the obtained UAS-specific information.

[0146] The configuration unit 900 determines the mapping of UAS-specific information to one or more of the multiple USSs. This tends to enable new capabilities to support dynamic and proactive in-flight adaptation of USSs while maintaining UAV connectivity. Furthermore, the collection of USS information and USS geographical areas in the configuration unit 900 tends to support both dynamic and proactive in-flight adaptation, especially during in-flight USS handovers. Furthermore, the configuration unit 900 tends to facilitate interaction between AFs over 5GS, which supports dynamic translation of UAV mobility events into a set of traffic steering of user plane paths and DNAIs. It should further be noted that the configuration unit 900 tends to facilitate SMF / PCF / NEF extensions to group AF service IDs and map them to DNAIs per group of USSs / LUNs, and enable publishing notifications to all involved AFs corresponding to UAV applications.

[0147] The step of determining the mapping may include selecting one or more of the multiple USSs to provide one or more services specified by the USS service requirements to the UAV when the UAS flies within the UAV registration area, the selection being based on the received USS information and the obtained UAS-specific information.

[0148] A UAV registration area may be a space in which a UAV is intended to operate and / or authorized to operate. The space in which a UAV is intended to operate may include a predefined route. The UAV may fly along the predefined route. The space may be defined by an area of ​​ground and a volume over that area of ​​ground. The volume may be constrained by a maximum and minimum operating height. A UAV registration area may specify a volume or physical region of airspace in which a UAV is registered to operate and / or a geographical area in which a UAV is registered to operate. A UAV registration area may include a registration area that is an authorized area in which a UAV is authorized to fly, provided by a UAS traffic management or flight aviation authority (e.g., Civil Aviation Authority (UK) or Federal Aviation Administration (USA) etc.). Alternatively, a UAV registration area may be defined by a UE registration area for a public land mobile network in which a UAS is authorized to communicate based on a prior service level agreement with a PLMN operator.

[0149] USS service requirements are definitions of services required by the UAS during the intended operation of the UAV. The USS provides various services that can be considered as tools used by the UAS operator to monitor the airspace, execute safe missions, and store operational data. USS services can relate to discovery / searching of airspace conditions for the flight of the UAV, support for UAV flight planning, and in-flight support, for example, to provide real-time alerts. In different USS instances, different services may be available, and USS service requirements can be both the various services that the USS provides and the service key performance requirements for each USS service to provide these services over the communication network. Such requirements can include minimum communication bandwidth in the uplink direction, or downlink direction, or both. The service definition can include maximum communication latency for the uplink direction, or downlink direction, or both. The service requirements can include position provisioning requirements, where the UAV is transmitted its location, and the position provisioning requirements can include minimum position accuracy.

[0150] The information specifying the service area of ​​the USS may be received from an application unit selected from a group of application units consisting of a USS, a UAS traffic management module, a UAV, a UAV-C, a UAS application specific server, and a UAS operator. The method may further include receiving an application capability service identifier and a DNAI for each of the plurality of USS networks.

[0151] The information specifying the service area of ​​the USS includes one or more of the group consisting of information specifying a geographical range of services provided by the USS, information specifying a geographical range of services provided by the USS within the registration area of ​​the UAV, information specifying a time period during which services are provided by the USS, information specifying a time period during which services are provided by the USS within the registration area, and information specifying a network topology of the USS.

[0152] The range of a USS network may be defined by a geographic area and the airspace above the geographic area. The geographic range of a USS network may be defined by location coordinates, such as GPS coordinates. The geographic range of a USS network may be defined by one or more cell service areas of a wireless communications network. At least one of the USS networks whose geographic range and time validity are transmitted to the configuration unit is an initial USS network. The initial USS network is the network with which the UAV communicates upon takeoff. The multiple USS networks may be defined by a local USS network (LUN).

[0153] The method may further include configuring a plurality of user plane communication paths for the UAS, the configuration based on the determined mapping of the UAS to a plurality of USSs and information specifying a service area of ​​the USSs, each user plane communication path including a data network access identifier (DNAI). Such configuration of user plane communication paths tends to facilitate improved handover between USSs of the UAV in flight.

[0154] The method may further include configuring one or more policies for the UAS based on the mapping of the UAS to the multiple USSs and the information specifying the service area of ​​the USS, the one or more policies including one or more policies selected from a group of policies consisting of USS switching criteria, priorities of USSs with overlapping service areas, and a primary USS for the UAS. The method may further include transmitting the one or more policies to a control function of the UAS and / or the communication network. The control function may be, for example, any network function of a 5G core network control plane defined in 3GPP TS 23.501 v 17.2.0.

[0155] The method may further include transmitting the determined mapping to one or more network functions of the communications network and / or the UAS.

[0156] The determination of the mapping of the UAS to multiple USSs may be based on a planned and / or expected route of the UAV. The route of the UAV may be defined by a flight plan. The expected route of the UAV may constitute a window of operation within which the flight of the UAV is expected to be constrained.

[0157] Multiple USSs may comprise one or more local USS networks (LUNs).

[0158] The method may further include using a service area of ​​the USS network to detect a trigger event to initiate a change of USS, determining whether a second USS is available to provide services to the UAV when the UAV is in communication with the first USS in response to detecting the trigger event, and sending a request for a UAV handover to the second USS network in response to determining that the second USS is available to provide services to the UAV.

[0159] The triggering event may include the UAV's current location satisfying a location criterion. The location criterion may include the UAV location coinciding with a boundary zone at the edge of the geographic range of the USS network. The location criterion may include the UAV detecting a signal from a base station of a cell outside the geographic range of the USS network. The triggering event may include the signal strength of a wireless communication signal at the USS in use falling below a signal strength threshold or packet loss of such a signal exceeding a packet loss threshold.

[0160] The configuration unit may detect a trigger event, which may be detected by the UAV or the UAV controller and a request may be sent to the configuration unit.

[0161] The method may further include transmitting a command to the UAS, the command being a command to transition to receiving one or more services from a second USS network. In response to receiving the command, the UAS transitions or may be transitioned to receiving one or more services from the second USS network instead of or in addition to the first USS. The method may further include receiving a confirmation that the UAV has handed over to the second USS network.

[0162] The constituent unit may be a unit selected from a group of units consisting of an Unmanned Aerial System Application Enabler Server (UAES), which is a server remote from the UAS, a UAV-C, a network publishing function, a network function, an application function, a service capability publishing function, and a UAV.

[0163] Further provided is a configuration unit for communicating with a communication network and an unmanned aerial system (UAS), the UAS including an unmanned aerial vehicle (UAV), the configuration unit comprising a receiver and a processor. The receiver is arranged to receive, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS. The processor is arranged to obtain UAS specific information, the UAS specific information including a UAV registration area, a USS service requirement, or a combination thereof, and to determine a mapping of the UAS to one or more of the plurality of USSs based on the received USS information and the obtained UAS information. The configuration unit may be embodied as a network node 800.

[0164] There is further provided a system comprising a configuration unit and an application unit as described herein, the configuration unit being arranged to receive information specifying a service area of ​​the USS from the application unit, the application unit being selected from a group of application units consisting of a USS, a UAS traffic management module, a UAV, a UAV-C, a UAS application specific server, and a UAS operator.

[0165] It should be noted that the above-described methods and apparatus are illustrative rather than limiting of the invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those recited in a claim, and "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of several units recited in a claim. Any reference signs in the claims should not be interpreted as limiting their scope.

[0166] Furthermore, although examples have been provided in the context of particular communication standards, these examples are not intended to be a limitation on the communication standards to which the disclosed methods and apparatus may be applied. For example, although particular examples have been provided in the context of 3GPP, the principles disclosed herein may be applied to other wireless communication systems, and indeed any communication system that uses routing rules.

[0167] The method may also be embodied in a set of instructions stored on a computer readable medium which, when loaded into a computer processor, a Digital Signal Processor (DSP), etc., causes the processor to perform the method described above.

[0168] The described method and apparatus may be embodied in other specific forms. The described method and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0169] 100 UAV 105 Ranged Unit 110 Vector 120 Routes 130 positions 210 First LUN 212 USS#1, USS Instance 214 USS#1.1, USS instance 216 USS#1.2, USS instance 220 Second LUN 222 USS#2, USS Instance 224 USS#2.1, USS instance 226 USS#2.2, USS instance 232 Data Network Access Identifier (DNAI) 234 Data Network Access Identifier (DNAI) 236 Data Network Access Identifier (DNAI) 238 Data Network Access Identifier (DNAI) 240 Data Network Access Identifier (DNAI) 242 Data Network Access Identifier (DNAI) 310 UE, UAV 320 NG Radio Access Network (NG-RAN), Access Network, NG-RAN 330 Access Network (AN), Access Network, (R)AN 340 5G Core (5GC), 5GC 350 Evolved Packet Core (EPC), EPC 360 UAS Network Function (NF) or Network Exposed Function (NEF), UAV NF 370 Data Network 372 USS 375 USS 380 Third Party Accreditation Body (TPAE), TPAE 410 UAV 412 UAS Application Enabler Client (UAEC), UAE Client 414 UAS Application Specific Client (UASASC) 420 UAV Controller, UAV-C 422 UAS Application Enabler Client (UAEC), UAE Client 424 UAS Application Specific Client (UASASC) 432 UAE Server (UAES), UAES 434 UAE Server (UAES), UAES 440 UAS Operator, UASASS 450 UAS Traffic Management (UTM), UASASS 501 UASC 502 UAEC 503 UAV UE, UAV 506 UASC 507 UAEC 508 UAV-C UE, UAV-C 510-5GC 520 UAES, UAE Server, UAE Server (UAES) 531 USS#1 532 USS#2 533 USS#3 601 UASC 603 UAV UE, UAV 606 UASC 608 UAV-C 614 Session Management Facility (SMF) 616 Policy Control Function (PCF), PCF 618 Unified Data Repository, UDR 620 UAS Network Function (NF) or Network Exposure Function (NEF), NEF, UAS NF / NEF 631 USS#1 632 USS#2 700 User equipment device, UE, device 705 processor, 710 Memory 715 Input Devices 720 output device 725 Transceiver 730 Transmitter 735 Receiver 740 Network Interface 745 Application Interface 800 network nodes 805 Controller 810 Memory 815 Input Devices 820 Output Device 825 Transceiver 840 Network Interface 845 Application Interface 900 configuration units

Claims

1. 1. A method performed by a configuration unit, the configuration unit being communicatively coupled to a communication network and an Uncrewed Aerial System (UAS), the UAS including an Uncrewed Aerial Vehicle (UAV) and a UAV controller (UAV-C), the method comprising: receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS; acquiring UAS specific information, the UAS specific information including a UAV registration area, a USS service requirement, or a combination thereof; determining a mapping of the UAS specific information to one or more of the plurality of USSs based on the received USS information and the obtained UAS specific information; A method comprising:

2. The method of claim 1, wherein the step of determining the mapping includes a step of selecting one or more of the plurality of USSs to provide one or more services specified by the USS service requirements to the UAV when the UAS flies within the UAV registration area, the selection being based on the received USS information and the acquired UAS-specific information.

3. 2. The method of claim 1, wherein the information specifying the service area of ​​the USS is received from an application unit, the application unit being an application unit selected from a group of application units consisting of a USS, a UAS traffic management module, a UAV, a UAV-C, a UAS application specific server, and a UAS operator.

4. The information specifying the service area of ​​a USS comprises: Information specifying the geographic extent of the services provided by that USS; Information specifying the geographic extent of the services provided by the USS within the registration area of ​​the UAV; Information specifying the time period for which services will be provided by the USS; Information specifying the time period during which services will be provided by the USS within the registration area of ​​the UAV; and Information specifying the network topology of the USS 2. The method of claim 1, comprising one or more of the group consisting of:

5. 2. The method of claim 1, further comprising: configuring a plurality of user plane communication paths for the UAS based on the determined mapping of the UAS to the plurality of USSs and the information specifying the service areas of the plurality of USSs, each user plane communication path including a Data Network Access Identifier (DNAI).

6. configuring one or more policies for the UAS based on the mapping of the UAS to the plurality of USSs and the information specifying the service area of ​​the USS, the one or more policies including one or more policies selected from a group of policies consisting of USS switching criteria, a priority of the USSs having overlapping service areas, and a primary USS for the UAS; transmitting the one or more policies to the UAS, or a control function of the communications network, or both; The method of claim 1, further comprising:

7. 10. The method of claim 1, further comprising transmitting the determined mapping to the communications network, or to one or more network functions of the UAS, or both.

8. The method of claim 1 , wherein the determining of the mapping of the UAS to the multiple USSs is based on a planned route of the UAV, or a predicted route of the UAV, or both.

9. The method of claim 1 , wherein the plurality of USSs comprises one or more Local USS Networks (LUNs).

10. using the service area of ​​the USS to detect a trigger event for initiating a change of USS; In response to detecting the trigger event, determining whether a second USS is available to provide service to the UAV when the UAV is in communication with a first USS; sending a request for UAV handover to a second USS in response to determining that the second USS is available to provide service to the UAV; The method of claim 1, further comprising:

11. 11. The method of claim 10, further comprising sending a command to the UAS, the command being a command to transition to receiving one or more services from the second USS.

12. The method of claim 10 , further comprising receiving a confirmation that the UAV has handed over to the second USS.

13. The constituent unit is an Unmanned Aerial System Application Enabler Server (UAES), a server remote from the UAS; The UAV-C, Network Exposure Function (NEF), Network Function (NF), Application Function (AF), Service Capability Exposure Function (SCEF), and The UAV 2. The method of claim 1, wherein the unit is selected from the group of units consisting of:

14. A configuration unit for communicating with a communication network and an Uncrewed Aerial System (UAS), the UAS including an Uncrewed Aerial Vehicle (UAV) and a UAV controller (UAV-C), the configuration unit comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor comprising: receiving, for each of a plurality of UAV service suppliers (USS), information specifying a service area of ​​the USS; obtaining UAS specific information, the UAS specific information including a UAV registration area, a USS service requirement, or a combination thereof; determining a mapping of the UAS specific information to one or more of the plurality of USSs based on the received USS information and the obtained UAS specific information; configured to cause the configuration unit to Configuration unit.

15. A configuration unit for communicating with a communication network and an Uncrewed Aerial System (UAS), the UAS comprising an Uncrewed Aerial Vehicle (UAV) and a UAV controller (UAV-C), Application Unit and Equipped with The constituent unit is receiving, for each of a plurality of UAV service suppliers (USS), information from the application unit specifying a service area of ​​each USS; obtaining UAS specific information, the UAS specific information including a UAV registration area, a USS service requirement, or a combination thereof; determining a mapping of the UAS specific information to one or more of the plurality of USSs based on the USS information and the UAS specific information; are arranged to The application unit is an application unit selected from a group of application units consisting of a USS, a UAS traffic management module, the UAV, the UAV-C, a UAS application specific server, and a UAS operator. system.

Images