Systems and methods for profiling low latency applications using telemetry

Abstract

The described embodiments provide systems and methods for profiling low latency applications using telemetry. A data processing system may include one or more processors and a memory. The data processing system may receive telemetry data for a plurality of packet flows. The data processing system may use the telemetry data to determine a bandwidth variance, a packet length variance, and an inter-packet arrival time variance for each of the packet streams. The data processing system may determine an application type for a stream of the packet streams based at least on characteristics of the bandwidth variance, the packet length variance, and the interval of arrival time variance for the stream. The data processing system may take one or more actions to provide quality of service for the stream according to an application type in response to determining the application type.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 607,396, filed on Dec. 7, 2023, the disclosure of which is hereby incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to systems and methods for communication, including but not limited to communication associated with Internet Service Provider (ISP) networks, cable modems, Gigabit Passive Optical Network (GPON) devices, set-top boxes, televisions, user devices, Ethernet network devices, and / or wireless devices. Some embodiments in the present disclosure relate to using telemetry to profile low-latency applications for such communication and / or controlling devices and networks for low-latency operation. Background Art

[0004] Latency issues in communication between a home network and an ISP can lead to various challenges and disruptions in Internet connectivity and user experience, especially for evolving low-latency uses, including but not limited to video conferencing, cloud gaming, augmented reality / virtual reality (AR / VR) applications, and metaverse applications.

[0005] An ISP is a company that provides Internet access to individuals and businesses. ISPs typically own, lease, and manage the network infrastructure that connects users to the Internet. This infrastructure can include various components, such as data centers, routers, switches, coaxial cables, and fiber optic cables. ISPs obtain Internet connectivity from larger networks, such as backbone providers or Internet Exchange Points (IXPs), and distribute communication services to their customers.

[0006] Latency can be associated with one or more parties (e.g., cloud providers, ISPs, application developers, and silicon vendors) and one or more devices and networks, including but not limited to ISP networks, cable modems, GPON devices, set-top boxes, WiFi networks, Ethernet, access networks, backbone networks, and cloud infrastructure. To support Internet speeds, ISPs are using larger burst data communications, which typically require larger buffers at each node. Larger bursts / buffers can increase communication latency.

[0007] Latency can manifest as slow response times (e.g., when loading a web page, streaming a video, or downloading a file), reduced quality of real-time applications (e.g., low-latency applications that rely on real-time communication, such as video conferencing, Voice over Internet Protocol (VoIP) calls, and online games), buffering and interruptions in streaming, unstable connections, adverse effects on cloud-based services (e.g., file storage, email, and productivity tools, affecting production and efficiency), increased vulnerability to network attacks, and limited capacity of interactive applications (e.g., limiting the effectiveness of interactive applications that require real-time user input, such as online collaboration tools, virtual classrooms, and remote desktop applications). High latency can result in unstable video / audio playback, laggy conversations, and delayed responses in online games, leading to a poor user experience and communication difficulties. High latency can cause data packets to arrive out of order or be delayed, resulting in playback pauses and degraded streaming quality. High latency can give attackers more time to exploit security vulnerabilities and launch malicious attacks, such as Distributed Denial of Service (DDoS) attacks or Man-in-the-Middle (MitM) attacks. SUMMARY OF THE INVENTION

[0008] This Summary of the Invention is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary of the Invention is not intended to identify key features or essential features nor is it intended to limit the scope of the claims included herein.

[0009] In certain communication systems, various devices may be interconnected or communicatively coupled to each other to perform the transmission, reception, or exchange of data via a network. Individual devices may include or be installed with at least one (network) application program that can be executed by the respective device. The application program may allow or facilitate the exchange of data between various devices within the network, including the transmission or reception of data packet flows. Different types of application programs may be utilized, ranging from basic data exchange to latency-sensitive audio and video streaming and other broad functionality. Such latency-sensitive application programs may be referred to as low-latency applications or real-time applications. Low-latency applications may be designed to operate with a relatively short response time to ensure near-instantaneous communication and interaction between users or devices, e.g., for video or audio streaming, online games, teleconferencing, virtual reality simulations, etc.

[0010] In some aspects, when various network devices or equipment in the communication path of an application's (e.g., a low-latency application's) traffic flow can provide or support low-latency services, low end-to-end latency can be configured or provided for the application. However, it may be difficult to identify whether a data stream is from a low-latency application (as opposed to a non-low-latency or non-real-time application) to provide low-latency services. For example, within a complex network infrastructure, each device may execute different applications with different latency requirements. While some applications may tolerate relatively high latency, other applications require near-instantaneous response times to maintain a seamless user experience. Given different types of applications, the available packet header fields of data packets (e.g., as part of at least one data stream) may lack identifiable or reliable information about the application or the priority level of the application. Thus, it may be difficult for network nodes to use packet header information to accurately identify or classify low-latency applications to provide low-latency services.

[0011] In addition, it can be challenging to determine whether certain devices or equipment support low-latency services (e.g., latency-sensitive data streams). For example, some network equipment may be owned or managed by a client and may not be managed by the network operator. In some cases, the network operator may not have information about network devices owned or managed by the client, e.g., to determine whether the network equipment can provide low-latency services. This network equipment may lack support for resource reservation for latency-sensitive data streams (e.g., audio or video streams). Thus, systems and methods of a technical solution can provide the features and operations discussed herein to profile, identify, or detect low-latency applications using telemetry information from data streams.

[0012] The system and method of this technical solution can use the collected real-time telemetry information to perform traffic analysis. For example, the system can collect the telemetry information of individual data streams. Each data stream can be identified or defined by at least a 5-tuple included in the data packets of the data stream. The system can perform a lookup in the database to determine whether an entry (e.g., 5-tuple) associated with the flow exists in the database. The system can update the counter associated with the existing flow, or learn a new flow and add the flow to the database based on whether the new flow exists in the database. The system can update the counter of the existing flow to determine or generate the telemetry data of the flow, such as but not limited to the bandwidth of the flow, the average packet length, or the average inter-arrival time of the packets. The system can periodically calculate one or more variances using the telemetry data to profile the flow and other flows, for example, to determine whether the flow is delay-sensitive or non-delay-sensitive (or delay-insensitive). Based on the profiled flow, the system can determine whether the application associated with the corresponding flow is a low-latency application or other types of applications (e.g., non-low-latency applications). In response to determining that the application is a low-latency application, the system can perform or take one or more actions discussed herein based on the application type to ensure the quality of service (QoS) and prevent packet loss of the profiled flow.

[0013] In one aspect, the present disclosure relates to a method for profiling low-latency applications using telemetry. The method can include receiving, by a data processing system including one or more processors and a memory, telemetry data of a plurality of packet flows. The method can include determining, by the data processing system, the bandwidth variance, the packet length variance, and the inter-arrival time variance between packets of each of the plurality of packet flows using the telemetry data. The method can include determining, by the data processing system, the application type of the flow based at least on the characteristics of the bandwidth variance, the packet length variance, and the inter-arrival time variance of the flow among the plurality of packet flows. The method can include taking, by the data processing system, one or more actions in response to determining the application type to provide quality of service for the flow according to the application type.

[0014] The method can include determining, by the data processing system, that the application type is one of a low-latency application or a real-time application. The method can include periodically receiving, by the data processing system, the telemetry data. The method can include periodically determining, by the data processing system, the bandwidth variance, the packet length variance, and the inter-arrival time variance between packets of each of the plurality of packet flows. The method can include tracking, by the data processing system, the changes in the bandwidth variance, the packet length variance, and the inter-arrival time variance over time.

[0015] The method may include a data processing system determining an application type of a flow based on variance of bandwidth, variance of packet length, and variance of inter-arrival time of the flow within a threshold among multiple packet flows. The method may include a data processing system determining an application type of a flow among multiple packet flows based at least on an average value of each of bandwidth, packet length, and inter-arrival time.

[0016] The method may include a data processing system determining characteristics of an application type based on variance of bandwidth, variance of packet length, and variance of inter-arrival time. Taking one or more actions may include one or more of the following: a data processing system assigning the flow to a link in a link aggregation as a destination port; the data processing system assigning the flow to a higher traffic class; the data processing system storing packets from the flow into one or more higher priority queues; the data processing system using a network traffic shaper to reduce burstiness; and the data processing system applying a traffic management or buffer policy to one or more other flows. The application type may include separate flows for each of voice, video, management, control, and data.

[0017] In one aspect, the present disclosure provides a system for profiling low-latency applications using telemetry. The system may include a data processing system including one or more processors and a memory. The data processing system may use telemetry data received for multiple packet flows to determine variance of inter-arrival time between packets of each of the multiple packet flows. The data processing system may determine an application type of the flow based at least on the variance of inter-arrival time of the flow among multiple packet flows. The data processing system may take one or more actions in response to determining the application type to provide quality of service for the flow according to the application type.

[0018] The data processing system may use the telemetry data to determine variance of packet length of each of the multiple packet flows and the application type of the flow based at least on the variance of inter-arrival time of the flow and the variance of packet length. The data processing system may use the telemetry data to determine variance of bandwidth of each of the multiple packet flows and the application type of the flow based at least on the variance of inter-arrival time of the flow and the variance of bandwidth.

[0019] The data processing system may determine an application type of a flow among multiple packet flows based on characteristics, the based on characteristics including within a threshold according to variance of bandwidth of the flow, variance of packet length, and variance of inter-arrival time. The data processing system may determine an application type of a flow among multiple packet flows based at least on an average value of inter-arrival time.

[0020] The data processing system may take one or more actions including one or more of the following in response to the application type: assign the flow to a link in a link aggregation as a destination port; assign the flow to a higher traffic class; store packets from the flow into one or more higher priority queues; use a network traffic shaper to reduce burstiness; and apply traffic management or buffer policies to one or more other flows.

[0021] In another aspect, the present disclosure relates to a system for profiling low-latency applications using telemetry. The system may include a network device among a plurality of devices, the plurality of devices transmitting a plurality of packet flows of one or more applications via the network device. The network device may use telemetry data of the plurality of packet flows to determine the inter-arrival time variance between packets of each of the plurality of packet flows. The network device may determine that the application type of the flow is a low-latency application based at least on the inter-arrival time variance of the flow among the plurality of packet flows. The network device may take one or more actions in response to determining the application type to provide quality of service for the flow according to the application type.

[0022] The network device may include a switch. The network device may determine that the application type of the flow is a low-latency application based at least on the inter-arrival time variance and bandwidth variance of the flow among the plurality of packet flows. The network device may determine that the application type of the flow is a low-latency application based at least on the inter-arrival time variance and packet length variance of the flow among the plurality of packet flows.

[0023] These and other aspects and implementations are discussed in detail below. The foregoing information and the following detailed description include illustrative examples of various aspects and implementations, and provide an overview or framework for understanding the nature and characteristics of the claimed aspects and implementations. The drawings provide an illustration and further understanding of the various aspects and implementations, and are incorporated into and form a part of this specification. Aspects may be combined, and it will be readily understood that features described in the context of one aspect of the invention may be combined with other aspects. Aspects may be implemented in any convenient form. For example, by means of a suitable computer program, which may be carried on a suitable carrier medium (computer-readable medium), the carrier medium may be a tangible carrier medium (such as a disk) or an intangible carrier medium (such as a communication signal). Aspects may also be implemented using a suitable device, which may take the form of a programmable computer running a computer program arranged to implement the aspect. As used in the specification and claims, the singular forms 'a', 'an' and 'the' include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The foregoing and other objects, aspects, features, and advantages of the present disclosure will become more apparent and better understood by reference to the following description taken in conjunction with the accompanying drawings, in which:

[0025] Figure 1A is a general schematic block diagram of a communication system according to one or more embodiments;

[0026] Figure 1B is according to one or more embodiments of Figure 1A a general schematic block diagram of a portion of the communication system illustrated in

[0027] Figure 1C is according to one or more embodiments of an Figure 1A application program communicating with the cloud infrastructure of the communication system illustrated in

[0028] Figure 1D is according to one or more embodiments of Figure 1A a general schematic flowchart of the operation of the communication system illustrated in

[0029] Figure 1E is according to one or more embodiments of Figure 1A a general schematic flowchart of the operation of the communication system illustrated in

[0030] Figure 1F is according to one or more embodiments of Figure 1A a schematic block diagram of a communication system including a server configured for augmented reality / virtual reality and / or metaverse applications, as illustrated in

[0031] Figure 2A A block diagram illustrating an embodiment of a computing device according to one or more embodiments;

[0032] Figure 2B A block diagram illustrating a computing environment depicting a client device communicating with a cloud service provider, according to one or more embodiments;

[0033] Figure 3 is a block diagram of an example system for profiling low-latency applications using telemetry, according to one or more embodiments;

[0034] Figure 4 is an example deployment of a client-owned access point, according to one or more embodiments;

[0035] Figure 5 is an example deployment of software-defined Ethernet video (SDVoE) for an audiovisual (AV) network, according to one or more embodiments;

[0036] Figure 6Describe example information of a voice stream from an application in a network according to one or more embodiments;

[0037] Figure 7 Describe example information of an encrypted service from an application in a network according to one or more embodiments; and

[0038] Figure 8 Is an example flowchart of a method for profiling a low-latency application using telemetry according to one or more embodiments.

[0039] When understood in conjunction with the accompanying drawings, the features and advantages of the present solution will become more apparent from the following detailed description, in which like reference numerals throughout identify corresponding elements. In the figures, like reference numbers generally indicate equal, functionally similar, and / or structurally similar elements. Detailed Description

[0040] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. Of course, these specific examples are merely examples and are not intended to be limiting. For example, in the following description, a first feature that communicates with or is communicatively coupled to a second feature may include embodiments in which the first feature communicates directly with the second feature or is directly coupled to the second feature, and may also include embodiments in which additional features may intervene between the first and second features such that the first feature communicates indirectly with or is indirectly coupled to the second feature. Additionally, in various examples, the present disclosure may repeat element symbols and / or letters. This repetition is for purposes of simplicity and clarity and does not in itself indicate a relationship between the various embodiments and / or configurations being discussed.

[0041] The entire content of the following IEEE standards, including any draft versions of such standards, are incorporated herein by reference and become part of the present disclosure for all purposes: IEEE 802.11 TM 、IEEE 802.14 TM 、IEEE P802.3 TM and the IEEE Ethernet standard system, including but not limited to LRM, VSR, SR, MR, LR, ZR, and KR. Although aspects of these standards may be referenced in the present disclosure, the present disclosure is in no way limited by these standards.

[0042] In some embodiments, devices, mobile phones, OTT devices, and cloud gaming clients provided by AR / VR setups owned by ISPs and customers are configured for low-latency use. Some embodiments of the systems and methods disclosed herein provide real-time or near-real-time systems to monitor end-to-end latency. In some applications, the Precision Time Protocol (PTP) synchronization protocol is used in conjunction with timestamps of applications at intermediate nodes and terminal devices for latency monitoring. In some embodiments, latency is monitored end-to-end such that the latency of all devices within the entire end-to-end process is considered, enabling the identification of the sources of a large amount of latency.

[0043] In some embodiments, the systems and methods achieve synchronization of wall clocks across all nodes and end-user devices by employing timestamps of low-latency data packets at each node. The determination of latency at each node is performed by the application at each node. The determination of latency is reported back to a server that communicates with the application. The systems and methods allow the communication system to distinguish whether the latency is from the home network, the ISP, or the cloud server.

[0044] In some embodiments, a latency application server extension is integrated into a modem or router provided by the ISP. In some embodiments, the server extension has the ability to filter all necessary information and transmit it to the ISP's cloud server or share open data with application developers. In some embodiments, the server extension can store or receive information about a customer's low-latency plan subscription and can track low-latency usage within the home.

[0045] In some embodiments, a server extension can refer to a software component or module that extends the functionality of a server application (e.g., a latency application). Server extensions can be used in various server environments, such as web servers, application servers, ISP servers, and database servers, to enhance their capabilities or add specific features customized to the needs of users or applications, and can be installed using extension files. Extensions can be installed on any of the devices discussed herein. In some embodiments, extensions are provided on an ISP-controlled server in the cloud, an ISP-controlled modem or access point, a third-party WiFi access point, a third-party modem, or a low-latency device provided by the ISP.

[0046] In some embodiments, the server extension allows users to select device applications for different latency handling. A server within a residence can use classifiers and queues to reduce the latency of low-latency devices. In some embodiments, the server can be part of a router, set-top box, hub, etc. In some embodiments, the server extension supports multi-party participation for end-to-end use (e.g., cloud managers, ISPs, application developers, and silicon vendors).

[0047] Regarding latency, generally, in some embodiments, latency refers to the amount of time it takes for a system, application, or device to process a request and respond to the request. Regarding low latency, in some embodiments, low latency means that this amount of time is within a threshold, performance level, user experience level, or requirements of an application or usage. The threshold, performance level, user experience level, or requirements of an application can vary based on context, such as the type of application and / or use case and the system, network, and computer environment in which such use cases and / or application operations or executions occur. From the perspective of a computing environment, low latency refers to the ability of a computing system or network to provide such a response for a context or use case for providing a response without unacceptable or inappropriate delay or with minimal delay. System criteria and application parameters can affect the threshold for low latency. The threshold can be fixed or variable (e.g., depending on conditions or actual needs or requirements at a particular time). Regarding low-latency networks and systems in the context of networks and network communications, low latency describes computer networks, systems, and environments that are designed, configured, and / or implemented to support application, network traffic, and processing operations to reduce, improve latency, or meet a low-latency threshold. End-to-end latency refers to the latency between two points in a network or communication system. The two points can be a data source and a data consumer, or in some embodiments, intermediate points between a data source and a data consumer.

