Manage end-to-end application session QoS

Abstract

An apparatus 700 includes an APP interface 745 that receives 805 a request to manage QoS for an end-to-end application (APP) session. The end-to-end APP session includes a first session for a first UE connected to a first network (NW) and a second session for a second UE connected to a second NW. The processor 705 configures 810 first QoS parameters for the first session for the first UE and second QoS parameters for the second session for the second UE and receives 815 a trigger event associated with a QoS change in the second QoS parameters. The processor 705 determines 820 a third QoS parameter for the first session for the first UE based on the QoS change in the second QoS parameter and communicates 825 the third QoS parameter to the first NW.

Description

[Technical field]

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly, to achieving end-to-end QoS. [Background technology]

[0002] The following abbreviations are used in this document: 3rd Generation Partnership Project ("3GPP"), 5th Generation Core Network ("5CG"), 5th Generation System ("5GS"), 5th Generation QoS Identifier ("5QI"), Authentication, Authorization, and Accounting ("AAA"), Advanced Intersection Collision Warning ("AICW"), Access and Mobility Management Function ("AMF"), Acknowledgement ("ACK"), Application Programming Interface ("API"), Access Stratum ("AS"), Base Station ("BS"), Category of Requirements ("CoR"), Command-and-Control ("C2"), Control Element ("CE"), Cooperative merging ("CM"), Cooperative Overtaking ("CO"), Cooperative Transition of Control ("CToC"), Cooperative Lane Change ("CLC"), and Cooperative Traffic Acceleration ("TCA") are used in this document. Change"), Collective Perception ("CP"), Collective Perception Message ("CPM"), Core Network ("CN"), Connected and Autonomous Vehicle ("CAV"), Decentralized Environmental Notification Message ("DENM"), Downlink ("DL"), Intermittent Transmission ("DTX"), Evolved Node B ("eNB"), Evolved Packet Core ("EPC"), Evolved Packet System ("EPS"), Evolved UMTS Terrestrial Radio Access ("E-UTRA"), Evolved UMTS Terrestrial Radio Access Network ("E-UTRAN"), European Telecommunications Standards Institute ("ETSI"), General Packet Radio Service ("GPRS"), Generic Public Service Identifier ("GPSI").Public Service Identifier", Global System for Mobile Communications ("GSM"), Hybrid Automatic Repeat Request ("HARQ"), Home Subscriber Server ("HSS"), Information Element ("IE"), Internet of Things ("IoT"), International Mobile Equipment Identity ("IMEI"), Intelligent Transport System ("ITS"), ITS Station ("ITS-S"), Infrastructure to Vehicle Information Message ("IVIM"), Key Performance Indicator ("KPI"), Level of Automation ("LoA"), Long Term Evolution ("LTE"), Mobility Management ("MM"), Mobility Management Entity ("MME"), Map (topology) Extended Message ("MAPEM"), Maneuver Control ("MC"), Mobile Telecommunications ("MTC ... Control"), Maneuvering Control Message ("MCM"), Negative Acknowledgement ("NACK") or ("NAK"), New Generation (5G) Node B ("gNB"), New Generation Radio Access Network ("NG-RAN", the RAN used for 5GS networks), New Radio ("NR", the 5G Radio Access Technology, also known as "5G NR"), Non-Access Stratum ("NAS"), Network Slice Selection Assistance Information ("NSSAI"), Overtaking Vehicle Warning ("OVW"), Packet Data Unit ("PDU", used in connection with a "PDU Session"), PC5 5QI ("PQI"), Permanent Equipment Identifier ("PEI"), Platoon Control ("PC"), Platoon Control Message ("PCM"), Proximity Services ("ProSe"),Service), Public Land Mobile Network ("PLMN"), Quality of Service / Experience ("QoS"), Radio Access Network ("RAN"), Receiver ("RX"), Road Side Unit ("RSU"), Service Enabler Architecture Layer ("SEAL"), Session Management ("SM"), Session Management Function ("SMF"), Service Provider ("SP"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Signal Phase And Timing Extended Message ("SPATEM"), Signal Request Extended Message ("SREM"), Signal Request Status Extended Message ("SSEM"), Target Driving Area Reservation ("TDAR"), Transport Block ("TB"), Transmission ("TX"), Vehicle to Everything ("V2X"), Vehicle-to-Everything ("V2I"), Vehicle-to-Vehicle ("V2V"), ​​Vehicle-to-Relay ("V2R"), V2X Application Enabler ("VAE"), Vulnerable Road Users Protection ("VRUP"), Unified Data Management ("UDM"), Unmanned Aerial System ("UAS"), UAS Application Enabler ("UAE: UAS Application Enabler" i.e. having a UAE server and at least one UAE client), UAS Service Suppliers ("USS: UAS Service Suppliers"), UAS Traffic Manager ("UTM: UAS TrafficThe following are defined herein, at least some of which are referenced in the following description: HARQ-ACK (HARQ-ACK) may collectively refer to positive acknowledgement ("ACK") and negative acknowledgement ("NACK") and discontinuous transmission ("DTX"). ACK means that the TB is correctly received, while NACK (or NAK) means that the TB is incorrectly received. DTX means that the TB was not detected.

[0003] In Unmanned Aircraft System ("UAS") communications, there are various scenarios that require interaction between the UAV and the pilot-owner, also known as the UAV controller (UAV-C). One main use case for such interaction is command and control ("C2") communications. A UAS may be configured with a C2 communications mode. According to TS 22.125 (a specification of Stage 1 requirements for UAS), a C2 mode configuration is defined as "a user plane link to deliver messages from the UAV controller or UTM to the UAV with command and control information for the operation of the UAV." [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] TS 22.125 [Non-Patent Document 2] 3GPP TS 26.348 [Non-Patent Document 3] 3GPP TS 23.434 [Non-Patent Document 4] TS 23.501 [Non-Patent Document 5] TS 23.401 [Non-Patent Document 6] TS 23.502 [Non-Patent Document 7] TS 29.514 Summary of the Invention [Means for solving the problem]

[0005] A method for achieving end-to-end QoS is disclosed, as well as an apparatus and system for performing the functions of the method.

[0006] One method of the control unit includes receiving a request to manage QoS of an end-to-end application session, where the end-to-end application session includes a first session of a first UE connected to a first network and a second session of a second UE connected to a second network. The method includes configuring a first QoS parameter for the first session of the first UE and a second QoS parameter for the second session of the second UE, and receiving a trigger event related to a change in QoS of the second QoS parameter. The method includes determining a third QoS parameter for the first session of the first UE based on the change in QoS of the second QoS parameter, and communicating the third QoS parameter to the first network.

[0007] A more particular description of the embodiments briefly described above will be made by reference to specific embodiments illustrated in the accompanying drawings, in which the embodiments will be described and explained with more specificity and detail, with the understanding that these drawings illustrate only some embodiments and therefore should not be considered limiting in scope. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for achieving end-to-end QoS. [Diagram 2] FIG. 1 illustrates one embodiment of a network architecture for achieving end-to-end QoS. [Diagram 3] FIG. 1 illustrates one embodiment of a UAS application layer functional model. [Figure 4] FIG. 1 illustrates a signaling flow for one embodiment of a procedure for managing QoS guarantees for C2 communications. [Figure 5A] FIG. 2 illustrates a signaling flow for one embodiment of a procedure for network-triggered joint QoS adaptation, functionality of which is enabled by the UE. [Figure 5B] This is a continuation of the procedure in FIG. 5A. [Figure 6A] FIG. 1 illustrates a signaling flow for one embodiment of a procedure for network-triggered collaborative QoS adaptation, the functionality of which is enabled by a UTM. [Figure 6B] This is a continuation of the procedure in Figure 6A. [Figure 7] FIG. 2 is a flow chart diagram illustrating one embodiment of a procedure for achieving end-to-end QoS. [Figure 8] FIG. 2 illustrates an embodiment of a user equipment device that may be used to achieve end-to-end QoS. [Figure 9]FIG. 1 illustrates an embodiment of a network equipment device that may be used to achieve end-to-end QoS. [Figure 10] FIG. 2 is a flow chart diagram illustrating one embodiment of a method that may be used to achieve end-to-end QoS. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method or program product. Accordingly, the embodiments may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

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

[0011] Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, hereinafter referred to as code, computer readable code, and / or program code. The storage devices may be tangible, non-transitory, and / or non-transmitting. The storage devices may not embody signals. In certain embodiments, the storage devices employ only signals to access the code.

[0012] 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, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof.

[0013] More specific examples (non-exhaustive list) of storage devices include 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 disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0014] The code for carrying out the operations of the embodiments may be any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, ordinary procedural programming languages ​​such as the "C" programming language, and / or machine code such as assembly language. The code may run entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network ("LAN") or wide area network ("WAN"), or a connection to an external computer may be made (e.g., via the Internet using an Internet Service Provider).

[0015] Reference throughout this specification to "one embodiment," "an embodiment," or similar phrases means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearance of "in one embodiment," "in an embodiment," and similar phrases throughout this specification may, but do not necessarily, refer to the same embodiment and may mean "one or more, but not all, embodiments" unless otherwise specified. The terms "including," "comprising," "having," and variations thereof mean "including, but not limited to," unless otherwise specified. An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless otherwise specified. Additionally, the terms "a," "an," and "the" refer to "one or more," unless otherwise specified.

[0016] As used herein, a list using 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 the term "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 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, "an element selected from the group consisting of A, B, and C" includes only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "an element 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.

[0017] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, and the like, are provided to provide a thorough understanding of the embodiments. However, one skilled in the art will recognize that the embodiments may be implemented without one or more of the 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 embodiments.

[0018] Aspects of the embodiments are described below with reference to schematic flowchart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowchart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flowchart illustrations and / or schematic block diagrams, may be implemented by code. This code may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus produce means for performing the functions / acts specified in the flowchart illustrations and / or block diagrams.

[0019] The code may 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, such that the instructions stored in the storage device produce a product that includes instructions that perform the functions / acts specified in the flowchart illustrations and / or block diagrams.

[0020] The code may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process such that the code executing on the computer or other programmable apparatus provides a process for performing the functions / acts specified in the flowchart illustrations and / or block diagrams.

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

[0022] 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 concurrently, or the blocks may 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.

[0023] Various arrow types and line types may be used in the flowchart diagrams and / or block diagrams, but they are understood not to limit the scope of the corresponding embodiment. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between recited steps of the depicted embodiment. It is also noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by dedicated hardware-based systems that perform the specified functions or acts, or a combination of dedicated hardware and code.

[0024] The description of the elements in each figure may refer to the elements in the procedure figures. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0025] Generally, the present disclosure describes a system, method, and apparatus for ensuring the achievement of E2E QoS in indirect UAS communications. In UAS communications, there are various scenarios that require interaction between a UAV and a pilot-owner, also known as a UAV controller (UAV-C). One main use case of such interaction is command and control (C2) communications. Disclosed herein is a solution for ensuring the achievement of E2E QoS in indirect UAS communications, which may involve dynamic changes in the QoS of one of the communications links (e.g., a link from the UAV to a 5G network).

