Method of quality of service conditioning for industrial wireless control

Abstract

A method for quality of service conditioning for industrial wireless control. In a system, apparatus, method, and non-transitory computer-readable medium, a network device may be caused to obtain task utility information for at least one task to be performed by at least one wireless controlled device, obtain wireless link utility information for at least one wireless link to be allocated to the at least one task, determining a QoS time function for the at least one task and the at least one wireless link based on the task utility information and the wireless link utility information, and transmitting the QoS time function to a network scheduler node, a core network node, and an enterprise management server, the QoS time function enables the network scheduler node to provide network resources to the at least one wireless controlled device for a first time period based on the QoS requirements.

Description

Technical Field

[0001] Various example embodiments relate to methods, apparatus, systems, and / or non-transitory computer-readable media for quality of service (QoS) conditioning of industrial wireless control systems. Background Technology

[0002] The fifth-generation mobile network (5G) standard, called 5G New Radio (NR), is being developed to provide communications with higher capacity, higher reliability, and lower latency than the 4G Long Term Evolution (LTE) standard.

[0003] With the deployment of fifth-generation mobile networks (5G) and other high-speed networks, more and more devices and / or applications are supporting these networks, such as autonomous vehicles, robots, Internet of Things (IoT) devices, industrial sensors, and network-enabled medical devices. These devices and applications have adapted to communication services with higher capacity, higher reliability, and lower latency.

[0004] One proposed implementation of 5G network capabilities relates to the field of cloud robotics and / or industrial wireless control, where the controller and / or control system of a robot system resides in a cloud network (e.g., a private network, a wide area network (WAN), a core network, the Internet, etc.) and provides control commands to wirelessly controlled devices (e.g., robots, actuators, autonomous ground vehicles (AGVs), unmanned aerial vehicles (UAVs), sensors, etc.). Summary of the Invention

[0005] At least one example embodiment relates to a network device.

[0006] In at least one example embodiment, the network device may include a memory storing computer-readable instructions and a processing circuitry configured to execute the computer-readable instructions such that the network device: acquires task utility information for at least one task to be performed by at least one wireless controlled device; acquires wireless link utility information for at least one wireless link to be allocated to at least one task; determines a Quality of Service (QoS) time function for at least one task and at least one wireless link based on the task utility information and the wireless link utility information; the QoS time function establishes QoS requirements for at least one task and at least one wireless link within a first time period; and transmits the QoS time function to a network scheduler node, a core network node, and an enterprise management server, the QoS time function enabling the network scheduler node to provide network resources to at least one wireless controlled device within the first time period based on the QoS requirements.

[0007] Some example implementations specify that, in response to transmitting the QoS time function, the network device is also configured to receive QoS allocation information for at least one radio link from the core network node.

[0008] Some example embodiments specify that the task utility information includes at least one of the following: at least one estimated total operating time of at least one task, at least one estimated time to complete at least one task, at least one estimated sampling time of at least one task, at least one estimated lifetime of at least one task, at least one operating state of at least one task, at least one sensor value associated with at least one task from at least one wirelessly controlled device, or any combination thereof; the wireless link utility information includes at least one of the following: available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof; and the task utility information and the wireless link utility information change during a first time period.

[0009] Some example embodiments specify that the network device is also made to: calculate O(t)β×U(t)γ, where O(t) is the task utility information over time, U(t) is the radio link utility information over time, β is the task priority weight, and γ is the link priority weight; and based on the calculation result, set a set of service priority metrics for each combination of at least one task and at least one radio link to be performed.

[0010] Some example embodiments specify that the network device is also made to determine the QoS time function by: negotiating a set of QoS requirement candidates for at least one task and at least one radio link with the network scheduler node; negotiating a set of time-varying preference metrics corresponding to the QoS requirement candidates with the network scheduler node; and determining the QoS time function based on the set of QoS requirement candidates and the set of time-varying preference metrics.

[0011] Some example embodiments specify that the network device is also configured to: receive a QoS range renegotiation request from a network scheduler node, the QoS range renegotiation request being based on changes in network load detected by the network scheduler node; and, in response to the QoS range renegotiation request, renegotiate with the network scheduler node a set of QoS requirement candidates for at least one task and at least one radio link, and renegotiate with the network scheduler node a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0012] Some example embodiments specify that the network device is also configured to: detect changes in QoS requirements as a QoS time function; send a QoS range renegotiation request to the network scheduler node based on the changes in QoS requirements; and, in response to the QoS range renegotiation request, renegotiate with the network scheduler node a set of QoS requirement candidates for at least one task and at least one radio link, and renegotiate with the network scheduler node a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0013] Some example embodiments specify that the network device is further configured to: acquire updated task utility information for at least one task to be performed by at least one wireless controlled device; acquire updated wireless link utility information for at least one wireless link to be allocated to at least one task; determine an updated QoS time function for at least one task and at least one wireless link based on the updated task utility information and the updated wireless link utility information, the updated QoS time function establishing updated QoS requirements for at least one task and at least one wireless link within a second time period; and transmit the updated QoS time function to a network scheduler node, the updated QoS time function enabling the network scheduler node to provide updated network resources to at least one wireless controlled device within a second time period based on the updated QoS requirements.

[0014] Some example embodiments specify that the network device is also configured to: receive a QoS update request from a network scheduler node, the QoS update request being based on changes in network load detected by the network scheduler node; and, in response to the QoS update request, determine updated wireless link utility information for at least one wireless link to be allocated to at least one task to be performed by at least one wireless controlled device.

[0015] Some example embodiments specify that the network device is also configured to: detect changes in QoS requirements as a QoS time function; send a QoS update request to a network scheduler node in response to the detected change in QoS requirements exceeding a desired threshold; and, in response to the QoS update request, determine updated radio link utility information for at least one radio link to be allocated to at least one task to be performed by at least one radio controlled device.

[0016] Some example embodiments specify that the network device is also configured to: detect changes in QoS requirements as a QoS time function; send a QoS update request to a network scheduler node in response to the detected changes in QoS requirements occurring at a desired time interval; and, in response to the QoS update request, determine updated wireless link utility information for at least one wireless link to be allocated to at least one task to be performed by at least one wireless controlled device.

[0017] Some example embodiments specify that the network device is also configured to: determine a task utility recommendation for at least one task to be performed by at least one wireless controlled device based on a QoS time function; and send the task utility recommendation to at least one wireless controlled device, wherein the determined task utility recommendation enables at least one wireless controlled device to update the task utility information of at least one task.

[0018] At least one example embodiment relates to a radio access network (RAN) node.

[0019] In at least one example embodiment, the RAN node may include a memory storing computer-readable instructions and a processing circuitry configured to execute the computer-readable instructions such that the RAN node: determines radio link utility information for at least one radio link to be allocated to at least one task to be performed by at least one radio controlled device; sends the radio link utility information to a co-design interface server; obtains a quality of service (QoS) value for at least one radio link from a core network node, the QoS value establishing QoS requirements for at least one radio link within a first time period; determines a scheduling metric for at least one radio link based on the QoS value; and provides network resources to at least one radio controlled device within the first time period based on the scheduling metric.

[0020] Some example implementations specify that the radio link utility information includes at least one of the following: available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof, and the radio link utility information and scheduling metrics change during a first time period.

[0021] Some example implementations specify that the RAN node is also configured to: negotiate with the Cooperative Design Interface Server a set of QoS requirement candidates for at least one radio link; and negotiate with the Cooperative Design Interface Server a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0022] Some example implementations specify that the RAN node is also configured to: receive a QoS range renegotiation request from the Cooperative Design Interface Server; and, in response to the QoS range renegotiation request, renegotiate a set of QoS requirement candidates for at least one radio link with the Cooperative Design Interface Server, and renegotiate a set of time-varying preference metrics corresponding to the QoS requirement candidates with the Cooperative Design Interface Server.

[0023] Some example implementations specify that the RAN node is also configured to: detect changes in network load; send a QoS range renegotiation request to the Cooperative Design Interface Server based on the changes in network load; and, in response to the QoS range renegotiation request, renegotiate a set of QoS requirement candidates for at least one radio link with the Cooperative Design Interface Server, and renegotiate a set of time-varying preference metrics corresponding to the QoS requirement candidates with the Cooperative Design Interface Server.