[0048] In some embodiments, a low-latency device refers to any hardware, device component, or system with low-latency considerations or requirements. Low-latency devices can be telecommunications, remote control systems, gaming, audio processing, financial transactions, augmented reality, and / or virtual reality devices where latency can affect the user experience or system performance. In some embodiments, there can be levels of low-latency requirements, where one low-latency device has more stringent requirements than another low-latency device. In some embodiments, a low-latency path refers to a path for low-latency operations. In some embodiments, latency data refers to any indication of latency associated with communication or configuration data for low-latency operations or controls. In some embodiments, a low-latency application refers to an application that uses or performs low-latency operations. Low-latency devices or software programs can be used to perform low-latency operations (video conferencing, cloud gaming, augmented reality / virtual reality (AR / VR) applications, and metaverse applications).

[0049] Some embodiments relate to a system including a first device and an application. The application operates on the first device and is configured to attach a timestamp to a first packet received by the first device. The timestamp indicates a first time when the first device received the first packet and a second time when the first device sent the first packet. In some embodiments, attaching refers to adding or appending information to a data structure (e.g., a packet).

[0050] In some embodiments, the application is configured to use timestamps to determine latency information associated with communication through a first device. The timestamp includes a first timestamp at a first time and a second timestamp at a second time. In some embodiments, the application is configured to provide a second packet that includes the latency information and transmit the second packet via a virtual communication link to a server remote from the first device. In some embodiments, the first timestamp is an ingress timestamp and the second timestamp is an egress timestamp.

[0051] In some embodiments, the timestamp is provided as part of the Precision Time Protocol. In some embodiments, the first packet is used in low-latency operations. In some embodiments, the timestamp is derived from a satellite time source. In some embodiments, the latency information includes a history of timestamps. In some embodiments, the first device is a user device, cloud infrastructure, Internet service provider infrastructure, set-top box, cable modem, or wireless router.

[0052] Some embodiments relate to a non-transitory computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to receive a first packet from a first node. The first packet includes latency information associated with a second packet provided to the first node for a low-latency application. If the latency information indicates that a latency threshold for the low-latency application has not been met, the instructions further cause the processor to provide a third packet to the first node or another node to increase the priority of packets for the low-latency application. The first node may be part of a communication system that includes a cable, fiber optic, or wireless network. The other node and the first node are in the path associated with the second packet provided to the first node for the low-latency application.

[0053] In some embodiments, the processor is located on a server remote from the first node. In some embodiments, the server communicates with Internet service provider infrastructure and the third packet is provided to the Internet service provider infrastructure. In some embodiments, the third packet is provided to the Internet service provider infrastructure, set-top box, cable modem, or wireless router.

[0054] In some embodiments, if the latency information indicates that the latency threshold for the low-latency application has been met and additional bandwidth is available, the instructions cause the processor to provide a fourth packet to the first node or another node to decrease the priority of packets for the low-latency application.

[0055] In some embodiments, the latency information includes a user identifier.

[0056] Some embodiments relate to a method of providing low-latency services. The method includes providing a first timestamp for a first packet provided to a first device. The first packet may be for reception by a low-latency device or for use in a low-latency operation. The method further includes providing a second packet containing latency information to a server remote from the first device via a virtual communication link.

[0057] In some embodiments, the method further includes providing a second timestamp for the first packet provided to the first device. In some embodiments, the first timestamp is an ingress timestamp and the second timestamp is an egress timestamp. In some embodiments, the first device includes an application configured to append the first timestamp to the first packet.

[0058] Some embodiments relate to a server. The server includes a first application configured to monitor the end-to-end latency of a network. The network includes devices. The application is configured to receive latency information from at least one of the devices. The latency information includes timestamp or time period data for packets transmitted across devices or links. Monitoring is the act of observing, checking, and / or recording performance and typically occurs over a period of time.

[0059] A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to receive a first packet from a first node. The first packet contains latency information associated with a second packet provided to the first node for a low-latency application. The instructions further cause the processor to provide a subscription offer in response to the latency information. The first node is part of a communication system including a cable, fiber optic, or wireless network. Other nodes and the first node are in a path associated with the second packet provided to the first node for the low-latency application.

[0060] In some embodiments, the first device is a set-top box, a cable modem, or a wireless router. In some embodiments, a device may refer to any device, system, or component for performing operations. A low-latency device may refer to any device capable of performing low-latency operations. In some embodiments, low-latency operations refer to operations in which a performance level, a user experience level, or requirements higher than the low-latency operations can affect an application or usage. In some embodiments, a packet refers to a data unit transmitted over a network. A packet may include a header and a payload. In some embodiments, a timestamp and latency information may be attached to a packet. In some embodiments, classify / classifying may refer to any operation for determining a classification, a grouping, or an arrangement. For example, in some embodiments, by examining an address, additional data, according to its data type, or other information, a packet may be classified for a low-latency device or application. In some embodiments, bandwidth may refer to an amount of capacity for communication. In some embodiments, priority refers to a rank, a hierarchical order, a level, or other classification. For example, in some embodiments, packets may be sorted for transmission according to a priority associated with latency requirements. In some embodiments, a cable, fiber optic, or wireless network refers to any network using one or more of fiber optic cables, coaxial cables, Ethernet cables, other wires, or wireless media.

[0061] To read the descriptions of the various embodiments below, the following descriptions of the paragraphs of the specification and their corresponding content may be helpful.

[0062] - Paragraph A describes a communication system that may be used to practice the embodiments described herein.

[0063] - Section B describes low-latency applications that may be used to practice the embodiments described herein.

[0064] - Paragraph C describes embodiments of network environments and computing environments that may be used to practice the embodiments described herein.

[0065] - Section D describes embodiments of systems and methods for profiling low-latency applications using telemetry.

[0066] A. Communication System

[0067] Network latency can significantly affect Internet connectivity, user experience, and the performance of various online applications and services. Some embodiments provide information to ISPs to address end-to-end latency issues through network optimization, infrastructure upgrades, and efficient routing to ensure a reliable and responsive Internet experience for their customers. In some embodiments, tools are provided such that the cloud servers of an ISP can collect and analyze data and can reconfigure the devices provided by the ISP, such as cable modems, GPON modems, or set-top boxes. In some embodiments, the systems and methods allow multiple parties (e.g., more than one ISP, cloud service providers, public switch operators, and application developers) to address low-latency usage, including but not limited to video conferencing, augmented reality (AR) / virtual reality (VR), and metaverse end-to-end usage. In some embodiments, the systems and methods allow multiple parties to collaborate and work together to address latency issues. In some embodiments, the systems and methods can be used with WiFi networks, Ethernet networks, modems, access networks, backbone networks, IXP, and cloud infrastructure and allow multiple teams to work together to optimize latency across various media.

[0068] In some embodiments, a latency monitor measures and reports the latency of each link, device, and end-user application. The report is provided to the controller of the path, such as an ISP, application developer, end user, etc., such that action can be taken once the low-latency requirements are not met. In some embodiments, the systems and methods provide seamless latency monitoring, analysis, and optimization. Analysis of the latency measurements and reports allows for the real-time identification of latency contributors and optimization by mapping the traffic that requires low-latency service to a low-latency queue or path. In some embodiments, the devices in the path have applications (e.g., software) for performing monitoring, analysis, and optimization. Analysis of the latency measurements and reports allows the control device to appropriately provide low-latency traffic to a low-latency queue or path. The application can communicate with a latency server (e.g., a server for the application), which coordinates operations and accumulates data based on the monitoring, analysis, and optimization operations. An application (application / app) can refer to a software program or module configured to perform a specific function or task on an electronic device.

[0069] Reference Figure 1A, the communication system 100 includes network 1002A for residences 1016A and 1018A, network 1002B for residences 1016B and 1018B, cloud infrastructure 1004, and BQUICK_TOP server 1005. The communication system 100 is advantageously configured such that information is provided to the ISP to address latency issues through network optimization, infrastructure upgrades, service upgrades, and / or efficient routing to ensure a reliable and responsive Internet experience for customers on networks 1002A and 1002B. In some embodiments, BQUICK_TOP server 1005 is configured to receive information and address latency issues. In some embodiments, BQUICK_TOP server 1005 communicates (e.g., via direct or virtual connections) with cloud infrastructure 1004 and networks 1002A and B (residences 1016A to B and 1018A to B) to share information, reports, commands, and other data. BQUICK_TOP server 1005, infrastructure 1004, and residences 1016A to B and 1018A to B can utilize any form of communication media, network, protocol, etc. to transmit data and information.

[0070] In some embodiments, cloud infrastructure 1004 includes a collection of hardware, software, networking, and other resources that enable the delivery of cloud computing services over the Internet. In some embodiments, cloud infrastructure 1004 includes physical servers, storage devices, networking equipment, and other hardware components hosted in data centers distributed across multiple geographical locations. In some embodiments, the data centers are equipped with high-performance servers, storage arrays, and networking devices to support the computing requirements of cloud services. In some embodiments, cloud infrastructure 1004 is configured to provide high-speed redundant network links, routers, switches, and content delivery networks (CDNs) for delivering low-latency, high-bandwidth content to users. In some embodiments, cloud infrastructure 1004 includes block storage devices (e.g., Amazon EBS, Azure disk storage), object storage devices (e.g., Amazon S3, Google Cloud Storage), and file storage devices (e.g., Amazon EFS, Azure Files).

[0071] Residences 1016A and 1018A may include a network associated with a first ISP, and residences 1016B and 1018B may include a network associated with the same ISP or a second ISP. In some embodiments, the networks for residences 1016A and 1018A and residences 1016B and 1018B are part of a broadband access server (BAS) network. Network 1002A includes infrastructure 1006A, a headend 1008A, a BQUICK ISP_A server 1012A, a splitter 1014A, the equipment of residence 1016A, and the equipment of residence 1018A. The equipment of residence 1018A includes an optical network unit (ONU) 1020, a user device 1022, and a television 1024. In some embodiments, the modem or optical network unit 1020 may be a fiber router, a switch, a gateway, etc., and has WiFi capabilities for the WiFi network associated with residence 1018A. In some embodiments, the optical network unit 1020 is a GPON modem or an optical network terminal (ONT). GPON is a technology that allows high-speed Internet access over an optical cable. The optical network unit 1020 converts the optical signals transmitted through the fiber optic cable into electrical and / or radio signals that can be used by the devices in residence 1018A. Although system 100 is shown to communicate via coaxial cable and optical cable, terrestrial wireless communication and satellite communication can be used in system 100. The optical network unit 1020 is typically provided by an optical network operator (ISP-A) and may be referred to as an optical network terminal. The BQUICK_TOP server 1005 and the BQUICK ISP_A server 1012A may be Broadcom analysis systems (BAS servers) that collect analysis data from various devices such as modems, set-top boxes, and other devices.

[0072] The user device 1022 is a smart phone, an AR / VR device, a tablet computer, a laptop computer, a smart watch, exercise equipment, a smart appliance, a camera, headphones, a car, other computing devices, etc. Residence 1016A may have similar devices to residence 1018A. The television 1024 and the user device 1022 communicate with the optical network unit 1020 via a wireless network or a wired connection. In some embodiments, the optical network unit 1020 may include an Ethernet router that includes wired connections to the user device 1022, a wireless modem, and the television 1024.

[0073] The headend 1008A includes a router, a switch, a server, and / or other infrastructure for communicating between the ISP infrastructure 1006A and the cloud infrastructure 1004. The ISP infrastructure 1006A includes a router, a switch, a server, and / or other infrastructure for communicating between the headend 1008A and the splitter 1014A. The splitter 1014A communicates via the infrastructure 1006A with the residential houses 1016A and 1018A over an optical fiber cable. The BQUICK ISP_A 1012A, the BQUICK_TOP server 1005 communicates with the server 1012, the infrastructure 1006A, the headend 1008A, and the residential houses 1016A and 1018A via direct or indirect communication (e.g., via the Internet).

[0074] In some embodiments, the splitter 1014A is an optical fiber splitter. The splitter 1014A can be used in an optical fiber network to divide an incoming optical signal into multiple individual signals for the residential houses 1016A and 1018A, and to combine the signals into one or more signals for the infrastructure 1006A. The splitter 1014A can be configured for a passive optical network (PON) architecture. In some embodiments, two-way communication occurs across the splitter 1014A. In some embodiments, the splitter 1014A is a conductive cable type splitter (e.g., for coaxial cables instead of optical cables). In some embodiments, the splitter 1014A includes a repeater, an amplifier, a signal conditioner, etc.

[0075] BQUICK ISP_A server 1012A is a computing device, such as a machine equipped with one or more processors, memory, and storage drives. In some embodiments, BQUICK ISP_A server 1012A delivers various services to customers of the ISP (e.g., residences 1016A and 1018A). BQUICK_TOP server 1005 is configured as a central hub responsible for managing and routing Internet traffic for its subscribers. BQUICK ISP_A server 1012A processes requests from users, such as accessing websites, sending emails, streaming content, and downloading files. BQUICK ISP_A server 1012A manages network protocols, assigns IP addresses, and facilitates communication between different devices on the Internet. BQUICK ISP_A server 1012A includes an operating system (such as Linux or Windows Server) and networking software (e.g., routing protocols (e.g., BGP, OSPF), DNS (Domain Name System) server, Dynamic Host Configuration Protocol (DHCP) server for IP address allocation, and firewall / security software to protect system 100 from network threats). BQUICK ISP_A server 1012A employs traffic shaping and Quality of Service (QoS) mechanisms to prioritize and optimize Internet traffic, ensuring a smooth and consistent user experience for all subscribers. These operations may involve managing bandwidth allocation, prioritizing certain types of traffic (e.g., VoIP or video streaming), and alleviating network congestion during peak usage periods, and may be performed in response to information from server 1012. In some embodiments, BQUICK ISP_A server 1012A uses monitoring tools or applications to continuously analyze traffic data to detect anomalies, resolve network issues, and ensure compliance with Service Level Agreements (SLAs) and regulatory requirements.

[0076] The BQUICK_TOP server 1005 is a computing device similar to servers 1012A and 1012B and is configured to communicate with servers 1012A and 1012B. In some embodiments, the BQUICK_TOP server 1005 includes software that is advantageously configured to address latency issues through network optimization, infrastructure upgrades, and efficient routing to ensure a reliable and responsive Internet experience for its customers. In some embodiments, the BQUICK_TOP server 1005 may receive logs of network activity from servers 1012A and 1012B, including but not limited to business models, usage statistics, and security events. In some embodiments, the BQUICK_TOP server 1005 employs monitoring tools to continuously analyze business data to detect anomalies, resolve network problems, and ensure compliance with service level agreements (SLAs) and regulatory requirements. In some embodiments, the BQUICK_TOP server 1005 is a platform configured to perform latency monitoring in real time, perform latency analysis in real time, and perform latency optimization in real time. In some embodiments, latency optimization is performed to provide a report indicating latency issues. In some embodiments, the BQUICK_TOP server 1005 may configure paths in networks 1002A and 1002B and control devices in networks 1002A and 1002B such that low latency requirements are met.

[0077] The BQUICK_TOP server 1005 and the BQUICK ISP_B server 1012B are similar to the BQUICK ISP_A server 1012A and are configured to operate with residences 1016B and 1018B. Residences 1016A, 1018A, 1016B, and 1018B are similar to each other and may include similar devices. Residence 1018B includes a cable modem 1030B, a set-top box 1036B, a game controller 1038, a television 1034, and a user device 1032. User device 1032 is similar to user device 1022. Headend 1008B is similar to headend 1008A, and ISP infrastructure 1006B is similar to ISP infrastructure 1006A. Televisions 1024 and 1034 are monitors, smart TVs, or other audio / video equipment. In some embodiments, networks 1002A and 1002B may include cameras, security devices, fire and safety equipment, smart appliances, etc. that communicate with infrastructures 1006A and 1006B. In some embodiments, ISP infrastructures 1006A and 1006B may each include fiber optic cables, coaxial cables, remote nodes, splitters, and other equipment for cable customers. The equipment may include amplifiers, remote physical devices or layers, and remote media access control devices or layers. Intermediate nodes in ISP infrastructures 1006A and 1006B may process data packets and monitor latency and traffic at various points in the network. In some embodiments, the BQUICK_TOP server 1005, the BQUICK ISP_B server 1012B, and the BQUICK_ISP_A server 1012A are controlled by an ISP (e.g., the respective ISP).

[0078] In some embodiments, the ISP infrastructure 1006B is coupled to residences 1016B and 1018B via coaxial cable. The cable modem 1030B is a device configured to connect the devices in residence 1018B to the ISP infrastructure 1006B. In some embodiments, the cable modem 1030 includes a computer, a router, a gateway, or other communication devices. The modem 1030 may be configured to provide a wireless network for communicating with the devices in residence 1018B. In some embodiments, repeaters, amplifiers, signal regulators, etc. may be provided on the cable associated with the modem 1030. In some embodiments, a cable modem refers to any device for communicating across a cable. The optical network unit 1020 and the modem 1030 provide a data connection to the ISP data pipe via fiber optic or cable. All devices within the home can be connected to the modem via WiFi or Ethernet for Internet connectivity. Each node within the home (e.g., router, repeater, modem, WiFi access point) may introduce latency. In some embodiments, the ONU 1020 and the modem 1030 may be any devices at a home or business that connect networked devices to the Internet data pipe provided by the ISP via coaxial cable, fiber optic cable, or digital subscriber line (DSL) or cellular connection (e.g., via a tower (e.g., 5G, LTE modem)).

