Method and apparatus for managing qos of end-to-end application session

Abstract

Devices, methods, and systems are disclosed for end-to-end QoS fulfillment. One device includes an application interface that receives a request to manage QoS for an end-to-end application session. Herein, 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 triggering event related to a QoS change of the second QoS parameter. The processor 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.

Description

Technical Field

[0001] The subject matter disclosed in this article generally relates to wireless communication, and more specifically to end-to-end QoS fulfillment. Background Technology

[0002] The following abbreviations are defined herein, and at least some of them are referenced in the following description: 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 Cross-Intersection Collision Warning System (“AICW”), Access and Mobility Management Function (“AMF”), Positive Acknowledgment (“ACK”), Application Programming Interface (“API”), Access Layer (“AS”), Base Station (“BS”), Category of Requests (“CoR”), Command and Control (“C2”), Control Control Elements (“CE”), Cooperative Merging (“CM”), Cooperative Overtaking (“CO”), Cooperative Control Transfer (“CToC”), Cooperative Lane Change (“CLC”), Collective Sense (“CP”), Collective Sense Message (“CPM”), Core Network (“CN”), Connected and Automated Vehicles (“CAV”), Distributed Environmental Notification Messages (“DENM”), Downlink (“DL”), Discontinuous Transmission (“DTX”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), Evolved Packet System (“EPS”), Evolved UMTS Terrestrial Radio Access (“E- UMTS”) UTRA, Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), General Packet Radio Service (“GPRS”), General Public Service Identifier (“GPSI”), 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 Identification (“IMEI”), Intelligent Transportation Systems (“ITS”), ITS Station (“ITS-S”), Infrastructure to Vehicle Information Consumption The following are included: IVIM (“IVIM”), Key Performance Indicators (“KPI”), Level of Automation (“LoA”), Long Term Evolution (“LTE”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Map (Topology) Extended Message (“MAPEM”), Maneuver Control (“MC”), Maneuver Control Message (“MCM”), Negative Acknowledgment (“NACK”) or (“NAK”), Next Generation (5G) Node B (“gNB”), Next Generation Radio Access Network (“NG-RAN”, RAN for 5GS Networks), New Radio (“NR”, 5G Radio Access Technology);Also known as "5G NR"), Non-Access Stratum ("NAS"), Network Slice Selection Assistance Information ("NSSAI"), Overtaking Warning ("OVW"), Packet Data Unit ("PDU", used in conjunction with 'PDU session'), PC5 5QI (“PQI”), Permanent Equipment Identifier (“PEI”), Fleet Control (“PC”), Fleet Control Information (“PCM”), Proximity Service (“ProSe”), Public Land Mobile Network (“PLMN”), Quality of Service / Experience (“QoS”), Radio Access Network (“RAN”), Receive (“RX”), Roadside Unit (“RSU”), Service Enabler Architecture Layer (“SEAL”), Session Management (“SM”), Session Management Function (“SMF”), Service Provider (“SP”), Single Network Slice Selection Auxiliary Information (“S-NSSAI”), Signal Phase and Timing Extension Message (“SPATEM”), Signal Request Extension Message (“SREM”), Signal Request Status Extension Message (“SSEM”), Target Driving Area Reservation (“TDAR”), Transport Block (“TB”), Transport (“TX”), Vehicle to Everything (“V2X”), Vehicle to Infrastructure (“V2I”) Vehicle-to-vehicle (“V2V”), vehicle-to-relay (“V2R”), V2X application enabler (“VAE”), vulnerable road user protection (“VRUP”), unified data management (“UDM”), unmanned aerial vehicle system (“UAS”), UAS application enabler (“UAE”, i.e., having a UAE server and at least one UAE client), UAS service provider (“USS”), UAS traffic manager (“UTM”), unmanned aerial vehicle (“UAV”), UAV controller (“UAV-C”), user data repository (“UDR”), user entity / equipment (mobile terminal) (“UE”), uplink (“UL”), user plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), UMTS Terrestrial Radio Access (“UTRA”), UMTS Terrestrial Radio Access Network (“UTRAN”), user service description (“USD”), and global microwave interconnection access (“WiMAX”). As used herein, “HARQ-ACK” can collectively represent a positive acknowledgment (“ACK”), a negative acknowledgment (“NACK”), and a discontinuous transmission (“DTX”). ACK means that the TB was received correctly, while NACK (or NAK) means that the TB was received incorrectly. DTX means that the TB was not detected.

[0003] In Unmanned Aerial Vehicle (“UAS”) communication, there are various scenarios requiring interaction between the UAV and the pilot-owner (also known as the UAV controller (UAV-C)). A primary use case for this interaction is command and control (“C2”) communication. The UAS can be configured with a C2 communication mode. According to TS22.125 (which is the specification for Phase 1 requirements of the UAS), the configuration of C2 mode is defined as “a user plane link for delivering messages containing command and control information for UAV operation from the UAV controller or UTM to the UAV.” Summary of the Invention

[0004] A method for end-to-end QoS enforcement is disclosed. Devices and systems also perform the functions of the method.

[0005] A method of the control unit includes receiving a request to manage the QoS of an end-to-end application session. Herein, 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 QoS change of the second QoS parameter. The method further includes determining a third QoS parameter for the first session of the first UE based on the QoS change of the second QoS parameter, and transmitting the third QoS parameter to the first network. Attached Figure Description

[0006] A more detailed description of the embodiments briefly described above will be presented with reference to the specific embodiments illustrated in the accompanying drawings. While it is understood that these illustrations depict only some embodiments and therefore should not be considered as limiting, the embodiments will be described and explained in a more specific and detailed manner using the accompanying drawings, in which:

[0007] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system for end-to-end QoS enforcement;

[0008] Figure 2 This is a diagram illustrating one embodiment of a network architecture used for end-to-end QoS enforcement;

[0009] Figure 3 This is a diagram illustrating one embodiment of the UAS application layer functional model;

[0010] Figure 4 This is a diagram illustrating the signaling flow of one embodiment of the process for managing QoS guarantees in C2 communications;

[0011] Figure 5AThis is a diagram illustrating a signaling flow of one embodiment of a network-triggered joint QoS adaptation process, wherein the functionality is enabled by the UE;

[0012] Figure 5B continue Figure 5A The process;

[0013] Figure 6A This is a diagram illustrating a signaling flow of one embodiment of a network-triggered joint QoS adaptation process, wherein the functionality is enabled by UTM;

[0014] Figure 6B continue Figure 6A The process;

[0015] Figure 7 This is a flowchart illustrating one embodiment of a procedure for end-to-end QoS enforcement;

[0016] Figure 8 This is a diagram illustrating one embodiment of a user equipment device that can be used for end-to-end QoS enforcement;

[0017] Figure 9 This is a diagram illustrating one embodiment of a network equipment device that can be used for end-to-end QoS enforcement; and

[0018] Figure 10 This is a flowchart illustrating one embodiment of a method that can be used for end-to-end QoS enforcement. Detailed Implementation

[0019] As those skilled in the art will understand, aspects of the embodiments may be embodied as systems, devices, methods, or program products. Therefore, embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0020] For example, the disclosed embodiments can be implemented as hardware circuitry that includes custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can 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, for example, be organized as objects, processes, or functions.

[0021] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device employs only signals for accessing the code.

[0022] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable storage medium. The computer-readable storage medium may be a storage device for storing code. The storage device may be (e.g., but not limited to) an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, device, or apparatus, or any suitable combination thereof.

[0023] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, computer-readable storage media can be any tangible medium that can contain or store programs for use by or in connection with an instruction execution system, device, or apparatus.

[0024] The code used to implement the operations of the embodiments can be of any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Python, Ruby, Java, Smalltalk, C++, etc.), and conventional procedural programming languages ​​(such as the "C" programming language, etc.) and / or machine languages ​​(such as assembly language). The code can be 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 latter case, the remote computer can be connected to the user's computer via any type of network (including local area networks ("LANs") or wide area networks ("WANs"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").

[0025] Throughout this specification, references to "an embodiment," "an embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Therefore, the phrases "in an embodiment," "in one embodiment," and similar language throughout this specification may (but not necessarily) refer to the same embodiment, but rather to "one or more, but not all, embodiments," unless explicitly stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "comprising but not limited to," unless explicitly stated otherwise. An enumerated list of items does not imply that any or all items are mutually exclusive unless explicitly stated otherwise. The terms "a," "an," and "described" also mean "one or more," unless explicitly stated otherwise.