[0026] According to TS 22.125 (a specification of Stage 1 requirements for UAS), the C2 mode configuration is defined as "a user plane link for delivering messages containing command and control information for the operation of the UAV from the UAV controller or UTM to the UAV."

[0027] During direct C2 communication, the UAV controller and the UAV establish a direct C2 link to communicate with each other and are both registered with the 5G network using configured and scheduled radio resources provided by the 5G network for direct C2 communication.

[0028] During Network-Assisted C2 communication (also known as "indirect C2 communication"), the UAV controller and the UAV register with the 5G network, establish respective unicast C2 communication links to the 5G network, and communicate with each other over the 5G network. Both the UAV controller and the UAV may also be registered with the 5G network via different NG-RAN nodes in the same or different PLMNs. Network-Assisted C2 communication must support specific control modes and specific KPIs (e.g., end-to-end latency and reliability) for each control mode.

[0029] During UTM navigated C2 communications, the UAV is provided with a pre-scheduled flight plan, e.g., an array of 4D polygons, for autonomous flight, but the UTM continues to maintain a C2 communications link with the UAV to periodically monitor the flight status of the UAV, validate the flight status with the latest dynamic constraints, provide route updates, and navigate the UAV whenever necessary.

[0030] The four control modes defined in TS 22.125 are (1) steer to waypoints, (2) direct stick steering, (3) automatic flight by UTM, and (4) approaching autonomous navigation infrastructure. Two of these control modes require network-assisted C2 communications.

[0031] Steering to Waypoint: Control messages include flight declarations, e.g., waypoints, sent from the UAV controller or UTM to the UAV. Control mode is used in both direct and network-assisted C2 communication.

[0032] Direct Stick Steering: Control messages include directional instructions sent from the UAV controller to the UAV, while optionally video traffic is provided as feedback from the UAV to the UAV controller. The control mode is used in both direct and network-assisted C2 communication.

[0033] One additional scenario is a remote UAV controller with HD video. After the UAV and UAV controller set up the association and start the flight task, a C2 link is established to support the operation of the UAS normally. In some scenarios, for example when the UAV is flying beyond line of sight or during an emergency, the UAV controller is taken over by another UAV controller or a higher priority UAV controller. In this case, a C2 connection is established with the new UAV controller to ensure the continued support of the flight task.

[0034] With respect to the above control modes / scenarios, the QoS requirements of the end-to-end application (between UAV and UAV-C) may vary in terms of latency (20ms to 140ms), reliability (99.9% to 99.99%), data rate, etc., and may differ based on whether the communication originates from the UAV or the UAV-C.

[0035] One important issue related to C2 communication is the translation between application QoS requirements and network QoS requirements, and the fact that multiple PDU sessions may correspond to one E2E application session (C2 application).

[0036] In particular, the solution described in this specification addresses the problems of a) where and how linking / binding of PDU sessions corresponding to C2 E2E sessions needs to be performed, and b) how the provision of QoS per PDU session should be dynamically configured or adapted to ensure end-to-end achievement of QoS for C2 applications.

[0037] FIG. 1 illustrates a wireless communication system 100 for achieving end-to-end QoS according to an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one access network 110 and a mobile core network 120. As shown, the wireless communication system 100 may include a first access network serving a UAV 103 and a second access network serving a UAV controller 104. Here, the wireless communication system 100 includes at least one core network 120 (e.g., a 5GC of a PLMN). The access network 110 and the mobile core network 120 form a mobile communication network.

[0038] The unmanned aerial system ("UAS") 101 includes an unmanned aerial vehicle ("UAV") 103, a UAV controller 104, and command and control ("C2") links between the UAV 103 and the UAV controller 104 and between the UAV 103 and a network, including related functionality for remote identification. The UAV controller 104 of the UAS 101 allows a pilot to control the UAV 103 (also called a remotely piloted aircraft or drone) of the UAS 101. The UAS operator 102 (i.e., pilot) is a person who operates the UAV 103 (e.g., via the UAV controller 104). The UAV 103 and the UAV controller 104 may each be a UE in the wireless communication system 100. Thus, the UAV 103 and / or the UAV controller 104 may communicate with the access network 110 to access services provided by the mobile core network 120.

[0039] Even though FIG. 1 depicts a particular number of UAVs 103, UAV controllers 104, access networks 110, and mobile core networks 120, those skilled in the art will recognize that any number of UAVs 103, UAV controllers 104, access networks 110, and mobile core networks 120 may be included in the wireless communications system 100.

[0040] Each access network 110 includes at least one base unit 111 and may consist of a 3GPP access network (including at least one cellular base unit) and / or a non-3GPP access network (including at least one access point). In various embodiments, the access network 110 is a wireless access network, such as a 5G-RAN. A UE (e.g., UAV 103 and / or UAV controller 104) may communicate with the 3GPP access network using a 3GPP communication link and / or with the non-3GPP access network using a non-3GPP communication link.

[0041] In one embodiment, the wireless communication system 100 complies with the 5G system defined in the 3GPP specifications. More broadly, however, the wireless communication system 100 may implement any other open or proprietary communication network, such as LTE or WiMAX, among other networks. This disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0042] In one embodiment, a UE (e.g., UAV 103 and / or UAV controller 104) may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smart phone, a smart appliance (e.g., an Internet connected appliance), a game console, a remote controller, etc. Additionally, a UE may be referred to as a remote unit, a subscriber unit, a mobile phone, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit ("WTRU"), a device, or other terminology used in the art.

[0043] A UE (e.g., UAV 103 and / or UAV controller 104) may communicate directly with one or more of the base units 117 in the access network 115 by uplink ("UL") and downlink ("DL") communication signals. In some embodiments, the UL and DL communication signals are carried over 3GPP communication links. In other embodiments, the UL and DL communication signals are carried over non-3GPP communication links. Here, the access network 115 is an intermediate network that provides the UAV 103 and / or UAV controller 104 with access to the mobile core network 120.

[0044] In some embodiments, the UE communicates with one or more UAV traffic management ("UTM") services via a network connection with the mobile core network 120. As described in more detail below, the UAV 103 may establish a PDU session (or similar data connection) with the mobile core network 120 using the access network 115. The mobile core network 120 then relays traffic between the UE and the data network 130 using the PDU session. It should be noted that the UE may establish one or more PDU sessions (or other data connections) with the mobile core network 120. Thus, the UE may have at least one PDU session for communicating with the data network 130. The UE may establish additional PDU sessions for communicating with other data networks and / or other remote hosts.

[0045] The base units 111 may be distributed across a geographic region. In certain embodiments, the base units 111 may be referred to as access points, access terminals, bases, base stations, Node Bs, eNBs, gNBs, Home Node Bs, relay nodes, devices, or any other terminology used in the art. The base units 111 are generally part of a radio access network ("RAN"), such as an access network 110, which may include one or more controllers communicatively coupled to one or more corresponding base units 111. These and other elements of a radio access network are not shown, but are generally familiar to those skilled in the art. The base units 111 connect to a mobile core network 120 via the access network 110.

[0046] The base unit 111 may serve multiple UEs in a serving area, e.g., a cell or a sector of a cell, via a wireless communication link. The base unit 111 may directly communicate with one or more of the UEs by communication signals. In general, the base unit 111 transmits DL communication signals to serve the UEs in the time, frequency, and / or spatial domains. Furthermore, the DL communication signals may be carried over a communication link. The communication link may be any suitable carrier in a licensed or unlicensed radio spectrum. The communication link facilitates communication between one or more of the UEs and / or one or more of the base units 111.