[0079] The set-top box 1036 is configured to receive and decode digital television signals for viewing on the television 1034. The set-top box 1036 may be configured for gaming operations and may communicate with the game controller 1038. The set-top box 1036 may also be configured to provide Internet access, shopping services, home automation, audio features, screen mirroring, etc. In some embodiments, the set-top box 1036 includes one or more processors, memory, a dedicated graphics processing unit (GPU), and / or storage capacity for storing games, applications (apps), latency data, and recorded content. A set-top box refers to any device that connects to a television or monitor and allows a user to receive and decode video signals. In some embodiments, the set-top box may be used as an interface between the television and various broadcast media sources, such as cable television, satellite, or Internet-based streaming services. The dashed lines in the figures may represent virtual connections, and the solid lines may represent physical connections (e.g., wires or fiber optic cables).

[0080] The cloud infrastructure 1004, the headends 1008A and 1008B communicate with the Internet 1009 either virtually or directly. The headends 1008A and 1008B may be associated with buildings 111A and 111B respectively. In some embodiments, the communication system 100 is generally an end-to-end combination of networking elements for networking a home or business to the Internet 1009 (e.g., the public Internet). In some embodiments, the cloud infrastructure 1004 is a group of multiple servers, switches, and storage units. The ISP may have a data center / cloud server co-located with the headends 1008A and 1008B or a pool of dedicated links from the headends 1008A and 1008B to the cloud infrastructure 1004 and headend connections to the Internet 1009.

[0081] Although the cloud infrastructure 1004 is shown as a single block, cloud servers and data servers may be co-located with the ISP headends 1008A and / or 1008B. The cloud servers may be at a third-party private facility and the ISP may have dedicated physical links or links via the Internet 1009. Depending on congestion and server processing capabilities, the cloud infrastructure 1004 can be a source of latency. In some embodiments, the cloud server processing elements can be upgraded to support a latency monitor application (e.g., the BQUICK application) or configurable devices to support low-latency services. The headends 1008A and 1008B can be central facilities (e.g., a central office). In some embodiments, a headend refers to a facility where Internet data or audio / video content is received, processed, and routed to end subscribers (such as a residential or business owner). The headends 1008A and 1008B may have multiple switching, routing, data metering, queuing, security elements, and / or other devices that can introduce latency. The headends 1008A and 1008B may also host cable modem termination systems (CMTS) in a cable network, DSLAMs (digital subscriber line access multiplexers) in a DSL network, and OLTs (optical line terminals) in a fiber network.

[0082] The networks 1002A and 1002B are operated by one of ISP-A and ISP-B. The ISP extends its services to various residences or businesses within a community, city, or a specific area. The networks 1002A and 1002B represent two different networks served by the same or different ISPs, which may be located in the same neighborhood or in completely different regions or countries. Homeowners or business owners look for an ISP that offers services in their local area and subscribe to Internet services accordingly.

[0083] B. Application Program

[0084] System 100 advantageously includes an ISP infrastructure BQUICK application 1056A for the ISP infrastructure 1006A, a headend BQUICK application 1058A for the headend 1008A, a modem BQUICK application 1020A for the optical network unit 1020, a user device BQUICK application 1022A for the user device 1022, and a TV BQUICK application 1024A for the TV 1024. The applications 1056A, 1058A, 1020A, 1022A, and 1024A can be software applications or programs designed to perform specific tasks or provide specific functions as described herein (e.g., latency monitoring, latency analysis, and latency optimization, as well as communication and storage of associated data). The applications 1056A, 1058A, 1020A, 1022A, and 1024A can be provided on any electronic device in the communication system 100, including but not limited to servers, computers, smartphones, tablet computers, smart devices, appliances, cameras, security devices, vehicles, user devices, and other digital platforms. In some embodiments, the applications 1056A, 1058A, 1020A, 1022A, and 1024A can execute on Windows, macOS, iOS, Android, or other operating systems, or can be web-based and accessible via an Internet browser. In some embodiments, the applications 1056A, 1058A, 1020A, 1022A, and 1024A can be cross-platform, capable of executing on multiple OS environments. The applications 1056A, 1058A, 1020A, 1022A, and 1024A can be installed from various sources such as application stores, software repositories, or directly from the ISP's website. In some embodiments, the applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to communicate with the BQUICK_TOP server 1005 via a virtual connection. In some embodiments, the applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to communicate with the BQUICK_TOP server 1005 via the BQUICK ISP_A server 1012A. The applications 1056A, 1058A, 1020A, 1022A, and 1024A can be updated via the application store or via automatic updates depending on the device settings.

[0085] The BQUICK applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to facilitate integration and communication with other services or platforms, data sharing, collaboration, and / or seamless access to additional functionality. The applications 1056A, 1058A, 1020A, 1022A, and 1024A allow the optical network unit 1020, the television 1024, and the user device 1022 to monitor latency, store subscription information (e.g., classic bandwidth in megabits per second (MPPS), monitored low-latency bandwidth (MBPS), maximum jitter in milliseconds), and provide options for upgrading Internet services. In some embodiments, latency information and subscription information may be tracked based on the device, device type, user identification, application, residence identification, etc. In some embodiments, latency information may be provided to the BQUICK_TOP server 1005 in packets with timestamps. A user interface may be provided by the applications 1056A, 1058A, 1020A, 1022A, and 1024A on the optical network unit 1020, the television 1024, and the user device 1022 to upgrade or downgrade to different levels of service based on the latency information. In some embodiments, different levels of service may be provided to the latency server 150 and the BQUICK_TOP server 1005, the BQUICK ISP_A BQUICK server 1012A, or the BQUICK ISP_B BQUICK server 1012B.

[0086] The system 100 advantageously includes an ISP infrastructure BQUICK application 1056B for the ISP infrastructure 1006B, a headend BQUICK application 1058B associated with the headend 1008B, a modem BQUICK application 1030B for the modem 1030, and a set-top box BQUICK application 1036B for the set-top box. The applications 1056B, 1058B, 1030B, and 1036B are similar to the applications 1056A, 1058A, 1020A, 1022A, and 1024A. In some embodiments, when the applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A are installed or the associated devices are added to the network, the applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A register with the server 1012 as conforming to the operations described herein. The user device 1032, the television 1034, and the game controller 1038 may also include applications similar to the BQUICK applications 1022A and 1024A.

[0087] In some embodiments, the BQUICK applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A are latency applications and are configured to transmit data such that a topology report can be provided. The topology report can identify end-to-end devices / networks. In some embodiments, the latency requirements for each device are provided in the report (e.g., per device, per usage type, per user ID, or per application). In some embodiments, the report can be stored at the server 1012. The latency requirements across the topology can be used to shape traffic, prioritize flows, etc. In some embodiments, the report tracks which devices are offline such that the bandwidth reserved for the devices in some embodiments can be used for another device. In some embodiments, the report tracks whether a device is not running a low-latency (e.g., BQUICK) application but is still online such that the bandwidth reserved for the device in some embodiments can be used for other devices. In some embodiments, offline refers to a state where a device, system, or application does not actively communicate with other devices or access online resources. In some embodiments, a powered-off or sleeping device is offline. In some embodiments, a low-latency application can be offline when it is not running.

[0088] In some embodiments, low-latency packets are marked such that the applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A can process the packets and flow as low-latency streams. In some embodiments, a terminal device (e.g., the application 1024A) can send a command or request indicating that the latency requirement is not met, and in some embodiments, each application in the path (applications 1020A, 1056A, and 1058A) can process the packets for the device with a higher priority or remove traffic from the path in response to the command. Latency issues can originate from the AP, the grid, the device, or the node. Tracking the bit rate or latency at each location allows guiding the solution to the specific location of the latency problem.

[0089] Reference Figure 1B, the residence 1018B may include an access point 1031 communicating with a modem 1030, and a wireless router 1074 communicating with televisions 1034, 1035, a set-top box 1036, and user devices 1032. The access point 1031 may be integrated with the modem 1030 or may be a separate unit. The user device 1032 includes a user device BQUICK application 1032B, and the access point 1031 includes a latency access point application 1031B. The router 1074 includes a wireless router BQUICK application 1074B, the television 1034 includes a television BQUICK application 1034B, and the television 1035 includes a television BQUICK application 1035B. In some embodiments, the BQUICK_TOP server 1005, the BQUICK_ISP_A server 1012A, and the BQUICK_ISP_B server 1012B communicate virtually with the applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B. In some embodiments, a server is any computing device that provides services or resources to other computers or clients within a network.

[0090] Application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B are similar to application programs 1056A, 1058A, 1020A, 1022A, and 1024A. Application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B allow modems 1030, televisions 1034 and 1035, access points 1031, routers 1074, set-top boxes 1036, and user devices 1032, as well as other cable modem termination systems, to monitor latency, store subscription information (e.g., classic bandwidth in megabits per second (MPPS), low-latency bandwidth (MBPS), maximum jitter in milliseconds), and provide options for upgrading Internet services. A user interface may be provided on optical network unit 1020, television 1024, and user device 1022 to upgrade or downgrade to different levels of service based on latency information. In some embodiments, this capability is available even if the device is a third-party device. In some embodiments, application program 1031B or 1074B may be configured to update network topology information to BQUICK TOP server 1012, and application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B may monitor low-latency resources, request services, register devices, and request different latency handling (e.g., for video, audio, commands, downloads, etc.). In some embodiments, the devices or nodes associated with application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B may include algorithms for changing packet priorities based on time and latency requirements. Application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B may communicate using virtual or logical connections (e.g., using Internet 1009).

[0091] Access Point 1031 is a networking device that allows Wi-Fi capable devices to connect to a wired network. In some embodiments, Access Point 1031 serves as a bridge between wireless devices (such as Wireless Router 1074, Set-Top Box 1036, User Device 1032, Televisions 1034 and 1035) and a wired network infrastructure (such as Modem 1030, router, switch, and server). Wireless Router 1074 can be a networking device that provides a wireless access point for a wireless network. Wireless Router 1074 serves as a hub for a wireless local area network (LAN), allowing multiple devices within or around Residence 1018B to connect to the Internet and communicate with each other. Wireless Router 1074 can include a wireless built-in Ethernet switch that provides multiple ports for connecting wired devices. In some embodiments, a wired connection can connect Router 1074 to Access Point 1031 or Modem 1030. In some embodiments, a wireless router refers to any device that provides a wireless access point for a wireless network.

[0092] Reference Figures 1B to 1C , Applications 1030B and 1032B communicate with BQUICK_TOP Server 1005 via a logical interface. The architectures of Applications 1030B and 1032B can be used in any of Applications 1031B, 1036B, 1074B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. A logical interface is a virtual interface that represents a specific network configuration or functionality within a networking device (such as Modem 1030 or User Device 1032). In some embodiments, the logical interface is software-defined and can be created, configured, and managed within the operating system of the device. Applications 1030B and 1032B can be equipped with a modem, router, access point, mesh device, set-top box, AR / VR device, game console, phone, over-the-top device (OTT), etc. Applications 1030B, 1032B, and Cloud Infrastructure 1004 can communicate using application-to-application communication. In some embodiments, application-to-application communication is the exchange of data, messages, or commands over a network between two or more software applications running on the same device or different devices. In some embodiments, application-to-application communication enables seamless integration and collaboration between different applications, allowing them to share information, trigger actions, or synchronize states without user intervention. BQUICK_TOP Server 1012 can include an application for monitoring and / or determining end-to-end latency.

[0093] In some embodiments, the applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B, and 1032B are client-level applications. The application 1036B may be configured for the highest priority (e.g., the lowest latency application), while normal streaming latency is associated with the applications 1020A, 1024A, 1032B, 1034B, 1035B, 1032B. The applications 1037A and 1031B are node-level applications and may be configured to provide or assign priorities for the applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B, and 1032B (client-level applications) and associated devices. The application 1030B may be configured to provide or assign priorities among the application 1036B, the applications 1037A and 1031B (e.g., node-level applications), and the applications 1020A, 1024A, 1032B, 1034B, 1035B, and 1032B (e.g., client-level applications) and their associated devices. In some embodiments, cloud-level applications may include the applications 1056B and 1058B. In some embodiments, the partitioning of the applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B allows for the separation of local and cloud processing, reduction of cloud server communication and ISP bandwidth, local data storage and security, availability of local resources (including edge processing and filtering of information), and faster response to low-latency devices. In some embodiments, the application 1030B has a server extension and handles the communication between the server 1012 and the applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B, and 1032B.

[0094] In some embodiments, when the application 1030B includes a server extension, the application 1030B may be a client-level application or a cloud-level application and maintain a virtual connection to the server 1012. In some embodiments, the server extension may provide the following advantages: decoupling development from the ISP (which may help with standardization), having a direct data path from the application 1020A or 1031B to the application developer's server, maintaining local data privacy, availability of local resources (e.g., local machine learning (ML), edge processing, and filtering information), and faster response to local low-latency gadgets or devices.

[0095] In some embodiments, the applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B can achieve the synchronization of wall clocks across all nodes and end-user devices. The applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B utilize the timestamps of low-latency data packets at each node. In some embodiments, this enhancement enables the determination of the latency at each node and reporting to the server 1012. In some embodiments, by utilizing the Precision Time Protocol (PTP), the applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B can use the timestamps to distinguish whether the latency is from the home network, ISP, or cloud server. Each device can have an associated PTP clock that communicates with the application associated with the device. The per-node latency can be shared across the network so that the network can avoid devices with latency issues or can perform other operations to reduce the latency at the node (e.g., divert higher-latency traffic away from the problematic node). In some embodiments, the PTP clock can be derived from a satellite clock.

[0096] Reference Figure 1C , the applications 1030B and 1032B each include a latency module 1040, an application 1042, an application framework 1044, a library and hardware abstraction layer 1046, a driver and linux kernel 1048, and a hardware and firewall 1050. In some embodiments, the latency module 1040 is configured to control and monitor the hardware and firewall based on latency. The latency module or BQUICK module 1040 is software configured to provide the low-latency operations described herein. The application 1042 is an application for performing various operations and may include third-party applications (e.g., android software package kits (APKs)). The application framework 1044 is a set of structured software components that provide the necessary infrastructure for building and running applications.

[0097] The library and hardware abstraction layer 1046 provides a standardized interface for device drivers to interact with hardware components. The library and hardware abstraction layer 1046 allows applications and system services to access hardware functionality in a consistent manner across different devices. The library and hardware abstraction layer 1046 provides a collection of pre-written code that developers can use to perform common tasks or implement specific functionality and typically contains reusable functions, classes, or modules that provide specific capabilities.

[0098] In some embodiments, the driver and the Linux kernel 1048 act as a bridge between the hardware layer and the software layer of the system, managing system resources. In some embodiments, the driver and the Linux kernel 1048 provide basic services and facilitate communication between software processes and hardware devices. In some embodiments, the driver and the Linux kernel 1048 include software components that facilitate communication between the operating system (OS) and hardware devices.

[0099] Reference Figure 1D , function, service, process, or operation 1080 can be controlled by any one of application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A ( Figure 1A and 1B ). Operation 1080 uses classifier 1082, low-latency queue 1084, and classic queue 1086. Queues 1084 and 1086 are memories or data structures for managing packet or message flows within network device or system 100 ( Figure 1A ). In some embodiments, queue 1084 is associated with a high-performance path, and queue 1086 is associated with a low-performance path. In some embodiments, a queue refers to any structure for storing information (e.g., packets). Any networking device can have a separate queue to support low-latency traffic, and operations can be performed on any device in communication system 100 ( Figure 1A ). Application programs 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A can independently report the latency of each queue.

[0100] In some embodiments, queues 1084 and 1086 are configured as first-in, first-out (FIFO) buffers for temporarily storing packets or messages before transmission or processing. In some embodiments, queue 1084 can store messages for a high-performance path (e.g., a low-latency path), and queue 1086 can store messages for a low-performance path (e.g., a high-latency path). In some embodiments, low-latency operations can use a low-performance path, and high-latency operations can use a high-performance path, or each operation uses the same path. In some embodiments, a path refers to any communication route or channel through which data or information propagates from a source to a destination (e.g., through devices and across media). In some embodiments, a path can include intermediate components and links involved in transmitting data between two or more points in one or more networks. In some embodiments, a low-latency path refers to a path for low-latency traffic.

[0101] Classifier 1082 is a processor and / or software configured to classify or categorize network traffic based on certain criteria, such as according to latency requirements and / or priorities. In some embodiments, classifier 1082 is configured to enforce network policies, prioritize traffic (e.g., for high-performance or low-performance paths), and / or apply specific actions based on the classification results. Classifier 1082 is used to distinguish different classes of traffic (e.g., voice, video, data) and apply QoS policies to ensure that critical applications receive sufficient bandwidth and latency requirements. Classifier 1082 prioritizes traffic based on predefined criteria, thereby ensuring that important or time-sensitive applications are given priority over less critical traffic by appropriately feeding traffic to queues 1084 and 1086. In some embodiments, classifier 1082 may utilize information about customer subscriptions (e.g., device level, user level, dwelling level) to classify traffic.