[0026] As used herein, a list containing 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 one and 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, excluding combinations of A, B, and C. As used herein, “selected as a member of the group consisting of A, B, and C” includes one and only one of A, B, or C, excluding combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0027] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. In the following description, numerous specific details (e.g., examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc.) are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0028] The following description refers to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to embodiments. It should be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce machine, such that instructions executable via the processor of the computer or other programmable data processing apparatus create components for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0029] The code may also be stored in a storage device, and the code may instruct a computer, other coded data processing device or other device to function in a particular manner, causing the instructions stored in the storage device to produce an article of art, including instructions to implement the functions / actions specified in the flowchart and / or block diagram.

[0030] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0031] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the device, system, method, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing (a number of) code with specified logical functions.

[0032] It should also be noted that in some alternative implementations, the functions mentioned in the boxes may not appear in the order shown in the figures. For example, in fact, depending on the functionality involved, two boxes shown consecutively may be performed substantially simultaneously, or the boxes may sometimes be performed in reverse order. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0033] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In fact, some arrows or other connecting symbols may be used only to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumeration steps in a depicted embodiment. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and code that performs the specified function or action.

[0034] In each figure, the description of an element may refer to an element in a previous figure. In all figures, the same numbers refer to the same elements, including alternative embodiments of the same elements.

[0035] This disclosure typically describes systems, methods, and apparatus for E2E QoS enforcement in indirect UAS communications. In UAS communications, there are various scenarios requiring interaction between the UAV and the pilot-owner (also known as the UAV controller (UAV-C)). A primary use case for this interaction is command and control (“C2”) communication. This document discloses solutions for ensuring E2E QoS enforcement in indirect UAS communications, which may involve dynamic changes in the QoS of one of the communication links (e.g., a UAV-to-5G network link).

[0036] According to TS22.125 (which is the specification for Phase 1 requirements of UAS), the configuration of C2 mode is defined as "a user plane link used to deliver messages containing UAV operation commands and control information from the UAV controller or UTM to the UAV".

[0037] During direct C2 communication, the UAV controller establishes a direct C2 link with the UAV to communicate with each other, and both register with the 5G network using radio resources configured and scheduled by the 5G network for direct C2 communication.

[0038] During network-assisted C2 communication (also known as "indirect C2 communication"), the UAV controller and UAVs register and establish corresponding unicast C2 communication links to the 5G network, and communicate with each other via the 5G network. Furthermore, both the UAV controller and UAVs can register to the 5G network via different NG-RAN nodes in the same or different PLMNs. Network-assisted C2 communication needs to support specific control modes and specific KPIs (e.g., end-to-end latency and reliability) for each control mode.

[0039] During C2 communication during UTM navigation, UAVs are provided with pre-scheduled flight plans for autonomous flight, such as 4D polygon arrays. However, UTMs still maintain a C2 communication link with UAVs to periodically monitor the flight status of UAVs, verify the flight status with the latest dynamic constraints, provide route updates, and navigate UAVs when necessary.

[0040] The four control modes defined in TS22.125 are (1) waypoint steering, (2) direct stick steering, (3) UTM autoflight, and (4) approach autonomous navigation infrastructure. Two of these control modes require network-assisted C2 communication.

[0041] Waypoint-based turning: Control information contains flight statements, such as waypoints, sent from the UAV controller or UTM to the UAV. This control method is used in both direct C2 communication and network-assisted C2 communication.

[0042] Direct joystick steering: The control message contains directional commands sent from the UAV controller to the UAV, while optionally providing video traffic as feedback from the UAV to the UAV controller. This control method is used in both direct C2 communication and network-assisted C2 communication.

[0043] An additional scenario involves a remote UAV controller via HD video. After the UAV and UAV controller have established a connection and commenced flight operations, the C2 link is established and normally supports UAS operations. In some scenarios, such as when the UAV flies beyond line of sight or during an emergency, the UAV controller will be taken over by another UAV controller or a higher-priority UAV controller. In this case, a C2 connection should be established with the new UAV controller to ensure continuous support for the flight mission.

[0044] For the control modes / scenarios mentioned above, end-to-end application QoS requirements (UAV to UAV-C) may vary in terms of latency (from 20ms to 140ms), reliability (from 99.9% to 99.99%), and data rate, and may also vary depending on whether the communication originates from UAV or UAV-C.

[0045] A key issue related to C2 communication is the conversion between application QoS requirements and network QoS requirements, and the fact that multiple PDU sessions can correspond to one E2E application session (C2 application).

[0046] Specifically, the solution described in this paper addresses the following issues: a) where and how to perform the linking / binding of PDU sessions corresponding to C2 E2E sessions; and b) how to dynamically configure or adapt the QoS provisioning of each PDU session to guarantee end-to-end QoS fulfillment for C2 applications.

[0047] Figure 1 This document describes a wireless communication system 100 for end-to-end QoS enforcement according to embodiments 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 depicted, 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. Hereinafter, the wireless communication system 100 includes at least one core network 120 (e.g., a 5GC of a PLMN). Several access networks 110 and mobile core networks 120 form a mobile communication network.

[0048] The Unmanned Aerial Vehicle System (“UAS”) 101 includes an unmanned aerial vehicle (“UAV”) 103, a UAV controller 104, and related functionality, including a command and control (“C2”) link between the UAV 103 and the UAV controller 104, between the UAV 103 and the network, and for remote identification. The UAV controller 104 of the UAS 101 enables a pilot to control the UAV 103 of the UAS 101 (also referred to as a remotely piloted aircraft or unmanned aerial vehicle). The UAS operator 102 (i.e., the pilot) is the 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. Therefore, the UAV 103 and / or the UAV controller 104 can communicate with the access network 110 to access services provided by the mobile core network 120.

[0049] Despite Figure 1 The present invention depicts a specific number of UAVs 103, UAV controllers 104, access networks 110, and mobile core networks 120, but those skilled in the art will recognize that the wireless communication system 100 may contain any number of UAVs 103, UAV controllers 104, access networks 110, and mobile core networks 120.

[0050] Each access network 110 includes at least one base station element 111 and may consist of a 3GPP access network (containing at least one cellular base station element) and / or a non-3GPP access network (containing at least one access point). In various embodiments, the access network 110 is a radio access network, such as 5G-RAN. UEs (e.g., UAV 103 and / or UAV controller 104) may communicate with the 3GPP access network using 3GPP communication links and / or with the non-3GPP access network using non-3GPP communication links.

[0051] In one implementation, the wireless communication system 100 is compatible with the 5G system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement other open or proprietary communication networks, such as LTE or WiMAX, and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

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

[0053] The UE (e.g., UAV 103 and / or UAV controller 104) can communicate directly with one or more of the base station units 117 in the access network 115 via 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. Hereinafter, the access network 115 is an intermediate network that provides access to the mobile core network 120 to the UAV 103 and / or UAV controller 104.

[0054] In some embodiments, the UE communicates with one or more UAV Service Management (“UTM”) services via a network connection to the mobile core network 120. As described further 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 uses the PDU session to relay services between the UE and the data network 130. Note that the UE may establish one or more PDU sessions (or other data connections) with the mobile core network 120. Therefore, 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.

[0055] Base station unit 111 may be distributed across a geographical area. In some embodiments, base station unit 111 may also be referred to as an access point, access terminal, base station, Node B, eNB, gNB, home Node B, relay node, apparatus, or any other term used in this art. Base station unit 111 typically comprises a portion of a radio access network (“RAN”) (e.g., access network 110) communicatively coupled to one or more controllers corresponding to one or more base station units 111. These and other elements of the radio access network are not described but are generally well known to those skilled in the art. Base station unit 111 is connected to mobile core network 120 via access network 110.

[0056] Base station unit 111 can serve several UEs within a service area, such as a cell or a cell sector, via a wireless communication link. Base station unit 111 can communicate directly with one or more of the UEs via communication signals. Typically, base station unit 111 transmits DL communication signals to serve the UEs in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried via a communication link. The communication link can be any suitable carrier in the licensed or unlicensed radio spectrum. The communication link facilitates communication between one or more UEs and / or one or more base station units 111.

[0057] In one embodiment, the mobile core network 120 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to a data network (e.g., data network 130), such as the Internet and private data networks, as well as other data networks. The UE 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 limit implementation to any particular wireless communication system architecture or protocol.