[0024] Some example embodiments specify that the RAN node is also configured to: determine updated radio link utility information for at least one radio link to be allocated to at least one task to be performed by at least one radio controlled device; send the updated radio link utility information to a co-design interface server; obtain an updated QoS value for at least one radio link, the updated QoS value establishing updated QoS requirements for at least one radio link within a second time period; determine an updated scheduling metric for at least one task based on the updated QoS value; and provide updated network resources to at least one radio controlled device within the second time period based on the updated scheduling metric.

[0025] Some example embodiments specify that the RAN node is also configured to: receive a QoS update request from a co-design interface server; and, in response to the QoS update request, determine updated radio link utility information for at least one radio link to be assigned to at least one task to be performed by at least one radio controlled device.

[0026] Some example embodiments specify that the RAN node is also configured to: detect changes in network load; send a QoS update request to the Cooperative Design Interface Server in response to the detected changes in network load; and determine, in response to the QoS update request, updated radio link utility information for at least one radio link to be assigned to at least one task to be performed by at least one radio controlled device.

[0027] At least one example embodiment relates to a method of operating a network device.

[0028] In at least one example embodiment, the method may include: obtaining task utility information of at least one task to be performed by at least one wireless controlled device; obtaining wireless link utility information of at least one wireless link to be allocated to at least one task; determining a quality of service (QoS) time function for at least one task and at least one wireless link based on the task utility information and the wireless link utility information; the QoS time function establishing QoS requirements for at least one task and at least one wireless link within a first time period; and transmitting the QoS time function to a network scheduler node, a core network node, and an enterprise management server, the QoS time function enabling the network scheduler node to provide network resources to at least one wireless controlled device within the first time period based on the QoS requirements.

[0029] At least one example embodiment relates to a network device.

[0030] In at least one example embodiment, the network device may include components for: acquiring task utility information for at least one task to be performed by at least one wireless controlled device; acquiring wireless link utility information for at least one wireless link to be allocated to at least one task; determining a Quality of Service (QoS) time function for at least one task and at least one wireless link based on the task utility information and the wireless link utility information; establishing QoS requirements for at least one task and at least one wireless link within a first time period based on the QoS time function; and transmitting the QoS time function to a network scheduler node, a core network node, and an enterprise management server, wherein the QoS time function enables the network scheduler node to provide network resources to at least one wireless controlled device within the first time period based on the QoS requirements.

[0031] Some example embodiments specify that the network device also includes a component for receiving QoS allocation information for at least one radio link from a core network node in response to transmitting a QoS time function.

[0032] Some example embodiments specify that the task utility information includes at least one of the following: at least one estimated total operating time of at least one task, at least one estimated time to complete at least one task, at least one estimated sampling time of at least one task, at least one estimated lifetime of at least one task, at least one operating state of at least one task, at least one sensor value associated with at least one task from at least one wirelessly controlled device, or any combination thereof; the wireless link utility information includes at least one of the following: available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof; and the task utility information and the wireless link utility information change during a first time period.

[0033] Some example embodiments specify that the network device further includes components for: calculating O(t)β×U(t)γ, where O(t) is task utility information over time, U(t) is radio link utility information over time, β is task priority weight, and γ is link priority weight; and based on the calculation results, setting a set of service priority metrics for each combination of at least one task and at least one radio link to be performed.

[0034] Some example embodiments specify that the network device further includes components for determining a QoS time function by: negotiating a set of QoS requirement candidates for at least one task and at least one radio link with a network scheduler node; negotiating a set of time-varying preference metrics corresponding to the QoS requirement candidates with the network scheduler node; and determining the QoS time function based on the set of QoS requirement candidates and the set of time-varying preference metrics.

[0035] Some example embodiments specify that the network device also includes components for: receiving a QoS range renegotiation request from a network scheduler node, the QoS range renegotiation request being based on changes in network load detected by the network scheduler node; and, in response to the QoS range renegotiation request, renegotiation with the network scheduler node of a set of QoS requirement candidates for at least one task and at least one radio link, and renegotiation with the network scheduler node of a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0036] Some example embodiments specify that the network device further includes components for: detecting changes in QoS requirements as a QoS time function; sending a QoS range renegotiation request to a network scheduler node based on the changes in QoS requirements; and, in response to the QoS range renegotiation request, renegotiation with the network scheduler node of a set of QoS requirement candidates for at least one task and at least one radio link, and renegotiation with the network scheduler node of a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0037] Some example embodiments specify that the network device further includes components for: acquiring updated task utility information for at least one task to be performed by at least one wireless controlled device; acquiring updated wireless link utility information for at least one wireless link to be allocated to at least one task; determining an updated QoS time function for at least one task and at least one wireless link based on the updated task utility information and the updated wireless link utility information, the updated QoS time function establishing updated QoS requirements for at least one task and at least one wireless link within a second time period; and transmitting the updated QoS time function to a network scheduler node, the updated QoS time function enabling the network scheduler node to provide updated network resources to at least one wireless controlled device within a second time period based on the updated QoS requirements.

[0038] Some example embodiments specify that the network device further includes components for: receiving a QoS update request from a network scheduler node, the QoS update request being based on changes in network load detected by the network scheduler node; and, in response to the QoS update request, determining updated wireless link utility information for at least one wireless link to be allocated to at least one task to be performed by at least one wireless controlled device.

[0039] Some example embodiments specify that the network device further includes components for: detecting changes in QoS requirements as a QoS time function; sending a QoS update request to a network scheduler node in response to the detected change in QoS requirements exceeding a desired threshold; and determining, in response to the QoS update request, updated wireless link utility information for at least one wireless link to be allocated to at least one task to be performed by at least one wireless controlled device.

[0040] Some example embodiments specify that the network device further includes components for: detecting changes in QoS requirements as a QoS time function; sending a QoS update request to a network scheduler node in response to the detected changes in QoS requirements occurring at a desired time interval; and determining, in response to the QoS update request, updated wireless link utility information for at least one wireless link to be allocated to at least one task to be performed by at least one wireless controlled device.

[0041] Some example embodiments specify that the network device further includes components for: determining a task utility recommendation for at least one task to be performed by at least one wireless controlled device based on a QoS time function; and sending the task utility recommendation to at least one wireless controlled device, wherein the determined task utility recommendation enables at least one wireless controlled device to update the task utility information of at least one task.

[0042] At least one example embodiment relates to a radio access network (RAN) node.

[0043] In at least one example embodiment, the RAN node may include components for: determining radio link utility information for at least one radio link to be assigned to at least one task to be performed by at least one radio controlled device; sending the radio link utility information to a co-design interface server; obtaining the quality of service (QoS) value of at least one radio link from a core network node, the QoS value establishing QoS requirements for at least one radio link within a first time period; determining a scheduling metric for at least one radio link based on the QoS value; and providing network resources to at least one radio controlled device within the first time period based on the scheduling metric.

[0044] Some example implementations specify that the radio link utility information includes at least one of the following: available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof, and the radio link utility information and scheduling metrics change during a first time period.

[0045] Some example embodiments specify that the RAN node also includes components for: negotiating a set of QoS requirement candidates for at least one radio link with the Cooperative Design Interface Server; and negotiating a set of time-varying preference metrics corresponding to the QoS requirement candidates with the Cooperative Design Interface Server.

[0046] Some example embodiments specify that the RAN node also includes components for: receiving a QoS range renegotiation request from the Cooperative Design Interface Server; and, in response to the QoS range renegotiation request, renegotiation with the Cooperative Design Interface Server of a set of QoS requirement candidates for at least one radio link, and renegotiation with the Cooperative Design Interface Server of a set of time-varying preference metrics corresponding to the QoS requirement candidates.

[0047] Some example embodiments specify that the RAN node also includes components for: detecting changes in network load; sending a QoS range renegotiation request to the Cooperative Design Interface Server based on the changes in network load; and, in response to the QoS range renegotiation request, renegotiating a set of QoS requirement candidates for at least one radio link with the Cooperative Design Interface Server, and renegotiating a set of time-varying preference metrics corresponding to the QoS requirement candidates with the Cooperative Design Interface Server.