[0102] Reference Figure 1E , operation 1088 can be controlled by any one of applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. Operation 1088 is similar to operation 1080 and utilizes classifier 1090, first low-latency queue 1092, second low-latency queue 1094, classic queue 1096, and priority queue 510. Queues 1092, 1094, 1096, and 1098 are for managing network device or system 100 ( Figure 1A) The memory or data structure of the grouping or message flow within. In some embodiments, queues 1092 and 1094 are associated with the high-performance path, and queue 1096 is associated with the low-performance path. In some embodiments, queue 1098 receives messages from queues 1092 and 1094 and provides messages or data to the high-performance path based on a priority scheme associated with queues 1092 and 1094. In some embodiments, classifier 1090 is similar to classifier 1082 and is configured to classify or categorize network traffic based on certain criteria (e.g., according to latency requirements) of queues 1092, 1094, and 1096. In some embodiments, classifiers 1082 and 1090 are software modules operating on a device (e.g., a server, an ISP-supplied device, a user device, etc.). In some embodiments, queues 1084, 1086, 1092, 1094, 1096, and 1098 are virtual queues provided on the memory of the device configured by operation 1080 or 1088. In some embodiments, queues 1084, 1086, 1092, 1094, 1096, and 1098 are dedicated hardware queues (e.g., FIFO memories) on the device. Classifiers 1090 and 1082 and queues 1084, 1086, 1092, 1094, 1096, and 1098 are implemented in the application layer of the device and, in some embodiments, can utilize the services and structures provided by the media access layer and the physical layer. In some embodiments, classifiers 1082 and 1090 can be configured by commands provided by BQUICK TOP server 1012 to appropriately classify low-latency traffic.

[0103] In some embodiments, applications 1080 and 1088 are configured to operate at nodes associated with devices including but not limited to ONU 1020, modem 1030, set-top box 1036, television 1024, access point 1031, user device 1032, and / or router 1074. Applications 1080 and 1088 are configured to control and / or allocate subscribed low-latency bandwidth services (e.g., 20Mbps vs. 50Mbps), track latency statistics (e.g., minimum, maximum, average latency of low-latency flows), process five-tuples (e.g., source IP address, source port, destination IP address, destination port, transport protocol) of X flows with latency and / or bandwidth requirements (where X is any integer), monitor the latency introduced by the node, provide timestamps at the ingress and egress ports, monitor buffer depth, execute boundary clock accuracy protocols (e.g., IEEE 10588-2008 standard and its extensions), and prioritize traffic among multiple low-latency clients. The monitored and measured information can be appended to packets for providing to other nodes and servers (e.g., server 1012). For example, timestamps can be applied to packets at each node or device. Latency can be determined by comparing timestamps. In some embodiments, applications 1080 and 1088 are also configured to track the status of low-latency applications and provide a user interface for controlling low-latency configurations. In some embodiments, classifier 1082 and 1090 and / or queues 1084, 1086, 1092, 1094, 1096 are configured by applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A (e.g., at each corresponding node). In some embodiments, servers 1012, 1012A, and 1012B configure classifier 1082 and 1090 and / or queues 1084, 1086, 1092, 1094, 1096 via virtual connections.

[0104] Applications 1080 and 1088 can identify the end-to-end bandwidth available for low-latency applications, provide real-time feedback on the monitored latency to the user, and adjust the latency response. In some embodiments, the adjustment can be in response to a purchased service or bandwidth upgrade. In some embodiments, applications 1080 and 1088 can be configured to provide advertisements or customer offers for low-latency resources. Applications 1080 and 1088 can address the variable latency of each user and adjust the response for latency levels at a specific time, within a specific time period, etc. In some embodiments, the latency information can be transmitted as a timestamp appended to a packet as described herein or a timestamp appended to a packet identifier (e.g., 5-tuple and sequence number) to servers 1012A, 1012B, and 1012 and applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. In some embodiments, the timestamp information can be sent to servers 1012A, 1012B, and / or 1012 via an independent virtual / logical channel.

[0105] Reference Figure 1F , the cloud infrastructure 1004 can include an application 1004A. Application 1004A is similar to applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B. The BQUICK TOP server 1012 can be configured to monitor AR / VR applications and / or metaverse applications. Applications executed on the BQUICK TOP server 1012 can perform monitoring functions. Application 1004A communicates with the BQUICK TOP server 1012. Servers 1012A and 1012B can include applications similar to application 1004A.

[0106] Using applications 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B, devices given by the ISP, customer-owned AR / VR setups, mobile phones, over-the-top (OTT) devices, and cloud gaming clients can facilitate low-latency use. Applications 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1037A, and 1032B allow the devices in residences 1018A and 1018B to interact with server extensions integrated in ONUs 1020 and (e.g., ISP-provided) modems 1030 or routers. Additionally, the server extensions have the ability to filter all necessary information and transmit it to servers 1012A and 1012B or share open data with application developers.

[0107] C. Computing Environment

[0108] Before discussing the details of embodiments of the systems and methods of the present solution, it may be helpful to discuss the computing environment in which such embodiments may be deployed.

[0109] As Figure 2A shown, the computer 2001 may include one or more processors 2003, volatile memory 2022 (e.g., random access memory (RAM)), non-volatile memory 2028 (e.g., one or more hard disk drives (HDDs) or other magnetic or optical storage media, one or more solid state drives (SSDs) (e.g., flash drives or other solid state storage media), one or more hybrid magnetic and solid state drives, and / or one or more virtual storage volumes (e.g., cloud storage devices), or a combination of such physical storage volumes and virtual storage volumes or their arrays), a user interface (UI) 2023, one or more communication interfaces 2018, and a communication bus 2050. The user interface 2023 may include a graphical user interface (GUI) 2024 (e.g., a touch screen, a display, etc.) and one or more input / output (I / O) devices 2026 (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, one or more accelerometers, etc.). The non-volatile memory 2028 stores an operating system 2015, one or more application programs 2016, and data 2017 such that computer instructions, such as the operating system 2015 and / or the application programs 2016, are executed by the processor 2003 outside of the volatile memory 2022. In some embodiments, the volatile memory 2022 may include one or more types of RAM and / or cache memory, which may provide a faster response time than main memory. Data may be input using the input devices of the GUI 2024 or received from the I / O devices 2026. The various elements of the computer 2001 may communicate via one or more communication buses shown as the communication bus 2050.

[0110] As Figure 2AThe computer 2001 shown in [description] is shown only as an example as a client, server, intermediary device, and other networked devices, and can be implemented by any computing or processing environment and by any type of machine or group of machines that can have suitable hardware and / or software capable of operating as described herein. The processor 2003 can be implemented by one or more programmable processors to execute one or more executable instructions (e.g., computer programs) to perform the functions of the system. As used herein, the term "processor" describes circuitry that performs functions, operations, or sequences of operations. The functions, operations, or sequences of operations can be hard-coded into the circuitry or soft-coded by instructions stored in a memory device and executed by the circuitry. A "processor" can perform functions, operations, or sequences of operations using digital values and / or using analog signals. In some embodiments, a "processor" can be embodied in one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multi-core processors, or general-purpose computers with associated memory. A "processor" can be analog, digital, or mixed-signal. In some embodiments, a "processor" can be one or more physical processors or one or more "virtual" (e.g., remotely located or "cloud") processors. Processors that include multiple processor cores and / or multiple processors can provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data.

[0111] The communication interface 2018 can include one or more interfaces to enable the computer 2001 to access a computer network, such as a local area network (LAN), wide area network (WAN), personal area network (PAN), or the Internet, through various wired and / or wireless or cellular connections.

[0112] In some embodiments, the computing device 2001 can execute an application program on behalf of a user of a client computing device. For example, the computing device 2001 can execute a virtual machine that provides an execution session in which the application program executes on behalf of the user or the client computing device, such as a hosted desktop session. The computing device 2001 can also execute a terminal services session to provide a hosted desktop environment. The computing device 2001 can provide access to a computing environment that includes one or more of the following: one or more application programs, one or more desktop application programs, and one or more desktop sessions in which the one or more application programs can execute.

[0113] Reference Figure 2B, depicting a computing environment 2060. The computing environment 2060 can generally be considered to be implemented as a cloud computing environment, an on-premises computing environment, or a hybrid computing environment that includes one or more on-premises computing environments and one or more cloud computing environments. When implemented as a cloud computing environment (also referred to as a cloud environment, cloud computing, or cloud network), the computing environment 2060 can provide the delivery of shared services (e.g., computer services) and shared resources (e.g., computer resources) to multiple users. For example, the computing environment 2060 can include an environment or system for providing or delivering access to multiple shared services and resources to multiple users over the Internet. Shared resources and services can include, but are not limited to, networks, network bandwidth, servers, processing, memory, storage devices, applications, virtual machines, databases, software, hardware, analytics, and intelligence.

[0114] In an embodiment, the computing environment 2060 can provide one or more resources provided by a network environment to a client 2062. The computing environment 2062 can include one or more clients 2062a through 2062n that communicate with a cloud 2068 via one or more networks 2064. The client 2062 can include, for example, a thick client, a thin client, and a zero client. The cloud 108 can include a backend platform, e.g., servers 106, storage devices, server farms, or data centers. The client 2062 can be the same as or substantially similar to Figure 2A computer 2001.

[0115] The user or client 2062 can correspond to a single organization or multiple organizations. For example, the computing environment 2060 can include a private cloud (e.g., an enterprise cloud) that serves a single organization. The computing environment 2060 can include a community cloud or a public cloud that serves multiple organizations. In an embodiment, the computing environment 2060 can include a hybrid cloud that is a combination of a public cloud and a private cloud. For example, the cloud 108 can be public, private, or hybrid. The public cloud 108 can include public servers maintained by a third party of the client 2062 or the owner of the client 2062. The servers can be located in a remote geographical location off-site, as disclosed above or otherwise. The public cloud 2068 can be connected to the servers via a public network 2064. The private cloud 2068 can include private servers physically maintained by the client 2062 or the owner of the client 2062. The private cloud 2068 can be connected to the servers via a private network 2064. The hybrid cloud 2068 can include both private and public networks 2064 and servers.

[0116] The cloud 2068 may include a backend platform, e.g., servers, storage devices, server farms, or data centers. For example, the cloud 2068 may include or correspond to a server or system remote from one or more clients 2062 to provide third-party control of a shared services and resource pool. The computing environment 2060 may provide resource pooling to serve multiple users via the clients 2062 through a multi-tenant environment or multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned in response to different demands within the respective environments. A multi-tenant environment may include a system or architecture that may provide a single instance of software, an application, or a software application to serve multiple users. In an embodiment, the computing environment 2060 may provide on-demand self-service to provide computing capabilities (e.g., server time, network storage) unilaterally across a network to multiple clients 2062. The computing environment 2060 may provide elasticity to scale out or scale in dynamically in response to different demands from one or more clients 2062. In some embodiments, the computing environment 2060 may include or provide monitoring services to monitor, control, and / or generate reports corresponding to the shared services and resources provided.

[0117] In some embodiments, the computing environment 2060 may include and provide different types of cloud computing services. For example, the computing environment 2060 may include Infrastructure as a Service (IaaS). The computing environment 2060 may include Platform as a Service (PaaS). The computing environment 2060 may include serverless computing. The computing environment 2060 may include Software as a Service (SaaS). For example, the cloud 2068 may also include cloud-based delivery, such as Software as a Service (SaaS) 2070, Platform as a Service (PaaS) 2072, and Infrastructure as a Service (IaaS) 2074. IaaS may refer to a user renting the use of infrastructure resources needed during a specified time period. An IaaS provider may provide storage, networking, servers, or virtualization resources from a large pool, allowing users to quickly scale by accessing more resources as needed. Examples of IaaS include AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Washington, RACKSPACECLOUD provided by Rackspace US, Inc., of San Antonio, Texas, Google Compute Engine provided by Google Inc. of Mountain View, California, or RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, California. A PaaS provider may provide the functionality provided by IaaS, including, for example, storage, networking, servers, or virtualization, as well as additional resources, such as operating systems, middleware, or runtime resources. Examples of PaaS include WINDOWS AZURE provided by Microsoft Corporation of Redmond, Washington, Google App Engine provided by Google Inc., and HEROKU provided by Heroku, Inc. of San Francisco, California. A SaaS provider may provide the resources provided by PaaS, which include storage, networking, servers, virtualization, operating systems, middleware, or runtime resources. In some embodiments, a SaaS provider may provide additional resources, including, for example, data and application resources.Examples of SaaS include GOOGLEAPPS provided by Google, Inc., SALESFORCE provided by Salesforce.com, Inc. of San Francisco, California, or OFFICE 365 provided by Microsoft Corporation. Examples of SaaS may also include data storage providers such as DROPBOX provided by Dropbox, Inc. of San Francisco, California, Microsoft SKYDRIVE provided by Microsoft Corporation, Google Drive provided by Google, Inc., or Apple ICLOUD provided by Apple Inc. of Cupertino, California.

[0118] Client 2062 may access IaaS resources conforming to one or more IaaS standards, including, for example, Amazon Elastic Compute Cloud (EC2), Open Cloud Computing Interface (OCCI), Cloud Infrastructure Management Interface (CIMI), or OpenStack standards. Some IaaS standards may allow a client to access resources via HTTP and may use Representational State Transfer (REST) protocol or Simple Object Access Protocol (SOAP). Client 2062 may access PaaS resources having different PaaS interfaces. Some PaaS interfaces use HTTP wrappers, standard Java APIs, Java Mail APIs, Java Data Objects (JDO), Java Persistence APIs (JPA), Python APIs, web integration APIs for different programming languages, including, for example, Rack for Ruby, WSGI for Python, or PSGI for Perl, or other APIs that may be built on REST, HTTP, XML, or other protocols. Client 2062 may access SaaS resources by using a web-based user interface provided by a web browser (e.g., GOOGLE CHROME, Microsoft INTERNET EXPLORER, or Mozilla Firefox provided by the Mozilla Foundation of Mountain View, California). Client 2062 may also access SaaS resources via a smartphone or tablet computer application, such as, for example, the Salesforce Sales Cloud or Google Drive application. Client 2062 may also access SaaS resources via a client operating system, including, for example, the Windows file system for DROPBOX.

[0119] In some embodiments, access to IaaS, PaaS, or SaaS resources may be authenticated. For example, a server or an authentication server may authenticate a user via a security certificate, HTTPS, or an API key. The API key may incorporate various encryption standards, such as the Advanced Encryption Standard (AES). Data resources may be sent via Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

[0120] Although examples of the communication systems described above may include devices operating according to Ethernet and other standards, it should be understood that embodiments of the described systems and methods may operate according to alternative standards and use wireless communication devices in addition to the devices configured as such. For example, multiple unit communication interfaces associated with cellular networks, satellite communications, vehicle communication networks, wired networks, and the Internet of Things (IoT) may utilize the systems and methods described herein without departing from the scope of the systems and methods described herein.

[0121] D. Systems and Methods for Profiling Low - Latency Application Programs Using Telemetry

[0122] In a network environment, interconnected devices such as computers, servers, routers, switches, or Internet of Things (IoT) devices and others may form a network of communication paths. These devices may communicate with each other using one or more applications that facilitate the exchange or communication of data or information. Different types of applications may be used for different purposes or functionality, ranging from basic data exchange to latency-sensitive content delivery (e.g., audio and video streaming). Applications for latency-sensitive content may be referred to as low-latency applications or real-time applications, which are designed to operate with a relatively short response time to ensure near-instantaneous communication and interaction between users or devices. Examples of low-latency applications may include, but are not limited to, video conferencing applications, online gaming applications, virtual reality (VR) simulation applications (e.g., leveraging resources from the cloud), or video or audio streaming applications, to name a few.

[0123] In certain scenarios, achieving low end-to-end latency for an application (e.g., a low-latency application) depends on network devices that support low-latency services throughout the communication path. However, differentiating between different types of applications (e.g., low-latency and non-low-latency applications) can be challenging. For example, when monitoring information from a data stream, the packet header fields of data packets may lack reliable information about the application type or priority level to determine whether to provide low-latency services. In another example, for network equipment owned or managed by a client, the network operator may lack information about the network equipment's support for low-latency services, such as support for resource reservation for latency-sensitive data streams.

[0124] The present disclosure relates to systems and methods for profiling low-latency applications using telemetry. The systems and methods of the technical solutions discussed herein may take one or more actions based on the application type. For example, the system may collect telemetry information for individual data streams. The data streams may be associated with applications executed on at least one device. Packets in the individual data streams may be identified or defined by information of a predetermined or configured type associated with one or more fields within the packet, such as but not limited to a 5-tuple from the header of a data packet. The 5-tuple may include a source Internet Protocol (IP) address, a destination IP address, a source port number, a destination port number, and a network protocol for transmitting the corresponding data stream. The network protocol may include at least one of Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), etc.

[0125] Using a 5-tuple (or other type of information), the system can determine whether a data flow is an existing flow or a new flow. A flow can contain or refer to a sequence of packets with certain shared characteristics or attributes and can be treated as a single entity. A flow can represent data communication between two endpoints (e.g., a source and a destination) across a network, which can be defined by various attributes, including but not limited to source and destination IP addresses, source and destination ports, protocol type (e.g., TCP, UDP), or other packet header fields. A flow can encapsulate data exchange between at least two network entities over a period of time, which can represent a communication session or a data transfer activity. For example, the system can search a database using the 5-tuple of one or more packets to determine whether a data flow corresponds to an existing data flow based on whether the 5-tuple matches at least one entry. If the flow is an existing flow, the system can update a counter associated with the existing flow as part of generating telemetry data. Otherwise, if the flow is a new flow, the system can learn the new flow, for example, by adding information associated with the new flow (e.g., the 5-tuple) to the database for subsequent generation of telemetry data. Although 5-tuples are used for the purpose of providing examples, it should be noted that more or fewer numbers of tuples can be used to perform the features or operations discussed herein. The system can use a counter for a specific flow to generate telemetry data, which includes but is not limited to at least one of bandwidth, average packet length, or average inter-arrival time, among others. The system can periodically calculate one or more variances using the telemetry data to profile one or more flows. Profiling one or more flows can refer to analyzing whether one or more flows contain characteristics, fingerprints, or profiles of delay-sensitive flows or delay-insensitive (or non-delay-sensitive) flows based on the variance of the telemetry data, such as relatively constant bit rate flows, relatively constant packet sizes, relatively constant average inter-arrival times, etc. In other words, the system can profile a constant bit rate flow, which can be considered a flow with a relatively minimal variance or standard deviation or a standard deviation of the telemetry data within or below a threshold (e.g., 5%, 1%, or 0.5%). In response to profiling one or more flows, the system can determine whether an application is a low-latency application or other type of application (e.g., a non-low-latency application) based on the consistency and stability of the data transfer rate and other factors discussed herein. Thus, the system can perform or take one or more predefined actions according to or based on the application type to ensure the desired QoS and prevent packet loss in the profiled flows.