[0058] Mobile core network 120 includes several network functions (“NFs”). As depicted, mobile core network 120 may include one or more user plane functions (“UPFs”) 121. Mobile core network 120 also includes multiple control plane functions, including, but not limited to, access and mobility management functions (“AMFs”) 123, session management functions (“SMFs”) 125, and network exposure functions (“NEFs”) 127. In some embodiments, mobile core network 120 may also include authentication server functions (“AUSFs”), policy control functions (“PCFs”), unified data management functions (“UDMs”), network repository functions (“NRFs”) (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for 5GC. In some embodiments, mobile core network 120 may include an AAA server.

[0059] In various embodiments, the mobile core network 120 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Hereinafter, a "network slice" refers to a portion of the mobile core network 120 optimized for a specific service type or communication service. Network examples may be identified by S-NSSAI, while a set of network slices authorized for use by the UE (e.g., UAV 103 and / or UAV controller 104) is identified by NSSAI. In some embodiments, various network slices may contain individual examples of network functions, such as SMF 125 and UPF 121. In some embodiments, different network slices may share some common network functions, such as AMF 123. For ease of illustration, Figure 1Different network slices are not shown, but it is assumed that they are supported.

[0060] although Figure 1 The description depicts a specific number and type of network functions, but those skilled in the art should recognize that any number and type of network functions may be included in the mobile core network 120. Furthermore, in the case where the mobile core network 120 is an EPC, the described network functions can be replaced by appropriate EPC entities, such as MME, S-GW, P-GW, HSS, etc.

[0061] In the following description, the term gNB is used for base station, but it can be replaced by any other radio access node, such as BS, eNB, gNB, AP, NR, etc. Furthermore, the operation is primarily described in the context of 5G NR. However, the proposed solution / method is equally applicable to other mobile communication systems that support serving cells / carriers configured for UAS operation.

[0062] As depicted, the UE (e.g., UAV 103 and / or UAV controller 104) can be connected to a mobile core network (e.g., a 5G mobile communication network) via access network 115. Connecting to a mobile communication network (e.g., a combination of access network and mobile core network) allows UAV 103 to operate at an increased distance from UAV controller 104 without requiring a line-of-sight connection between UAV 103 and UAV controller 104.

[0063] Typically, when operating UAV 103 and / or submitting flight plans, UAS 101 may interact with one or more UAV traffic management (“UTM”) services 131. In various embodiments, each mobile core network 120 supporting UAV operation is capable of communicating with one or more UTMs 131.

[0064] UTM 131 is an element that manages the operation of one or more UAVs 103 and UAV controllers 104. In various embodiments, UTM 131 monitors the operation of UAVs 103 and UAV controllers 104 in specific uncontrolled airspace (e.g., below 400 feet above ground). Managing UAV operations may include providing flight authorization, performing collision avoidance, determining alternative flight routes, and ensuring that UAV operations remain within authorized limits. In various embodiments, the operation of the UTM is similar to the operation of an air traffic controller (ATC) that manages manned aircraft on the ground and in controlled airspace (above 400 feet).

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

[0066] UTM 131 can send a request to UAE server 133 to manage the quality of service (QoS) of the C2 communication session of UAS101, as shown in the following reference. Figure 2 , Figure 3 and Figure 4 Further details will be discussed. The UAE server 133 collects information to help determine whether to dynamically adapt the C2 communication quality of service parameters of the UAS 101. Additionally, the UAE server 133 may receive location and other information from the Service Enabler Application Layer (SEAL) server 135.

[0067] SEAL server 135 provides on-demand (subscription or request) services to all vertical industry enabler layer (also known as middleware) platforms (e.g., UAE server 133). Vertical industry-specific support functionality exists between the application-specific server and the mobile core network 120. Common support functionality (service platforms that enable faster deployment of new vertical industries) includes location management, group management, network resource management, configuration management servers, etc., and can be used as services for vertical industry-specific enablers.

[0068] UAV control function (“UCF”) 129 is a function that processes location information from the network. 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, which interacts with the mobile core network 120 via NEF 127.

[0069] Note that while the following description takes into account the mobility of UAV 103, it is assumed that UAV controller 104 remains stationary. However, in other embodiments, the mobility of UAV controller 104 may require system 100 to take into account radio link conditions that change due to mobility, interference, etc.

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

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

[0072] Figure 2 A network architecture 200 for end-to-end QoS enforcement according to embodiments of the present disclosure is depicted. Network architecture 200 includes an example of UAV 103, an example of UAV-C 104, a UTM / USS 205, a UAE server and / or a SEAL server and / or a UCF 210, and a 5GS 215. UAV 103 includes a middleware layer for communication with UAE clients and / or SEAL clients 240 and C2 applications 255. UAV-C 104 includes a middleware layer for communication with UAE clients and / or SEAL clients 220 and C2 applications 235.

[0073] UTM is the air traffic management ecosystem for UAS, encompassing a set of functions and services for managing a range of autonomous unmanned aerial vehicle (UAV) operations (e.g., certifying UAVs, authorizing UAS services, managing UAS policies, and controlling UAV traffic in airspace). UTM services are defined outside the 3GPP system and are subject to specific regional requirements. USS is part of UTM and is the service provider for UAS. USS provides services to support the safe and efficient use of airspace by fulfilling UTM operational requirements by providing services to UAS operators / pilots. One or more USS may exist in a specific area and can manage UAVs through one or more 3GPP networks. 3GPP networks can provide UAV / UAV-C location information to UTM / USS205 and support UTM in establishing associations between UAV 103 and UAV-C 104. Furthermore, one of the services provided by UTM offers UAS operators the infrastructure and quality of service guarantees for radio frequency (RF) command and control (C2) capabilities.

[0074] As depicted, UAE-C / SEAL-C 220 can establish UAE and / or SEAL sessions 225 with UAE-S / SEAL-S / UCF 210. Similarly, UAE-C / SEAL-C 240 can also establish UAE and / or SEAL sessions 245 with 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 deployed at the UAV and UAV-C for interaction with the UAE / SEAL server.

[0075] Additionally, C2 application 235 can establish an application-specific end-to-end (“E2E”) session 260 with C2 application 255. Note that the application-specific E2E session 260 has associated application QoS requirements. The application-specific E2E session 260 represents a session between the UAV’s C2 application and the UAV-C and / or UTM / USS205’s C2 application (in C2 communication during UTM navigation).

[0076] UAV-C 104 establishes a network connection with 5GS215 230. Note that network session 230 has associated network QoS requirements (displayed as 5QI'x', 'y'). UAV 103 establishes a network connection with 5GS215 250. Note that network session 250 has associated network QoS requirements (displayed as 5QI'y', 'z'). As discussed above, UAV 103 and UAV-C 104 transmit direction and / or waypoint 265 via 5GC 215. Similarly, UAV 103 can send video data to UAV-C 104 270.

[0077] In network-assisted C2 communication, the following considerations should be taken into account:

[0078] 1) Assume 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. On the network side, there is no mechanism to link these two PDU sessions for joint QoS monitoring and configuration.

[0079] 2) Assume that each of these PDU sessions may have one or more QoS profiles based on service requirements. An example of multiple QoS profiles is the direct joystick C2 mode, where the UAV-C provides direction to the UAV (associated with one QoS profile), and the UAV provides video feed to the 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 transmission.

[0080] 3) Assume that UAV-C 104 can be a mobile UE and can be connected to a different access network or even a different PLMN than UAV 103.

[0081] For example, if the E2E latency of C2 communication is 40ms, then each PDU session (one for UAV and one for UAV-C) can be configured with a latency-critical GBR QoS flow with a latency budget, such as 10ms (see 5QI = 82 or 83). The 3GPP network guarantees that the GBR flows of both UAV and UAV-C meet the 10ms latency requirement. When the latency of the GBR flow used by UAV exceeds a threshold (e.g., >30ms), UAV-C can request a lower latency for its own GBR flow (e.g., 5QI 85) so that the total latency does not exceed 40ms. However, this mechanism for coordinating the QoS attributes of two dependent sessions does not exist.

[0082] Figure 3 A UAS application layer functional model 300 according to an embodiment of the present disclosure is depicted. 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) interacting with a UAS application server 305 via a 3GPP network system 307. The UAS application layer functional model 300 includes at least a UAS-specific application layer 307, a UAE layer 309, and a SEAL layer 311. At each layer, UAS UEs 301 and 303 include clients that interact with a corresponding server at the UAS application server.

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