[0047] In one embodiment, the mobile core network 120 is a 5G Core ("5GC") or Evolved Packet Core ("EPC") that may be coupled to a data network (e.g., data network 130), such as the Internet and a private data network, among other data networks. The UEs may have a subscription or other account with the mobile core network 120. Each mobile core network 120 belongs to a single public land mobile network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0048] The mobile core network 120 includes several network functions ("NFs"). As shown, the mobile core network 120 may include one or more user plane functions ("UPFs") 121. The mobile core network 120 also includes multiple control plane functions, including but not limited to an access and mobility management function ("AMF") 123, and a session management function ("SMF") 125, and a network publication function ("NEF") 127. In certain embodiments, the mobile core network 120 may also include an authentication server function ("AUSF"), a policy control function ("PCF"), and a unified data management function ("UDM"), a network repository function ("NRF") (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for 5GC. In certain embodiments, the mobile core network 120 may include an AAA server.

[0049] In various embodiments, the mobile core network 120 supports different types of mobile data connections and different types of network slices, each of which utilizes a particular network slice. Here, a "network slice" refers to a portion of the mobile core network 120 optimized for a particular traffic type or communication service. A network instance may be specified by the S-NSSAI, while a set of network slices that a UE (e.g., the UAV 103 and / or the UAV controller 104) is authorized to use is specified by the NSSAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF 125 and the UPF 121. In some embodiments, different network slices may share some common network functions, such as the AMF 123. For ease of illustration, different network slices are not shown in FIG. 1, but their support is assumed.

[0050] 1, one skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 120. Furthermore, if the mobile core network 120 is an EPC, then the depicted network functions may be replaced with appropriate EPC entities, such as an MME, an S-GW, a P-GW, an HSS, etc.

[0051] In the following description, the term gNB is used for a base station, but it may be replaced by any other radio access node, e.g., BS, eNB, gNB, AP, NR, etc. Furthermore, the operation is primarily described in the context of 5G NR, however, the proposed solutions / methods are equally applicable to other mobile communication systems that support serving cells / carriers configured for operation of a UAS.

[0052] As shown, the UE (e.g., UAV 103 and / or UAV controller 104) may connect to a mobile core network (e.g., to a 5G mobile communications network) via an access network 115. Connecting to a mobile communications network (e.g., a combination of an access network and a mobile core network) allows the UAV 103 to operate at a greater distance from the UAV controller 104 and does not require a line-of-sight connection between the UAV 103 and the UAV controller 104.

[0053] Generally, a UAS 101 may interact with one or more UAV traffic management ("UTM") services 131 when operating a UAV 103 and / or submitting a flight plan. In various embodiments, each mobile core network 120 that supports the operation of a UAV may communicate with one or more UTMs 131.

[0054] UTM 131 is an element that manages UAV operation for one or more UAVs 103 and UAV controllers 104. In various embodiments, UTM 131 monitors UAVs 103 and UAV controllers 104 operating in certain uncontrolled airspace (e.g., less than 400 feet above ground). Managing the operation of a UAV may include granting flight authorization, performing collision avoidance, determining alternate flight routes, ensuring that the UAV's operation is within authorized limits, etc. In various embodiments, the operation of the UTM is similar to that of an air traffic controller (ATC) that manages manned aircraft on the ground and in controlled airspace (above 400 feet).

[0055] In many scenarios, the UAV controller 104 establishes a connection to the UAV 103 via one or more 5G systems operated by the same or different mobile network operators. For example, the UAV controller 104 may establish a data connection with the UAV 103 via the access network 115 and the core network 120. When a UE (e.g., one of the UAV 103 and the UAV controller 104) requests to establish a data connection (e.g., a PDU session) for the operation of the UAV, the SMF 125 selects the UTM 131 and validates the operation of the UAV.

[0056] The UTM 131 may send requests to the UAE server 133 to manage quality of service of C2 communication sessions for the UAS 101, as discussed in further detail below with reference to Figures 2, 3A-3B, and 4A-4B. The UAE server 133 collects information to assist in determining whether to dynamically adapt quality of service parameters of the C2 communications of the UAS 101. Additionally, the UAE server 133 may receive location and other information from a Service Enabler Application Layer (SEAL) server 135.

[0057] The SEAL Server 135 provides on-demand (subscription or request) services to all vertical enabler layer (aka middleware) platforms (e.g., UAE Server 133). Vertical specific support functions between application specific servers and the Mobile Core Network 120. Common support functions (service platforms enabling common capabilities for faster onboarding of new verticals) include location management, group management, network resource management, configuration management servers, etc., and can be used as services to vertical specific enablers.

[0058] The UAV Control Function ("UCF") 129 is a function for processing location information from the network. The UCF 129 can be a network function within the mobile core network 120 (i.e., 5GC) or an application function (AF) outside the mobile core network 120 that interacts with the mobile core network 120 via the NEF 127.

[0059] It should be noted that although the following description takes into account the mobility of UAV 103 and assumes that UAV controller 104 remains stationary, in other embodiments the mobility of UAV controller 104 may require system 100 to take into account changing wireless link conditions of UAV controller 104 due to mobility, interference, etc.

[0060] In UTM-Navigated C2 mode, the UTM 131 acts as a UAV-C 104 for the UAV 103 and establishes a C2 communication session with the UAV 103 via the mobile core network 120 (and access network 110). Through the mobile network connection, the UTM 131 sends flight instructions to the UAV 103. Note that the UTM-Navigated C2 mode does not require line of sight between the UAV-C 104 and the UAV 103.

[0061] In the indirect C2 mode, UAV-C 104 establishes a C2 communication session with UAV 103 via the mobile core network 120 (and access network 110). Through the mobile network connection, UAV-C 104 may send flight instructions to UAV 103. Note that the indirect C2 mode does not require line of sight between UAV-C 104 and UAV 103.

[0062] 2 illustrates a network architecture 200 for achieving end-to-end QoS according to an embodiment of the present disclosure. The network architecture 200 includes an instance of a UAV 103, an instance of a UAV-C 104, a UTM / USS 205, a UAE server and / or a SEAL server and / or a UCF 210, and a 5GS 215. The UAV 103 includes a middleware layer having a UAE client and / or a SEAL client 240 and a C2 application 255. The UAV-C 104 includes a middleware layer having a UAE client and / or a SEAL client 220 and a C2 application 235.

[0063] The UTM is an air traffic management ecosystem for UAS that includes a set of functions and services for managing the operation of various autonomous vehicles (e.g., authentication of UAVs, authorization of UAS services, management of UAS policies, and control of UAV traffic in the airspace). UTM services are defined outside the 3GPP system and follow the requirements of a particular region. The USS is part of the UTM and is a service provider for UASs. The USS provides services to support the safe and efficient use of the airspace by providing services to the operators / pilots of the UAS to meet the requirements of the UTM operation. One or more USSs may exist in a particular region and may manage the UAVs on one or more 3GPP networks. The 3GPP network may provide the UTM / USS 205 with location information of the UAVs / UAV-Cs and may support the UTM to establish associations between the UAVs 103 and the UAV-Cs 104. Additionally, one of the services of the UTM is to provide the operators of the UASs with infrastructure and quality of service guarantees for radio frequency (RF) command and control (C2) capabilities.

[0064] As shown, the UAE-C / SEAL-C 220 may establish a UAE and / or SEAL session 225 with the UAE-S / SEAL-S / UCF 210. Similarly, the UAE-C / SEAL-C 240 may also establish a UAE and / or SEAL session 245 with the UAE-S / SEAL-S / UCF 210. A UAE / SEAL session refers to an application session established between the UAE / SEAL server and the UAE / SEAL client of the UAV and UAV-C deploying the UAE / SEAL client to interact with the UAE / SEAL server.

[0065] Additionally, the C2 application 235 may establish an application-specific end-to-end ("E2E") session 260 with the C2 application 255. Note that the application-specific E2E session 260 has the QoS requirements of the associated application. The application-specific E2E session 260 represents a session between the C2 application on the UAV and the C2 application on the UAV-C and / or the UTM / USS 205 (in UTM-navigated C2 communication).

[0066] The UAV-C 104 establishes a network connection 230 with the 5GS 215. Note that the network session 230 has associated network QoS requirements (denoted as 5QIs “x”, “y”). The UAV 103 establishes a network connection 250 with the 5GS 215. Note that the network session 250 has associated network QoS requirements (denoted as 5QIs “y”, “z”). As discussed above, the UAV 103 and the UAV-C 104 communicate instructions and / or waypoints 265 via the 5GC 215. Similarly, the UAV 103 may transmit video data 270 to the UAV-C 104.

[0067] In network-assisted C2 communications, the following considerations apply:

[0068] 1) It is assumed that both UAV and UAV-C are connected to one or more 3GPP networks. In this case, two PDU sessions need to be established for C2 communication, specifically, 1) a UAV-C PDU session and 2) a UAV PDU session. There is no mechanism on the network side to link these two PDU sessions for joint QoS monitoring and configuration.

[0069] 2) It is assumed that each of these PDU sessions may have one or more QoS profiles based on traffic requirements. An example of multiple QoS profiles is direct stick C2 mode, where UAV-C gives instructions to UAV (associated with one QoS profile) and UAV provides video feed to UAV-C (associated with another QoS profile). In this scenario, each PDU session requires at least two QoS profiles: one for command and control messages and one for video transfer.

[0070] 3) It is assumed that UAV-C 104 may be a mobile UE and may be connected to a different access network than UAV 103, or even a different PLMN.

[0071] As an example, if the E2E latency of C2 communication is 40 ms, each PDU session (the PDU session for UAV and the PDU session for UAV-C) may be configured with a delay-critical GBR QoS flow (see 5QI=82 or 83) with a delay budget, e.g., 10 ms. The 3GPP network ensures that the GBR flow of the UAV and the GBR flow of the UAV-C meet the delay requirement of 10 ms. When the delay of the GBR flow used by the UAV exceeds a threshold (e.g., >30 ms), the UAV-C may request a smaller delay (e.g., 5QI 85) for its own GBR flow so that the overall delay does not exceed 40 ms. However, there is no mechanism to adjust the QoS attributes of the two dependent sessions.

[0072] 3 illustrates a UAS application layer functional model 300 according to an embodiment of the present disclosure. The UAS application layer functional model 300 includes a first UAS UE 301 (e.g., UAV-C or UAV) and a second UAS UE 303 (e.g., UAV or UAV-C) that interact with a UAS application server 305 via a 3GPP network system 307. The UAS application layer functional model 300 includes at least a UAS application specific layer 309, a UAE layer 311, and a SEAL layer 313. In each layer, the UAS UE 301, 303 includes a client that interacts with a corresponding server of the UAS application server.

[0073] The first UAS UE 301 includes a UAE client 321, a SEAL client 327, and a UAS application specific client 315. The second UAS UE 303 includes a UAE client 323, a SEAL client 329, and a UAS application specific client 317. The UAS application server 305 includes a UAE server 325, a SEAL server 331, and a UAS application specific server 319.

[0074] The UAS application specific layer 309 includes UAS application specific functionality. The functionality of the UAS application specific layer 309 includes the USS / UTM 205. In the UAS application specific layer 309, the UAS application specific client 317 of the second UAS UE 303 communicates with the UAS application specific client 315 of the first UAS UE 301 over the U5-APP reference point. The UAS application specific clients 315, 317 communicate with the UAS application specific server 319 over the U1-APP reference point. It should be noted that the U1-APP reference point includes communication from the UAV controller / UAV to the USS / UTM.

[0075] The UAE layer 311 provides UAE capabilities to the UAS application specific layer 309. The UAE clients 321, 323 provide UAS application layer support functions to the UAS application specific clients 315, 317 over the Uc reference point. The UAE server 325 provides UAS application layer support functions to the UAS application specific server 319 over the Us reference point.

[0076] In the UAE layer 311, the UAE client 323 of the second UAS UE 303 communicates with the UAE client 321 of the first UAS UE 301 over the U5-AE reference point. The UAE clients 321, 323 communicate with the UAE server 325 over the U1-AE reference point. To support distributed UAE server deployment, the UAE server 325 interacts with another UAE server 325 over the UAE-E reference point. The UAE server 325 interacts with the 3GPP network system over the U2, MB2, xMB, Rx, T8, and Nnef reference points.

[0077] The U1-AE message may be sent at least via unicast, transparent multicast via xMB or transparent multicast via MB2. Non-transparent multicast via xMB (as specified in 3GPP TS 26.348) is triggered by the U1-AE message. Multicast delivery may be supported by both transparent and non-transparent multicast modes.