[0048] Some example embodiments specify that the RAN node further includes components for: determining updated radio link utility information for at least one radio link to be allocated to at least one task to be performed by at least one radio controlled device; sending the updated radio link utility information to a co-design interface server; obtaining an updated QoS value for at least one radio link, the updated QoS value establishing updated QoS requirements for at least one radio link within a second time period; determining an updated scheduling metric for at least one task based on the updated QoS value; and providing updated network resources to at least one radio controlled device within the second time period based on the updated scheduling metric.

[0049] Some example embodiments specify that the RAN node also includes components for: receiving a QoS update request from a co-design interface server; and, in response to the QoS update request, determining updated radio link utility information for at least one radio link to be assigned to at least one task to be performed by at least one radio controlled device.

[0050] Some example embodiments specify that the RAN node also includes components for: detecting changes in network load; sending a QoS update request to a co-design interface server in response to the detected changes in network load; and determining, in response to the QoS update request, updated radio link utility information for at least one radio link to be assigned to at least one task to be performed by at least one radio controlled device. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate one or more exemplary embodiments and explain these exemplary embodiments together with the specification. In the drawings:

[0052] Figure 1 An example wireless communication system according to at least one example embodiment is illustrated;

[0053] Figure 2 The illustration shows a block diagram of an example network device according to at least one example embodiment;

[0054] Figure 3 The diagram illustrates a block diagram of an example wireless controlled device according to at least one example embodiment;

[0055] Figure 4 The diagram illustrates a graph of example time-varying utility of an AGV as a function of its position over time, according to some example embodiments; and a graph of example scheduling weights of an AGV over time; and

[0056] Figures 5A to 5C An example transport flowchart according to some example embodiments is illustrated. Detailed Implementation

[0057] Various exemplary embodiments will now be described more fully with reference to the accompanying drawings, some of which illustrate exemplary embodiments.

[0058] Detailed exemplary embodiments are disclosed herein. However, the specific structural and functional details disclosed herein are for illustrative purposes only. These exemplary embodiments may be embodied in many alternative forms and should not be construed as being limited to the exemplary embodiments described herein.

[0059] It should be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term "and / or" includes any and all combinations of one or more items in the associated list.

[0060] It is understandable that when a component is described as "connected" or "coupled" to another component, it can be directly connected or coupled to the other component, or there may be intermediate components. In contrast, when a component is described as "directly connected" or "directly coupled" to another component, there are no intermediate components. Other terms used to describe the relationship between components should be interpreted in a similar manner (e.g., "between" and "directly between," "adjacent" and "next to"), etc.

[0061] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein also include the plural forms. It should also be understood that the terms “comprises,” “comprising,” “includes,” and / or “including”, when used herein, specify the presence of the stated feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0062] It should also be noted that in some alternative implementations, the functions / actions described above may not occur in the order shown in the diagram. For example, two diagrams shown consecutively may actually be executed substantially concurrently, or sometimes in reverse order, depending on the functions / actions involved.

[0063] Specific details are provided in the following description to provide a thorough understanding of the exemplary embodiments. However, those skilled in the art will understand that the exemplary embodiments can be practiced without these specific details. For example, a system may be shown in block diagrams so as not to obscure the exemplary embodiments with unnecessary details. In other instances, well-known processes, structures, and techniques may be shown without unnecessary details to avoid obscuring the exemplary embodiments.

[0064] Furthermore, it should be noted that the example embodiments can be described as processes shown in flowcharts, diagrams, data flow diagrams, structure diagrams, or block diagrams. While flowcharts can describe operations as sequential processes, many operations can be performed in parallel, concurrently, or simultaneously. Moreover, the order of operations can be rearranged. When an operation of a process completes, the process can terminate, but there may also be additional steps not included in the diagram. A process can correspond to a method, a function, a procedure, a subroutine, a subroutine, etc. When a process corresponds to a function, the termination of the process can correspond to the function returning to the calling function or the main function.

[0065] Furthermore, as disclosed herein, the term "memory" can refer to one or more devices for storing data, including random access memory (RAM), magnetic RAM, core memory, and / or other machine-readable media for storing information. The term "storage medium" can refer to one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, core memory, disk storage media, optical storage media, flash memory devices, and / or other machine-readable media for storing information. The term "computer-readable medium" can include, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying instructions and / or data.

[0066] Furthermore, the example embodiments can be implemented by combining hardware circuitry and / or software, firmware, middleware, microcode, hardware description languages, etc., with hardware (e.g., software executed by hardware). When implemented as software, firmware, middleware, or microcode, program code or code segments for performing the desired task can be stored in a machine or computer-readable medium (such as a non-transitory computer storage medium) and loaded onto one or more processors to perform the desired task.

[0067] A code segment can represent a procedure, function, subroutine, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., can be passed, forwarded, or sent via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0068] As used in this application, the terms "circuit system" and / or "hardware circuit system" may refer to one or more or all of the following: (a) a purely hardware circuit implementation (such as an implementation in an analog and / or digital circuit system only); (b) a combination of hardware circuitry and software, such as (if applicable): (i) a combination of (multiple) analog and / or digital hardware circuitry with software / firmware, and (ii) any portion of (multiple) hardware processors (including (multiple) digital signal processors), software, and (multiple) memories having software, which work together to enable a device such as a mobile phone or server to perform various functions; and (c) (multiple) hardware circuitry and / or (multiple) processors, such as (multiple) microprocessors or portions thereof, which require software (e.g., firmware) to operate, but may be absent when not required to operate. For example, a circuit system may more specifically include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field-programmable gate array (FPGA), a system-on-a-chip (SoC), a programmable logic unit, a microprocessor, an application-specific integrated circuit (ASIC), etc.

[0069] This definition of circuit system applies to all uses of the term in this application, including in any claim. As another example, as used herein, the term circuit system also covers implementations of hardware circuitry or processors (or processors) alone, or a portion thereof, and their accompanying software and / or firmware. For instance, if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0070] While various exemplary embodiments of this disclosure are discussed in conjunction with the 5G wireless communication standard for clarity and convenience, the exemplary embodiments are not limited thereto, and those skilled in the art will recognize that the exemplary embodiments can be applied to other wireless communication standards, such as the 4G standard, the Wi-Fi standard, the future 6G standard, the future 7G standard, etc.

[0071] Various example embodiments relate to a co-design interface for a cloud control system, a cloud controller for controlling at least one device via a network, a cloud control system including a co-design interface, a cloud controller and a communication scheduler, and / or a method for operating the co-design interface / cloud controller / communication scheduler / wireless controlled device, etc. A cloud control system refers to a control system for wireless controlled devices (WCDs), such as robots, AGVs, UAVs, etc., where the WCD's controller resides on a network (e.g., a cloud network, etc.), such as at an edge node of the network, and sends instructions to the WCD and / or receives feedback data (e.g., sensor data, etc.) from the WCD via the network. Compared to direct control systems where the controller is "onboard" on the controlled device, physically connected to the controlled device, and / or within direct communication range of the controlled device, the WCD is controlled by a controller connected to the WCD via at least one network. Because the controller sends data to and / or receives data from the WCD via the network, the Quality of Service (QoS) requirements for data communication (such as latency, reliability, lifetime, and service availability) must be high. For example, in industrial automation use cases, the availability requirement for communication services, or in other words, the ratio of the amount of time a task and / or service is unavailable to the amount of time a task and / or service is running, within a time budget of 0.5 milliseconds to 2 milliseconds, can be 10. -5 Up to 10 -9 Furthermore, for cyclical business models, some applications (such as motion control) require deterministic communication service availability of up to nine figures, for example, 10. -9 .

[0072] However, high QoS requirements can place extremely high resource demands on wireless communication systems. While efforts have been made to improve the quality of experience for end-user applications (e.g., WCD) by detecting network impairments and / or performance degradation at the end-user side and adjusting network traffic flows in response to network constraints (e.g., reducing the frame rate and / or video resolution of video streams sent by end-user applications), these solutions are not ideal because they are passive rather than proactive, and adjustments are only made after performance degradation is observed. For some cloud control systems, such as industrial wireless control and autonomous vehicle navigation, this passive corrective action may be insufficient due to the lack of cloud controller control, and may lead to performance failures, safety issues, and / or increased security threats, such as autonomous vehicle collisions, industrial robots injuring human operators, etc.