[0084] UAS-specific application layer 309 includes UAS-specific application functionality. The functionality of UAS-specific application layer 309 includes USS / UTM 205. In UAS-specific application layer 309, the UAS-specific application client 317 of the second UAS UE 303 communicates with the UAE client 315 of the first UAS UE 301 via the U5-APP reference point. UAS-specific application clients 315 and 317 communicate with the UAS-specific application server 319 via the U1-APP reference point. Note that the U1-APP reference point includes UAV controller / UAV-to-USS / UTM communication.

[0085] UAE layer 311 provides UAE capabilities to UAS-specific application layer 307. UAE clients 321 and 323 provide UAS application layer support functions to UAS-specific application clients 315 and 317 through the Uc reference point. UAE server 325 provides UAS application layer support functions to UAS-specific application server 319 through the Us reference point.

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

[0087] U1-AE messages can be sent via at least unicast, and can also be sent via transparent multicast via xMB or via MB2. Non-transparent multicast via xMB (as specified in 3GPP TS26.348) is triggered by U1-AE messages. Multicast distribution can be achieved through both transparent and non-transparent multicast modes.

[0088] UAE clients 321 and 323 interact with SEAL clients 327 and 329 via the SEAL-C reference point specified for each SEAL service. UAE server 325 interacts with SEAL server 331 via the SEAL-S reference point specified for each SEAL service. Interaction between SEAL clients 327 and 329 is supported by the SEAL-PC5 reference point specified for each SEAL service. Interaction between SEAL clients 327 and 329 and their corresponding SEAL server 331 is supported by the SEAL-UU reference point specified for each SEAL service. Note that the SEAL-C, SEAL-S, SEAL-PC5, and SEAL-UU reference points for each SEAL service are specified in 3GPP TS23.434.

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

[0090] UAE and SEAL layers 311 and 313 provide support functionality for the UAS, which acts as a middleware logical entity between the UTM / USS (e.g., UAS application server 305) and (some) underlying 3GPP networks. SEAL is a set of common functions (including location management, network resource management, configuration management, etc.) that support the UTM / USS to simplify and optimize interaction with the network.

[0091] Figure 4 This describes a process 400 for managing QoS guarantees for C2 communications. Process 400 is executed by a control unit 405, which may take the form of an Application Function (AF) and / or a vertical industry enabler server. Process 400 assumes that both the UAV and UAV-C have established PDU sessions with the same or different PLMNs for C2 communications. To address the following issues: where and how to perform the linking / binding of PDU sessions corresponding to C2 E2E sessions, and how to dynamically configure or adapt the QoS provisioning of each PDU session to guarantee end-to-end QoS fulfillment for C2 applications, process 400 performs the following steps:

[0092] In step 1, while the UAV is in flight, 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 the UAV controller (see message 407). Alternatively, the request to manage the QoS of the UAS may come from the UTM. This request may include the application ID or UAS ID, UAV ID (PEI / IMEI, GPSI), PLMNID, high-definition (“HD”) location map, the UAV's permitted route, C2 KPI requirements, and command / control mode.

[0093] In step 2, in response to receiving a request, control unit 405 performs pairing / association of the UAV and UAV-C sessions corresponding to the application ID / UAS ID (see box 409). This pairing / association may take the form of converting the UAS ID / application ID into a group ID or two (linked) AF service identifiers (one for UAV and one for UAV-C) or two (linked) session IDs for interaction with (several) underlying PLMNs. As used herein, an AF service identifier refers to the identifier of the service represented by the AF's request to the 5GC. This is used to describe the service of the C2 application at the UE.

[0094] In step 3, when pairing / associating UAV-UAV-C, the control unit 405, acting as the AF, subscribes to the PLMN to receive QoS monitoring events corresponding to both the UAV and UAV-C PDU sessions; and specifically, if a QoS degradation (failure to meet GBR QoS requirements) is detected at one of the C2 links, then a QoS notification control [TS 23.501] (see message passing 411) is received.

[0095] In step 4, the monitoring event report (i.e., the triggering event) is received by the 5GC or optionally by the UAV application enabler client in control unit 405 (see message passing 413). For example, the monitoring event report may indicate a QoS degradation notification for one of the PDU sessions (e.g., a notification that the QoS notification control or QoS flow of the UAV session will be downgraded to a lower priority QoS profile).

[0096] In step 5, the control unit 405 requests and receives supplemental information about the linked session in question, such as for a UAV-C session, and specifically, the network QoS status and indications of access conditions that can be used to identify whether the QoS is upgradable (message passing 415). This may be provided by a 5GC or SEAL / NRx server.

[0097] In step 6, the control unit 405 assesses / checks whether QoS requirement adaptation for the involved communication sessions is feasible by upgrading the QoS requirements of PDU sessions unaffected by QoS degradation, in order to avoid failure to meet end-to-end C2 application requirements (see box 417). If this adaptation is feasible, the control unit determines that the application QoS requirements for each UE session have changed and triggers PCC rule adaptation (QoS profile change) for one or more sessions within the C2 application.

[0098] In step 7, the control unit 405 transmits the determined changes to one or more of the involved entities (see message passing 419). This involves providing updates to the service-specific parameters of the PCF / SMF via NEF, with different QoS profiles (one downgraded and one upgraded) for the involved network sessions.

[0099] This document describes two scenarios for communicating with (several) networks when determining a new QoS: one for notification control of an alternative QoS profile with QoS flows (5.7.2.4.1b of 23.501), and one for... NoNotification control of alternative QoS profiles (5.7.2.4.1b of 23.501). If an alternative QoS profile is pre-configured by the AF, then in the first case, the QoS flow will be downgraded to a lower priority QoS on the network side based on the initial configuration (therefore the control unit will only update the upgraded QoS and will not determine the adaptive QoS requirements of the downgraded flow); while in the second case, the control unit will determine the updated requirements for the two QoS flows corresponding to the two sessions.

[0100] Figures 5A to 5B This document describes a process 500 for network-triggered joint QoS adaptation (UE-enabled functionality) according to embodiments of the present disclosure. Process 500 relates to 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 UTM).

[0101] In the depicted embodiment, the control unit 405 resides at a UAE server or any SEAL server (NRx, CM). Initially, the application enabler client (UAE-C / SEAL-C) at the UAV or UAV-C sends a request to the application enabler server (UAE-S / SEAL-S) to monitor and manage end-to-end application QoS for C2 communication. This triggers the UAE-S / SEAL-S to subscribe for receiving... two The corresponding PLMN for QoS monitoring events of the PDU session (one for UAV and one for UAV-C).

[0102] QoS monitoring events can be used for QoS notification control, issuing alerts for QoS degradation indications that fail to meet GBR QoS requirements. When a QoS monitoring event is received by the UAE-S / SEAL-S, the UAE-S / SEAL-S checks whether and how the QoS of another link can be upgraded to meet end-to-end C2 requirements. If this upgrade is feasible and can compensate for the QoS degradation of another PDU session, then the updated QoS requirements are sent to the underlying PLMN of one or both sessions. Procedure 500 includes the following steps:

[0103] In step 0, as a prerequisite, the UAS is registered and connected to the PLMN. In the depicted embodiment, the first UASUE 501 is connected to the first PLMN 505, and the second UAS UE 503 is connected to the 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; therefore, two PDU sessions are established separately. The UAE-S / SEAL-S interacts with the corresponding UAE / SEAL client to establish individual application sessions for application registration and context transfer.

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

[0105] In step 1b, control unit 405 also sends a C2UAE session establishment request message as described above to the UAE / SEAL client in UAV 103 (see Message Passing 515). In response to receiving the request, the UAE / SEAL client sends a C2 UAE session setup response / result message (ACK / NACK) back to control unit 405.

[0106] In step 2, the control unit 405 receives a request from the UAE / SEAL client for managing the QoS of the C2 application session. This request message provides the control unit 405 with the ability to manage C2 communication and includes at least one of the following parameters:

[0107] UAS identification

[0108] • UAV / UAV-C identification. This may include at least one of the following: external UE identifier (GPSI, external ID) or permanent device identifier (PEI / IMEI).

[0109] • UAV / UAV-C IP address and port [How do I find out?]

[0110] ·PLMN ID

[0111] • Application identifiers (e.g., USS identifiers), UTM identifiers

[0112] • C2 control mode (direct joystick, follow waypoint), C2 KPI

[0113] • Applicable geographical area

[0114] • Required valid time