[0078] The UAE clients 321, 323 interact with the SEAL clients 327, 329 via a SEAL-C reference point designated for each SEAL service. The UAE server 325 interacts with the SEAL server 331 via a SEAL-S reference point designated for each SEAL service. The interaction between the SEAL clients 327 and 329 is supported by a SEAL-PC5 reference point designated for each SEAL service. The interaction between the SEAL clients 327, 329 and the corresponding SEAL server 331 is supported by a SEAL-UU reference point designated for each SEAL service. It should be noted that the SEAL-C, SEAL-S, SEAL-PC5, and SEAL-UU reference points for each SEAL service are specified in 3GPP TS 23.434.

[0079] The SEAL services utilized by the UAE layer 311 may include location management, group management, configuration management, identity management, key management, and network resource management. In some deployments, the SEAL client and server entities 327, 329, and 331 may be part of the UAE clients 321, 323 and UAE server 325, respectively.

[0080] The UAE and SEAL layers 311, 313 provide support functions for the UAS that act as a middleware logical entity between the UTM / USS (e.g., UAS Application Server 305) and the underlying 3GPP network. SEAL is a common set of functions (including location management, network resource management, configuration management, ...) that may support the UTM / USS to simplify and optimize interaction with the network.

[0081] FIG. 4 shows a procedure 400 for managing QoS guarantees for C2 communication. The procedure 400 is executed by a control unit 405, which may take the form of an application function (AF) and / or a vertical enabler server. The procedure 400 assumes that both the UAV and the UAV-C have established PDU sessions with the same or different PLMNs for C2 communication. To solve the problem of where and how the linking / binding of PDU sessions corresponding to the C2 E2E session should be performed, and further how the provision of QoS per PDU session should be dynamically configured or adapted to ensure the end-to-end achievement of QoS for C2 applications, the procedure 400 executes the following steps:

[0082] In step 1, the control unit 405 receives a request to manage the QoS of the UAS from the UAV's application enabler client (i.e., UAE-C or SEAL-C) or UAV-Controller during the duration of the UAV's flight (see messaging 407). Alternatively, the request to manage the QoS of the UAS may come from the UTM. The request may include an application ID or UAS ID, a UAV ID (PEI / IMEI, GPSI), a PLMN ID, a high definition ("HD") location map, allowed routes for the UAV, C2 KPI requirements, and a mode of command / control.

[0083] In step 2, in response to receiving the request, the control unit 405 performs pairing / association of the UAV, UAV-C session corresponding to the Application ID / UAS ID (see block 409). This pairing / linking can be in the form of a translation of the UAS ID / Application ID to a Group ID, or two (linked) AF-Service-Identifiers (AF-Service-Identifier for the UAV and AF-Service-Identifier for the UAV-C), or two (linked) Session IDs for interaction with the underlying PLMN. As used herein, AF-Service-Identifier refers to the identifier of the service on whose behalf the AF is issuing a request to the 5GC. It is used to describe the traffic of the C2 application in the UE.

[0084] In step 3, upon UAV-UAV-C pairing / association, the control unit 405 acting as the AF subscribes to the PLMN (see messaging 411) to receive QoS monitoring events for both the PDU sessions corresponding to the UAV and the PDU sessions corresponding to the UAV-C, and in particular to receive QoS Notification Control [TS 23.501] when a QoS downgrade is captured in one of the C2 links (failure to meet GBR QoS requirements).

[0085] In step 4, a monitoring event report (i.e., a trigger event) is received at the control unit 405 by the 5GC or, optionally, by an application enabler client of the UAV (see messaging 413). For example, the monitoring event report may indicate a QoS downgrade notification for one of the PDU sessions (e.g., a QoS notification control for a UAV session, or a notification that a QoS flow is downgraded to a lower priority QoS profile).

[0086] In step 5, the control unit 405 requests and receives (messaging 415) supplemental information about the relevant linked session, e.g., UAV-C session, and in particular an indication of the QoS status of the network and access conditions that can be used to identify whether the QoS can be upgraded. This can be provided by the 5GC or by the SEAL / NRx server.

[0087] In step 6, the control unit 405 evaluates / checks whether an adaptation of QoS requirements can be realized for the concerned communication sessions by upgrading the QoS requirements of the PDU sessions not affected by the QoS degradation in order to avoid failing to meet the requirements of the end-to-end C2 application (see block 417). If such an adaptation can be realized, the control unit determines the change of the QoS requirements of the application for each of the UE sessions and triggers for the adaptation of the PCC rules (change of QoS profile) for one or more sessions in the C2 application.

[0088] In step 7, the control unit 405 communicates the determined changes to one or more involved entities (see messaging 419). This entails updating the provisioning of service specific parameters to the PCF / SMF via the NEF such that the QoS profiles for the involved network sessions are different (one is downgraded and one is upgraded).

[0089] Described herein are two cases of communication with the network when a new QoS is determined, namely, the case of notification control with an Alternative QoS profile for the QoS flow (5.7.2.4.1b of 23.501) and the case of notification control without an Alternative QoS profile (5.7.2.4.1b of 23.501). If an Alternative QoS profile is pre-configured by the AF, for the first case, the QoS flow is downgraded to a lower priority QoS on the network side based on the initial configuration (so the control unit only updates the upgraded QoS and does not determine the adaptation of the QoS requirements of the downgraded flow), while for the second case, the control unit determines the updated requirements for both QoS flows corresponding to the two sessions.

[0090] 5A-5B illustrate a procedure 500 for network-triggered collaborative QoS adaptation (a UE-enabled feature) according to an embodiment of the present disclosure. The procedure 500 involves a UAV-C 104 (including one or more application clients and a first UAS UE 501), a UAV 103 (including one or more application clients and a second UAS UE 503), and a service provider domain including a control unit 405 and at least one application server (e.g., a USS and / or a UTM).

[0091] In the illustrated embodiment, the control unit 405 resides in the UAE server or any SEAL server (NRx, CM). First, the application enabler client (UAE-C / SEAL-C) of the UAV or UAV-C sends a request to the application enabler server (UAE-S / SEAL-S) to monitor and manage the QoS of the end-to-end application of C2 communication. This triggers the UAE-S / SEAL-S to join the corresponding PLMN to receive QoS monitoring events for both PDU sessions (the PDU session for the UAV and the PDU session for the UAV-C).

[0092] The QoS monitoring event may be a QoS notification control that alerts for an indication of QoS downgrade to a level where the GBR QoS requirements cannot be met. When the QoS monitoring event is received by the UAE-S / SEAL-S, it checks whether and how the QoS of the other link can be upgraded to meet the end-to-end C2 requirements. If such an upgrade is feasible and can compensate for the QoS downgrade of the other PDU session, updated QoS requirements are sent to the underlying PLMN for one or both sessions. The procedure 500 includes the following steps.

[0093] In step 0, as a prerequisite, the UAS is registered and connected to a PLMN. In the illustrated embodiment, a first UAS UE 501 is connected to a first PLMN 505 and a second UAS UE 503 is connected to a second PLMN 507. The first PLMN 505 and the second PLMN 507 may be the same PLMN and / or different PLMNs. C2 communication is assumed to be indirect / network assisted, and thus two PDU sessions are established respectively. The UAE-S / SEAL-S interacts with the corresponding UAE / SEAL client to establish individual application sessions for application registration and context transfer.

[0094] In step 1a, the control unit 405 (i.e., the UAE / SEAL server) sends a C2 UAE session establishment request message to the UAE / SEAL client of the UAV-C 104 (see messaging 513). In various embodiments, the C2 UAE session establishment request message includes a request to the UAE / SEAL client to send a first report to the control unit 405 when a first condition occurs, and includes at least one of the following: UAS / UAV / UAV-C identification information as in step 1a, a UAE server ID, which may be an FQDN or an IP address, one or more application specific requirements, a geographic area, a session validity period, a transaction ID, the location and capabilities of one or more nearby UAVs, and the location and configuration of the UAV-C.

[0095] In step 1b, the control unit 405 also sends the above-mentioned C2 UAE session establishment request message (see messaging 515) to the UAE / SEAL client of the UAV 103. In response to receiving the request, the UAE / SEAL client returns a C2 UAE session setup response / result message (ACK / NACK) to the control unit 405.

[0096] In step 2, the control unit 405 receives a request from the UAE / SEAL client to manage the QoS of the C2 application session. The requirements message provides the control unit 405 with the capability to manage the C2 communication and includes at least one of the following parameters: UAS Identification Information UAV / UAV-C identification information, which may include at least one of the following: external UE identifier (GPSI, external ID) or permanent device identifier (PEI / IMEI) · IP address and port of the UAV / UAV-C [how is it known?] PLMN ID Application Identifiers (e.g. USS Identifiers), UTM Identifiers C2 control modes (direct stick, stick to waypoints), C2 KPI The geographic area to which the requirement applies Requirement Expiration Date C2 E2E QoS parameters Use of HD video flag, required video resolution / encoding HD Location Maps · Permitted UAV routes

[0097] In step 3, once the control unit 405 receives the necessary authorization and information to manage C2 QoS, it links / pairs the per-UAS request to two corresponding PDU sessions (between UAV-PLMN1 and UAV-C-PLMN2 (or PLMN1)), see block 519. This triggers the translation of UAS ID / Application ID to a Group ID, or two (linked) GPSIs, or two (linked) AF-Service-Identifiers, or two (linked) Session IDs (Session ID for UAV and Session ID for UAV-C). This mapping is stored in the control unit 405 for further interaction with the 5GS.

[0098] In steps 4a / 4b, the control unit 405 acting as AF subscribes to the 5GC / NEF for each AF-service-identifier or session ID of the UAV and UAV-C session (see messaging 521, 523) in order to receive QoS and network monitoring events. In the illustrated embodiment, the procedure 500 shows different PLMNs as possible implementations, but this request may also be possible for a single PLMN. This monitoring information is related to possible QoS downgrades of one or more Uu links (UAV-C-network server or network-UAV). These links may be provided by more than one PLMN. Thus, the UAE server should receive any updated information regarding possible QoS downgrades (this is already supported for EPS by Explicit Congestion Notification (ECN) [e.g. as described in TS 23.401] and for 5GS by QoS Notification Control (QNC) [e.g. as described in TS 23.501]).