[0073] Therefore, a method is needed to provide a co-design interface between remotely controlled applications (e.g., WCD) and the network, which can improve and / or optimize network processes, such as improving QoS selection and / or scheduling, based on the current application objectives of the WCD. The current application objectives of the WCD can be tracked using a utility function corresponding to the time-varying and / or dynamic changes in the WCD's requirements and / or objectives, and thus, the network parameters used to achieve the application objectives and / or objectives can be dynamically and / or in real-time adjusted, taking into account both the current state of the task being performed and the network state.

[0074] For example, not every task executed by WCD requires 10. -9 The availability of WCD, and / or the fact that WCD may not want and / or need to have 10 for the entire execution task. -9 The availability of WCDs is a key factor. Conversely, a WCD might only require high availability and / or high network bandwidth for specific time periods corresponding to the performance of a particular part of the task, such as controlling the movement of an AGV when it turns. Different parts of the task might require and / or demand less network resources and / or network priority, such as controlling the movement of an AGV while it travels in a straight line at a constant speed. Furthermore, in cases where multiple WCDs can cooperate to complete a task, such as multiple robots performing different tasks on an assembly line, different robots may have different importance and / or priorities (which may change over time), and there may be interdependencies between each robot and / or between the tasks each robot is performing. Therefore, there is an expectation and / or need for a jointly designed interface that jointly processes the time-varying utility and time-varying network state of the control task (e.g., the task performed by the WCD) to determine improved and / or optimal actions to be performed on both the WCD and network sides, such as determining improved and / or optimal QoS selection and / or guarantees, scheduling weighting, and network resource allocation.

[0075] While the example embodiments are discussed in conjunction with autonomous ground vehicles, the example embodiments are not limited thereto. For example, one or more aspects of the example embodiments can be applied to controlling robot movement and / or robot operations in warehouse facilities, controlling actuators and / or other mechanical operating equipment, controlling sensors and / or safety equipment, UAVs, etc.

[0076] Figure 1 An example wireless communication system according to at least one example embodiment is illustrated.

[0077] like Figure 1As shown, the wireless communication system 1000 includes a core network 100, a data network 105, a radio access network (RAN) node 110, a collaborative design interface network node 120, an enterprise management server 130, and / or wireless controlled devices (e.g., WCDs, user equipment (UE) devices, or UEs, etc.) 140, etc. However, the example embodiment is not limited to this; for example, it may include more or fewer components. For example, the wireless communication system may include two or more RAN nodes, two or more WCDs, additional base stations, servers, routers, access points, gateways, etc.

[0078] RAN node 110 and WCD 130 can be connected via at least one wireless network, such as a cellular radio access network (e.g., a 3G radio access network, a 4G Long Term Evolution (LTE) network, a 5G New Radio (e.g., 5G) wireless network, a 6G wireless network, a WiFi network, etc.). The wireless network may include core network 100 and / or data network 105. RAN node 110 can connect to other RAN nodes (not shown) and core network 100 and / or data network 105 via wired and / or wireless networks. Core network 100 and data network 105 can be connected to each other via wired or wireless networks. Data network 105 may refer to the Internet, intranet, wide area network, etc.

[0079] According to some example embodiments, RAN node 110 may act as a relay node (e.g., an Integrated Access and Backhaul (IAB) node) and may be combined with at least one base station (and / or access point (AP), router, etc.) (not shown) using the same or different radio access technologies (e.g., WiFi, etc.) to communicate with WCD 130, etc. According to other example embodiments, the wireless communication system 1000 may also include at least one Co-design Interface node 120, and the Co-design Interface node 120 may act as an intermediary entity and / or mediator between scheduler 115 and enterprise management server 130. According to some example embodiments, enterprise management server 130 may be a controller of WCD 140, cloud controller, etc., and in example embodiments where multiple WCDs 140 exist, a single enterprise management server 130 may control two or more WCDs 140, all WCDs 140, etc., and / or control of multiple WCDs 140 may be split among multiple enterprise management servers 130, but the example embodiments are not limited thereto. Furthermore, in one or more example embodiments, the enterprise management server 130 and / or scheduler 115 may be installed on, located with, and executed by the co-design interface node 120, etc., but the example embodiments are not limited thereto.

[0080] WCD 130 can be a wirelessly controlled device, such as, but not limited to, Internet of Things (IoT) devices, sensors (e.g., thermometers, humidity sensors, pressure sensors, motion sensors, accelerometers, etc.), actuators, robotic devices, robots, drones, connected medical devices, e-health devices, smart city-related devices, security cameras, autonomous devices (e.g., autonomous vehicles, etc.), and / or any other type of fixed or portable device capable of operating according to, for example, 5G NR communication standards and / or (multiple) other wireless communication standards. Furthermore, in some example embodiments, the wireless network 1000 may also include additional UE devices, such as smartphones, tablets, desktop computers, laptops, wearable devices, etc., but the example embodiments are not limited thereto. WCD 130 can be configured to send and / or receive data according to stringent latency, reliability, and / or accuracy requirements (such as URLLC communication, TSC communication, etc.), but is not limited thereto.

[0081] The wireless communication system also includes multiple transmit / receive points (TRPs) (e.g., base stations, wireless access points, etc.), such as RAN node 110. RAN node 110 can operate according to the underlying cellular and / or radio access technology (RAT), such as 5G NR, LTE, Wi-Fi, etc. For example, RAN node 110 can be a 5G gNB node, an LTE eNB node, or an LTE ng-eNB node, etc., but the example embodiment is not limited thereto. RAN node 110 can provide wireless network services to one or more WCD devices within one or more cells (e.g., cell service area, broadcast area, service area, coverage area, etc.) surrounding the corresponding physical location of the RAN node. Figure 1 As shown, RAN node 110 can provide a single cell 110A, but is not limited to this.

[0082] Furthermore, RAN node 110 can be configured to operate in multi-user (MU) multiple-input multiple-output (MIMO) mode and / or massive MIMO (mMIMO) mode, wherein RAN node 110 uses multiple antennas (e.g., antenna panels, antenna elements, antenna arrays, etc.) and beamforming and / or beam control techniques to transmit multiple beams (e.g., radio channels, data streams, streams, etc.) in different spatial and / or frequency domains. For example, RAN node 110 may use two or more beams to transmit and / or receive transmissions, but the example embodiment is not limited thereto, and for example, the RAN node may use more or fewer beams for transmission, etc.

[0083] Furthermore, the WCD 130 can be located within the cell service area 110A and can connect to the RAN node 110, receive broadcast messages from the RAN node 110, receive paging messages from the RAN node 110, receive signaling messages from / send signaling messages to the RAN node 110, and / or access the wireless network through the RAN node 110, etc. However, the example embodiment is not limited to this; for example, one or more WCDs can connect to two or more RAN nodes and can perform carrier aggregation using one or more component carriers (CCs) from one or more RAN nodes, etc.

[0084] According to at least one example embodiment, WCD 130 may include multiple antenna panels (e.g., it may be a multi-panel UE device, etc.) and may transmit and / or receive to multiple RAN nodes (e.g., TRPs, etc.) using the same time-frequency resources and / or resources that overlap in time, but the example embodiment is not limited thereto.

[0085] According to at least one example embodiment, RAN node 110 may connect to at least one core network element (not shown) residing on core network 100, such as core network equipment, core network server, access point, switch, router, node, etc., but the example embodiment is not limited thereto. Core network 100 may provide network functions 101, such as Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Unified Data Management (UDM), User Plane Function (UPF), Authentication Server Function (AUSF), Application Function (AF), and / or Network Slice Selection Function (NSSF), and / or equivalent functions, but the example embodiment is not limited thereto.

[0086] According to some example embodiments, RAN node 110 may also include scheduler 115, but the example embodiments are not limited thereto. Scheduler 115 (e.g., a communications scheduler, radio resource management (RRM) scheduler, radio resource control (RRC) scheduler, media access control (MAC) scheduler, etc.) may communicate with the cloud controller and / or enterprise management server 130 of WCD 130. According to some example embodiments, wireless communication system 1000 may include multiple RAN nodes 110 and multiple schedulers 115 corresponding to and / or associated with each RAN node 110. For example, multiple RAN nodes 110 may use different radio access technologies (RATs), such as 5G NR, 4G, 6G, WiFi, etc., and a separate scheduler 115 may perform scheduling operations and / or functions for each of the different RATs, and / or one or more RAN nodes 110 may be located in different geographical locations, provide different cell service areas, and / or support different WCDs 130, etc., and the individual scheduler 115 may perform scheduling operations on the WCDs 130, etc. connected to each individual RAN node 110.