[0126] Figure 3A block diagram depicting one embodiment of a system 300 for using telemetry to profile low-latency applications. The system 300 may include at least one network 301, at least one client device 302, at least one Internet service provider (ISP) 303, at least one server 304, at least one cloud 305 (e.g., a cloud network or a cloud computing device), and at least one data processing system 306 ("DPS"). These elements may generally be referred to as one or more components, elements, entities, or devices of the system 300. The system 300 may utilize the features and functionality of one or more components to perform at least one of the following: monitoring network data flows (e.g., sometimes generally referred to as streams), processing data packets, obtaining telemetry data, determining different types of applications, or performing one or more actions based on the application type. Each component may receive, transmit, or otherwise communicate information with other components of the system 300 via the network 301. The data processing system 306 may correspond to or be referred to as a computing device, an intermediate device, a network device, or a profiling system.

[0127] In some embodiments, the data processing system 306 may include, correspond to, or be part of at least one other component of the system 300, such as a client device 302, an ISP 303, a server 304, a cloud 305, or a part of another device within the network 301. In some other embodiments, the data processing system 306 may be a component different from or independent of the client device 302, the ISP 303, the server 304, and the cloud 305. In some configurations, the data processing system 306 may include or correspond to an intermediate switch between network devices that exchange data packets.

[0128] In some embodiments, one or more components of the system 300 may include, correspond to, or communicate with one or more components of the communication system 100, as combined with Figure 1Adescribed by at least one of A to F. For example, the server 304 may include or correspond to the latency server 1005. In another example, the application detector of the data processing system 306 (e.g., the application detector 318) may include or correspond to at least one of the latency applications 1004A, 1056A, 1056B, 1058A, 1058B, etc. In a further example, the data collector of the data processing system 306 (e.g., the data collector 310) may communicate with the latency server 1005 to collect or generate telemetry data using data from the latency server 1005. For example, the latency server 1005 may monitor the telemetry data and communicate the telemetry data to the data processing system 306 (e.g., received via the interface 308 of the data processing system 306). One or more components of the system 300 may include, correspond to, or communicate with other components of the communication system 100, such as the ISP infrastructure 1006A or 1006B corresponding to the ISP 303, the cloud infrastructure 1004 corresponding to the cloud 305, or the user devices 1022, 1032, or the television 1036 corresponding to the client device 302. One or more components of the system 300 may include or exhibit features or functionality similar to the corresponding one or more components of the communication system 100.

[0129] In one or more embodiments, one or more of the components discussed herein (e.g., the client device 302, the ISP 303, the server 304, the cloud 305, or the data processing system 306) may include hardware or a combination of hardware and software or be implemented in hardware or a combination of hardware and software. Each component of the system 300 may be implemented using the hardware or a combination of hardware or software detailed above in conjunction with Figure 1A at least one of A to F and 2A to B. For example, each of these components may include any application, program, library, script, task, service, process, or any type and form of executable instruction that executes on the hardware of the corresponding component to perform the features, functionality, or operations discussed herein. In one or more embodiments, the hardware includes circuitry such as one or more processors.

[0130] Network 301 may include a computer network, such as the Internet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or other regional network, an intranet, a satellite network, other computer networks (such as voice or data mobile telephone communication networks), and combinations thereof. Components of system 300 may communicate with each other via network 301. For example, data processing system 306 may communicate with at least one of client device 302, ISP 303, server 304, or cloud 305. Network 301 can be any form of computer network that can relay information between network devices or components within system 300 and others. In some embodiments, network 301 may include the Internet and / or other types of data networks, such as local area networks (LANs), wide area networks (WANs), cellular networks, satellite networks, or other types of data networks. Network 301 may also include any number of computing devices (such as computers, servers, routers, network switches, etc.) configured to receive and / or transmit data within network 301. Network 301 may further include any number of hardwired and / or wireless connections. Any or all of the computing devices described herein (such as client device 302, ISP 303, server 304, cloud 305, data processing system 306, etc.) may communicate wirelessly (such as via WiFi, cellular, radio, etc.) with transceivers hardwired (such as via fiber optic cable, CAT5 cable, etc.) to other computing devices in network 301. Any or all of the computing devices described herein (such as client device 302, ISP 303, server 304, cloud 305, data processing system 306, etc.) may also communicate wirelessly with computing devices of network 301 via a proxy device (such as a router, network switch, or gateway).

[0131] System 300 may include one or more client devices 302 communicatively coupled to a network 301. Each of the client devices 302 may include at least one processor and a memory, e.g., processing circuitry. The memory may store processor-executable instructions that, when executed by the processor, cause the processor to perform one or more of the operations described herein. The processor may include a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., or a combination thereof. The memory may include, but is not limited to, an electronic, optical, magnetic, or any other storage or transmission device capable of providing program instructions to the processor. The memory may further include a floppy disk, a CD-ROM, a DVD, a magnetic disk, a memory chip, an ASIC, an FPGA, a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable ROM (EEPROM), an erasable programmable ROM (EPROM), flash memory, an optical medium, or any other suitable memory from which the processor can read instructions. The instructions may include code from any suitable computer programming language. The client devices 302 may include or correspond to one or more computing devices or network devices capable of performing the various functions described herein. One or more of the client devices 302 may include any or all of the components and perform any or all of the functions of at least one of the user / client devices 1022, 1032, 2062 described in conjunction with but not limited to Figures 1A to 2B at least one of those described in. In some cases, one or more of the client devices 302 may include or correspond to the user / client devices 1022, 1032, 2062, e.g., as described in conjunction with Figures 1A to 2B at least one of those described in. One or more of the client devices 302 may include other devices associated with a residence, such as modems 1020, 1030, set-top boxes 1036, game controllers 1038, or other devices of at least one of the residences 1018A, 1018B described in conjunction with Figure 1A through F.

[0132] Each client device 302 may include, but is not limited to, a television device, a mobile device, a smart phone, a personal computer, a laptop computer, a game device, a kiosk, or any other type of computing device. Each client device 302 may be implemented using a combination of hardware or software and hardware. Each client device 302 may include or have installed thereon one or more applications. The one or more applications may be managed or hosted by a third-party entity or a remote device, e.g., by a server 304 or a cloud 305. The one or more applications may be executed by the respective client device 302 to establish a communication session or to allow for the exchange of data with one or more network devices via the network 301, e.g., to communicate with an ISP 303, a server 304, a cloud 305, or a data processing system 306, as well as other components of the system 300.

[0133] Each client device 302 may include a display device that can provide visual information, such as information presented as a result of executing instructions stored in the memory of the client device 302. The display device may include a liquid crystal display (LCD) device, an organic light emitting diode (OLED) display, a light emitting diode (LED) display, a bistable display (e.g., electronic ink, etc.), and others. According to the embodiments described herein, the display device may present one or more user interfaces on various regions of the display. In some embodiments, the display device may include interactive elements, such as capacitive or resistive touch sensors. Thus, the display device may be an interactive display (e.g., a touch screen, a display, etc.), and may include one or more input / output (I / O) devices or interfaces. Each client device 302 may further include one or more input devices (e.g., a mouse, a keyboard, or a numeric keypad, and others) or communicate with one or more input devices (e.g., via a communication bus coupled to the processor of the client device 302, etc.). The display may be used to present one or more application programs as described herein, such as a web browser, an email, a social networking application, a video or audio stream, a VR or AR simulation, a game application, etc. The display may include a bezel region (e.g., a side bezel, a top bezel, a bottom bezel). Input received via an input / output device (e.g., a touch screen, a mouse, a keyboard, etc.) may be detected by one or more event listeners and indicate an interaction with one or more user interface elements presented on the display device of the client device 302. The interaction may generate interaction data, which may be stored and transmitted by the processing circuitry of the client device 302 to other computing devices, such as those computing devices that communicate with the client device 302. The interaction data may include, for example, interaction coordinates, interaction types (e.g., click, swipe, scroll, tap, etc.), and an indication of the actionable object with which the interaction occurs. Thus, each client device 302 may allow / enable a user to interact with and / or select one or more actionable objects presented as part of a graphical user interface to perform various functions as described herein.

[0134] System 300 may include at least one ISP 303. The ISP 303 may correspond to or include one or more devices controlled by a company that provides Internet services to individuals and enterprises. The ISP 303 may include, for example, at least one processor and memory as described in connection with the processor and memory of the client device 302 and other devices within the system 300. The ISP 303 may include any or all components and perform any or all of the functions of at least one of the ISP infrastructures 1006A, 1006B described herein in connection with, but not limited to, Figure 1A at least one of A through F. In some cases, the ISP 303 may correspond to, for example, in connection with Figure 1AAt least one of the ISP infrastructures 1006A, 1006B described by at least one of A to F.

[0135] The ISP 303 can include hardware, software, or a combination of hardware and software components, or be composed of hardware, software, or a combination of hardware and software components. The ISP 303 can include or correspond to at least one device, such as but not limited to a data center, router, switch, coaxial cable, fiber optic cable, router, gateway, or other networking device. The ISP 303 can be an intermediate device between one or more devices within the network 301, such as an intermediate device between the client device 302 and the cloud 305. The ISP 303 can operate or function as a gateway between one or more client devices 302 and an external network resource such as the cloud 305.

[0136] The ISP 303 can facilitate communication by providing connectivity between network devices. For example, when an application executed on the client device 302 sends a request to access or communicate with at least the cloud 305 (e.g., cloud service), the ISP 303 can route or forward the request from the client device 302 to the corresponding destination through the network infrastructure (e.g., via the network 301). The destination can be indicated in the data packet of the data stream. In another example, the ISP 303 can route data transmission from the cloud 305 to one or more client devices 302 based on the destination of the data stream. The ISP 303 can manage data transmission by performing at least one load balancing technique, maintaining QoS, implementing traffic shaping techniques (e.g., adjusting the data transmission rate) to prioritize certain data streams (e.g., critical or high-priority data streams), filtering packets, performing error detection or correction, etc. The ISP 303 can perform other features or functions not limited to those discussed herein to ensure successful information exchange between network devices.

[0137] In some arrangements, the system 300 can include multiple ISPs 303. Each ISP 303 can provide network services to a corresponding group of client devices 302. For example, the first ISP can facilitate communication between the first group of client devices 302 and at least the server 304. The second ISP can facilitate communication between the second group of client devices 302 and at least the server 304 (or other servers). In various embodiments, the ISP 303 can provide features or functions as described in connection with at least one of the ISP infrastructures 1006A or 1006B.

[0138] The system 300 can include one or more servers 304. The one or more servers 304 can include, correspond to, or be, for example, in combination with at least Figure 1APart of at least one of the servers 1005, 1012A, 1012B described from A to F. For example, the server 304 can be a computing device, including one or more processors and memory. The server 304 can be composed of hardware, software, or a combination of hardware and software components. In some embodiments, the server 304 can deliver various services to the client device 302 of the ISP. The server 304 can be configured as a central hub responsible for managing and routing Internet traffic for its subscribers. The server 304 can handle requests from users, such as accessing websites, sending emails, streaming content, and downloading files, and manage network protocols, assign IP addresses, and facilitate communication between different devices on the Internet (e.g., within the network 301).

[0139] In some embodiments, the server 304 can include, correspond to, or be part of the ISP 303 (e.g., operated by the ISP). For example, the server 304 can employ traffic shaping and QoS mechanisms to prioritize and optimize Internet traffic, thereby ensuring a smooth and consistent user experience for all subscribers. These operations can involve managing bandwidth allocation, prioritizing certain types of traffic (e.g., VoIP or video streaming), and alleviating network congestion during peak usage periods, and can respond to information from another server (e.g., from the server 1005). In some embodiments, the server 304 can use monitoring tools to continuously analyze traffic data to detect anomalies, resolve network problems, and ensure compliance with service level agreements (SLAs) and regulatory requirements.

[0140] In some embodiments, the server 304 (e.g., the server 1005, similar to the server 1012A or 1012B) can manage data transmission for low-latency applications or real-time applications. In this case, the server 304 can be referred to as, for example, the latency server described in connection with Figure 1A the latency server 1005 from A to F. In some embodiments, the latency server (e.g., the low-latency server 1005) can include software that is advantageously configured to address latency issues through network optimization, infrastructure upgrades, and efficient routing to ensure a reliable and responsive Internet experience for its customers. In some embodiments, the latency service can receive logs of network activities from other servers (e.g., the server 1012A or 1012B), including but not limited to traffic patterns, usage statistics, and security events. In some embodiments, the latency server can use monitoring tools to continuously analyze traffic data to detect anomalies, resolve network problems, and ensure compliance with SLAs and regulatory requirements. In some embodiments, the latency server can be a platform configured to perform real-time latency monitoring, real-time latency analysis, and real-time latency optimization. In some embodiments, latency optimization is performed to provide a report indicating latency issues.

[0141] In some embodiments, the server 304 may be operated or managed by a service provider (e.g., the ISP of the client device), e.g., the ISP 303 may correspond to the server 304. In some other embodiments, the server 304 may be an entity different from the ISP 303, which is configured to communicate with and provide resources to one or more applications executing on the client device 302, e.g., via the ISP 303. In certain configurations, the server 304 may comprise, correspond to, or be part of the cloud 305.

[0142] The system 300 may comprise at least one cloud 305. The cloud 305 may comprise at least one processor and memory. The cloud 305 may be referred to as a cloud service, cloud storage service, third-party resource provider, or resource distributor. The cloud 305 may comprise any or all of the components and perform any or all of the functions of the cloud infrastructure 1004 described herein in connection with, but not limited to, Figure 1A at least one of A to F. In some cases, the cloud 305 may at least correspond to the cloud infrastructure 1004 described in connection with Figure 1A at least one of A to F.

[0143] For example, in some embodiments, the cloud 305 may comprise a collection of hardware, software, networking, and other resources that permit the delivery of cloud computing services over the Internet. In some embodiments, the cloud 305 may comprise physical servers, storage devices, networking equipment, and other hardware components hosted in data centers distributed across multiple geographical locations. In some embodiments, the cloud 305 may be configured to provide high-speed redundant network links, routers, switches, and a content delivery network (CDN) for delivering low-latency, high-bandwidth content to users. In some embodiments, the cloud 305 may comprise block storage devices (e.g., Amazon EBS, Azure Disk Storage), object storage devices (e.g., Amazon S3, Google Cloud Storage), and file storage devices (e.g., Amazon EFS, Azure Files).

[0144] In some embodiments, the cloud 305 may comprise or be part of the server 304. For example, the cloud 305 may comprise a remote data storage device configured to store information of the server 304. The cloud 305 may provide the server 304 with access to remote data storage. The cloud 305 may be communicatively coupled to one or more devices within the network 301. The cloud 305 may communicate with the client device 302 via the ISP 303. In some cases, the cloud 305 may provide resources to one or more applications executing on the client device 302 (or other client devices 302). In some cases, components of the system 300 (e.g., the client device 302, the ISP 303, the server 304, or the cloud 305) may communicate with the data processing system 306 via the network 301.

[0145] In various embodiments, for example, one or more of the applications discussed above may be any type of application installed or executed on the network devices of the system 300, such as executed by the client device 302, the ISP 303, the server 304, the cloud 305, etc. An application may refer to a software program or service executed on at least one of the devices within the network 301 (e.g., the client device 302, the ISP 303, the server 304, the cloud 305, the data processing system 306), which may allow an operator or user of the device to perform application-specific tasks, such as sending messages, accessing websites, streaming audio or video content, performing VR / AR simulations, etc. The application may utilize standardized protocols and data formats to package data and transmit the data through the network 301, such as transmitting from the cloud 305 to the ISP 303 and from the ISP 303 to the client device 302, or vice versa. In some embodiments, one or more applications may be managed or hosted by the server 304 or the cloud 305.

[0146] The application may include a browser application (e.g., a web browsing application), a content streaming application (e.g., video and audio streaming), a gaming application, or other non-limiting applications accessible by the network device. A user or operator of the client device 302 may interact with the application to perform application-specific tasks, such as opening a web browser, starting content streaming, or initializing an application example and others. In response to the interaction, the application may generate data packets containing the necessary information and send the generated data packets through the network 301 to the desired destination. At the receiving end, the destination device (which may be executing the application) may interpret or process the data packets and perform one or more predefined actions based on the (aggregated) data packets, such as presenting content to the end user or processing requests from the end user. For the purpose of providing examples, the application may be a low-latency application (e.g., a latency-sensitive application or a real-time application) or a non-low-latency application.