[0099] 5B, in step 5a, the UAE / SEAL server control unit 405 receives a trigger event from the 5GC (SMF / NEF) indicating a change in QoS (experienced or expected) (see messaging 525). This message includes at least one of the following parameters: UAV ID Application ID (e.g. C2 App#A) - Expected degraded QoS parameters (latency, reliability, data rate, jitter, ...) Actual degraded QoS parameters (latency, reliability, data rate, jitter, ...) Network status information (per TA / cell area) QoS Profile Downgrade Indication

[0100] In step 5b (optional), a trigger event (see messaging 527) from the UAV's application enabler client indicating a change in the QoS of the application (experienced or expected) that satisfies the trigger condition given in steps 1a / 1b. The criteria for this trigger can be based on packet delay or packet loss experienced on the Uu link (e.g., channel loss > X%), based on the trigger configuration. This message includes at least one of the following parameters: UAV ID Application ID (e.g. C2 App#A) Trigger cause (e.g. QoS degradation, UE context change (location / mobility)) - Expected degraded QoS parameters (latency, reliability, data rate, jitter, ...) Actual degraded QoS parameters (latency, reliability, data rate, jitter, ...) - Predicted / actual location / mobility of the UAV High interference indication (due to multiple BSs)

[0101] It should be noted that the joining of step 4a for UAV-C may be performed before the trigger event (5a / 5b) or after the trigger event, based on the implementation.

[0102] In step 5c, the control unit 405 sends a request to the 5GC (SMF / NEF) to receive supplemental QoS information for UAV-C (see messaging 529). The request includes at least one of the following parameters: ·UAS ID / UAV ID Application ID (e.g. C2 App#A) · Configuring report parameters

[0103] Based on this request, the control unit 405 receives (via N33) a report with the following requested parameters: ·UAS ID / UAV ID Application ID (e.g. C2 App#A) ·UAE / SEAL ID - Expected QoS parameters (latency, reliability, data rate, jitter, ...) Actual QoS parameters (latency, reliability, data rate, jitter, ...) QoS upgrade capability indication

[0104] In step 6, the control unit 405 of the UAE / SEAL server checks the achievement / non-achievement of E2E QoS based on the trigger event and additional information of the UAV-C in response to receiving the report in step 5b (see block 531). This is performed by matching the estimated application QoS per link with the configured E2E application QoS metrics. The control unit 405 of the UAE / SEAL server then decides on an action based on the evaluation of the E2E QoS. This action can be an adaptation of the QoS of both links (QoS profile downgrade for links subject to QoS notification control and QoS upgrade for links that can be upgraded).

[0105] In step 7, the control unit 405 acting as AF sends to the 5GC (to the SMF via the NEF or to the PCF via the N5) a request to change the QoS profile mapped to one or both network sessions (UAV, UAV-C) or to update the PCC rules to apply a new traffic policy (both AF triggered actions are supported in TS 23.501 / 502) (see messaging 533).

[0106] In step 8, the PLMN updates the QoS profile for the corresponding PDU session (see block 535).

[0107] 6A-6B illustrate a procedure 600 for network-triggered collaborative QoS adaptation (a UTM-enabled feature) according to an embodiment of the disclosure. The procedure 600 involves a UAV-C 104 (including one or more application clients and a first UAS UE 501), a UAV 103 (including one or more application clients and a second UAS UE 503), and a service provider domain including a control unit 405 and at least one application server (e.g., a UTM) 509.

[0108] In this embodiment, the control unit 405 resides in the UAE server or any SEAL server (NRx, CM). In step 0, it is assumed as a precondition that the flight of the UAV is ongoing and both the UAV and the UAV-C are connected to the 3GPP network. In the illustrated embodiment, the first UAS UE is connected to a first PLMN and the second UAS UE is connected to a second PLMN. The first PLMN and the second PLMN may be the same PLMN and / or different PLMNs. Here, it is assumed that the C2 communication is indirect / network assisted, and thus two PDU sessions are established respectively. The UAE / SEAL server receives a request from the UTM to manage the C2 QoS of the UAS. Then, the UAE / SEAL server interacts with the 5GC to subscribe to receive reports and triggers related to QoS. Upon receiving a QoS monitoring trigger event for a session (e.g., a UAV session), the UAE / SEAL server obtains supplemental information from the 5GC and determines an action, which may take the form of balancing the QoS within the UAS's C2 communication link.

[0109] In step 1a, the UTM / USS sends a request to manage the QoS of the E2E application of the C2 communication to the control unit 405. The requirement message provides the control unit 405 with the capability to manage the C2 communication and includes at least one of the following parameters: UAS Identification Information UAV / UAV-C identification information, which may include at least one of the following: external UE identifier (GPSI, external ID) or permanent device identifier (PEI / IMEI) PLMN ID Transaction ID for the UAS API call · Application Identifier (e.g. USS Identifier) ·UTM identifier C2 control mode (direct stick, stick to waypoint), C2 KPI The geographic area to which the requirement applies Requirement Expiration Date

[0110] In step 1b, the UAE / SEAL server responds to the UTM / USS with a positive / negative response and may further request additional UAS-related information and other context information. In response to receiving a request for additional UAS-related information, the UTM / USS provides at least one of the following parameters to the UAE / SEAL server: UAV / UAV-C application context / configuration information C2 E2E QoS parameters Use of HD video flag, required video resolution / encoding HD Location Maps · Permitted UAV routes ·Communication / C2 quality assurance indications on configured frequencies for C2 communications Dynamic reroute information (updated / predicted trajectory of the UAV)

[0111] In step 2, once the control unit 405 receives the necessary authorization and information to manage C2 QoS, it links / pairs the per-UAS request to two corresponding PDU sessions (between UAV-PLMN1 and UAV-C-PLMN2 (or PLMN1)). This triggers the translation from UAS ID / Application ID to a Group ID, or two (linked) GPSIs, or two (linked) AF-Service-Identifiers (AF-Service-Identifier for UAV and AF-Service-Identifier for UAV-C), or two Session IDs. This mapping is stored in the control unit 405 for further interaction with the 5GS.

[0112] In step 3a / 3b, the control unit 405 acting as AF (i.e., UAE / SEAL server) subscribes to the 5GC / NEF for each session ID or AF-service-identifier of UAV and UAV-C sessions in order to receive QoS and network monitoring events. Although Fig. 6 shows different PLMNs as possible implementations, this subscription request is also possible for a single PLMN. This monitoring information is related to possible QoS downgrades of one or more Uu links (UAV-C-Network Server or Network-UAV). These links may be provided by more than one PLMN. Thus, the UAE server should receive any updated information regarding possible QoS downgrades (this is already supported for EPS by Explicit Congestion Notification (ECN) [e.g., as described in TS 23.401] and for 5GS by QoS Notification Control (QNC) [e.g., as described in TS 23.501]).

[0113] 6B, in step 4a, the UAE / SEAL server control unit 405 receives a trigger event from the 5GC (SMF / NEF) indicating a change in QoS (experienced or expected) (see messaging 613). This message includes at least one of the following parameters: UAV ID Application ID (e.g. C2 App#A) - Expected degraded QoS parameters (latency, reliability, data rate, jitter, ...) Actual degraded QoS parameters (latency, reliability, data rate, jitter, ...) Network status information (e.g. per TA / cell area) QoS Profile Downgrade Indication

[0114] In step 4b, the control unit 405 of the UAE / SEAL server sends a request to the 5GC (SMF / NEF) to receive supplemental QoS information about the UAV-C (see messaging 615). The request includes at least one of the following parameters: ·UAS ID / UAV ID Application ID (e.g. C2 App#A) · Configuring report parameters

[0115] Based on this request, the UAE / SEAL server control unit 405 receives (via N33) a report with the following requested parameters: ·UAS ID / UAV ID Application ID (e.g. C2 App#A) ·UAE / SEAL ID - Expected degraded QoS parameters (latency, reliability, data rate, jitter, ...) Actual QoS parameters (latency, reliability, data rate, jitter, ...) QoS upgrade capability indication

[0116] In step 5, the control unit 405 of the UAE / SEAL server checks the achievement / non-achievement of E2E QoS based on the trigger event and additional information of the UAV-C in response to receiving the report in step 4c (see block 617). This is performed by matching the estimated application QoS per link with the configured E2E application QoS metrics. The control unit of the UAE / SEAL server then decides on an action based on the evaluation of the E2E QoS. This action can be an adaptation of the QoS of both links (QoS profile downgrade for links subject to QoS notification control and QoS upgrade for links that can be upgraded).

[0117] In step 6, the control unit 405 of the UAE / SEAL server acting as AF sends a request to the 5GC (via NEF to SMF or via N5 to PCF) to change the QoS profile mapped to one or both network sessions (UAV, UAV-C) or to update the PCC rules to apply a new traffic policy (actions triggered by both AFs are supported in TS 23.501 / 502) (see messaging 619).

[0118] In step 7, the PLMN updates the QoS profile for the corresponding PDU session (see block 621).

[0119] 7 illustrates a procedure 700 for achieving end-to-end QoS according to an embodiment of the present disclosure. The procedure 700 involves UAV-C 104 (including one or more application clients and a first UAS UE 501), UAV 103 (including one or more application clients and a second UAS UE 503), and a UAS enabler server ("UAE-S") 133. This embodiment is another alternative solution that does not require capability initialization in the UAE server / AF.

[0120] In step 0, as a prerequisite, it is assumed that the UAV flight is ongoing and both UAV 103 and UAV-C 104 are connected to a 3GPP network (same or different PLMN) (see block 701). Here, it is assumed that C2 communication is indirect / network-assisted, and therefore two PDU sessions are established respectively.

[0121] In step 1, UAV 103 and UAV-C 104 establish a session with the same UAE-S 133 (see messaging 703).

[0122] In step 2, the UAE-S 133 (AF) sends a Npcf_PolicyAuthorization_Create request (see messaging 705) to the PCF handling the PDU session of the UAV 103 in PLMN2 507. The request indicates that the UL QoS attributes (e.g., packet delay, packet error rate) and DL QoS attributes (e.g., packet delay, packet error rate) between the UAV 103 and the UPF of PLMN2 507 should be monitored, and when the QoS attributes exceed thresholds, notify the UAS enabler server 133 (e.g., as described in TS 29.514).

[0123] In step 3, the UAE-S 133 sends the same Npcf_PolicyAuthorization_Create request to the PCF handling the PDU session of the UAV-C 104 in PLMN1 505 (see messaging 707).

[0124] In step 4, based on the above Npcf_PolicyAuthorization_Create request, the PCF creates a PCC rule matching the C2 traffic, including "QoS Monitoring for URLLC", which indicates that the UL QoS attributes (e.g., packet delay, packet error rate) and DL QoS attributes (e.g., packet delay, packet error rate) of the C2 traffic should be measured and send a report when they exceed a threshold. In response, the SMF sends a QoS monitoring request to the NG-RAN and UPF (see block 709).

[0125] In step 5, when UL and / or DL ​​QoS attributes (e.g., packet delay, packet error rate) of the C2 communication exceed a threshold, the SMF sends (either directly or via the PCF) a report to the UAE-S 133 (see messaging 711). Based on this report, the UAE-S 133 can determine when the delay of C2 packets to / from the UAV 103 exceeds a threshold and when the delay of C2 packets to / from the UAV-C 104 exceeds a threshold.

[0126] In step 6, if the QoS attributes (e.g., packet delay, packet error rate) to / from UAV 103 exceed a threshold, the AF may request the PCF handling the PDU session of UAV-C 104 to adapt the QoS to / from UAV-C 104 (reducing C2 packet delay) so that the overall C2 QoS (end-to-end packet delay) between the UAV and UAC-C remains within an acceptable QoS (e.g., 40 ms) (see messaging 713).

[0127] In step 7, the PLMN updates the QoS profile for the corresponding PDU session (see block 715).

[0128] FIG. 8 illustrates a user equipment device 800 that may be used for achieving end-to-end QoS according to embodiments of the present disclosure. In various embodiments, the user equipment 800 is used to implement one or more of the solutions described above. The user equipment 800 may be an embodiment of a UAE client and its supporting hardware, such as the UAV 103, UAV controller 104, UAV 201, UAV-C 203, UAE client 205, UAE client 301, and / or UAE client 305 described above. Additionally, the user equipment 800 may include a processor 805, a memory 810, an input device 815, an output device 820, and a transceiver 825. In some embodiments, the input device 815 and the output device 820 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment 800 may not include any input device 815 and / or output device 820. In various embodiments, the user equipment 800 may include one or more of a processor 805 , a memory 810 , and a transceiver 825 , but may not include an input device 815 and / or an output device 820 .

[0129] The processor 805, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 805 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, the processor 805 executes instructions stored in memory 810 to perform the methods and routines described herein. The processor 805 is communicatively coupled to the memory 810, the input device 815, the output device 820, and the transceiver 825.

[0130] In various embodiments, the processor 805 controls the user equipment 800 to implement the UAS UE and / or UAE client behaviors described above.

[0131] Memory 810, in one embodiment, is a computer-readable storage medium. In some embodiments, memory 810 includes a volatile computer storage medium. For example, memory 810 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 810 includes a non-volatile computer storage medium. For example, memory 810 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 810 includes both volatile and non-volatile computer storage media.

[0132] In some embodiments, memory 810 stores data related to achieving end-to-end QoS. For example, memory 810 may store policies, parameters, etc. In certain embodiments, memory 810 also stores program code and associated data, such as operating systems or other controller algorithms running on UAV 103 and / or UAV-C 104.

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

[0134] The output device 820 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 820 includes 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 display, 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, other parts of the user equipment 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 table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0135] In certain embodiments, the output device 820 includes one or more speakers for producing sound. For example, the output device 820 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 820 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device 820 may be integrated with the input device 815. For example, the input device 815 and the output device 820 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device 820 may be located near the input device 815.

[0136] As discussed above, the transceiver 825 communicates with one or more UAVs / UAV-Cs. The transceiver 825 operates under the control of the processor 805 to transmit messages, data, and other signals and to receive messages, data, and other signals. For example, the processor 805 may selectively activate the transceiver (or a portion thereof) at particular times to transmit and receive messages.

[0137] In various embodiments, the transceiver 825 is configured to communicate with a 3GPP access network and / or a non-3GPP access network. In some embodiments, the transceiver 825 implements modem functionality for a 3GPP access network and / or a non-3GPP access network. In one embodiment, the transceiver 825 implements multiple logical transceivers that use different communication protocols or protocol stacks while using common physical hardware.

[0138] In one embodiment, the transceiver 825 includes 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. In a particular embodiment, the first transmitter / receiver pair used to communicate with a mobile communication network over a licensed radio spectrum and the second transmitter / receiver pair used to communicate with a mobile communication 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. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, a particular transceiver 825, transmitter 830, and receiver 835 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 840.

[0139] The transceiver 825 may include one or more transmitters 830 and one or more receivers 835. Although a particular number of transmitters 830 and receivers 835 are illustrated, the user equipment device 800 may have any suitable number of transmitters 830 and receivers 835. Moreover, the transmitters 830 and receivers 835 may be any suitable type of transmitters and receivers. In particular embodiments, one or more transmitters 830 and / or one or more receivers 835 may share transceiver hardware and / or circuitry. For example, one or more transmitters 830 and / or one or more receivers 835 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, etc.

[0140] In various embodiments, the transceiver 825 can communicate with the mobile core network via an access network. Thus, the transceiver 825 may support at least one network interface 840. Here, the at least one network interface 840 facilitates communication with a RAN node, such as an eNB or a gNB, using, for example, a "Uu" interface (e.g., LTE-Uu for eNB, NR-Uu for gNB). Additionally, the at least one network interface 840 may include an interface used for communication with one or more network functions in the mobile core network, such as the UPF 141, the AMF 143, and / or the SMF 145. With respect to UAS communication, the transceiver 825 may support a PC5 interface for direct C2 communication. The transceiver 825 and / or the processor 805 may support one or more application interfaces 845. Via the application interface 845, the user equipment device may transmit QoS monitoring events, such as application QoS downgrade reports.

[0141] In various embodiments, one or more transmitters 830 and / or one or more receivers 835 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. In certain embodiments, one or more transmitters 830 and / or one or more receivers 835 may be implemented and / or integrated in a multi-chip module. In some embodiments, other components, such as a network interface 840 or other hardware components / circuits, may be integrated in a single chip with any number of transmitters 830 and / or receivers 835. In such embodiments, the transmitters 830 and receivers 835 may be logically configured as a transceiver 825 using one or more common control signals, or as modular transmitters 830 and receivers 835 implemented in the same hardware chip or multi-chip module. In particular embodiments, the transceiver 825 may implement a 3GPP modem (e.g., for communicating over an NR or LTE access network) and a non-3GPP modem (e.g., for communicating over a Wi-Fi or other non-3GPP access network).

[0142] FIG. 9 illustrates an embodiment of a network equipment device 900 that may be used to achieve end-to-end QoS according to an embodiment of the present disclosure. In some embodiments, the network equipment device 900 may be an embodiment of the UAE server 133, SEAL server 135, UAE server / SEAL server / UCF 210, and / or a control unit such as the control unit 405 described above and its supporting hardware. Additionally, the network equipment device 900 may include a processor 905, a memory 910, an input device 915, an output device 920, a transceiver 925, and an application interface 945. In some embodiments, the input device 915 and the output device 920 are combined into a single device such as a touch screen. In certain embodiments, the network equipment device 900 does not include any input device 915 and / or output device 920.

[0143] As shown, the transceiver 925 includes at least one transmitter 930 and at least one receiver 935, where the transceiver 925 communicates with one or more remote units 105. Additionally, the transceiver 925 may support at least one network interface 940 and / or application interface 945. In some embodiments, the transceiver 925 supports an interface (e.g., an Nnef interface) for communicating with a NEF (i.e., the NEF 127). As will be appreciated by one of ordinary skill in the art, other network interfaces may be supported.

[0144] The processor 905, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 905 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 905 executes instructions stored in the memory 910 to perform the methods and routines described herein. The processor 905 is communicatively coupled to the memory 910, the input device 915, the output device 920, and the first transceiver 925.

[0145] In various embodiments, the processor 905 controls the network equipment device 900 to implement the UAE client behavior described above. For example, via the application interface 945, the processor 905 may receive a request to manage QoS of an end-to-end application session, where the end-to-end application session includes a first session of a first UE connected to a first network and a second session of a second UE connected to a second network.

[0146] In some embodiments, the request is received from an application executing on one of the first UE and the second UE. In other embodiments, the request is received from a UTM. In certain embodiments, the first network and the second network include the same network (i.e., the same PLMN).

[0147] In some embodiments, the first session includes a first application session and the second session includes a second application session. In some embodiments, the first session includes a first network session and the second session includes a second network session. In a particular embodiment, the first UE includes a UAV-C and the second UE includes a UAV.

[0148] In some embodiments, the end-to-end application session supports C2 communications and has C2 requirements, which consist of one or more of the following parameters: UAS identity, UAV identity, UAV-C identity, at least one PLMN ID, a transaction ID for the UAS API call, an application identifier (e.g., USS identifier), a UTM identifier, a C2 control mode (e.g., direct stick, stick to waypoint), one or more C2 KPIs, a geographic area to which the requirement applies, an expiration date for the requirement, an application context of at least one of the UAV and UAV-C, configuration information of at least one of the UAV and UAV-C, at least one C2 end-to-end QoS parameter, a flag indicating use of HD video to support C2, video resolution / encoding required for HD video, an HD location map to support C2, and an allowed route for the UAV.

[0149] The processor 905 configures first QoS parameters for the first session of the first UE and second QoS parameters for the second session of the second UE. In a particular embodiment, the configuration is provided to the first UE and the second UE by establishing an application session between the apparatus and the first UE and the second UE.

[0150] In some embodiments, the configuration further includes at least one mapping for the sessions of the first UE and the second UE, the mappings including at least one of: a mapping of a UAS ID to a group ID, a mapping of an application ID to a group ID, a mapping of a UAS ID to two (linked) GPSIs, a mapping of an application ID to two (linked) GPSIs, a mapping of a UAS ID to two (linked) AF-service-identifiers or two (linked) session IDs, a mapping of an application ID to two (linked) AF-service-identifiers or two (linked) session IDs, and a mapping of a service API to a control API for the application sessions of the first UE and the second UE, where the service API is received by the UTM and / or USS for each UAS.

[0151] The processor 905 receives a triggering event related to a change in the QoS of the second QoS parameter, hi some embodiments, the triggering event includes a downgrade indication of the second QoS parameter.

[0152] In some embodiments, the trigger event includes at least one of the following parameters: application ID (e.g., C2 App#A), predicted degraded QoS parameters (latency, reliability, data rate, jitter, ...), actual degraded QoS parameters (latency, reliability, data rate, jitter, ...), predicted location of the UAV, actual location of the UAV, mobility information of the UAV, high interference indication, network status information (per TA / cell area), QoS profile downgrade indication, indication of RAN congestion and / or overload condition, and QoS upgrade indication for the QoS flow.

[0153] In some embodiments, the processor 905 obtains supplemental QoS and / or UE context information regarding the second application session of the second UE, the supplemental information including at least one of one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more actual QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), a QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0154] The processor 905 determines a third QoS parameter for the first session of the first UE based on the QoS change of the second QoS parameter and communicates the third QoS parameter to the first network.

[0155] In some embodiments, the processor 905 determines a fourth QoS parameter for the second application session of the second UE based on the QoS change of the second QoS parameter and communicates the fourth QoS parameter to the second network. In a particular embodiment, the third QoS parameter is an upgrade of the first QoS parameter and the fourth QoS parameter is a downgrade of the second QoS parameter. In other embodiments, the third QoS parameter is a downgrade of the first QoS parameter and the fourth QoS parameter is an upgrade of the second QoS parameter.

[0156] In some embodiments, the determination of the third QoS parameter and the fourth QoS parameter is mapped to a traffic policy / PCC rule update and / or a QoS profile update of the network for the first UE and the second UE. In some embodiments, communicating the third parameter includes sending a QoS profile change request to the first network (e.g., to a PCF or SMF of the first network). Similarly, in some embodiments, communicating the fourth parameter includes sending a QoS profile change request to the second network (e.g., to a PCF or SMF of the second network).

[0157] Memory 910, in one embodiment, is a computer-readable storage medium. In some embodiments, memory 910 includes a volatile computer storage medium. For example, memory 910 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 910 includes a non-volatile computer storage medium. For example, memory 910 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 910 includes both volatile and non-volatile computer storage media. In some embodiments, memory 910 stores data related to the selection of a server application instance, e.g., server addresses, location of the UE, DNS cache, etc. In certain embodiments, memory 910 also stores program code and associated data, such as an operating system ("OS") or other controller algorithms and one or more software applications operating on network equipment device 900.

[0158] The input device 915, in one embodiment, may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 915 may be integrated with the output device 920, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device 915 includes a touch screen, such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 915 includes two or more different devices, such as a keyboard and a touch panel.

[0159] The output device 920, in one embodiment, may include any known electronically controllable display or display device. The output device 920 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 920 includes an electronic display capable of outputting visual data to a user. For example, the output device 920 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 920 may include a wearable display, such as a smart watch, smart glasses, a head-up display, etc. Additionally, the output device 920 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0160] In certain embodiments, the output device(s) 920 include one or more speakers for producing sound. For example, the output device(s) 920 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device(s) 920 include one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device(s) 920 may be integrated with the input device(s) 915. For example, the input device(s) 915 and the output device(s) 920 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or a portion of the output device(s) 920 may be located proximate the input device(s) 915.

[0161] As discussed above, the transceiver 925 may communicate with one or more remote units and / or with one or more interconnection functions that provide access to one or more PLMNs. The transceiver 925 may communicate with one or more network functions (e.g., in the mobile core network 120). The transceiver 925 operates under the control of the processor 905 to transmit messages, data, and other signals and to receive messages, data, and other signals. For example, the processor 905 may selectively activate the transceiver (or a portion thereof) at certain times to transmit and receive messages.

[0162] The transceiver 925 may include one or more transmitters 930 and one or more receivers 935. In certain embodiments, the one or more transmitters 930 and / or the one or more receivers 935 may share transceiver hardware and / or circuitry. For example, the one or more transmitters 930 and / or the one or more receivers 935 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, etc. In one embodiment, the transceiver 925 implements multiple logical transceivers that use different communication protocols or protocol stacks while using common physical hardware.

[0163] 10 illustrates one embodiment of a method 1000 for achieving end-to-end QoS in accordance with an embodiment of the present disclosure. In various embodiments, the method 1000 is performed by a control unit, such as the UAE server 133, SEAL server 135, UAE server / SEAL server / UCF 210, control unit 405, and / or network equipment device 900 described above. In some embodiments, the method 1000 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0164] The method 1000 begins by receiving (1005) a request to manage QoS of an end-to-end application session, where the end-to-end application session includes a first session of a first UE connected to a first network and a second session of a second UE connected to a second network. The method 1000 includes configuring (1010) a first QoS parameter for the first session of the first UE and a second QoS parameter for the second session of the second UE. The method 1000 includes receiving (1015) a trigger event associated with a QoS change of the second QoS parameter. The method 1000 includes determining (1020) a third QoS parameter for the first session of the first UE based on the QoS change of the second QoS parameter. The method 1000 includes communicating (1025) the third QoS parameter to the first network. The method 1000 ends.

[0165] Disclosed herein is a first apparatus for achieving end-to-end QoS according to an embodiment of the present disclosure. The first apparatus may be implemented by a control unit, such as the UAE server 133, the SEAL server 135, the UAE server / SEAL server / UCF 210, the control unit 405, and / or the network equipment device 900. The first apparatus includes an interface for receiving a request to manage QoS of an end-to-end application session, where the end-to-end application session includes a first session of a first UE connected to a first network and a second session of a second UE connected to a second network. A processor configures a first QoS parameter for the first session of the first UE and a second QoS parameter for the second session of the second UE, and receives a trigger event associated with a change in QoS of the second QoS parameter. The processor determines a third QoS parameter for the first session of the first UE based on the change in QoS of the second QoS parameter, and communicates the third QoS parameter to the first network.

[0166] In certain embodiments, the first network and the second network comprise the same network (e.g., the same PLMN). In some embodiments, the first session comprises a first application session and the second session comprises a second application session. In other embodiments, the first session comprises a first network session and the second session comprises a second network session.

[0167] In some embodiments, the end-to-end application session supports C2 communications and has C2 requirements, which consist of one or more of the following parameters: UAS identity, UAV identity, UAV-C identity, at least one PLMN ID, a transaction ID for the UAS API call, an application identifier (e.g., USS identifier), a UTM identifier, a C2 control mode (e.g., direct stick, stick to waypoint), one or more C2 KPIs, a geographic area to which the requirement applies, an expiration date for the requirement, an application context of at least one of the UAV and UAV-C, configuration information of at least one of the UAV and UAV-C, at least one C2 end-to-end QoS parameter, a flag indicating use of HD video to support C2, video resolution / encoding required for HD video, an HD location map to support C2, and an allowed route for the UAV.

[0168] In certain embodiments, the first UE includes a UAV-C and the second UE includes a UAV. In some embodiments, the request is received from an application executing on one of the first UE and the second UE. In other embodiments, the request is received from a UTM.

[0169] In some embodiments, the configuration further includes at least one mapping for the sessions of the first UE and the second UE, the mapping including at least one of: a mapping of a UAS ID to a group ID, a mapping of an application ID to a group ID, a mapping of a UAS ID to two (linked) GPSIs, a mapping of an application ID to two (linked) GPSIs, a mapping of a UAS ID to two (linked) AF-service-identifiers or two (linked) session IDs, a mapping of an application ID to two (linked) AF-service-identifiers or two (linked) session IDs, and a mapping of a service API to a control API for the application sessions of the first UE and the second UE, the service API being received by the UTM and / or USS for each UAS. In a particular embodiment, the configuration is provided to the first UE and the second UE by establishing an application session between the device and the first UE and the second UE.

[0170] In some embodiments, the triggering event includes a downgrade indication of the second QoS parameter. In some embodiments, the triggering event includes at least one of the following parameters: application ID (e.g., C2 App#A), predicted degraded QoS parameters (latency, reliability, data rate, jitter, ...), actual degraded QoS parameters (latency, reliability, data rate, jitter, ...), predicted location of the UAV, actual location of the UAV, mobility information of the UAV, high interference indication, network status information (per TA / cell area), QoS profile downgrade indication, indication of RAN congestion and / or overload condition, and QoS upgrade indication for the QoS flow.

[0171] In some embodiments, the processor obtains supplemental QoS and / or UE context information regarding the second application session of the second UE, the supplemental information including at least one of one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more actual QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), a QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0172] In some embodiments, the processor determines a fourth QoS parameter for the second application session of the second UE based on the QoS change of the second QoS parameter and communicates the fourth QoS parameter to the second network. In such embodiments, the third QoS parameter is an upgrade of the first QoS parameter and the fourth QoS parameter is a downgrade of the second QoS parameter. In certain embodiments, the third QoS parameter is a downgrade of the first QoS parameter and the fourth QoS parameter is an upgrade of the second QoS parameter.

[0173] In some embodiments, the determination of the third QoS parameter and the fourth QoS parameter is mapped to a traffic policy / PCC rule update and / or a QoS profile update of the network for the first UE and the second UE. In some embodiments, communicating the fourth parameter includes sending a QoS profile change request to the second network (e.g., to a PCF or SMF). In some embodiments, communicating the third parameter includes sending a QoS profile change request to the first network (e.g., to a PCF or SMF).

[0174] Disclosed herein is a first method for achieving end-to-end QoS according to an embodiment of the present disclosure. The first method may be performed by a control unit, such as the UAE server 133, the SEAL server 135, the UAE server / SEAL server / UCF 210, the control unit 405, and / or the network equipment device 900. The first method includes receiving a request to manage QoS of an end-to-end application session, where the end-to-end application session includes a first session of a first UE connected to a first network and a second session of a second UE connected to a second network. The method includes configuring a first QoS parameter for the first session of the first UE and a second QoS parameter for the second session of the second UE, and receiving a trigger event associated with a change in QoS of the second QoS parameter. The method includes determining a third QoS parameter for the first session of the first UE based on the change in QoS of the second QoS parameter, and communicating the third QoS parameter to the first network.

[0175] In certain embodiments, the first network and the second network comprise the same network (e.g., the same PLMN). In some embodiments, the first session comprises a first application session and the second session comprises a second application session. In other embodiments, the first session comprises a first network session and the second session comprises a second network session.

[0176] In some embodiments, the end-to-end application session supports C2 communications and has C2 requirements, which consist of one or more of the following parameters: UAS identity, UAV identity, UAV-C identity, at least one PLMN ID, a transaction ID for the UAS API call, an application identifier (e.g., USS identifier), a UTM identifier, a C2 control mode (e.g., direct stick, stick to waypoint), one or more C2 KPIs, a geographic area to which the requirement applies, an expiration date for the requirement, an application context of at least one of the UAV and UAV-C, configuration information of at least one of the UAV and UAV-C, at least one C2 end-to-end QoS parameter, a flag indicating use of HD video to support C2, video resolution / encoding required for HD video, an HD location map to support C2, and an allowed route for the UAV.

[0177] In certain embodiments, the first UE includes a UAV-C and the second UE includes a UAV. In some embodiments, the request is received from an application executing on one of the first UE and the second UE. In other embodiments, the request is received from a UTM.

[0178] In some embodiments, the configuration further includes at least one mapping for the sessions of the first UE and the second UE, the mapping including at least one of: a mapping of a UAS ID to a group ID, a mapping of an application ID to a group ID, a mapping of a UAS ID to two (linked) GPSIs, a mapping of an application ID to two (linked) GPSIs, a mapping of a UAS ID to two (linked) AF-service-identifiers or two (linked) session IDs, a mapping of an application ID to two (linked) AF-service-identifiers or two (linked) session IDs, and a mapping of a service API to a control API for the application sessions of the first UE and the second UE, the service API being received by the UTM and / or the USS for each UAS. In a particular embodiment, a request to manage QoS of an end-to-end application session is received at the control unit, and the configuration is provided to the first UE and the second UE by establishing the application sessions between the control unit and the first UE and the second UE.

[0179] In some embodiments, the triggering event includes a downgrade indication of the second QoS parameter. In some embodiments, the triggering event includes at least one of the following parameters: application ID (e.g., C2 App#A), predicted degraded QoS parameters (latency, reliability, data rate, jitter, ...), actual degraded QoS parameters (latency, reliability, data rate, jitter, ...), predicted location of the UAV, actual location of the UAV, mobility information of the UAV, high interference indication, network status information (per TA / cell area), QoS profile downgrade indication, indication of RAN congestion and / or overload condition, and QoS upgrade indication for the QoS flow.

[0180] In some embodiments, the processor obtains supplemental QoS and / or UE context information regarding the second application session of the second UE, the supplemental information including at least one of one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more actual QoS parameters (e.g., latency, reliability, data rate, jitter, ...), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), a QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0181] In some embodiments, the first method further includes determining a fourth QoS parameter for the second application session of the second UE based on the QoS change of the second QoS parameter and communicating the fourth QoS parameter to the second network. In such embodiments, the third QoS parameter is an upgrade of the first QoS parameter and the fourth QoS parameter is a downgrade of the second QoS parameter. In a particular embodiment, the third QoS parameter is a downgrade of the first QoS parameter and the fourth QoS parameter is an upgrade of the second QoS parameter.