[0115] • C2 E2E QoS parameters

[0116] • Use the HD video label, and specify the required video resolution / encoding.

[0117] HD location map

[0118] UAV permitted routes

[0119] In step 3, upon receiving the necessary authorization and information for managing C2 QoS, control unit 405 links / pairs each UAS request to two corresponding PDU sessions (UAV to PLMN1 and UAV-C to PLMN2 (or PLMN1)) (see box 519). This triggers a conversion from UAS ID / application ID to group ID or two (linked) GPSIs or two (linked) AF service identifiers or two (linked) session IDs (one for UAV and one for UAV-C). This mapping is stored at control unit 405 for further interaction with 5GS.

[0120] In steps 4a / 4b, the control unit 405, acting as the AF, subscribes to the 5GC / NEF for each AF service identifier or session ID of the UAV and UAV-C sessions to receive QoS and network monitoring events (see messaging 521, 523). In the depicted embodiment, process 500 shows different PLMNs as possible implementations, but this request may also be directed to a single PLMN. This monitoring information relates to possible QoS degradation of one or more Uu links (UAV-C to the network server or network to UAV). These links may be provided by more than one PLMN. Therefore, the UAE server should receive each updated message regarding possible QoS degradation (this already supports EPS with Explicit Congestion Notification (ECN) [e.g., as described in TS23.401], and 5GS with QoS Notification Control (QNC) [e.g., as described in TS23.501]).

[0121] continue Figure 5BIn step 5a, the control unit 405 at the UAE / SEAL server receives a trigger event (SMF / NEF) from 5GC, indicating a QoS change (experienced or anticipated) (see message passing 525). This message contains at least one of the following parameters:

[0122] UAV ID