[0147] A low-latency application may refer to any application configured to deliver data or receive a response between a client device 302 and a cloud 305 (or server) with minimal latency. Examples of low-latency applications may provide various latency-sensitive functionalities such as, but not limited to, video conferencing, video or audio streaming, gaming, or virtual simulation, to name a few. A non-low-latency application may refer to any application that does not prioritize real-time interactions or can tolerate a relatively long latency between the client device 302 and the cloud 305. Examples of non-low-latency applications may include non-latency-sensitive functionalities such as, but not limited to, email, document editing software, social media platforms, or file storage. For the purposes of the examples provided herein, the application executed by the client device 302 may be a low-latency application or a non-low-latency application, which may be analyzed, monitored, or detected by the data processing system 306.

[0148] The components of the system 300 may be deployed in different deployment scenarios such as, but not limited to, Figure 4 or those described in at least one of 5. For example, Figure 4 illustrates an example deployment 400 of a client-owned access point according to one or more embodiments. The example deployment 400 includes a cloud 305 (or server 304), an ISP 303 (e.g., a device of an ISP that manages traffic from the client device 302), and a client device 302 (e.g., a device of a customer associated with a residence). The cloud 305 may communicate with the ISP 303. The ISP 303 may communicate with the client device 302. In some cases, the cloud 305 may be interchanged with the server 304 such that the server 304 may communicate with the ISP 303 to perform the features or functionalities discussed herein.

[0149] For example, the client device 302 may deploy or execute an application to communicate with the cloud 305. The application of the client device 302 may transmit data packets (of one or more data streams) to the ISP 303 for relaying to the cloud 305. The data packets may include requests (e.g., for a streaming service), input data (e.g., user interactions such as keystrokes, interactive elements within an application, etc.), or other types of information associated with the application or the client device 302. In response to receiving the data packets, the ISP 303 may route the data packets from the client device 302 to the cloud 305. The cloud 305 may process the data received from the ISP 303 to determine and perform application-specific tasks based on the received data. For example, for a content streaming, video conferencing, or gaming application, the cloud 305 may respond with the resources requested by the application. Such requested resources may include data uploaded by other client devices 302, such as video or audio data, etc.

[0150] In some cases, the cloud 305 may verify whether the client device 302 (e.g., the user of the client device 302) can access a resource. The cloud 305 may provide at least a portion of the requested resource to the client device 302 based on an access level associated with the user of the client device 302. The cloud 305 may provide a response or transmit a resource to the ISP 303. The ISP 303 may relay the resource to the client device 302. There may be one or more intermediate devices or servers between the cloud 305 and the ISP 303, such as one or more servers 304 configured to manage traffic to at least the ISP 303. In some embodiments, the cloud 305 may, in response to a request from the client device 302, transmit a resource to at least one of the servers 304 depending on the application type. For example, the cloud 305 may receive an indication of the traffic handled by the server 304. Based on the priority level of the request, the cloud 305 may send a resource (e.g., a data stream) to a server 304 with more or less traffic or load, e.g., sending a high-priority data stream to a server 304 with relatively low traffic (e.g., a server 304 configured to handle high-priority data streams), or sending a low-priority data stream to a server 304 with relatively high traffic. The cloud 305 may send data streams to one or more servers 304 based on other factors including but not limited to load balancing policies, network congestion, best path, distance between servers 304, etc., to handle different types of applications.

[0151] In an example deployment 400, the client device 302 may be owned and managed by a client (e.g., a customer-owned WiFi access point in a home network). The client device 302 may not be managed by a network operator (e.g., an ISP or an administrator). In some cases, the client device 302 may not support any resource reservation for latency-sensitive data streams. In the case where the client device 302 is not managed by a network operator, it may be difficult to determine whether an application is a latency-sensitive application. For example, the client device 302 may not be configured or modified to identify low-latency streams.

[0152] In some cases, Dot1P (e.g., 802.1P) or Differentiated Services Code Point (DSCP) may not identify an application as high-priority or latency-sensitive, or Dot1P or DSCP may be spoofed or relabeled such that the application is not identified as high-priority or latency-sensitive. For example, refer to Figure 6, depicts voice stream 600 from an application in a network / instance information from an application in a network according to one or more embodiments. Information for voice stream 600 can be from packets of a latency-sensitive stream (e.g., from a teleconference application monitored and captured in the network). As shown, voice stream 600 may not contain a virtual local area network (VLAN) tag and thus does not contain 802.1P information. Additionally, the UDP port number presented in voice stream 600 and used by the application may not be an indication of an AV service and may not indicate bandwidth requirements. The example voice stream 600 contains a DSCP of zero, which does not identify the packet as a voice packet. In such cases, in this example scenario, the priority in the packet header shown in example voice stream 600 can be classified as the same as other non-latency-sensitive (e.g., latency-insensitive) streams.

[0153] In some aspects, the server 304, cloud 305, or data processing system 306 may not be able to access the Layer 4 (L4) (TCP / UDP) port number (or other packet header fields) from the client device 302, or the data stream may be end-to-end encrypted by the cloud 305 (or server 304) and the client device 302, as in this example scenario. For example, refer to Figure 7 , depicts example information for encrypted traffic 700 from an application in a network according to one or more embodiments. Information for traffic 700 can be from packets of a latency-sensitive stream. Example information for traffic 700 can represent application-encrypted AV traffic for data packets from a latency-sensitive stream. As shown, traffic 700 includes at least an application IP address, a TCP port number, and a DSCP. The TCP or UDP port number in a low-latency encrypted stream can be for Secure Sockets Layer (SSL) and is not advertised. As discussed above, there may be no VLAN tag (e.g., no 802.1P) and the DSCP can be zero. In such cases, according to the packet header, the priority of this data stream can be considered the same as other latency-insensitive streams.

[0154] In another deployment scenario, Figure 5 illustrates an example deployment 500 of Software-Defined Video over Ethernet (SDVoE) for an AV network according to one or more implementations. In example deployment 500, SDVoE may lack support for the Multiple Stream Reservation Protocol (MSRP). SDVoE can refer to a technology designed to distribute high-quality audio and video signals over a network. SDVoE can utilize network infrastructure to transmit compressed or uncompressed video, audio, and control signals to network devices.

[0155] Instance deployment 500 may include multiple switches 502A - E (e.g., sometimes referred to as switches 502). Each switch 502 may correspond to an SDVoE device, e.g., a transmitter or a receiver. Switch 502C may represent an Ethernet switch configured to relay information between a transmitter and a receiver (e.g., switches 502A - B and 502D - E).

[0156] For the purpose of providing an example, switches 502A - B may be associated with an SDVoE transmitter (e.g., server 304 or cloud 305), and switches 502D - E may be associated with an SDVoE receiver (e.g., client device 302). It should be noted that there may be more or fewer switches 502. Each switch 502 may be connected to a corresponding computing device, e.g., an SDVoE transmitter coupled to an encoder or a talker, and an SDVoE receiver coupled to a decoder or a listener. For example, an SDVoE transmitter may be a device or endpoint that captures video and audio signals from various sources such as a camera, a computer, or a media player. The SDVoE transmitter may encode the audio and video signals for transmission over a network. The Ethernet switch may provide the network infrastructure for transmitting these signals between devices within an AV network. An SDVoE receiver may be a device or endpoint that receives the video and audio signals transmitted by the SDVoE transmitter over the network. The SDVoE receiver may decode the received signals and output the decoded signals in a format compatible with an SDVoE receiver such as a display device, a speaker, etc.

[0157] In some cases, instance deployment 500 may experience packet loss for high - bandwidth video streams. For example, a switch 502 may not detect that a data stream is delay - sensitive (e.g., an audio or video stream), e.g., to avoid load balancing because the bandwidth of an AV stream may not be guaranteed, resulting in link bandwidth over - booking or packet loss. For example, a switch 502 may reserve bandwidth for each AV stream (and load - balance other non - delay - sensitive streams) by obtaining the 5 - tuple of the data stream and the bandwidth to be reserved for the stream. To separate streams, the present disclosure may determine or detect whether a stream is delay - sensitive and the type of application receiving (or transmitting) the stream.

[0158] In this example deployment scenario, a communicator, listener, or switch 502 may lack support for a certain protocol such as MSRP to reserve network resources for audio-video bridging (AVB) streams. In some cases, SDVoE may route audio independently of video by assigning separate high-priority queues and shapers. In some other cases, the switch 502 may not store historical information about data streams (e.g., stream definition, bandwidth, or burstiness), and thus may not support prioritization or shaping of traffic to ensure QoS for AVB streams. In such example deployment scenarios, it may be difficult to prioritize certain data streams that may originate from latency-sensitive applications. Accordingly, the present disclosure may provide systems and methods for detecting or identifying low-latency applications using telemetry as discussed herein.

[0159] System 300 may include at least one data processing system 306 for profiling low-latency applications using telemetry data. The data processing system 306 may include at least one processor and a memory, e.g., a processing circuit. The memory may store processor-executable instructions that, when executed by the processor, cause the processor to perform one or more of the operations described herein. The processor may include a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc. or a combination thereof. The memory may include, but is not limited to, an electronic, optical, magnetic, or any other storage or transmission device capable of providing program instructions to the processor. The memory may further include a floppy disk, a CD-ROM, a DVD, a magnetic disk, a memory chip, an ASIC, an FPGA, a read-only memory (ROM), a random-access memory (RAM), an electrically erasable programmable ROM (EEPROM), an erasable programmable ROM (EPROM), flash memory, an optical medium, or any other suitable memory from which the processor can read instructions. The instructions may include code from any suitable computer programming language. The data processing system 306 may include one or more computing devices or servers capable of performing the various functions described herein. The data processing system 306 may include any or all of the components and perform any or all of the functions of the computer 2001 described herein in conjunction with at least Figure 2A described.

[0160] In some configurations, the data processing system 306 may include components and perform any or all of the features and functionality of at least one of the client device 302, the ISP 303, the server 304, the cloud 305, or other network devices within the network 301. In some configurations, the data processing system 306 may include, correspond to, or be a part of at least one network device (such as the ISP 303, the server 304, or the cloud 305). For example, the features or operations of the data processing system 306 for profiling low-latency applications may be performed by the ISP 303, the server 304, or the cloud 305 to take actions for latency-sensitive applications.

[0161] In some configurations, the data processing system 306 may be an entity or device separate from the client device 302, the ISP 303, the server 304, or the cloud 305. For example, the data processing system 306 may be connected to other devices and components of the system 300 via the network 301. For example, the data processing system 306 may receive instructions from the cloud 305 (or other network devices) to monitor the data flow to or from the client device 302, such as the data flow between the client device 302 and the ISP 303, the server 304, or the cloud 305. As discussed herein, the data processing system 306 may determine the type of application executed on the client device 302 based on the monitored data (e.g., telemetry data / information). As part of the received instructions, the data processing system 306 may report the application type to the ISP 303, the server 304, or the cloud 305 to take corresponding actions based on the application type.

[0162] In some embodiments, the data processing system 306 may delegate certain tasks to one or more other devices within the network 301, such as the ISP 303, the server 304, or the cloud 305. For example, the data processing system 306 may provide the monitored data flow to at least one other component within the system 300 to obtain telemetry data, determine variance based on the telemetry data, detect the application type, or take actions based on the application type. For the purpose of providing examples, the features or operations discussed herein may be performed locally on the data processing system 306, but it should be noted that the features or operations may be performed on other network devices, including but not limited to at least one of the ISP 303, the server 304, or the cloud 305. Additionally, it should be noted that certain tasks discussed herein may be delegated to one or more other components within the system 300 and are not limited to being performed locally by the data processing system 306.

[0163] The data processing system 306 may include an interface 308. The interface 308 may transfer data between one or more components of the data processing system 306, such as a data collector 310, a telemetry manager 312, a variance generator 314, a model manager 316, an application detector 318, an action manager 320, and a data repository 322. The interface 308 may include hardware, software, or a combination of hardware and software components to interface with the network 301, devices within the system 300 (e.g., the network 301, the client device 302, the ISP 303, the server 304, or the cloud 305), or components of the data processing system 306. The interface 308 may include features and functionality similar to the communication interface 2018 to interface with the foregoing components, such as in conjunction with Figure 2A . For example, the interface 308 may include a standard telephone line, LAN, or WAN link (e.g., 802.11, T1, T3, Gigabit Ethernet, InfiniBand), a broadband connection (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet over SONET, ADSL, VDSL, BPON, GPON, fiber optic including FiOS), a wireless connection, or a combination of any one or all of the above. Various communication protocols (e.g., TCP / IP, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), IEEE 802.11a / b / g / n / ac, CDMA, GSM, WiMax, and direct asynchronous connection) may be used to establish the connection. The interface 308 may include a built-in network adapter, a network interface card, a PCMCIA network card, an EXPRESSCARD network card, a card bus network adapter, a wireless network adapter, a USB network adapter, a modem, or any other device suitable for interfacing one or more devices within the system 300 to any type of network capable of communication. The interface 308 may communicate with one or more of the foregoing components to at least receive, transmit, or otherwise exchange data / information. The interface 308 may interact with other components or devices not limited to the components or devices discussed herein.

[0164] The data processing system 306 may include a data collector 310 to collect data received from one or more network devices or components in the network 301 (e.g., the client device 302, the ISP 303, the server 304, or the cloud 305). The data collector 310 may obtain or collect data packets of the monitored flow between the client device 302 and the cloud 305. In some cases, the data collector 310 may collect a portion of the information from the data packet, such as information from the header fields of the data packet, and filter out other portions of the data packet. For example, the data collector 310 may collect the 5-tuple associated with each flow and other information associated with one or more packets of each flow, as discussed herein.

[0165] The data collector 310 can collect one or more packets of an individual data stream. The data collector 310 can periodically obtain one or more packets, for example, receive a group of packets from the ISP 303, the server 304, or the cloud 305 at a predefined interval. The data collector 310 can receive individual packets of a stream in response to a packet being sent from the client device 302, the cloud 305, or other network devices. For example, the data processing system 306 can be an intermediate device configured to monitor the packets of a stream when transmitting various streams between devices similar or corresponding to the ISP 303. In another example, the data processing system 306 can be an edge / terminal device configured to receive a data stream, such as the server 304 or the cloud 305. The data collector 310 can store the collected data in the data repository 322. In some cases, the data collector 310 can temporarily store the collected data and periodically or in response to an action being taken on the data stream (e.g., performed by the action manager 320) remove the temporarily stored data.

[0166] As discussed herein, low-latency real-time applications (e.g., a teleconference application, a broadcast from a TV station to a TV or the client device 302, or video, etc.) can have different or separate data streams for different types of data, such as corresponding streams for voice, video, management, control, and data. In some embodiments, certain streams of the same application can be considered latency-sensitive streams, and certain other streams can be considered non-latency-sensitive streams. For example, these separate streams can be prioritized differently. For the purposes of the examples provided herein, a real-time AV stream (e.g., a latency-sensitive stream) can be associated with a low-latency application. Such low-latency applications can have relatively constant bitrate streams, e.g., the bandwidth of the stream is relatively constant and the bandwidth variation is relatively small. Bandwidth variation can refer to the variation in the bandwidth magnitude or value between different streams. For example, the bandwidth of a voice stream can be approximately 15 Kbit / sec, and the bandwidth of a video stream can be approximately 550 Kbit / sec, but other bandwidth magnitudes of latency-sensitive streams can be recorded.

[0167] In some cases, delay-sensitive flows may contain relatively similar packet sizes. For example, the packet length may (substantially) not change over time, having a relatively low packet length variation. Packet length variation may refer to the change in packet length across different flows. For example, the packet length or size of an average voice packet may be approximately 180 bytes, and the packet length of an average video packet may be approximately 1041 bytes, but other packet sizes for delay-sensitive flows may be recorded. In some other cases, audio and video captures may be packed by an encoder or talker and transmitted at regular intervals. For delay-sensitive flows, the average inter-arrival time (IAT) (e.g., the time between the first bits of two consecutive packets received in the same flow) may not change over time or may be relatively similar over time, e.g., a relatively low average IAT variation. For example, the average voice IAT may be approximately 110 ms, and the average video IAT may be approximately 15 ms, but other IATs for delay-sensitive flows may be recorded. Thus, the data collector 310 may obtain or collect information related to at least one of the bandwidth, average packet length, and average IAT of the packets of an individual flow, as well as other types of data for determining the application type.

[0168] The data processing system 306 may include a telemetry manager 312 that is configured to generate or manage telemetry information / data for individual data flows. The telemetry manager 312 may collect per-flow telemetry in response to receiving each packet of the corresponding flow. Per-flow telemetry may refer to the telemetry data associated with each flow. Telemetry data may refer to or be defined as an automated process of remotely collecting data created by a system (e.g., the data processing system 306) by using agents and protocols. Telemetry data may extend to and include various logs, metrics, events, or traces created or generated by one or more applications. For example, telemetry data may include information about network traffic, performance metrics, error rates, packet loss, latency, or other related parameters. The type of telemetry data to be collected may be configured or predefined by an administrator of the data processing system 306. For the purposes of providing examples herein, the type of telemetry data may include at least one of bandwidth, average packet length, or average IAT, but other types of telemetry data may be used to detect the application type, not limited to those discussed herein. The telemetry manager 312 may store the telemetry data in the data repository 322.

[0169] To obtain telemetry data, the telemetry manager 312 can determine whether the received packet is for an existing flow or belongs to an existing flow. For example, the telemetry manager 312 can use the 5-tuple from the packet (or other information in the packet header field) to perform a lookup or search in the data repository 322. The data repository 322 can store multiple historical tuples (e.g., 5-tuples) associated with flows that have been historically recorded by the data processing system 306 (e.g., the telemetry manager 312) or retrieved by one or more other devices within the network 301. In some cases, one or more 5-tuples can be provided by at least one remote device (e.g., the server 304 or the cloud 305) for the data processing system 306 to monitor low-latency applications.