[0182] In some embodiments, the determination of the third QoS parameter and the fourth QoS parameter is mapped to a traffic policy / PCC rule update and / or a QoS profile update of the network for the first UE and the second UE. In some embodiments, communicating the fourth parameter includes sending a QoS profile change request to the second network (e.g., to a PCF or SMF). In some embodiments, communicating the third parameter includes sending a QoS profile change request to the first network (e.g., to a PCF or SMF).

[0183] The embodiments may be embodied in other specific forms. The described embodiments 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 which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0184] 100 Wireless communication system 101 Unmanned Aircraft Systems (UAS) 102 UAS Operator 103 Unmanned Aerial Vehicle (UAV) 104 UAV Controller (UAV-C) 105 Remote Unit 110 Access Network 111 Base Unit 115 Access Network 117 Base Unit 120 Mobile Core Network, Core Network 121 User Plane Function (UPF) 123 Access and Mobility Management Function (AMF) 125 Session Management Facility (SMF) 127 Network Published Function (NEF) 129 UAV Control Function (UCF) 130 Data Network 131 UTM 133 UAE Server 135 Service Enabler Application Layer (SEAL) Server 200 Network Architecture 201 UAV 203 UAV-C 205 UTM / USS, UAE client 210 UAE Server / SEAL Server / UCF 215 5GS, 5GC 220 UAE Clients / SEAL Clients 225 UAE / SEAL Session 230 Network connection, network session 235 C2 Applications 240 UAE Clients / SEAL Clients 245 UAE / SEAL Session 250 network connections, network sessions 255 C2 Applications 260 Application-Specific End-to-End ("E2E") Sessions 265 Instructions / Waypoints 270 Video Data 300 UAS Application Layer Functional Model 301 1st UAS UE, UAE client 303 Second UAS UE 305 UAS Application Server 307 3GPP Network System 309 UAS Application Specific Layer 311 UAE layer 313 SEAL layer 315 UAS Application Specific Client 317 UAS Application Specific Client 319 UAS Application Specific Server 321 UAE clients 323 UAE clients 325 UAE server 327 SEAL Client 329 SEAL Client 331 SEAL Server 400 Steps 405 Control Unit 500 steps 501 First UAS UE 503 Second UAS UE 505 1st PLMN 507 Second PLMN 509 Application Server 600 steps 700 steps 800 User Equipment Device 805 Processor 810 Memory 815 Input Devices 820 Output Device 825 Transceiver 830 Transmitter 835 Receiver 840 Network Interface 845 Application Interface 900 Network Equipment 905 Processor 910 Memory 915 Input Devices 920 Output Device 925 Transceiver 930 Transmitter 935 Receiver 940 Network Interface 945 Application Interface 1000 ways