[0087] According to some example embodiments, the enterprise management server 130 (e.g., an enterprise management node, an enterprise management network node, etc.) may be located in the core network 100, for example, it may reside on a core network element, an edge network node, a core network device, etc., but the example embodiments are not limited thereto. Furthermore, in other example embodiments, the enterprise management server 130 may run on a UE device (not shown) and may communicate and / or interface with the scheduler 115 via a co-design interface node 120 (e.g., an intermediate network node, an intermediate network entity, etc.), and the intermediate network node may be a second RAN node, a TRP, a server, a computing device, a UE device, etc., but the example embodiments are not limited thereto. Additionally, in some example embodiments, the enterprise management server 130 may be co-located with the scheduler 115 on a RAN node 110, etc.

[0088] Scheduler 115, Enterprise Management Server 130, and / or WCD 140 can exchange information statically and / or dynamically through a desired control communication interface (e.g., Cooperative Design Interface Node 120), wherein scheduler 115 can allocate network resources for one or more control tasks (e.g., control operations, control assignments, etc.) of WCD 140 based on data provided by user applications of Enterprise Management Server 130 and / or WCD 140. According to some example embodiments, scheduler 115, Cooperative Design Interface Node 120, and WCD 140 can perform an initial handshake operation to establish radio links(s), and initial exchange of establishment parameters, etc., can be performed between user applications of WCD 140, Enterprise Management Server 130, and Cooperative Design Interface Node 120, but are not limited thereto.

[0089] For example, assuming there are multiple WCDs 140, and each WCD includes a user application for executing tasks that depend on the execution of other WCD tasks, then each WCD 140 can send task utility information related to the corresponding task it is to execute, such as an estimated total operation time of the task, an estimated completion time of the task, an estimated sampling time of the task, an estimated lifetime of the task, the operational status of the task, and at least one sensor value associated with the task, but is not limited thereto. Each task utility information parameter can change over time, but is not limited thereto.

[0090] Furthermore, user applications of WCD 140 can also evaluate and / or continuously evaluate (e.g., real-time evaluation, etc.) the tolerable QoS range for the execution of their respective current tasks based on their own data (e.g., data collected using local sensors of the WCD) and / or based on data and / or instructions received from the enterprise management server 130. The enterprise management server 130 can evaluate and / or continuously evaluate task utility information parameters received from each of the multiple WCDs, and can determine the range of operating parameters for each WCD based on the sum of information received from the multiple WCDs.

[0091] More specifically, based on factors such as the importance, priority, and / or criticality of individual tasks being performed by the WCDs, the time and / or energy consumed by each task, and the interdependencies of the tasks (e.g., tasks 1 and 2 may require the same level of QoS, but task 1 is assigned a higher priority than task 2 because task 2 depends on the completion of task 1, etc.), the enterprise management server 130 can determine and / or compute a global control utility function O(t) for all tasks being performed by multiple WCDs, such as a time-varying task utility function, but the example embodiments are not limited thereto. The enterprise management server 130 can send the task utility function O(t) to the co-design interface node 120 and / or the corresponding WCD 130, etc. For WCD 130, according to at least one example embodiment, WCD 130 can update, adjust, and / or modify its corresponding tolerable QoS range based on input received from the enterprise management server 130, and can report the updated tolerable QoS range information to the enterprise management server 130 and / or the co-design interface 120.

[0092] Concurrently, scheduler 115 may send radio link utility information (e.g., network utility information) U(t) for each radio link available to WCD 130 to the Cooperative Design Interface Node 120, such as available network resource information, channel state information, network load information, estimated future network load information, etc., but not limited to these. The Cooperative Design Interface 120 may then calculate and / or determine the time-varying QoS time function QoS(t) based on the task utility information O(t) and network utility information U(t) for each user application of the multiple WCDs 130. For example, the Cooperative Design Interface Node 120 may determine the QoS time function QoS(t) by determining the acceptable QoS range for a task and / or application based on a traffic priority metric of radio scheduling for each application, where the traffic priority metric is based on data traffic flows to / from the application, such as consecutive packets generated by and / or arriving at the application. For example, the Cooperative Design Interface 120 can determine and / or select the time-varying QoS of the task to be performed by the WCD 140 based on a lookup table stored on the Cooperative Design Interface 120 (e.g., a first QoS for WCD 130 in a first time period on the desired radio link, a second QoS for WCD 130 in a second time period on the desired radio link, etc.), which maps service priority metrics to QoS allocations assigned to the radio links for WCD 140 to complete the desired task. The Cooperative Design Interface 120 can send the allocated QoS time function QoS(t) to the scheduler 115 for implementation in its radio link scheduling with WCD 140, and can also send the QoS time function QoS(t) to WCD 140 so that user applications can adjust their operating and / or control parameters based on the expected radio link scheduling with RAN node 110. However, the example embodiment is not limited thereto, and the determination of task utility information O(t), network utility information U(t), and QoS time function QoS(t), etc., will be combined with... Figures 4 to 5C Let's discuss this in more detail.

[0093] Furthermore, the collaborative design interface 120 can also send task utility recommendations to the enterprise management server 130 and / or WCD 140. For example, the collaborative design interface 120 can determine suggestions and / or recommendations regarding the priority of a task's utility, the order in which multiple tasks are executed, the amount of resources allocated to the tasks, etc., for the enterprise management server 130 and / or WCD 140 to implement. However, the example embodiment is not limited thereto.

[0094] Although some components of the wireless communication network are shown as Figure 1 This is part of a wireless communication system, but the example embodiments are not limited thereto, and the wireless communication network may include, in addition to, Figure 1Other components not shown, which are desired, necessary and / or beneficial for the operation of the underlying network within the wireless communication system, such as access points, switches, routers, nodes, servers, gateways, etc.

[0095] Figure 2 A block diagram of an example network device and / or network node according to at least one example embodiment is illustrated. Figure 2 The network devices may correspond to RAN node 110 including scheduler 115, network devices including enterprise management server 130, and / or with Figure 1 The network device corresponding to the collaborative design interface node 120 is not limited to this example embodiment.

[0096] refer to Figure 2 The network device 2000 (e.g., a network node, etc.) may include a processing circuitry (such as processing circuitry 2100), at least one communication bus 2200, a memory 2300, at least one core network interface 2400 (e.g., a dedicated network interface, etc.), at least one wireless antenna array 2500, etc., but the example embodiment is not limited thereto. For example, the core network interface 2400 and the wireless antenna array 2500 may be combined into a single network interface, etc., or the network device 2000 may include multiple wireless antenna arrays, multiple core network interfaces, etc., and / or any combination thereof. Furthermore, the network device 2000 may also include a scheduler 115 and / or an enterprise management server 130 (e.g., a wireless controller, etc.), but is not limited thereto. The memory 2300 may include various dedicated program code, including code for executing... Figures 4 to 5C The computer-executable instructions for operations such as those described above can cause network device 2000 to perform one or more methods of the example embodiments, but the example embodiments are not limited thereto.

[0097] In at least one example embodiment, the processing circuitry 2100 may include at least one processor (and / or processor core, distributed processor, networking processor, application processor, etc.) configured to control one or more elements of the network device 2000, thereby causing the network device 2000 to perform various operations. The processing circuitry 2100 is configured to perform processing by retrieving program code (e.g., computer-readable instructions) and data from memory 2300 for processing, thereby performing dedicated control and functions for the entire network device 2000. After dedicated program instructions are loaded into the processing circuitry 2100, the processing circuitry 2100 executes the dedicated program instructions, thereby transforming the processing circuitry 2100 into a dedicated processor. According to some example embodiments, the processing circuitry 2100 may include a specially programmed FPGA, a dedicated system-on-a-chip (SoC), a dedicated ASIC, etc., specifically designed to perform operations related to… Figures 4 to 5CThe methods and functions are related, but the example embodiments are not limited thereto.