[0170] The telemetry manager 312 can compare the 5-tuple of the received packet with one or more entries in the data repository 322. A match between the 5-tuple and an entry within the data repository 322 (e.g., the entry contains the 5-tuple or is associated with the 5-tuple) can indicate that the received packet is part of an existing flow. In response to the match, the telemetry manager 312 can determine that the packets received in the flow are eligible for telemetry collection. In some embodiments, the telemetry manager 312 can perform telemetry data collection on any flow. In some other embodiments, the telemetry manager 312 can perform telemetry data collection on flows with a source IP address or a destination IP address. The telemetry manager 312 can collect telemetry data for one or more flows with one or more packets containing certain predefined types of information (not limited to IP addresses) and discard other packets that do not have the predefined type of information.

[0171] In response to comparing the 5-tuple with the entries in the data repository 322, the telemetry manager 312 can determine whether there is an existing flow entry (e.g., an entry for a flow with the same 5-tuple). If there is an existing flow entry, then the telemetry manager 312 can update one or more counters associated with the existing flow. Otherwise, if there is no entry in the data repository 322, then the telemetry manager 312 can add the 5-tuple as part of a new entry in the data repository 322 to identify, track, and / or manage a new flow (e.g., sometimes referred to as learning a new flow for profiling the flow as latency-sensitive or latency-insensitive). The telemetry manager 312 can assign or allocate one or more counters for the new flow.

[0172] To generate or obtain telemetry data, the telemetry manager 312 can use one or more counters to track or record information about the packets within a flow. The telemetry manager 312 can store the counters used to obtain telemetry data for an individual flow in the data repository 322. Each counter can be used for a specific type of telemetry data for the corresponding flow. For example, a first counter can be used to determine the bandwidth, a second counter can be used to determine the average packet length, and a third counter can be used to determine the average IAT, etc.

[0173] In response to determining that the received packet is associated with an existing flow, the telemetry manager 312 may update one or more counters (e.g., flow analysis counters) and periodically (e.g., every 0.1 second, 0.2 second, or 0.5 second) collect the counter values. The periodic interval for collecting the counter values may be predetermined or configured by an administrator of the data processing system 306. The collected counter values may be used to generate telemetry data. In some cases, the collected counter values may represent certain types of telemetry data for detecting the application type (or flow type).

[0174] The telemetry data may include, but is not limited to, at least one of the bandwidth of the flow, the average packet length, or the average IAT. To obtain the bandwidth, the telemetry manager 312 may add the packet length (L) to a counter (C1) reserved for measuring the bandwidth of the flow (e.g., sometimes referred to as a byte counter). When the telemetry manager 312 receives a new packet associated with the flow, the telemetry manager 312 may iteratively add the packet length of the new packet to the counter C1, e.g., C1 = C1 + L. The telemetry manager 312 may periodically read the counter value from the data repository 322 and export the counter value to calculate the bandwidth. Using the counter value, the telemetry manager 312 may use the formula to generate the bandwidth of the flow. The period (T) may be predetermined. The value 8 may represent the number of bits per byte. The telemetry manager 312 may store the bandwidth in the data repository 322.

[0175] The telemetry manager 312 may use a variety of techniques or formulas to generate the average packet length. The telemetry manager 312 may use a counter (C2) to obtain the average packet length. For example, in response to receiving a packet, the telemetry manager 312 may update the average packet length in the counter C2 according to the following formula: where n is greater than zero. For example, for n = 7, the result of the counter C2 may be C2 = (C2 - (C2 >> 7)) + (L >> 7), where L is the length of the current packet (e.g., the most recently received packet). The telemetry manager 312 may periodically (e.g., every T seconds) collect the counter value (C2). The telemetry manager 312 may periodically poll C2 or package C2 for processing. The telemetry manager 312 may export or output the counter value C2 as the average packet length.

[0176] In another example, the telemetry manager 312 may increment the number of packets received using the counter C2. For example, in response to receiving each packet of the flow, the telemetry manager 312 may increment C2 by 1, e.g., C2 = C2 + 1. The telemetry manager 312 may periodically (e.g., every T seconds) collect (e.g., read or export from the data repository 322) the counter value C2. The telemetry manager 312 may use the formula Calculate the average packet size in the interval T. In other words, in this instance, the average packet size is equal to the total packet length (e.g., according to the byte counter used for bandwidth generation or estimation) divided by the number of packets received within the interval T.

[0177] The telemetry manager 312 can calculate the current IAT using the following formula: current IAT = (T1 - T2), where T1 is the arrival time of the first bit of the current packet, and T2 is the stored value of the time when the first bit of the previous packet in the same flow was received. In other words, the current IAT can represent the time difference between the reception of the most recent packet and the reception of the second most recent packet. The telemetry manager 312 can calculate the moving average of the IAT in the counter (C3). For example, the telemetry manager 312 can calculate the moving average of the IAT using the following formula: where n is greater than zero. For example, if n = 5, then C3 = (C3 - (C3 >> 5)) + (IAT >> 5). In this case, the IAT can be the current IAT, and C3 can represent the average IAT updated over the interval T. The telemetry manager 312 can update and store T2 = T1 in response to determining the current IAT or updating the counter C3, for example, to prepare to calculate the next current IAT in response to receiving a new packet of the flow.

[0178] The telemetry manager 312 can provide the telemetry data to the variance generator 314 or other components of the data processing system 306. The telemetry manager 312 can generate or obtain other types of telemetry data / information, not limited to the bandwidth of the flow, the average packet length, or the average IAT.

[0179] In some embodiments, the telemetry manager 312 can receive telemetry data from one or more remote devices. For example, the telemetry manager 312 can delegate the telemetry data generation task to one or more remote devices. One or more remote devices can generate telemetry data in response to receiving one or more packets of each data stream. One or more remote devices can send the generated telemetry data to the data processing system 306. The telemetry manager 312 can receive the telemetry data from one or more remote devices via the interface 308. In some cases, the telemetry manager 312 can access a remote data storage device (e.g., of the server 304 or the cloud 305) to obtain telemetry data. In some embodiments, the variation over time or the value of the type of telemetry data can represent the characteristics, patterns, or profiles of the telemetry data. The characteristics or patterns of the telemetry data can be used to determine the variance discussed herein.

[0180] Variance generator 314 can generate one or more variances of (real-time) telemetry data obtained periodically (e.g., every T seconds). Variance can refer to the dispersion or spread of a set of data points. For example, variance can represent the difference between at least two measurements or values, between at least one value and a certain function, statistic, or metric, or between at least two states, metrics, or functions. In another example, the variance of telemetry data can represent or measure the degree to which the data points of the telemetry data deviate from the average or mean. Variance can include at least one of bandwidth variance, packet length variance, or IAT variance and other variances associated with the telemetry data. Variance generator 314 can calculate the variance of the telemetry data over multiple intervals of collecting the telemetry data or use the telemetry data to calculate one or more variances. Variance generator 314 can use any suitable variance calculation technique or variance formula to calculate one or more variances of the telemetry data. Variance generator 314 can store the generated variances in data repository 322. It should be noted that more or fewer variances can be obtained to profile individual flows.

[0181] The dispersion or variability of the data points associated with the telemetry data used to calculate the variance can represent the characteristics, patterns, or profiles of the variance. In some embodiments, one or more variances of bandwidth, packet length, or IAT can respectively correspond to or refer to the characteristics of bandwidth, packet length, or IAT. In some cases, the characteristics or patterns of the variance can represent the values of multiple variances of a flow, such that the characteristics represent a combination of the bandwidth variance, packet length variance, or IAT variance of the flow.

[0182] Application detector 318 can profile constant bit rate (CBR) flows. Profiling a constant bit rate flow can refer to or involve monitoring or analyzing characteristics, behaviors, patterns, or otherwise can refer to or involve monitoring or analyzing profiles or flows. Application detector 318 can profile CBR flows based on one or more variances of the telemetry data from variance generator 314. For example, application detector 318 can compare at least one of the variances (e.g., bandwidth variance, packet length variance, or IAT variance) with a predetermined threshold (e.g., sometimes referred to as a standard deviation threshold). For example, the predetermined threshold can be 1% standard deviation, 2% standard deviation, or 5% standard deviation. The threshold can be configured by an administrator of data processing system 306 or a network operator.

[0183] In response to the comparison, the application detector 318 may determine whether the flow is delay-sensitive or delay-insensitive. For example, if the flow has at least one of bandwidth, packet length, or IAT that is within, below, or within a threshold (e.g., within 1% standard deviation) based on the corresponding variance, then the application detector 318 may determine that the flow is delay-sensitive. In such a case, the application detector 318 may determine that the application (e.g., the application executed on the client device 302) for the flow is a low-latency application based on the characteristics or profile of at least one of the variances. Otherwise, if at least one of the variances is greater than the threshold (or outside the threshold), then the application detector 318 may determine that the flow is delay-insensitive, which is associated with a non-delay-sensitive application.

[0184] The application detector 318 may store in the data repository 322 an indication associating the flow with the determined application type (e.g., low-latency or non-low-latency application). For example, the application detector 318 may store an indication associating the 5-tuple representing the flow with the determined application type. In such cases, any subsequent packet or flow with the same 5-tuple may be considered a low-latency application or a non-low-latency application. In some cases, due to changes in the 5-tuple, the application detector 318 may discard the stored indication at the end of the communication session between the application and the cloud 305 (or the server 304).

[0185] In some embodiments, the application detector 318 may utilize a model to detect the application type or the type of the flow. For example, the data processing system 306 may include a model manager 316 configured to generate, train, update, or otherwise manage one or more models. The models may be referred to as machine learning (ML) models or artificial intelligence (AI) models. The model manager 316 may use at least one suitable machine learning technique to train one or more models. Machine learning techniques may include, but are not limited to, supervised learning, unsupervised learning, reinforcement learning, transfer learning, etc. The models may include or correspond to convolutional neural network (CNN) models, long short-term memory (LSTM) models, support vector machines (SVM), or other types of models. In some cases, the model manager 316 may use a combination of different types of models. The model manager 316 may receive or obtain training data for training the models. The model manager 316 may receive models generated or trained by other devices within the network 301, such as models trained by the server 304, the cloud 305, or in some cases locally on the client device 302.

[0186] The model manager 316 can store models in the data repository 322. The model manager 316 can manage multiple models. Each model can be configured to perform a certain feature, such as but not limited to at least one of learning features of telemetry data or features of variances of telemetry data. The model manager 316 can update the model based on data (such as data streaming) during the deployment of the model, for example, update relatively in real time or in response to receiving a new (training) data set. For the purpose of providing an example, the model manager 316 can generate, train, or use one of the multiple models. The model manager 316 can select a model from the multiple models for detecting the application type.

[0187] For example, the model manager 316 can provide training data to the model, including at least one of historical telemetry data, historical variances, or historical features associated with known applications. The known applications can include multiple low-latency applications (such as video conferencing applications, gaming applications, or VR / AR simulation applications) and multiple non-low-latency applications (such as web browsing applications, email applications, or file storage applications). The model manager 316 can train the model to distinguish features of telemetry data or variances of telemetry data representing low-latency applications (such as latency-sensitive types). In some cases, the model manager 316 can train the model to distinguish features of telemetry data or variances of telemetry data representing non-low-latency applications (such as other types of applications).

[0188] The model manager 316 can iteratively train the model with new training data sets. The new training data sets can include but are not limited to at least one of the following: telemetry data (such as generated by the telemetry manager 312), variances (such as calculated by the variance generator 314), the application type determined by the application detector 318 using the model (such as the latest version of the model), or an indication of whether the determined application type is accurate (such as true or false determined by the application detector 318 using the model). According to the new training data sets, the model can update or readjust the features representing low-latency applications and non-low-latency applications, thereby improving the detection accuracy of latency-sensitive data streams and low-latency applications. In some embodiments, updating the model can include at least generating a new version of the model or creating a new model according to the new training data sets.

[0189] In some embodiments, the application detector 318 may use a model trained with machine learning to match the (current) characteristics of a flow (e.g., characteristics of telemetry data or variance) with historical characteristics of known applications. For the purpose of providing examples, the historical characteristics may be associated with latency-sensitive applications. If the current characteristics match at least one of the historical characteristics associated with at least one low-latency application, then the application detector 318 may determine that the flow is from a low-latency application (e.g., the same or a different low-latency application as those used in the training process of the model). Otherwise, if the current characteristics do not match any of the historical characteristics, then the application detector 318 may determine that the flow is from another type of application (e.g., at least one non-low-latency application).

[0190] The data processing system 306 may include an action manager 320 configured to take one or more actions in response to profiling a flow to associate it with an application type. One or more actions may be taken to guarantee, ensure, or provide QoS and prevent packet loss for the profiled flow. Providing QoS may include prioritizing and managing network resources to ensure that the flow receives the necessary service or performance level according to the flow requirements, which may involve mechanisms and techniques for controlling factors such as bandwidth, latency, jitter, and packet loss. For example, some techniques for providing QoS for a flow may include, but are not limited to, at least one of traffic prioritization, traffic shaping, packet queuing bandwidth reservation, or admission control. One or more actions may be predefined and stored in the data repository 322. In some cases, the action manager 320 may receive instructions from one or more remote devices within the network 301 indicating one or more actions to be taken according to different types of applications, e.g., a first action for low-latency applications and a second action for non-low-latency applications.

[0191] In some cases, the action manager 320 may take, execute / perform one or more actions according to the application type, e.g., provide QoS for the flow. In some other cases, the action manager 320 may send instructions to one or more remote devices (e.g., ISP 303, server 304, or cloud 305) within the network 301 to take one or more actions. In some configurations, the action manager 320 may send an indication of the application type associated with the flow to one or more remote devices to determine and take one or more actions.

[0192] Example actions taken to provide QoS for a flow can include assigning a link in a lag bundle as the destination port for a delay-sensitive flow. In this case, the link can receive delay-sensitive flows designated for a particular network device or service. Load balancing can be performed for other types of traffic (e.g., delay-insensitive flows or flows from other types of applications). Another example action can include assigning a higher traffic class and storing delay-sensitive flows (e.g., voice and video flows) in a high-priority queue to ensure lower latency. Assigning a higher traffic class can involve configuring one or more network devices (e.g., routers, switches, or QoS mechanisms) to prioritize certain types of traffic relative to other types of traffic. In this case, delay-sensitive flows can be prioritized relative to other types of flows.

[0193] In another example, the action can involve using an Audio Video Bridging (AVB) shaper to reduce the burstiness of AV flows. An AVB shaper can be a network component or feature designed to enforce the bandwidth and latency requirements of AVB traffic within an AVB-enabled network. AVB can include a set of standards that allow for the reliable and time-synchronized transmission of audio and video flows over Ethernet. For example, an AVB shaper can ensure that AVB traffic complies with specific timing and QoS parameters defined by the AVB standards.

[0194] In a further example, the action can involve shaping low-latency flows to reduce burstiness in the downstream network. Shaping low-latency flows can include a process of controlling the rate or pattern of data transmission within the network by adjusting the packet flow according to predefined criteria or policies. Shaping of the flow can ensure that the flow complies with predefined parameters such as bandwidth limits, latency requirements, or QoS standards, to name a few.

[0195] In yet another example, the action can involve using one or more buffers and traffic management policies for all other flows that do not match the profile of a delay-sensitive flow. For example, this action can be performed for delay-insensitive flows, such as flows having at least one of a characteristic that does not match a historical characteristic or a variance greater than a predefined standard deviation threshold. The action manager 320 can select and perform other actions not limited to those discussed herein.

[0196] In some embodiments, data processing system 306 may use the components described above to perform other features and functionality to at least obtain telemetry data, generate variance, detect application types, or take actions based on application types. The data processing system 306 may include additional components configured to perform the features or functionality discussed herein. In some cases, for example, one or more components of the data processing system 306 (e.g., interface 308, data collector 310, telemetry manager 312, variance generator 314, model manager 316, application detector 318, or action manager 320) may be combined or part of a single component. In some other cases, each of the components of the data processing system 306 may include multiple devices, circuits, or components configured to perform individual features to detect application types and take actions and others.

[0197] Data repository 322 may include at least a flow data storage device 324, a counter storage device 326, a telemetry data storage device 328, a variance data storage device 330, a model storage device 332, an application type storage device 334, and an action storage device 336. The data repository 322 may include data stored in at least one remote storage device (e.g., data stored on server 304 or cloud 305). In some cases, the data processing system 306 may relocate or transfer data between the data repository 322 and the remote storage device. In such a case, the data processing system 306 may access data from the remote storage device. For example, the data repository 322 may be referred to as the memory of the data processing system 306. The data repository 322 may be accessed by one or more components within the data processing system 306 (e.g., interface 308, data collector 310, telemetry manager 312, variance generator 314, model manager 316, application detector 318, or action manager 320). The data repository 322 may be accessed by other devices within the network 301, such as ISP 303, server 304, or cloud 305.

[0198] The flow data storage device 324 may contain, store, or maintain data packets or information associated with flows transmitted by one or more applications executed by at least one of the network devices. For example, the flow data storage device 324 may store data packets of various flows, header fields of the packets, 5-tuples from the packets, etc. For example, the flow data storage device 324 may store other data utilized or stored by the data collector 310 or received by the interface 308.