Claims

1. receiving a request to manage quality of service ("QoS") of an end-to-end application session, the end-to-end application session including a first session of a first user equipment ("UE") connected to a first network and a second session of a second UE connected to a second network; configuring one or more first QoS parameters for the first session of the first UE and one or more second QoS parameters for the second session of the second UE; receiving an indication of a QoS change to at least one of the one or more second QoS parameters for the second session; performing QoS adaptation for at least one of the one or more first QoS parameters for the first session based on the QoS change to the at least one of the one or more second QoS parameters; and communicating the QoS adaptation for the first session.

2. The method of claim 1 , wherein the first network and the second network comprise the same network.

3. The method of claim 1 , wherein the first session comprises a first application session and the second session comprises a second application session.

4. 2. The method of claim 1, wherein the first session comprises a first network session and the second session comprises a second network session.

5. The end-to-end application session supports command and control ("C2") communications and has C2 requirements, the C2 requirements being: Unmanned Aircraft System ("UAS") identification information; Unmanned Aerial Vehicle ("UAV") identification information; The identity of the UAV Controller ("UAV-C"); At least one Public Land Mobile Network Identifier ("PLMN ID"); A transaction identifier for the UAS application programming interface ("API") call; Application Identifier, UAS Traffic Manager ("UTM") identifier, C2 control mode, One or more C2 Key Performance Indicators; the geographic area to which said requirements apply; The validity period of said requirements; an application context of at least one of the UAV and the UAV-C; Configuration information of at least one of the UAV and the UAV-C; at least one end-to-end QoS parameter of C2; A flag indicating the use of high definition ("HD") video to aid C2; the video resolution / encoding required for said HD video, HD location maps to aid C2, as well as The method of claim 1 , comprising one or more of the permitted routes for the UAV.