[0098] In at least one example embodiment, memory 2300 may be a non-transitory computer-readable storage medium and may include random access memory (RAM), read-only memory (ROM), and / or permanent mass storage devices, such as disk drives or solid-state drives. Memory 2300 stores program code (i.e., computer-readable instructions) related to operating network device 2000, such as combining... Figures 4 to 5C The method discussed includes at least one core network interface 2400, at least one wireless antenna array 2500, a scheduler 115, an interface 120, and / or an enterprise management server 130. Such software elements can be loaded from a non-transitory computer-readable storage medium independent of memory 2300 using a drive mechanism (not shown) connected to network device 2000 or via at least one core network interface 2400 and / or at least one wireless antenna array 2500.

[0099] In at least one example embodiment, the communication bus 2200 enables communication and data transfer between components of the network device 2000. The bus 2200 can be implemented using a high-speed serial bus, a parallel bus, and / or any other suitable communication technology. According to at least one example embodiment, the network device 2000 may include multiple communication buses (not shown), such as an address bus, a data bus, etc.

[0100] Furthermore, according to some example embodiments, for any UE device and / or WCD within the wireless range of the network node, the network device 2000 can also operate as a RAN node, such as a 4G RAN node, a 5G RAN node, etc., but the example embodiments are not limited thereto. Additionally, for at least one RAN node and / or core network 100, the network device 2000 can operate as a co-design interface node 120, an intermediate network node, an intermediate network entity, etc., but the example embodiments are not limited thereto.

[0101] Network device 2000 may also include at least one core network interface 2400 and / or at least one wireless antenna array 2500, etc. The at least one wireless antenna array 2500 may include an associated array of radio units (not shown) and may be used to transmit wireless signals, such as 4G LTE wireless signals, 5G NR wireless signals, RFID wireless signals, Bluetooth wireless signals, WiFi wireless signals, etc., to at least one WCD and / or UE device (such as WCD 130, etc.) according to a radio access technology. According to some example embodiments, the wireless antenna array 2500 may be a single antenna or multiple antennas, etc. For example, the wireless antenna array 2500 may be configured as a beam grid (GoB) that transmits multiple beams in different directions, angles, frequencies, and / or different delays, etc., but the example embodiments are not limited thereto.

[0102] Network device 2000 can communicate with a core network (e.g., backend network, backhaul network, backbone network, private network, local area network (LAN), WAN, data network, etc.) via core network interface 2400. Core network interface 2400 can be a wired and / or wireless network interface, and enables network device 2000 to transmit and / or send data to and / or from network devices on the backend network, such as adjacent network devices and / or network nodes (not shown), core network gateways (not shown), and data networks such as the Internet, intranets, WANs, LANs, etc.

[0103] Although Figure 2 An example embodiment of network device 2000 is depicted, but the network device is not limited thereto and may include additional and / or alternative architectures that may be suitable for the purposes shown.

[0104] Figure 3 A block diagram of an example wireless control device according to at least one example embodiment is illustrated. Figure 3 Example WCD3000 can correspond to Figure 1 The example implementation is WCD 130, but the example implementation is not limited to this, and WCD may adopt alternative architectures, etc.

[0105] refer to Figure 3The WCD 3000 (e.g., a robot, industrial sensor, AGV, UAV, etc.) may include a processing circuit system 3100, at least one communication bus 3200, a memory 3300, multiple wireless antennas and / or a wireless antenna panel 3400, at least one actuator 3500, at least one input / output (I / O) device 3600 (e.g., a touchscreen, microphone, camera, keyboard, mouse, speaker, etc.) and / or at least one sensor 3700 (proximity sensor (e.g., infrared proximity sensor, radar sensor, LiDAR sensor, etc.), thermometer, humidity sensor, pressure sensor, motion sensor, accelerometer, computer vision camera, etc.), but the example embodiments are not limited thereto. According to some example embodiments, the WCD 3000 may include more or fewer components, and for example, the WCD 3000 may also include at least one battery (not shown), a display panel, a geolocation sensor (e.g., GPS, etc.), but the example embodiments are not limited thereto. In addition, the actuator 3500, I / O device 3600, sensor 3700, etc. of WCD 3000 can be optional.

[0106] In at least one example embodiment, the processing circuitry 3100 may include at least one processor (and / or processor core, distributed processor, networking processor, etc.) configured to control one or more elements of the WCD 3000, thereby causing the WCD 3000 to perform operations related to a user application (e.g., Figure 5B and Figure 5C The processing circuit system 3100 is configured to perform processing by retrieving program code (e.g., computer-readable instructions) and data from memory 3300 for processing, thereby executing dedicated control and functions of the entire WCD 3000. After the dedicated program instructions are loaded into the processing circuit system 3100, the processing circuit system 3100 executes the dedicated program instructions, thereby transforming the processing circuit system 3100 into a dedicated processor. According to some example embodiments, the processing circuit system 3100 may include a specially programmed FPGA, dedicated SoC, dedicated ASIC, etc., specifically designed to perform functions related to wireless control of the WCD, but the example embodiments are not limited thereto. The dedicated FPGA / SoC / ASIC, etc., may be separate from the processing circuit system 3100 and / or may be added to the WCD 3000 after purchase (e.g., as an add-on component), executed using dedicated software installed on the user's smartphone, etc.

[0107] In at least one example embodiment, memory 3300 may be a non-transitory computer-readable storage medium and may include random access memory (RAM), read-only memory (ROM), and / or permanent mass storage devices such as disk drives or solid-state drives. Memory 3300 stores program code (i.e., computer-readable instructions) related to operating the WCD 3000, such as user applications and / or combinations thereof for operating the WCD 3000. Figures 4 to 5C The methods discussed, etc. Such software elements can be loaded using a drive mechanism (not shown) connected to the WCD 3000 or via multiple wireless antennas 3400 from a non-transitory computer-readable storage medium independent of the memory 3300.

[0108] In at least one example embodiment, at least one communication bus 3200 enables communication and data transfer / reception between elements of the WCD 3000, and / or monitoring of the status of elements of the WCD 3000, etc. The bus 3200 can be implemented using a high-speed serial bus, a parallel bus, and / or any other suitable communication technology. According to at least one example embodiment, the WCD 3000 may include multiple communication buses (not shown), such as address buses, data buses, etc.

[0109] The WCD 3000 may also include, but is not limited to, multiple wireless antenna panels 3400. The multiple wireless antenna panels 3400 may include multiple associated radio units, etc., and may be used to transmit wireless signals according to at least one desired radio access technology (such as 4G LTE, 5G NR, Wi-Fi, Bluetooth, RFID, etc.). According to some example embodiments, the WCD 3000 may transmit collected sensor data, such as current speed, current acceleration, current heading, current position, current occupancy level, desired destination, current fuel level, current temperature, access request, etc., collected by the WCD 3000 to the enterprise management server 130 at a desired time frequency (e.g., sampling time), desired travel distance, etc., but is not limited to.

[0110] Furthermore, the multiple wireless antenna panels 3400 can be configured to send and / or receive data communications to one or more RAN nodes (not shown), but the example embodiments are not limited thereto. The multiple wireless antenna panels 3400 can be located at the same or different physical locations on the body of the WCD 3000, can have the same or different orientations, can operate within the same or different frequency ranges, can operate according to the same or different radio access technologies, and so on. According to some example embodiments, the multiple wireless antenna panels 3400 can be a single antenna, or can be multiple antennas, and so on.

[0111] Although Figure 3Illustrates an example embodiment of the WCD 3000, but the WCD is not limited thereto, and they may include additional and / or alternative architectures suitable for the purposes shown.

[0112] Figure 4 Illustrates a graph of an example time-varying utility of an AGV as a function of its position over time and a graph of an example scheduling weight of the AGV over time, according to some example embodiments.

[0113] According to at least one example embodiment, as Figure 4 shown in the above figure, the utility of a WCD (such as an AGV) can vary over time as a function of its position, but the example embodiments are not limited thereto. In Figure 4 the above figure, it is assumed that there are three tasks to be completed, represented by the v_0 line, the v_1 line, and the v_2 line, where each line represents a different speed for performing the same task, where v_2 < v_1 < v_0, and where the utility value represents how close the AGV is to completing its task, e.g., the remaining time to deliver certain items at a given speed at a given position. As Figure 4 shown in the above figure, all three tasks can have the same utility value "1.0" at the (X_0, Y_0) and (X_1, Y_1) positions, but when the AGV reaches the (X_7, Y_7) position, they start to have different utility values, but the example embodiments are not limited thereto. When the utility provided by the AGV decreases and / or reduces, the enterprise management server 130 can use the time-varying utility value (such as Figure 4 the value shown in the above figure) to change the speed of the AGV, but the example embodiments are not limited thereto.

[0114] Furthermore, Figure 4 the following figure depicts the adjustment of the scheduling weight representing and / or corresponding to a business priority metric (such as a business metric, a priority metric, a preference metric, etc.) in response to the current utility value applied by the AGV (such as Figure 4 the utility value shown in the above figure), but the example embodiments are not limited thereto. For example, the scheduling weight can correspond to the same speeds v_0 to v_2 as in the above figure, and the scheduler 115 can assign a larger scheduling weight to the speed that is furthest from completion, but the example embodiments are not limited thereto.

[0115] Figure 5A Illustrates a first example transmission flowchart of QoS implementation based on a co-design interface, according to at least one example embodiment. Although Figures 5A to 5C depicts a single WCD 140, a single enterprise management server 130, and a single RAN scheduler 115, the example embodiments are not limited thereto, and there can be multiple WCD 140s, multiple enterprise management servers 130, and / or multiple RAN schedulers 115, etc.

[0116] According to at least one example embodiment, operations S5010 to S5050 correspond to the initial link establishment phase, operations S5060 to S5120 correspond to the utility collection and QoS time function QoS(t) establishment phase, steps S5130 to S5160 correspond to the QoS time function QoS(t) update cycle, and operation S5170 corresponds to the QoS time function QoS(t) renegotiation phase, but the example embodiment is not limited thereto.

[0117] In operations of S5010 and S5020, the link establishment phase can begin at WCD 140 (such as...). Figure 1 The WCD140) user application 140B, collaborative design interface node 120 (such as WCD140) Figure 2 The WCD 140 transmits task planning information and / or QoS planning information between the WCD 140 (cooperative design interface node 120) and the enterprise management server 130, etc. The task planning information may include information about the tasks(s) to be performed by the WCD 140, priority information (e.g., service priority information, preference metric information, etc.), task interdependencies, etc., but the example embodiment is not limited thereto. Furthermore, the QoS planning information may include information related to network-related information desired by the WCD 140, such as a QoS profile for completing each task or a set of QoS alternative profiles, but is not limited thereto. In operation S5030, the WCD 140 may send a connection request to the core network function 101 of the core network 100, and in operation S5040, the core network function 101 may send a radio link establishment request for the WCD 140 to the RAN scheduler 115. In operation S5050, a radio link may be established between the RAN 110, the cooperative design interface 120, and the WCD 140 based on the radio link establishment request.