[0199] The counter storage device 326 may contain, store, or maintain counters associated with each flow. For example, the counter storage device 326 may store one or more counters for calculating or generating telemetry data. The counter storage device 326 may be accessed at least by the telemetry manager 312. The counters stored in the counter storage device 326 may be updated by the telemetry manager 312. The counter storage device 326 may reset or remove one or more counters for certain flows after a predetermined time, after a communication session for an application is disconnected, or in response to receiving an instruction from an administrator of the data processing system 306 to clear or reset the counter values. The counter storage device 326 may contain other information used by the telemetry manager 312 to generate telemetry data.

[0200] The telemetry data storage device 328 may contain, store, or maintain telemetry data. The telemetry data storage device 328 may be accessed by the telemetry manager 312 to store, retrieve, or access telemetry data. The telemetry data storage device 328 may group telemetry data for individual flows. The variance generator 314 may access the telemetry data storage device 328 to generate the variance of the telemetry data. The telemetry data storage device 328 may contain historical telemetry data generated by the telemetry manager 312 or obtained from other remote devices.

[0201] The variance data storage device 330 may contain, store, or maintain variance data including one or more variances calculated based on the telemetry data. The variance data storage device 330 may be accessed by the variance generator 314 to store the generated variance data. The model manager 316 or the application detector 318 may access the variance data storage device 330 to detect the application type of the flow.

[0202] The model storage device 332 may contain, store, or maintain at least one model trained using machine learning. The model storage device 332 may be accessed by the model manager 316 to store the generated model. The model stored in the model storage device 332 may be trained or updated by the model manager 316. The application detector 318 may access the model storage device 332, and the application detector 318 is configured to use the trained model to detect or determine the application type of the flow.

[0203] The application type storage device 334 may contain, store, or maintain various types of applications. The application type storage device 334 may store information associated with different applications (e.g., known applications). For example, the application type storage device 334 may store identifiers representing known applications, such as certain teleconferencing applications, streaming applications, social media applications, web browsing applications, etc. The application type storage device 334 may store corresponding characteristics (or historical telemetry data or variance data) associated with each known application. The application type storage device 334 may store indications of various 5-tuples associated with the corresponding types of applications. The application type storage device 334 may store other information that can be linked to or associated with the type of application.

[0204] The action storage device 336 may contain, store, or maintain one or more actions that can be executed by the action manager 320 or other authorized remote devices. The action storage device 336 may store other actions not limited to those discussed herein. The action storage device 336 may be accessible at least by the action manager 320. The action storage device 336 may receive updated actions, new actions, or indications to remove at least one existing action. In some cases, the action storage device 336 may contain one or more actions configured to be executed by remote devices, such as actions for the ISP 303, server 304, cloud 305, etc.

[0205] Figure 8 An example flowchart illustrating a method 800 for profiling low-latency applications using telemetry. The example method 800 may be performed by one or more components of the system 300 (e.g., the data processing system 306, network 301, client device 303, server 304, or cloud 305), one or more components of the communication system 100, the computer 2001, one or more components of the computing environment 2060, or as otherwise described herein Figures 1A to 2BAny other computing device described executes, performs, or otherwise implements. Method 800 may include receiving a packet flow at action 802 by a data processing system (e.g., data processing system 306). At action 804, the data processing system may determine whether an individual packet flow is associated with an existing flow. At action 806, the data processing system may learn a new flow. At action 808, the data processing system may receive telemetry data. At action 810, the data processing system may determine the variance of information. At action 812, the data processing system may determine the application type. At action 814, the data processing system may determine whether each packet flow is for a low-latency application or a real-time application. At action 816, the data processing system may take one or more actions for a low-latency application or a real-time application. At action 818, the data processing system may take one or more actions for other types of applications.

[0206] Still referring more particularly to Figure 8 , at action 802, a data processing system (e.g., data collector 310) may receive a packet flow from at least one network device (e.g., a client device (e.g., client device 302), an ISP (e.g., ISP 303), a server (e.g., server 304), or a cloud (e.g., cloud 305)). The packet flow may be from or for at least one application executed by the network device. For purposes of providing an example, an analysis for detecting the application type may be performed on at least one flow of multiple packets.

[0207] In some embodiments, the data processing system may determine whether a packet flow is eligible for telemetry collection. For example, the data processing system may identify the information contained in an individual packet. The data processing system may be configured to collect telemetry data for packet flows that contain certain types of information (e.g., source IP address or destination IP address). The data processing system may filter out one or more packet flows that lack the configured type of information. The data processing system may determine to collect telemetry data for packet flows that have the configured type of information. In some cases, the data processing system may collect telemetry data for any flow.

[0208] At operation 804, the data processing system may determine whether one or more packet flows are associated with at least one existing flow. For example, the data processing system may obtain a 5-tuple from an individual packet. The data processing system may compare the 5-tuple with entries within a database (e.g., data repository 322). Each entry may include a corresponding 5-tuple for a corresponding existing flow. If the 5-tuple of the packet associated with the flow matches at least one of the entries, then the data processing system may determine that the packet belongs to an existing flow. In such a case, the data processing system may proceed to operation 808. Otherwise, if the 5-tuple of the packet associated with the flow does not match any of the entries, then the data processing system may proceed to operation 806 because the packet flow is a new flow (not an existing flow).

[0209] At operation 806, the data processing system may learn a new flow. Learning a new flow may include adding the 5-tuple associated with the new flow as part of a new entry in the database. The new entry may include or be associated with one or more counters for obtaining telemetry data for the flow. As part of learning the new flow, the data processing system may update one or more counters for the new flow or variables used to generate telemetry data with information associated with the packet (e.g., bandwidth, packet length, or arrival time of the packet, etc.). The data processing system may return to operation 802 to receive one or more other packets of the flow (or a different flow).

[0210] At operation 808, the data processing system (e.g., telemetry manager 312) may receive, obtain, or generate telemetry data. The data processing system may receive telemetry data for an individual packet flow. The telemetry data may be received periodically (e.g., at a predefined interval or period). For example, in response to receiving each packet of the flow, the data processing system may update counters for individual telemetry data, such as counters for bandwidth, average packet length, or average IAT. The data processing system may iteratively update the counters with each new packet of the flow. The data processing system may periodically (e.g., every T seconds) export the counters to generate corresponding telemetry data.

[0211] At operation 810, the data processing system (e.g., variance generator 314) may use the telemetry data to determine the variance of information. The variance of information may include, but is not limited to, at least one of the following: bandwidth variance, packet length variance, or inter-arrival time variance between packets for each of a plurality of packet flows. The data processing system may periodically calculate or determine at least one of the variances. Periodically determining the variance may involve the data processing system updating the variance with newly collected telemetry data that is collected periodically. For example, the data processing system may track the change in at least one of the variances over time as at least one of the bandwidth variance, packet length variance, or inter-arrival time variance changes over time based on newly received or collected telemetry data.

[0212] At operation 812, a data processing system (e.g., application detector 318) can determine the application type of the flow based at least on characteristics of at least one of bandwidth variance, packet length variance, or inter-arrival time variance of the flow in a plurality of packet flows, and other variances. For example, the data processing system can compare one or more variances with a predetermined threshold (e.g., standard deviation of 1%, 2%, 5%, or other predetermined value). The result of the comparison can indicate whether the flow is a latency-sensitive flow or a latency-insensitive flow. In another example, the data processing system can use a model trained with machine learning (e.g., by model manager 316) to compare characteristics of the flow (e.g., variance or values of telemetry data) with historical characteristics of known applications. The data processing system can use the model to determine whether there is a matching historical characteristic for the characteristics of the flow. Any match can indicate whether the flow is a latency-sensitive flow (for low-latency applications) or a latency-insensitive flow (or other type of application).

[0213] At operation 814, the data processing system can determine whether each packet flow is for a low-latency application (or real-time application) or another type of application. For example, the data processing system can determine that the application type for the flow is a low-latency application based on at least one of bandwidth variance, packet length variance, or inter-arrival time variance of the flow of packets being within a predefined threshold (e.g., equal to or below the predefined threshold). The data processing system can determine that the packet flow is for another type of application based on at least one of bandwidth variance, packet length variance, or inter-arrival time variance of the flow being outside the predefined threshold (e.g., above the predefined threshold). In some cases, the data processing system can determine that the packet flow is for a low-latency application based on all variances (e.g., bandwidth variance, packet length variance, and inter-arrival time variance) being within the predefined threshold. The data processing system can proceed to operation 816 in response to detecting or determining that the flow is for a low-latency application, or proceed to operation 818 in response to detecting that the flow is for another type of application.

[0214] In some embodiments, a data processing system may use a model to determine whether the characteristics of a flow match the historical characteristics of a known application. The characteristics may include or refer to values of variance (e.g., characteristics determined as a function of bandwidth variance, packet length variance, and inter-arrival time variance) or telemetry data. In a scenario where a match between the characteristics is identified, using the model, the data processing system may obtain an indication of the application type (e.g., low latency or other types of applications) associated with the matching historical characteristics of the known application. Similar to the above, the data processing system may proceed to action 816 to take an action on the latency-sensitive flow, or proceed to action 818 to take an action on the latency-insensitive flow. In a scenario where the characteristics do not match any of the historical characteristics of the known application, the data processing system may proceed to action 818 because the characteristics of the flow do not represent the characteristics of a latency-sensitive flow.

[0215] In some embodiments, the data processing system may calculate the average value of each of bandwidth, packet length, and inter-arrival time (or other telemetry data) over multiple time intervals. The average value of the telemetry data may correspond to or be a part of the characteristics of the telemetry data. In this case, the data processing system may determine the characteristics based on the average value of each of the telemetry data. For example, the data processing system may train the model with the historical average value of each of the historical telemetry data. The data processing system may match the characteristics determined based on the average value with at least one historical characteristic indicating a known application, e.g., to determine the application type of the flow.

[0216] At action 816, the data processing system may take one or more actions for a low latency application or a real-time application. For example, the data processing system (e.g., action manager 320) may take one or more actions to provide quality of service for the flow according to the application type in response to determining the application type. For a flow of a low latency application or a real-time application, the data processing system may assign the flow to a link in a link aggregation as the destination port. In some cases, the data processing system may assign the flow (e.g., a latency-sensitive flow) to a higher traffic class. In some cases, the data processing system may store packets from the flow into one or more higher priority queues. In some other cases, the data processing system may use a network traffic shaper to reduce burstiness. In some configurations, the data processing system may take multiple actions or a combination of actions for the type of application. In some embodiments, the data processing system may send instructions to at least one other network device to take one or more actions for the type of application.

[0217] At action 818, the data processing system may take one or more actions for other types of applications. In such a case, one or more actions for other types of applications (e.g., non-latency-sensitive applications) may include at least applying traffic management of the buffer policy to one or more latency-insensitive flows. In some cases, the data processing system may store packets from the latency-insensitive flows into one or more lower-priority queues. In some other cases, the data processing system may assign the latency-insensitive flows to a lower traffic class.

[0218] In some embodiments, the types of applications may include separate flows for each of voice, video, management, control, and data. In such cases, each of the flows may be handled separately such that each flow of the same application may be associated with a different type of flow (e.g., a latency-sensitive flow or a latency-insensitive flow). In such a case, for example, the data processing system may take different actions for different flows of the same application. It should be noted that other actions may be performed for different types of flows or applications and are not limited to those discussed herein.

[0219] It should be understood that the systems described above may provide multiple or each of any of those components, and these components may be provided on a stand-alone machine or, in some embodiments, on multiple machines in a distributed system. Additionally, the systems and methods described above may be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture. The article of manufacture may be a floppy disk, a hard disk, a CD-ROM, a flash memory card, a PROM, a RAM, a ROM, or a magnetic tape. Generally, the computer-readable programs may be implemented in any programming language (e.g., LISP, PERL, C, C++, C#, PROLOG) or any byte code language (e.g., JAVA). The software programs or executable instructions may be stored as object code on or in one or more articles of manufacture.

[0220] Although the foregoing written description of the methods and systems enables one of ordinary skill in the art to make and use what is currently considered to be the best mode thereof, one of ordinary skill in the art should understand and appreciate that there are variations, combinations, and equivalents of specific embodiments, methods, and examples herein. The methods and systems should not, therefore, be limited by the embodiments, methods, and examples described above, but rather should be limited by all embodiments and methods within the scope and spirit of the present invention. The headings provided in this document are non-limiting.

[0221] The application and server have been described above in terms of functional building blocks that illustrate the performance of certain important functions. For ease of description, the boundaries of these functional building blocks have been arbitrarily defined. Functions and structures can be integrated together across such boundaries. Alternative boundaries can be defined as long as certain important functions are appropriately performed. Similarly, flowchart blocks can be arbitrarily defined herein to illustrate certain important functionality. Within the scope of use, the flow boundaries and sequences can be defined in other ways and still perform certain important functionality. Accordingly, such alternative definitions of functional building blocks and flowchart blocks and sequences are within the scope and spirit of the claimed invention. One of ordinary skill in the art will also recognize that the functional building blocks and other illustrative blocks, modules, and components herein can be implemented as described or by discrete components, application specific integrated circuits, processors executing appropriate software, etc., or any combination thereof.

Claims

1. A method comprising: receiving, by a data processing system including one or more processors and memory, telemetry data for a plurality of packet streams; determining, by the data processing system, a bandwidth variance, a packet length variance, and an inter-arrival time variance between packets for each of the plurality of packet flows using the telemetry data; Determining, by the data processing system, an application type of a flow in the plurality of packet flows based at least on characteristics of the bandwidth variance, the packet length variance, and the inter-arrival time variance of the flow; and One or more actions are taken by the data processing system in response to determining the application type to provide quality of service for the flow according to the application type.

2. The method of claim 1, further comprising determining, by the data processing system, that the application type is one of a low-latency application or a real-time application. 3 . The method of claim 1 , further comprising periodically receiving, by the data processing system, the telemetry data.

4. The method of claim 3, further comprising periodically determining, by the data processing system, the bandwidth variance, the packet length variance, and the inter-arrival time variance between packets for each of the plurality of packet flows.

5. The method of claim 4, further comprising tracking, by the data processing system, changes in the bandwidth variance, the packet length variance, and the inter-arrival time variance over time.

6. The method of claim 1, further comprising determining, by the data processing system, the application type of the flow based on the bandwidth variance, the packet length variance, and the inter-arrival time variance of the flow in the plurality of packet flows being within a threshold.

7. The method of claim 1, further comprising determining, by the data processing system, the application type of the flow in the plurality of packet flows based at least on an average of each of bandwidth, packet length, and inter-arrival time.

8. The method of claim 1, further comprising determining, by the data processing system, the characteristics of the application type based on the bandwidth variance, the packet length variance, and the inter-arrival time variance.

9. The method of claim 1 , wherein taking the one or more actions comprises one or more of: assigning, by the data processing system, the flow to a link in the link aggregation as a destination port; assigning, by the data processing system, the flow to a higher traffic class; storing, by the data processing system, packets from the flow into one or more higher priority queues; Using a network traffic shaper by the data processing system to reduce burstiness; as well as Traffic management or buffer policies are used by the data processing system for one or more other flows.

10. The method of claim 1, wherein the application type comprises a separate stream for each of voice, video, management, control, and data.

11. A system comprising: A data processing system comprising one or more processors and a memory, the data processing system being configured to: determining, using telemetry data received for a plurality of packet flows, an inter-arrival time variance between packets for each of the plurality of packet flows; determining an application type of a flow in the plurality of packet flows based at least on the inter-arrival time variance of the flow; and One or more actions are taken in response to determining the application type to provide quality of service for the flow according to the application type.

12. The system of claim 11, wherein the data processing system is further configured to use the telemetry data to determine the packet length variance for each of the plurality of packet flows and the application type for the flows based at least on the inter-arrival time variance and packet length variance for the flows.

13. The system of claim 11, wherein the data processing system is further configured to use the telemetry data to determine the bandwidth variance of each of the plurality of packet flows and the application type of the flows based at least on the inter-arrival time variance and bandwidth variance of the flows.

14. The system of claim 11, wherein the data processing system is further configured to determine the application type of the flow among the plurality of packet flows based on characteristics, the characteristics comprising bandwidth variance, packet length variance, and inter-arrival time variance of the flow being within a threshold.

15. The system of claim 11, wherein the data processing system is further configured to determine the application type of the flow in the plurality of packet flows based at least on an average of inter-arrival times.

16. The system of claim 11, wherein the data processing system is further configured to take the one or more actions in response to the application type determination, the actions comprising one or more of the following: assigning the flow to a link in the link aggregation as a destination port; assigning the flow to a higher traffic class; storing packets from the flow into one or more higher priority queues; Use network traffic shapers to reduce burstiness; and Use traffic management or buffer strategies for one or more other flows.

17. A system comprising: A network device among a plurality of devices, the plurality of devices communicating a plurality of packet streams of one or more applications via the network device, the network device being configured to: determining an inter-arrival time variance between packets for each of the plurality of packet flows using telemetry data for the plurality of packet flows; determining, based at least on the inter-arrival time variance of a flow in the plurality of packet flows, that an application type of the flow is a low-latency application; and One or more actions are taken in response to determining the application type to provide quality of service for the flow according to the application type.

18. The system of claim 17, wherein the network device comprises a switch.

19. The system of claim 17, wherein the network device is further configured to determine that the application type of the flow is the low-latency application based at least on the inter-arrival time variance and bandwidth variance of the flow in the plurality of packet flows.

20. The system of claim 17, wherein the network device is further configured to determine that the application type of the flow is the low-latency application based at least on the inter-arrival time variance and packet length variance of the flow in the plurality of packet flows.

Images