6. The method of claim 5 , wherein the first UE includes the UAV-C and the second UE includes the UAV.

7. The method of claim 1 , wherein the request is received from an application executing on one of the first UE and the second UE.

8. 2. The method of claim 1, wherein the request is received from a UAS traffic manager ("UTM").

9. The configuration further includes at least one mapping for the session of the first UE and the second UE, the mapping comprising: Mapping UAS IDs to group IDs, A mapping of application IDs to group IDs; Mapping UAS ID to two GPSIs, A mapping of the application ID to the two GPSIs; Mapping of the UAS ID to two AF-Service-Identifiers or two Session IDs, Mapping the application ID to the two AF-service-identifiers or the two session IDs; and 2. The method of claim 1, comprising at least one of a mapping of service APIs to control APIs for the application sessions of the first UE and the second UE, the service APIs being received by a UAS Traffic Manager ("UTM") and / or a UAS Service Supplier ("USS") for each UAS.

10. 10. The method of claim 9, wherein the request to manage the QoS of an end-to-end application session is received at a control unit, and the configuration is provided to the first UE and the second UE by establishing an application session between the control unit and the first UE and the second UE.

11. The method of claim 1 , wherein the indication of the change in QoS comprises a downgrade indication to the at least one of the one or more second QoS parameters.

12. The following parameters: Application ID, the predicted degraded QoS parameters, Actual degraded QoS parameters, the predicted location of unmanned aerial vehicles ("UAVs"); the actual location of the UAV; UAV mobility information, High interference indication, Network status information, QoS profile downgrade indication, Indication of congestion and / or overload conditions of the RAN; and The change in QoS is associated with the indication of the change in QoS, the indication including at least one of a QoS upgrade indication for a QoS flow. The method of claim 1.

13. The method further comprises obtaining supplemental QoS and / or UE context information for a second application session comprised in the second session, the supplemental information comprising: one or more predicted QoS parameters; one or more actual QoS parameters, one or more predicted QoE parameters; one or more actual QoE parameters; QoS upgrade capability indication, location information of the second UE; and The method of claim 1 , further comprising at least one of the mobility information of the second UE.

14. performing QoS adaptation for the at least one of the one or more second QoS parameters for the second session based on the QoS change to the at least one of the one or more second QoS parameters; and communicating the QoS adaptation for the second session.

15. The method described in claim 14, wherein the QoS adaptation for the first session is an upgrade to at least one of the one or more first QoS parameters, and the QoS adaptation for the second session is a downgrade to at least one of the one or more second QoS parameters.

16. A method as described in claim 14, wherein at least one of the one or more first QoS parameters and at least one of the one or more second QoS parameters are mapped to a traffic policy, a PCC rule update, or a network QoS profile update for the first UE and the second UE.

17. 15. The method of claim 14, wherein communicating the QoS adaptation for the second session comprises sending a QoS profile change request to the second network.

18. 2. The method of claim 1, wherein communicating the QoS adaptation for the first session comprises sending a QoS profile change request to the first network.

19. an interface for receiving requests to manage quality of service ("QoS") of end-to-end application sessions, the end-to-end application sessions including a first session of a first user equipment device ("UE") connected to a first network and a second session of a second UE connected to a second network; a processor, the processor comprising: configuring one or more first QoS parameters for the first session of the first UE and one or more second QoS parameters for the second session of the second UE; receiving an indication of a QoS change to at least one of the one or more second QoS parameters for the second session; performing QoS adaptation for at least one of the one or more first QoS parameters for the first session based on the QoS change to the at least one of the one or more second QoS parameters; An apparatus that communicates the QoS adaptation for the first session.

Images