[0118] In operation S5060, given the current state of the network, the cooperative design interface 120 can receive radio link utility information U(t) from the RAN scheduler 115 regarding each available radio link of the WCD 140, such as available network resource information, channel state information, network load information, estimated future network load information, etc., but not limited to this. In operation S5070, given the current state of the user application, the cooperative design interface 120 can receive task utility information O(t) for each task to be performed by the WCD 140, such as the estimated total operation time of the task, the estimated completion time of the task, the estimated sampling time of the task, the estimated lifetime of the task, the operation state of the task, at least one sensor value associated with the task from at least one wireless controlled device, etc., but the example embodiment is not limited to this. In operation S5080, the cooperative design interface 120 can calculate a time-varying priority metric for radio scheduling based on the task utility information O(t) and the radio link utility information U(t). According to at least one example embodiment, the priority metric can be calculated using the following equation, but the example embodiment is not limited to this.

[0119] [Equation 1] O(t)β×U(t)γ

[0120] Where O(t) is the task utility information over time, U(t) is the radio link utility information over time, β is the task priority weight, and γ is the link priority weight.

[0121] According to some example embodiments, in operation S5080, the calculated priority metrics can also be used by the co-design interface 120 to determine the set of service priority metrics (e.g., preference metrics, priority metrics, etc.) for each task / radio link. In addition to the implicit priority derived by using the time-domain and / or frequency-domain scheduler of each radio link's QoS (e.g., throughput, latency, packet loss, etc.), the service priority metrics can also be shared with the RAN scheduler 115 for network scheduling (e.g., link scheduling).

[0122] In other example embodiments, the QoS time function QoS(t) can be calculated for each task / link based on a determined priority metric of the task / link. QoS(t) can be calculated according to QoS... R And priority metrics, establish communication QoS requirements for tasks / links over one or more time periods, such as link reliability latency, lifetime, etc., where QoS R This is a reference range for the tolerable and / or acceptable QoS requirements of the link.

[0123] In some example embodiments, the co-design interface 120 can be used to calculate the QoS requirement candidate set and the corresponding preference set QoS(i), w i(t), where i∈{1,…,n}, where w i This refers to scheduling weights. According to some example embodiments, the QoS requirement set is negotiated and agreed upon between the scheduler 115 and the user application 140B of the WCD 140 during the radio link establishment phase, and time-varying preference metrics (e.g., priority metrics, etc.) are periodically and / or dynamically recalculated by the co-design interface 120 and exchanged with the scheduler 115, but the example embodiments are not limited to this.

[0124] Next, in operation S5090, the co-design interface 120 can send a QoS time function QoS(t) to the core network function 101 (such as PCF, SMF, etc.) and / or the enterprise management server 130 to track the performance of user application 140B of WCD 140. In operation S5100, the core network function 101 can configure the radio bearers of RAN node 110 and co-design interface 120 based on the QoS specified in the QoS time function QoS(t) for a given time period. In operation S5110, the RAN scheduler 115 can calculate and / or update scheduling metrics, such as scheduling weights, based on the received QoS of each radio bearer.

[0125] In operation S5120, RAN scheduler 115 can send a schedule with network resource allocation to WCD 140 based on the calculated scheduling metric.

[0126] After the expected time period expires, the cloud control system can execute a QoS time function QoS(t) update cycle. For example, in operation S5130, the enterprise management server 130 can send an update of the time-varying control and / or task utility information O(t) to the co-design interface 120, and in operation S5140, the WCD 140 can send an update of the QoS range requirements to the co-design interface 120 based on the current state of the task. Furthermore, in operation S5150, the RAN scheduler 115 can send an update of the time-varying state of the radio link to the co-design interface 120, such as the updated link utility information U(t). According to at least one example embodiment, these updates can be sent periodically to the co-design interface 120, or can be triggered by a significant change in the observed value compared to the expected threshold, but the example embodiment is not limited thereto.

[0127] In operation S5160, based on the updated task utility information O(t) and the updated link utility information U(t), the collaborative design interface 120 can recalculate and / or update the priority metric and assign a new QoS time function QoS(t) to each task / link pair. Optionally, in operation S5170, the updated QoS(t) can be renegotiated by the RAN scheduler 115 and the collaborative design interface 120, but the example embodiment is not limited thereto.

[0128] Figure 5B A second example transport flowchart according to at least one example embodiment is illustrated. More specifically, the second example transport flowchart illustrates an alternative QoS renegotiation process triggered and / or initiated by a co-design interface, but the example embodiment is not limited thereto.