[0123] • Application ID (e.g., C2 App#A)

[0124] • QoS parameters expected to degrade (latency, reliability, data rate, jitter, etc.)

[0125] • Actual QoS parameters that are downgraded (latency, reliability, data rate, jitter, etc.)

[0126] • Network status information (per TA / cell area)

[0127] • QoS profile downgrade indication

[0128] In step 5b (optional), a trigger event from the UAV application enabler client indicates an application QoS change (experienced or anticipated) that meets the triggering conditions provided in steps 1a / 1b (see message 527). Based on the trigger configuration, this triggering criterion may be based on experienced packet delays or packet losses on the Uu link (e.g., channel loss > X%). This message contains at least one of the following parameters:

[0129] UAV ID

[0130] • Application ID (e.g., C2 App#A)

[0131] • Triggering reasons (e.g., QoS degradation, UE context change (location / mobility))

[0132] • QoS parameters expected to degrade (latency, reliability, data rate, jitter, etc.)

[0133] • Actual QoS parameters that are downgraded (latency, reliability, data rate, jitter, etc.)

[0134] UAV expected / actual location / mobility

[0135] • High interference indication (via multiple BS)

[0136] Note that, depending on the implementation scheme, step 4a subscription in UAV-C can be performed before (5a / 5b) or after the triggering event.

[0137] In step 5c, the control unit 405 sends a request (SMF / NEF) to the 5GC to receive supplemental QoS information from the UAV-C (see message passing 529). This request includes at least one of the following parameters:

[0138] ·UAS ID / UAV ID

[0139] • Application ID (e.g., C2 App#A)

[0140] • Configuration of report parameters

[0141] Based on this request, control unit 405 receives a report (via N33) containing the requested parameters:

[0142] ·UAS ID / UAV ID

[0143] • Application ID (e.g., C2 App#A)

[0144] ·UAE / SEALID

[0145] • Expected QoS parameters (latency, reliability, data rate, jitter, etc.)

[0146] • Actual QoS parameters (latency, reliability, data rate, jitter, etc.)

[0147] • QoS upgrade capability indicator

[0148] In step 6, the control unit 405 at the UAE / SEAL server, responding to the report received in step 5b, checks the fulfillment / non-fulfillment of E2E QoS based on the triggering event and additional UAV-C information (see box 531). This is performed by matching the estimated per-link applied QoS with the constituent E2E applied QoS metrics. The control unit 405 at the UAE / SEAL server then determines an action based on the assessment of the E2E QoS. This action can be QoS adaptation for both links (QoS profiles degrading for links receiving QoS notification control and QoS upgrading for scalable links).

[0149] In step 7, the control unit 405, acting as the 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 the new service policy (TS23.501 / 502 supports actions triggered by two AFs) (see message passing 533).

[0150] In step 8, the PLMN updates the QoS profile of the corresponding PDU session (see box 535).

[0151] Figures 6A to 6B A process 600 for network-triggered joint QoS adaptation (a UTM-enabled feature) according to embodiments of the present disclosure is described. Process 600 relates to 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.

[0152] In this embodiment, the control unit 405 resides on a UAE server or any SEAL server (NRx, CM). In step 0, as a prerequisite, it is assumed that a UAV flight is in progress and both the UAV and UAV-C are connected to a 3GPP network. In the depicted embodiment, a first UAS UE is connected to a first PLMN, and a 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. In this document, C2 communication is assumed to be indirect / network-assisted; therefore, two PDU sessions are established separately. The UAE / SEAL server receives a request from the UTM to manage the C2 QoS of the UAS. The UAE / SEAL server then interacts with the 5GC to subscribe to receive QoS-related reports and triggers. Upon receiving a QoS monitoring trigger event for a session (e.g., a UAV session), the UAE / SEAL server obtains supplementary information from the 5GC and determines the action that can be taken in the form of QoS balancing within the UAS's C2 communication link.

[0153] Step 1a, the UTM / USS sends a request to control unit 405 for E2E application QoS to manage C2 communication. This request message provides control unit 405 with the ability to manage C2 communication and includes at least one of the following parameters:

[0154] UAS identification

[0155] • UAV / UAV-C identification. This may include at least one of the following: external UE identifier (GPSI, external ID) or permanent device identifier (PEI / IMEI).

[0156] ·PLMN ID

[0157] Transaction ID of UAS API call

[0158] • Application identifier (e.g., USS identifier)

[0159] UTM identifier

[0160] • C2 control mode (direct joystick, follow waypoint), C2 KPI

[0161] • Applicable geographical area

[0162] • Required valid time

[0163] In step 1b, the UAE / SEAL server responds to the UTM / USS with a positive / negative acknowledgment, and may further request additional UAS-related information and other contextual information. In response to receiving the request for additional UAS-related information, the UTM / USS provides the UAE / SEAL server with at least one of the following parameters:

[0164] UAV / UAV-C application context / configuration information

[0165] • C2 E2E QoS parameters

[0166] • Use the HD video label, and specify the required video resolution / encoding.

[0167] HD location map

[0168] UAV permitted routes

[0169] • C2 communication frequency configured frequency communication / C2 quality assurance indication

[0170] • Dynamic rerouting information (updated / expected trajectory of the UAV)

[0171] In step 2, upon receiving the necessary authorization and information for managing C2 QoS, control unit 405 links / pairs each UAS request to two corresponding PDU sessions (UAV to PLMN1 and UAV-C to PLMN2 (or PLMN1)). This triggers a conversion from UASID / application ID to group ID or two (linked) GPSIs or two (linked) AF service identifiers (one for UAV and one for UAV-C) or two session IDs. This mapping is stored at control unit 405 for further interaction with 5GS.

[0172] In steps 3a / 3b, the control unit 405 acting as the AF (i.e., the UAE / SEAL server) subscribes to 5GC / NEF by each session ID or AF service identifier of the UAV and UAV-C sessions to receive QoS and network monitoring events. Although Figure 6A and 6BDifferent PLMNs are shown as possible implementations, but this subscription request can also be targeted at a single PLMN. This monitoring information relates to potential QoS degradation on one or more Uu links (UAV-C to the network server or network to UAV). These links can be provided by more than one PLMN. Therefore, the UAE server should receive each updated message regarding potential QoS degradation (this already supports EPS with Explicit Congestion Notification (ECN) [e.g., as described in TS23.401], and 5GS with QoS Notification Control (QNC) [e.g., as described in TS23.501]).

[0173] continue Figure 6B In step 4a, the control unit 405 at the UAE / SEAL server receives a trigger event (SMF / NEF) from the 5GC, indicating a QoS change (experienced or anticipated) (see message passing 613). This message contains at least one of the following parameters:

[0174] UAV ID

[0175] • Application ID (e.g., C2 App#A)

[0176] • QoS parameters expected to degrade (latency, reliability, data rate, jitter, etc.)

[0177] • Actual QoS parameters that are downgraded (latency, reliability, data rate, jitter, etc.)

[0178] • Network status information (e.g., per TA / cell area)

[0179] • QoS profile downgrade indication

[0180] In step 4b, the control unit 405 at the UAE / SEAL server sends a request (SMF / NEF) to the 5GC to receive supplemental QoS information from the UAV-C (see message passing 615). This request includes at least one of the following parameters:

[0181] ·UAS ID / UAV ID

[0182] • Application ID (e.g., C2 App#A)

[0183] • Configuration of report parameters

[0184] Based on this request, the control unit 405 at the UAE / SEAL server receives a report (via N33) containing the requested parameters:

[0185] ·UAS ID / UAV ID

[0186] • Application ID (e.g., C2 App#A)

[0187] ·UAE / SEALID

[0188] • QoS parameters expected to degrade (latency, reliability, data rate, jitter, etc.)

[0189] • Actual QoS parameters (latency, reliability, data rate, jitter, etc.)

[0190] • QoS upgrade capability indicator

[0191] In step 5, the control unit 405 at the UAE / SEAL server, responding to the report received in step 4c, checks the fulfillment / non-fulfillment of E2E QoS based on the triggering event and additional UAV-C information (see box 617). This is performed by matching the estimated per-link applied QoS with the constituent E2E applied QoS metrics. The control unit at the UAE / SEAL server then determines an action based on the assessment of the E2E QoS. This action can be QoS adaptation for both links (QoS profiles degrading for links that receive QoS notification control, and QoS upgrading for scalable links).

[0192] In step 6, the control unit 405, acting as the AF at the UAE / SEAL server, 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 the new service policy (TS23.501 / 502 supports actions triggered by two AFs) (see message passing 619).

[0193] In step 7, the PLMN updates the QoS profile of the corresponding PDU session (see box 621).

[0194] Figure 7 A process 700 for end-to-end QoS enforcement according to an embodiment of this disclosure is described. Process 700 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 UAS enabler server (“UAE-S”) 133. This embodiment is an alternative solution that does not require initialization of capabilities at the UAE server / AF.

[0195] In step 0, as a prerequisite, it is assumed that UAV flight is in progress and that both UAV 103 and UAV-C 104 are connected to a 3GPP network (the same or different PLMNs) (see box 701). In this document, C2 communication is assumed to be indirect / network-assisted; therefore, two PDU sessions are established separately.

[0196] In step 1, UAV 103 and UAV-C 104 establish a session with the same UAE-S133 (see Message Passing 703).

[0197] In step 2, UAE-S133(AF) sends an Npcf_PolicyAuthorization_Create request (see message 705) to the PCF handling the PDU session of UAV 103 in PLMN2 507. This request indicates that UL QoS attributes (e.g., packet delay, packet error rate) and DL QoS attributes (e.g., packet delay, packet error rate) between UAV 103 and UPF in PLMN2 507 should be monitored, and that UAE-S133 should be notified when QoS attributes exceed thresholds (e.g., as described in TS29.514).

[0198] In step 3, UAE-S133 sends the same Npcf_PolicyAuthorization_Create request to the PCF that handles the PDU session of UAV-C 104 in PLMN1 505 (see Message Passing 707).

[0199] In step 4, based on the aforementioned Npcf_PolicyAuthorization_Create request, the PCF creates a PCC rule matching the C2 service, which includes "QoS monitoring for URLLC". This rule 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 service should be measured, and a report should be sent when they exceed a threshold. In response, the SMF sends a QoS monitoring request to the NG-RAN and UPF (see box 709).

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

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

[0202] In step 7, the PLMN updates the QoS profile of the corresponding PDU session (see box 715).

[0203] Figure 8 User equipment device 800, which can be used for end-to-end QoS enforcement according to embodiments of this disclosure, is depicted. In various embodiments, user equipment 800 is used to implement one or more of the solutions described above. User equipment 800 may be an embodiment of a UAE client and its supporting hardware, such as UAV 103, UAV controller 104, UAV 201, UAV-C203, UAE client 205, UAE client 301, and / or UAE client 305 described above. Furthermore, user equipment 800 may include a processor 805, memory 810, input device 815, output device 820, and transceiver 825. In some embodiments, input device 815 and output device 820 are combined into a single device, such as a touchscreen. In some embodiments, user equipment 800 may not include any input device 815 and / or output device 820. In various embodiments, user equipment 800 may include one or more of processor 805, memory 810 and transceiver 825, and may not include input device 815 and / or output device 820.

[0204] In one embodiment, processor 805 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, 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, processor 805 executes instructions stored in memory 810 to perform the methods and routines described herein. Processor 805 is communicatively coupled to memory 810, input device 815, output device 820, and transceiver 825.

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

[0206] In one embodiment, memory 810 is a computer-readable storage medium. In some embodiments, memory 810 includes volatile computer storage media. 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 non-volatile computer storage media. For example, memory 810 may include a hard disk drive, 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.

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

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

[0209] In one embodiment, 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, etc., to a user. As another non-limiting example, the output device 820 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., separate from but communicatively coupled to the rest of the user equipment 800. Furthermore, the output device 820 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0210] In some embodiments, the output device 820 includes one or more speakers for generating sound. For example, the output device 820 may generate an audible alarm or notification (e.g., a beep or chime). In some embodiments, the output device 820 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part 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.

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

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

[0213] In one embodiment, transceiver 825 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and the second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for use with both 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, some transceivers 825, transmitters 830, and receivers 835 may be implemented as physically separate components that access shared hardware resources and / or software resources, such as, for example, network interface 840.

[0214] Transceiver 825 may include one or more transmitters 830 and one or more receivers 835. Although only a specific number of transmitters 830 and receivers 835 are described, user equipment device 800 may have any suitable number of transmitters 830 and receivers 835. Furthermore, transmitters 830 and receivers 835 may be of any suitable type. In some 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.

[0215] In various embodiments, transceiver 825 is capable of communicating with the mobile core network via an access network. Therefore, transceiver 825 may support at least one network interface 840. Hereinafter, at least one network interface 840 facilitates communication with RAN nodes, such as eNBs or gNBs, using, for example, “Uu” interfaces (e.g., LTE-Uu for eNBs, NR-Uu for gNBs). Additionally, at least one network interface 840 may include interfaces for communicating with one or more network functions (e.g., UPF 141, AMF 143, and / or SMF 145) in the mobile core network. For UAS communication, transceiver 825 may support a PC5 interface for direct C2 communication. Transceiver 825 and / or processor 805 may support one or more application interfaces 845. Through application interfaces 945, user equipment equipment can send QoS monitoring events, such as application QoS degradation reports.

[0216] In various embodiments, one or more transmitters 830 and / or one or more receivers 835 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (“ASIC”), or other types of hardware components. In some embodiments, one or more transmitters 830 and / or one or more receivers 835 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as network interface 840 or other hardware components / circuits, may be integrated with any number of transmitters 830 and / or receivers 835 into a single chip. In this embodiment, transmitters 830 and receivers 835 may be logically configured as transceivers 825 using one or more common control signals, or as modular transmitters 830 and receivers 835 implemented in the same hardware chip or in a multi-chip module. In some embodiments, transceiver 825 may implement a 3GPP modem (e.g., for communication via NR or LTE access networks) and a non-3GPP modem (e.g., for communication via Wi-Fi or other non-3GPP access networks).

[0217] Figure 9 This description depicts one embodiment of a network equipment device 900 for end-to-end QoS enforcement according to embodiments of the present disclosure. In some embodiments, the network equipment device 900 may be an embodiment of a control unit and its supporting hardware, such as the UAE server 133, SEAL server 135, UAE server / SEAL server / UCF 210 and / or control unit 405 described above. Furthermore, the user 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 touchscreen. In some embodiments, the network equipment device 900 does not include any input device 915 and / or output device 920.

[0218] As depicted, transceiver 925 includes at least one transmitter 930 and at least one receiver 935. Hereinafter, transceiver 925 communicates with one or more remote units 105. Additionally, transceiver 925 may support at least one network interface 940 and / or application interface 945. In some embodiments, transceiver 925 supports an interface (e.g., an Nnef interface) for communicating with a NEF (i.e., NEF 127). Other network interfaces may be supported, as will be understood by those skilled in the art.

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

[0220] In various embodiments, processor 905 controls network equipment device 900 to implement the aforementioned UAE client behavior. For example, via application interface 945, processor 905 may receive requests to manage the QoS of end-to-end application sessions. Herein, an 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.

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

[0222] 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 some embodiments, the first UE includes a UAV-C, and the second UE includes a UAV.

[0223] In some embodiments, the end-to-end application session supports C2 communication and has C2 requirements consisting of one or more of the following parameters: identification of the UAS, identification of the UAV, identification of the UAV-C, at least one PLMN ID, transaction ID of the UAS API call, application identifier (e.g., USS identifier), UTM identifier, C2 control mode (e.g., direct joystick, follow waypoint), one or more C2 KPIs, geographical area required by the application, required valid time, 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 the use of HD video to assist C2, video resolution / encoding required for HD video, HD location map for assisting C2, and permitted routes for the UAV.

[0224] The processor 905 configures first QoS parameters for a first session of the first UE and second QoS parameters for a second session of the second UE. In some embodiments, the configuration is provided to the first and second UEs by establishing application sessions between the device and the first and second UEs.

[0225] In some embodiments, the configuration further includes at least one mapping for sessions of the first and second UEs, the mapping including at least one of the following: a mapping from UAS ID to group ID; a mapping from application ID to group ID; a mapping from UAS ID to two (linked) GPSIs; a mapping from application ID to two (linked) GPSIs; a mapping from UAS ID to two (linked) AF service identifiers or two (linked) session IDs; a mapping from application ID to two (linked) AF service identifiers or two (linked) session IDs; and a mapping from service API to control API for application sessions of the first and second UEs, wherein the service API is received by UTM and / or USS per UAS.

[0226] Processor 905 receives a trigger event related to a QoS change in a second QoS parameter. In some embodiments, the trigger event includes a downgrade indication of the second QoS parameter.

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

[0228] In some embodiments, the processor 905 obtains supplementary QoS and / or UE context information of the second application session of the second UE, wherein the supplementary information includes at least one of the following: one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more actual QoE parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0229] The processor 905 determines the third QoS parameter of the first session of the first UE based on the QoS change of the second QoS parameter, and transmits the third QoS parameter to the first network.

[0230] 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 transmits the fourth QoS parameter to the second network. In some embodiments, the third QoS parameter may be an upgrade of the first QoS parameter, and the fourth QoS parameter may be 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.

[0231] In some embodiments, the determination of the third and fourth QoS parameters is mapped to service policy / PCC rule updates and / or network QoS profile updates for the first and second UEs. In some embodiments, transmitting the third parameter includes sending a QoS profile change request to the first network (e.g., to the PCF or SMF in the first network). Similarly, in some embodiments, transmitting the fourth parameter includes sending a QoS profile change request to the second network (e.g., to the PCF or SMF in the second network).

[0232] In one embodiment, memory 910 is a computer-readable storage medium. In some embodiments, memory 910 includes volatile computer storage media. 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 non-volatile computer storage media. 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 example, such as storing server addresses, UE locations, DNS caches, etc. In some embodiments, memory 910 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on network equipment device 900 and one or more software applications.

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

[0234] In one embodiment, output device 920 may include any known electronically controllable display or display device. Output device 920 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 920 includes an electronic display capable of outputting visual data to a user. For example, output device 920 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 920 may include wearable displays, such as smartwatches, smart glasses, head-up displays, etc. Furthermore, output device 920 may be a component of smartphones, personal digital assistants, televisions, desktop computers, laptop computers, personal computers, vehicle dashboards, etc.

[0235] In some embodiments, the output device 920 includes one or more speakers for generating sound. For example, the output device 920 may generate an audible alarm or notification (e.g., a beep or chime). In some embodiments, the output device 920 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of the output device 920 may be integrated with the input device 915. For example, the input device 915 and the output device 920 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of the output device 920 may be located near the input device 915.

[0236] As discussed above, transceiver 925 can communicate with one or more remote units and / or with one or more interoperability functions providing access to one or more PLMNs. Transceiver 925 can also communicate with one or more network functions (e.g., in mobile core network 120). Transceiver 925 operates under the control of processor 905 to transmit and receive messages, data, and other signals. For example, processor 905 can selectively activate the transceiver (or a portion thereof) at specific times to send and receive messages.

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

[0238] Figure 10 One embodiment of a method 1000 for end-to-end QoS enforcement according to embodiments of the present disclosure is described. In various embodiments, method 1000 is executed by a control unit, such as 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, method 1000 is executed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0239] Method 1000 begins and receives 1005 a request to manage the QoS of an end-to-end application session. In this document, 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. Method 1000 includes configuring 1010 first QoS parameters for the first session of the first UE and second QoS parameters for the second session of the second UE. Method 1000 includes receiving 1015 a trigger event related to a QoS change of the second QoS parameters. Method 1000 includes determining 1020 third QoS parameters for the first session of the first UE based on the QoS change of the second QoS parameters. Method 1000 includes transmitting 1025 the third QoS parameters to the first network. Method 1000 ends.

[0240] This document discloses a first device for end-to-end QoS enforcement according to embodiments of this disclosure. The first device may be implemented by a control unit, such as a UAE server 133, a SEAL server 135, a UAE server / SEAL server / UCF 210, a control unit 405, and / or a network equipment device 900. The first device includes an interface that receives requests to manage the QoS of an end-to-end application session. Herein, 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 first QoS parameters for the first session of the first UE and second QoS parameters for the second session of the second UE, and receives trigger events related to QoS changes in the second QoS parameters. The processor determines third QoS parameters for the first session of the first UE based on the QoS changes in the second QoS parameters and transmits the third QoS parameters to the first network.

[0241] In some embodiments, the first network and the second network include the same network (e.g., the same PLMN). In some embodiments, the first session includes a first application session, and the second session includes a second application session. In other embodiments, the first session includes a first network session, and the second session includes a second network session.

[0242] In some embodiments, the end-to-end application session supports C2 communication and has C2 requirements consisting of one or more of the following parameters: identification of the UAS, identification of the UAV, identification of the UAV-C, at least one PLMN ID, transaction ID of the UAS API call, application identifier (e.g., USS identifier), UTM identifier, C2 control mode (e.g., direct joystick, follow waypoint), one or more C2 KPIs, geographical area required by the application, required valid time, 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 the use of HD video to assist C2, video resolution / encoding required for HD video, HD location map for assisting C2, and permitted routes for the UAV.

[0243] In some embodiments, the first UE includes a UAV-C, and the second UE includes a UAV. In some embodiments, a request is received from an application running on either the first UE or the second UE. In other embodiments, the request is received from a UTM.

[0244] In some embodiments, the configuration further includes at least one mapping for sessions for the first and second UEs, the mapping including at least one of the following: a mapping from UAS ID to group ID; a mapping from application ID to group ID; a mapping from UAS ID to two (linked) GPSIs; a mapping from application ID to two (linked) GPSIs; a mapping from UAS ID to two (linked) AF service identifiers or two (linked) session IDs; a mapping from application ID to two (linked) AF service identifiers or two (linked) session IDs; and a mapping from a service API to a control API for the application sessions of the first and second UEs, wherein the service API is received by the UTM and / or USS per UAS. In some embodiments, the configuration is provided to the first and second UEs via establishing application sessions between the device and the first and second UEs.

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

[0246] In some embodiments, the processor obtains supplementary QoS and / or UE context information of the second application session of the second UE, wherein the supplementary information includes at least one of the following: one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more actual QoE parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0247] 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 transmits 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 some 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.

[0248] In some embodiments, the determination of the third and fourth QoS parameters is mapped to service policy / PCC rule updates and / or network QoS profile updates for the first and second UEs. In some embodiments, transmitting the fourth parameter includes sending a QoS profile change request to the second network (e.g., to the PCF or SMF). In some embodiments, transmitting the third parameter includes sending a QoS profile change request to the first network (e.g., to the PCF or SMF).

[0249] This document discloses a first method for end-to-end QoS enforcement according to embodiments of this disclosure. The first method may be executed by a control unit, such as a UAE server 133, a SEAL server 135, a UAE server / SEAL server / UCF 210, a control unit 405, and / or a network equipment device 900. The first method includes receiving a request to manage the QoS of an end-to-end application session. Herein, 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 configuring a second QoS parameter for the second session of the second UE, and receiving a trigger event related to a QoS change of the second QoS parameter. The method includes determining a third QoS parameter for the first session of the first UE based on the QoS change of the second QoS parameter, and transmitting the third QoS parameter to the first network.

[0250] In some embodiments, the first network and the second network include the same network (e.g., the same PLMN). In some embodiments, the first session includes a first application session, and the second session includes a second application session. In other embodiments, the first session includes a first network session, and the second session includes a second network session.

[0251] In some embodiments, the end-to-end application session supports C2 communication and has C2 requirements consisting of one or more of the following parameters: identification of the UAS, identification of the UAV, identification of the UAV-C, at least one PLMN ID, transaction ID of the UAS API call, application identifier (e.g., USS identifier), UTM identifier, C2 control mode (e.g., direct joystick, follow waypoint), one or more C2 KPIs, geographical area required by the application, required valid time, 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 the use of HD video to assist C2, video resolution / encoding required for HD video, HD location map for assisting C2, and permitted routes for the UAV.

[0252] In some embodiments, the first UE includes a UAV-C, and the second UE includes a UAV. In some embodiments, a request is received from an application running on either the first UE or the second UE. In other embodiments, the request is received from a UTM.

[0253] In some embodiments, the configuration further includes at least one mapping for sessions for the first and second UEs, the mapping including at least one of the following: a mapping from UAS ID to group ID; a mapping from application ID to group ID; a mapping from UAS ID to two (linked) GPSIs; a mapping from application ID to two (linked) GPSIs; a mapping from UAS ID to two (linked) AF service identifiers or two (linked) session IDs; a mapping from application ID to two (linked) AF service identifiers or two (linked) session IDs; and a mapping from the service API to the control API for the application sessions of the first and second UEs, wherein the service API is received by the UTM and / or USS per UAS. In some embodiments, a request for managing the QoS of the end-to-end application sessions is received at the control unit, and the configuration is provided to the first and second UEs via establishing application sessions between the control unit and the first and second UEs.

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

[0255] In some embodiments, the processor obtains supplementary QoS and / or UE context information of the second application session of the second UE, wherein the supplementary information includes at least one of the following: one or more expected QoS parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more actual QoS parameters (e.g., latency, reliability, data rate, jitter, etc.), one or more expected QoE parameters (e.g., received video quality), one or more actual QoE parameters (e.g., received video quality), QoS upgrade capability indication, location information of the second UE, and mobility information of the second UE.

[0256] In some embodiments, the first method further includes determining a fourth QoS parameter for a second application session of the second UE based on a QoS change of the second QoS parameter, and transmitting the fourth QoS parameter to a 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 some 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.

[0257] In some embodiments, the determination of the third and fourth QoS parameters is mapped to service policy / PCC rule updates and / or network QoS profile updates for the first and second UEs. In some embodiments, transmitting the fourth parameter includes sending a QoS profile change request to the second network (e.g., to the PCF or SMF). In some embodiments, transmitting the third parameter includes sending a QoS profile change request to the first network (e.g., to the PCF or SMF).

[0258] The embodiments may be practiced in other specific forms. The described embodiments should be considered illustrative and non-limiting in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All changes within the equivalent meaning and scope of the claims should be covered within its scope.

Claims

1. A device for wireless communication, comprising: processor; as well as A memory coupled to the processor, the memory including instructions executable by the processor to cause the device to: Receive a request to manage the Quality of Service (QoS) of an end-to-end application session, wherein the end-to-end application session includes 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. Configure the first QoS parameters of the first session of the first UE and the second QoS parameters of the second session of the second UE; Receive a trigger event related to a QoS change of the second QoS parameter, wherein the trigger event includes a degradation indication for the second QoS parameter; The third QoS parameter of the first session of the first UE is determined based on the QoS change of the second QoS parameter; and The third QoS parameter is transmitted to the first network.

2. The device according to claim 1, wherein the first network and the second network comprise the same network.

3. The device according to claim 1, wherein the first session includes a first application session, and the second session includes a second application session.

4. The device of claim 1, wherein the first session includes a first network session, and the second session includes a second network session.

5. The device of claim 1, wherein the end-to-end application session supports command and control "C2" communication and has C2 requirements, the C2 requirements including one or more of the following parameters: Identification of Unmanned Aerial Vehicle Systems (UAS) Identification of unmanned aerial vehicles (UAVs) Identification of the UAV controller "UAV-C" At least one Public Land Mobile Network Identifier "PLMN ID" The transaction identifier ID for UAS application programming interface (API) calls. Application ID, UAS Business Manager "UTM" ID, C2 control mode, One or more C2 key performance indicators, The C2 requirement applies to the geographical area. The effective time required by C2 The application context of at least one of the UAV or the UAV-C Configuration information of at least one of the UAV or the UAV-C At least one C2 end-to-end QoS parameter, The logo indicates the use of high-definition "HD" video assistance for C2. The required video resolution / encoding for the HD video. HD location map used to assist C2 The permitted routes for the UAV, Or a combination thereof.

6. The device according to claim 5, wherein the first UE includes the UAV-C, and the second UE includes the UAV.

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

8. The device of claim 1, wherein the request is received from the UAS Service Manager "UTM".

9. The device of claim 1, wherein 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 the following: Mapping of UAS identifier "ID" to group ID; Mapping of application IDs to the group IDs; The mapping of the UAS ID to the two Common Public Service Identifiers "GPSI"; The mapping from the application ID to the two GPSIs; The mapping from the UAS ID to the two application function service identifiers; The mapping from the application ID to the identifiers of the two application function services; The mapping from the UAS ID to the two session IDs; The mapping from the application ID to the two session IDs; A mapping of service APIs to one or more control APIs used in application sessions for the first UE and the second UE, wherein the service APIs are received per UAS by the UAS Service Manager "UTM" and / or the UAS Service Provider "USS". Or a combination thereof.

10. The device of claim 9, wherein the request for managing the QoS of an end-to-end application session is received at the control unit, wherein the configuration is provided to the first UE and the second UE via establishing an application session between the control unit and the first UE and the second UE.

11. The device of claim 1, wherein the triggering event includes at least one of the following parameters: Application identifier "ID", Expected degraded QoS parameters, Actual downgraded QoS parameters, The expected location of the unmanned aerial vehicle (UAV). The actual location of the UAV. UAV mobility information, High interference indication, Network status information, QoS profile downgrade indication, Indication of Radio Access Network (RAN) congestion. Indication of RAN overload condition. QoS upgrade indication for QoS streams Or a combination thereof.

12. The device of claim 1, further comprising obtaining supplemental QoS and / or UE context information of the second session of the second UE, wherein the supplemental QoS and / or UE context information includes at least one of the following: One or more expected QoS parameters, One or more actual QoS parameters, One or more expected quality of experience (QoE) parameters, One or more actual QoE parameters, QoS upgrade capability indication The location information of the second UE, The mobility information of the second UE, Or a combination thereof.

13. The device according to claim 1, further comprising: The fourth QoS parameter of the second session of the second UE is determined based on the QoS change of the second QoS parameter; and The fourth QoS parameter is transmitted to the second network.

14. The device of claim 13, wherein the third QoS parameter is an upgrade of the first QoS parameter, and wherein the fourth QoS parameter is a downgrade of the second QoS parameter.

15. The device of claim 13, wherein the third QoS parameter is a downgrade of the first QoS parameter, and wherein the fourth QoS parameter is an upgrade of the second QoS parameter.

16. The device of claim 13, wherein the determination of the third and fourth QoS parameters is mapped to one or more of the following: Update the service policy rules for the first UE. For the service policy rule update of the second UE, Update the Policy and Charging Control (PCC) rules for the first UE. PCC rule update for the second UE For the network QoS configuration file update of the first UE, For the network QoS configuration file update of the second UE, Or a combination thereof.

17. The device of claim 13, wherein transmitting the fourth QoS parameter includes sending a QoS profile change request to the second network.

18. The device of claim 1, wherein transmitting the third QoS parameter includes sending a QoS profile change request to the first network.

19. A method for wireless communication, comprising: Receive a request to manage the Quality of Service (QoS) of an end-to-end application session, wherein the end-to-end application session includes 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. Configure the first QoS parameters of the first session of the first UE and the second QoS parameters of the second session of the second UE; Receive a trigger event related to a QoS change of the second QoS parameter, wherein the trigger event includes a degradation indication for the second QoS parameter; The third QoS parameter of the first session of the first UE is determined based on the QoS change of the second QoS parameter; and The third QoS parameter is transmitted to the first network.

Images