[0129] According to at least one example embodiment, in operation S5210, for example based on the updated utility value received from WDC user application 140B and / or enterprise management server 130 and / or RAN scheduler 115 (e.g., Figure 5A Based on operations S5130 to S5150 and the expected thresholds of task utility information O(t) and link utility information U(t), the collaborative design interface 120 can determine the desired and / or necessary changes and / or updates to the QoS time function QoS(t) or QoS range. In operation S5220, the collaborative design interface 120 can send a QoS update request and / or QoS range update request to the RAN scheduler 115. In operation S5230, the RAN scheduler 115 and the collaborative design interface 120 can renegotiate the QoS range and / or QoS time function QoS(t) for each task / link pair.

[0130] Figure 5C A third example transmission flowchart according to at least one example embodiment is illustrated. More specifically, the third example transmission flowchart illustrates an alternative QoS renegotiation process triggered and / or initiated by the RAN scheduler, but the example embodiments are not limited thereto.

[0131] According to at least one example embodiment, in operation S5240, the network state may change, for example, the network load may change, network service may be interrupted, etc., and the RAN scheduler 115 may determine the desired and / or necessary change of the QoS time function QoS(t). In operation S5250, the RAN scheduler 115 may send a QoS update request and / or a QoS range update request to the co-design interface 120. In operation S5260, the RAN scheduler 115 and the co-design interface 120 may renegotiate the QoS time function QoS(t) and / or the QoS range based on the updated and / or current state of the network, etc.

[0132] This written description uses examples of the disclosed subject matter to enable those skilled in the art to practice the subject matter, including making and using any device or system and performing any combined methods. The patentable scope of the subject matter is defined by the claims and may include other examples that would occur to those skilled in the art. These other examples are intended to fall within the scope of the claims.

Claims

1. A network device for providing quality of service (QoS) adjustment, comprising: Memory, which stores computer-readable instructions; as well as The processing circuitry is configured to execute the computer-readable instructions to cause the network device to: Obtain task utility information for at least one task to be performed by at least one wirelessly controlled device. Obtain radio link utility information for at least one radio link to be assigned to the at least one task. Based on the task utility information and the wireless link utility information, a Quality of Service (QoS) time function is determined for the at least one task and the at least one wireless link. This QoS time function establishes QoS requirements for the at least one task and the at least one wireless link within a first time period. The QoS time function is transmitted to the network scheduler node, the core network node, and the enterprise management server. The QoS time function enables the network scheduler node to provide network resources to the at least one wireless controlled device within the first time period based on the QoS requirements.

2. The network device of claim 1, wherein in response to transmitting the QoS time function, the network device is further configured to: Receive QoS allocation information for the at least one radio link from the core network node.

3. The network device according to any one of claims 1 to 2, wherein The task utility information includes at least one of the following: At least one estimated total operation time of the at least one task, at least one estimated time to complete the at least one task, at least one estimated sampling time of the at least one task, at least one estimated survival time of the at least one task, at least one operating state of the at least one task, at least one sensor value associated with the at least one task from the at least one wirelessly controlled device, or any combination thereof; The wireless link utility information includes at least one of the following: Available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof; and The task utility information and the wireless link utility information change during the first time period.

4. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Calculate O(t)β×U(t)γ, Where O(t) is the task utility information over time, U(t) is the radio link utility information over time, β is the task priority weight, and γ is the link priority weight; and Based on the results of the calculation, a set of service priority metrics is set for each combination of the at least one task and the at least one wireless link to be performed.

5. The network device according to any one of claims 1 to 2, wherein the network device is further configured to determine the QoS time function by: Negotiate with the network scheduler node a set of QoS requirement candidates for the at least one task and the at least one radio link; A set of time-varying preference metrics that are negotiated with the network scheduler node and correspond to the QoS requirement alternatives; as well as The QoS time function is determined based on the QoS requirement candidate set and the time-varying preference metric set.

6. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Receives a QoS range renegotiation request from the network scheduler node, the QoS range renegotiation request being based on changes in network load detected by the network scheduler node; and In response to the QoS range renegotiation request, the network scheduler node renegotiation is performed on the QoS requirement candidate set for the at least one task and the at least one radio link, and the network scheduler node renegotiation is performed on the time-varying preference metric set corresponding to the QoS requirement candidate.

7. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Detect changes in the QoS requirements of the QoS time function; Based on the change in the QoS requirements, a QoS range renegotiation request is sent to the network scheduler node; and In response to the QoS range renegotiation request, the network scheduler node renegotiation is performed on the QoS requirement candidate set for the at least one task and the at least one radio link, and the network scheduler node renegotiation is performed on the time-varying preference metric set corresponding to the QoS requirement candidate.

8. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Obtain updated task utility information for the at least one task to be performed by the at least one wirelessly controlled device; Obtain updated radio link utility information for at least one radio link to be assigned to the at least one task; Based on the updated task utility information and the updated radio link utility information, an updated QoS time function for the at least one task and the at least one radio link is determined, and the updated QoS time function establishes updated QoS requirements for the at least one task and the at least one radio link within a second time period. as well as The updated QoS time function is transmitted to the network scheduler node, which enables the network scheduler node to provide updated network resources to the at least one wireless controlled device within the second time period based on the updated QoS requirements.

9. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Receive a QoS update request from the network scheduler node, the QoS update request being based on changes in network load detected by the network scheduler node; and In response to the QoS update request, the updated wireless link utility information is determined for the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device.

10. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Detect changes in the QoS requirements of the QoS time function; In response to the detected change in the QoS requirement exceeding a desired threshold, a QoS update request is sent to the network scheduler node; and In response to the QoS update request, the updated wireless link utility information of the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device is determined.

11. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Detect changes in the QoS requirements of the QoS time function; In response to the detected change in the QoS requirement occurring at a desired time interval, a QoS update request is sent to the network scheduler node; and In response to the QoS update request, the updated wireless link utility information of the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device is determined.

12. The network device according to any one of claims 1 to 2, wherein the network device is further configured to: Based on the QoS time function, a task utility recommendation is determined for the at least one task to be performed by the at least one wirelessly controlled device; and The task utility recommendation is sent to the at least one wireless controlled device, and the determined task utility recommendation enables the at least one wireless controlled device to update the task utility information of the at least one task.

13. A radio access network (RAN) node for scheduling based on quality of service, comprising: Memory, which stores computer-readable instructions; as well as The processing circuitry is configured to execute the computer-readable instructions to cause the RAN node to: Determine the wireless link utility information of at least one wireless link to be assigned to at least one task to be performed by at least one wireless controlled device. Send the wireless link utility information to the collaborative design interface server. The Quality of Service (QoS) value of the at least one radio link is obtained from the core network node, and the QoS value establishes the QoS requirements for the at least one radio link within a first time period. The scheduling metric for the at least one wireless link is determined based on the QoS value, and Based on the scheduling metric, network resources are provided to the at least one wireless controlled device during the first time period.

14. The RAN node according to claim 13, wherein The wireless link utility information includes at least one of the following: Available network resource information, channel state information, network load information, estimated future network load information, or any combination thereof; and The wireless link utility information and the scheduling metric change during the first time period.

15. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured such that: Negotiate the QoS requirement candidate set for the at least one wireless link with the collaborative design interface server; and The time-varying preference metric set negotiated with the collaborative design interface server and corresponding to the QoS requirement alternatives.

16. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured to: Receive a QoS range renegotiation request from the collaborative design interface server; and In response to the QoS range renegotiation request, the set of QoS requirement candidates for the at least one radio link is renegotiated with the Cooperative Design Interface Server, and the set of time-varying preference metrics corresponding to the QoS requirement candidates is also renegotiated with the Cooperative Design Interface Server.

17. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured such that: Detect changes in network load; Based on the changes in network load, a QoS range renegotiation request is sent to the collaborative design interface server; and In response to the QoS range renegotiation request, the set of QoS requirement candidates for the at least one radio link is renegotiated with the Cooperative Design Interface Server, and the set of time-varying preference metrics corresponding to the QoS requirement candidates is also renegotiated with the Cooperative Design Interface Server.

18. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured such that: Determine the updated wireless link utility information of the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device; Send the updated wireless link utility information to the collaborative design interface server; Obtain an updated QoS value for the at least one wireless link, wherein the updated QoS value establishes updated QoS requirements for the at least one wireless link within a second time period; The updated scheduling metric for the at least one task is determined based on the updated QoS value; as well as Based on the updated scheduling metrics, updated network resources are provided to the at least one wireless controlled device during the second time period.

19. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured such that: Receive QoS update requests from the collaborative design interface server; and In response to the QoS update request, the updated wireless link utility information of the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device is determined.

20. The RAN node according to any one of claims 13 to 14, wherein the RAN node is further configured to: Detect changes in network load; In response to the detected change in network load, a QoS update request is sent to the collaborative design interface server; and In response to the QoS update request, the updated wireless link utility information of the at least one wireless link to be assigned to the at least one task to be performed by the at least one wireless controlled device is determined.

21. A method for operating a network device to provide quality of service adjustment, comprising: Obtain task utility information for at least one task to be performed by at least one wirelessly controlled device; Obtain radio link utility information for at least one radio link to be assigned to the at least one task; Based on the task utility information and the wireless link utility information, a quality of service (QoS) time function is determined for the at least one task and the at least one wireless link, and the QoS time function establishes QoS requirements for the at least one task and the at least one wireless link within a first time period; as well as The QoS time function is transmitted to the network scheduler node, the core network node, and the enterprise management server. The QoS time function enables the network scheduler node to provide network resources to the at least one wireless controlled device within the first time period based on the QoS requirements.

Images