Enterprise friendly SCS policy verification

Abstract

The present disclosure provides techniques for flow classification service (SCS) policy verification for downlink and uplink traffic. A network device receives an SCS request from an associated STA, the SCS request specifying one or more sets of traffic class (TCLAS) information for a data stream transmitted between the network device and the STA, each set of TCLAS information carrying associated QoS profile information for the data stream. The network device compares these TCLAS information and associated QoS profile information to one or more cached application profiles and determines that there is no match. In response to the determination, the network device performs packet analysis and confirms that the TCLAS information and the associated QoS profile information are consistent with the service type of the data flow under a defined network policy. In response to the acknowledgement, the network device applies one or more processes to the data stream.

Description

[0001] Cross-references to related applications This application claims the benefit of co-pending U.S. Provisional Patent Application Serial No. 63 / 580,241, filed September 1, 2023, and co-pending U.S. Provisional Patent Application Serial No. 63 / 589,122, filed October 10, 2023. The foregoing patent applications are incorporated herein by reference in their entirety. Technical Field

[0002] The embodiments presented in this disclosure generally relate to wireless communications. More specifically, the embodiments disclosed in this disclosure relate to enhanced Flow Classification Service (SCS) policy verification by performing on-demand packet analysis to identify the service type or application classification of traffic and implementing application-specific Quality of Service (QoS) management based on the detected characteristics. Background Technology

[0003] The IEEE 802.11be / Wi-Fi 7 Flow Classification Service (SCS) feature defines a request / response transaction between a Station (STA) or Non-Access Point Multilink Device (non-AP MLD) and an Access Point (AP) or AP MLD. This transaction allows the STA to request specific Traffic Classification (TCLAS) processing for traffic flows identified by a 5-tuple or by a class flow identified by a Differential Service Code Point (DSCP) value, mapping these flows to specific User Priority / Traffic Identifiers (UP / TID). In Wi-Fi 7, TCLAS can only be specified for downlink (DL) traffic flows. SCS requests can be sent before the corresponding traffic flow begins via explicit integration with the operating system (OS) stack combined with SCS, or during the traffic flow via implicitly triggered SCS flow detection based on the Wi-Fi driver. Regardless of the timing, the policy requested by the Wireless LAN (WLAN) or AP application is typically expected, and the request is responded to positively or rejected primarily based on WLAN resources (e.g., TCLAS processing restrictions) or application policies that disallow the request. Attached Figure Description

[0004] To gain a more detailed understanding of the features described above, a more specific description of the disclosure can be obtained by referring to the embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the drawings illustrate only exemplary embodiments and should not be considered limiting; other equally effective embodiments are also contemplated.

[0005] Figure 1 An example WLAN infrastructure for application-based traffic management in an enterprise environment is described according to some embodiments of this disclosure.

[0006] Figure 2 An example SCS policy verification sequence is described, which uses policy pre-detection and on-demand grouping analysis according to some embodiments of this disclosure.

[0007] Figure 3 An example SCS policy verification sequence with temporary resource allocation is described according to some embodiments of this disclosure.

[0008] Figure 4 Example methods for performing application-specific policy verification and on-demand grouping analysis for enhanced quality of service (QoS) management, according to some embodiments of this disclosure, are described.

[0009] Figure 5 This is a flowchart depicting an example method for enhanced SCS policy verification according to some embodiments of the present disclosure.

[0010] Figure 6 An example network device is described that is configured to perform various aspects of this disclosure in accordance with some aspects thereof.

[0011] Figure 7 Example client devices configured to perform various aspects of this disclosure according to some embodiments are depicted.

[0012] For ease of understanding, the same reference numerals are used where possible to denote common elements in the figures. It is anticipated that elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0013] Overview One embodiment of this disclosure provides a method comprising: receiving a Flow Classification Service (SCS) request from an associated site (STA) by a network device, wherein the SCS request specifies one or more sets of Traffic Classification (TCLAS) information for a data stream transmitted between the network device and the STA, each set of TCLAS information being accompanied by an associated Quality of Service (QoS) profile for the data stream; comparing the one or more sets of TCLAS information and the associated QoS profile with one or more cached application profiles by the network device; and determining, by the network device, that the one or more sets of TCLAS information and the associated QoS profile are compared with the one or more cached application profiles. None of the cached application profiles match; in response to the determination, the network device performs packet analysis to determine the service type of the data stream; the network device confirms, based on one or more defined network policies, that the set of or more TCLAS information and the associated QoS profile information are consistent with the determined service type; in response to the confirmation, the network device applies one or more processing steps to the data stream based on the set of or more TCLAS information and the associated QoS profile information received in the SCS request, wherein the one or more processing steps are consistent with at least one of the following: the determined service type, and the one or more defined network policies.

[0014] Other embodiments of this disclosure provide: one or more non-transitory computer-readable media containing computer program code in any combination, the computer program code performing operations according to one or more of the methods described above when executed by operation of a computer system; and a network device system including one or more computer processors and one or more memories collectively containing one or more programs, the one or more programs performing operations according to one or more of the methods described above when executed by the one or more computer processors.

[0015] Example Implementation Based on the SCS characteristics defined in early Wi-Fi standards, the AP receives an SCS request from the client device, which includes details of the requested TCLAS processing. The AP then checks its predefined policies and rules to determine if the requested TCLAS processing is supported. This traditional approach relies on static, predefined rules to classify and prioritize traffic based on specific conditions such as DSCP values ​​and 5-tuple data (e.g., source IP, destination IP, protocol, source port, and destination port).

[0016] However, this traditional SCS approach has limitations and cannot adapt to enterprise environments that require application-specific policy validation of requested data flows. In enterprise environments, QoS policies are not solely determined by the AP. Instead, these policies are managed at a higher network level (e.g., end-to-end (E2E) network-wide policies) and are application-specific. These network-wide policies ensure that QoS processing is consistent with the specific needs of different applications running on the STA.

[0017] Because these policies are application-specific, the final decision on QoS processing for uplink / downlink (UL / DL) traffic specified in an SCS request depends primarily on accurate identification of the traffic service type or application category. This identification may require packet analysis using techniques such as Application Visibility and Control (AVC), Deep Packet Inspection (DPI), or Next-Generation Network-Based Application Identification (NBAR2), which can reside on nodes outside the access point (e.g., a Wireless Local Area Network (LAN) controller (WLC)). This packet analysis can take microseconds or milliseconds, making it impractical to provide an SCS response within the extremely short time frame required for a Wi-Fi transaction. Furthermore, techniques such as DPI may be disabled by default due to computational costs. Therefore, client devices may unnecessarily time out and retry SCS requests due to the failure to provide a timely SCS response. This prevents the allocation of network resources for UL / DL flows, resulting in failure to meet E2E Service Level Agreements (SLAs) set in enterprise environments.

[0018] Embodiments of this disclosure introduce techniques for application-specific QoS policy verification of UL / DL data flows in an enterprise environment. Considering the constraints of limited or no negotiation, in one embodiment, SCS features can be tightly integrated with Network Policy Enforcement Function (PEF) and deep packet analysis capabilities (e.g., DPI, NBAR2). In this integration, packet analysis can focus on specific verification of flows requested by the STA. When processing an SCS request (which is processed for UL / DL traffic requests corresponding to different applications), the AP can construct an relevant application profile. Each application profile may include information such as a DSCP value, associated TID, 5-tuple data, and other relevant attributes indicating the characteristics of the data flow serving a specific application. Upon receiving a new SCS request, the AP can first compare it with a stored application profile for verification. If a match is found, the AP can directly confirm the request and apply the requested TCLAS (and / or QoS profile) processing. If no match is found, the AP can perform in-depth packet analysis (e.g., DPI, NBAR2) on the specified UL / DL packets within a limited time period (also known as the verification time in some embodiments) and perform further analysis to determine the appropriate QoS handling.

[0019] This method enables traffic classification and prioritization based on application-specific profiles, ensuring that the applied QoS processing aligns with the specific needs of different applications. Furthermore, this method reduces computational load by eliminating the need for detailed packet analysis of all UL / DL data flows within the WLAN. Conversely, in this disclosure, packet analysis is only performed when no matching application profile exists. Moreover, packet analysis targets specific flows falling within the verification time frame, rather than indiscriminately analyzing all flows or packets, which typically leads to high computational demands and causes APs to disable this feature. This disclosure ensures efficient and accurate verification of application-specific QoS policies and improves network performance and overall resource allocation.

[0020] Figure 1 An example WLAN infrastructure for application-based traffic management in an enterprise environment is described according to some embodiments of this disclosure.

[0021] As shown in the figure, this example WLAN infrastructure 100 includes multiple BSSs, including BSS 1 and BSS 2. Each BSS includes an AP 105, which is connected to multiple site devices (STAs) 110. Figure 1 As shown, BSS 1 includes AP 105-1, which is connected to STA 110-1 and 110-2; BSS 2 includes AP 105-2, which is connected to STA 110-3.

[0022] Both APs 105 are connected to a central network switch 145, which manages UL and / or DL ​​traffic across multiple BSSs. In uplink transmissions, switch 145 can collect data traffic from both APs 105 and route it to higher network layers via router (or gateway) 150. In downlink transmissions, switch 145 distributes incoming traffic from these higher layers to the appropriate APs 105 for delivery to the connected STAs 110. Higher network layers establish connections to internal and / or external networks 115 (e.g., the Internet). These networks 115 can connect the APs to remote servers 120, which serve as the primary source for various types of data requested by the STAs, including but not limited to video streaming content, web pages, voice calls, bulk data downloads, and other online services.

[0023] As shown in the figure, switch 145 is also communicatively coupled to a wireless local area network (LAN) controller (WLC) 155, which monitors all APs 105 within the BSS and manages all wireless data exchange between connected STAs 110 and remote servers 120. STAs 110 in the disclosed network setup can include various computing devices, such as tablets, mobile phones, laptops, or smart home devices. In some embodiments, STAs 110 may also be referred to as client devices or user devices. Each STA 110 can run multiple applications 125-140, each with specific requirements for UL / DL data. This example WLAN infrastructure 100 enables data to flow smoothly and directly from these remote servers 120 through APs 105 to STAs 110. This path not only supports the transmission of DL data required by applications running on the STAs but also facilitates the uploading of UL data, which can be sent from STAs 110 and relayed back through APs 105 to the wider network 115.

[0024] like Figure 1 As shown, four applications are installed on the STA 110-2. Application 125 is designed for video conferencing, which typically requires high bandwidth and low latency to maintain video and audio quality. Application 140 handles telephone calls, which, similar to video conferencing, requires high bandwidth and prioritizes audio transmission over other transmissions. Application 130 supports web browsing, and its QoS requirements are typically lower compared to real-time communication services such as video conferencing or audio calls. Application 135 provides reliable transmission of text messages, which typically requires minimal bandwidth.

[0025] In enterprise environments adhering to End-to-End Service Level Agreements (E2E SLAs), QoS policies are not determined by a single AP. Instead, E2E SLAs can prioritize applications based on their business criticality, operational requirements, and other relevant factors. For example, in an office environment, applications used for routine operations (such as audio calls or cloud-based collaboration tools) may take precedence over less critical applications (such as video streaming for entertainment). For applications providing similar services, such as video conferencing tools, the E2E SLA may prioritize one application based on vendor agreements or company preferences. In such configurations, these QoS policies can be part of a comprehensive E2E network-wide policy and are designed to meet specific criteria set by the E2E SLA. These policies can be application-specific and / or flow-specific, aiming to maintain optimal (or at least improved) performance and compliance across the network. Due to the complexity and scope of these policies, a single AP 105 may not be able to enforce them independently. Instead, the WLC 155 can be configured with a PEF, enabling it to manage and enforce these detailed QoS policies across the entire network infrastructure.

[0026] In some embodiments, STA 110 can specify Traffic Class of Qualities (TCLAS) QoS processing for incoming (or being processed) UL / DL traffic as part of an SCS request. For example, for DL ​​data for application 125 designed for video conferencing, STA 110-2 can indicate specific requirements in the SCS request, such as a high DSCP value (e.g., “46”) and its associated TID (e.g., “TID 7”) to indicate the desired priority level. The request may also include 5-tuple data consisting of source and destination IP addresses, source and destination ports (e.g., “5004”), and protocol type (e.g., “User Datagram Protocol (UDP)”), which helps to accurately identify the traffic stream requesting enhanced QoS processing. Given that these policies are application-specific in an enterprise environment, a WLC 155 configured with PEF may need to verify that the requested UL / DL traffic does indeed serve the identified application, thus conforming to the requested processing. To achieve this, the WLC 155 can implement packet analysis techniques such as AVC, DPI, and NBAR2, and examine packet payloads to determine the actual service type or application classification of UL / DL traffic.

[0027] Based on the results of packet analysis, the WLC 155 can perform policy verification to determine whether the traffic actually matches any existing application profile and conforms to the priority level and / or QoS processing defined within the enterprise E2E SLA. However, as mentioned above, there are two problems with implementing such application-specific policy verification. First, performing packet analysis like DPI can be very time-consuming, requiring microseconds or milliseconds, which exceeds the extremely short time frames required for Wi-Fi transactions. Second, packet analysis consumes significant computational resources, making it impractical given the current hardware and software capabilities of the AP (or WLC).

[0028] To address these issues and make application-specific policy verification feasible in enterprise environments, in some embodiments, the WLC 155 can combine policy preflight and on-demand payload inspection during the policy verification process. Initially, when the WLC 155 receives an SCS request from a STA (e.g., 110-2) via its associated AP (e.g., 105-1), the WLC 155 can perform a policy preflight. During the preflight phase, the WLC 155 can compare data included in the SCS request that indicates the characteristics of UL / DL traffic with existing application profiles (e.g., application profiles maintained by the WLC 155 in its database). In some embodiments, the application profiles can be constructed based on previously processed UL / DL traffic for a specific application. These profiles can allow the WLC 155 to quickly identify the nature or classification of incoming traffic based on historical data and manage network resources more effectively. In some embodiments, an application profile may include information such as DSCP, 5-tuple data (e.g., source IP, destination IP, source port, destination port, protocol), TID mapping, and other metrics that can serve as reliable indicators specific to each application (e.g., period, start time, burst size, and inter-arrival-time range). For example, a profile for application 125 (which provides video conferencing services) may include a typical DSCP value “46” and its associated TID “6” or “7”, reflecting high-priority processing and low-latency requirements. The profile may also include specific source and destination IP addresses, identify “UDP” as the protocol, and source and / or destination port “5004”. These parameters can be used to verify that the traffic flow is serving application 125. Furthermore, the profile may include additional metrics, such as an inter-arrival-time range of 20 ms, which is typical for video conferencing data that requires consistent packet transmission to maintain video quality. Similarly, the profiles for application 130 (providing web browsing services), application 135 (providing text messaging services), and application 140 (providing telephone calling) can capture the unique characteristics and requirements of each application, such as the lower DSCP values ​​and associated TIDs of applications 130 and 135, as well as the specific protocols and ports commonly used by these applications. In some embodiments, the application profiles may include QoS access control lists (ACLs) discovered and automatically created by PEF.

[0029] If the policy pre-check indication matches a known profile, WLC 155 can directly approve the request based on the pre-verified policy without extensive packet analysis. This efficient verification provides optimized resource allocation and ensures that the quality of service for known applications is maintained without unnecessary latency. If no match is found during the initial policy check, suggesting a potential policy violation or the emergence of new application traffic (e.g., beyond the current application 125-140 range), WLC 155 can then perform on-demand packet analysis (e.g., DPI, NBAR2). This may involve a more detailed examination of the UL / DL packet content to determine the exact nature or application category of the traffic. On-demand analysis allows WLC 155 to dynamically assess whether unclassified traffic aligns with any policy rules and / or updated application profiles, or whether it should be considered a potential threat or non-compliance issue.

[0030] The dual-layered approach, combining policy pre-detection with on-demand analytics capabilities, makes policy validation by application or traffic flow (as required in enterprise environments) both feasible and efficient. This approach significantly reduces response time to meet the stringent time constraints of Wi-Fi transactions. Furthermore, by allocating packet analysis tasks only when necessary (e.g., when incompatible with existing application profiles), this approach avoids excessive computational demands and ensures compatibility with the current hardware and software capabilities of the WLC 155 (or AP 105).

[0031] Figure 2 An example SCS policy verification sequence 200 is depicted according to some embodiments of this disclosure, using policy pre-detection and on-demand grouping analysis. In some embodiments, STA 210 may correspond to Figure 1 The STA 110 is depicted in the diagram. In some embodiments, entity 205, which receives SCS requests and performs policy checks and packet analysis, can be various network devices configured with PEF. Entity 205 may correspond to... Figure 1 The AP 105 and / or WLC 155 depicted, or any other dedicated network device designed to handle such policy enforcement functions.

[0032] As shown in the figure, STA 210 first sends an SCS request to AP / WLC 205 (step 215). The SCS request may include TCLAS information indicating the type of service and required priority for certain UL / DL data flows. The SCS request may be sent before traffic arrives or while traffic is being processed. This information can suggest the processing required to meet the QoS requirements set in the E2E SLA. In some embodiments, the request may specify parameters such as DSCP values ​​and desired TIDs for traffic prioritization within the network. In some embodiments, the request may also include 5-tuple data (e.g., source IP, destination IP, source port, destination port, and protocol), which helps define flow characteristics associated with maintaining a specific service level. In some embodiments, metadata such as mandatory traffic period, start time, burst size, and arrival interval range may also be included in the SCS request to further identify the type and nature of the data. In implementations where multiple applications may use the same DSCP value (or TID) for similar services and where IP tuples may change over time (e.g., video streaming and video conferencing applications both use DSCP "46" for accelerated forwarding), additional identifiers (e.g., application ID or fully qualified domain name (FQDN) / URL) can be included in the SCS request. These additional identifiers can help AP / WLC205 determine the application classification of UL / DL traffic more accurately and efficiently.

[0033] For applications that provide video conferencing services (e.g.) Figure 1 Application 125), an example SCS request may include: a DSCP value "46" and a desired TID mapping "7" for high priority; 5-tuple data (including destination IP address "192.168.1.50", source IP address "192.168.1.100", protocol "UDP", source port "5004", and destination port "5004"); a specific URL identifying the conference service (e.g., "conference.example.com"); and metadata supporting real-time interaction (e.g., mandatory traffic period "20 ms", start time "0 ms", burst size "50,000 bytes", and arrival interval range "20 ms").

[0034] Upon receiving an SCS request, the AP / WLC 205 processes the information provided in the request and compares it with its cached application profile (step 220). In some embodiments, these profiles may contain pre-stored data characterizing typical network usage patterns of the identified applications, including their DSCP values, associated TIDs, source and destination ports, protocol types, application signatures, and other QoS parameters. If the SCS request matches a known application profile, the AP / WLC 205 can identify incoming (or currently being processed) UL / DL traffic as belonging to an identified application with established QoS settings (e.g., ...). Figure 1 Application 125).

[0035] Based on this match, AP / WLC 205 promptly sends a response back to STA 210 (step 225). In some embodiments, this response may confirm that the requested TCLAS processing is consistent with the identified application profile and commit to processing UL / DL traffic according to specific requirements to ensure the expected quality of service level (e.g., as defined by an E2E SLA in an enterprise environment).

[0036] After sending confirmation (or simultaneously in some embodiments), the AP / WLC 205 allocates relevant network resources based on the matching application profile and / or prioritizes UL / DL traffic in the network queue (step 230). Performing these operations ensures that known applications (e.g., Figure 1 Application 125) obtains the bandwidth and processing priority defined by the network policy for UL / DL traffic flows.

[0037] When no match is found during the initial policy check, this indicates that deep packet analysis is required to determine the specific characteristics and requirements of the UL / DL traffic. In such a configuration, AP / WLC 205 sends an SCS response to STA 210 (step 235). This response informs STA 210 that SCS verification is currently in progress and a final decision has not yet been made. In some embodiments, the SCS response may include an indication of "SCS in progress" and an estimated time frame for the verification process (e.g., 200 ms), which helps STA 210 estimate how long it may take to apply the allocated resources. AP / WLC 205 then defines a verification time for on-demand packet analysis (step 240). Setting the verification time conserves computational resources and avoids applying packet analysis (e.g., DPI, NBAR2) to all UL / DL packets being processed by the AP / WLC. By establishing this verification time, packet analysis is specifically applied to a limited number of UL / DL packets that fall within a predefined time frame. In some embodiments, the verification time may be determined to balance the need for thorough packet checking with the application's tolerance for latency, particularly for real-time applications such as voice or video conferencing. For example, the typical verification time for these applications can be around 200 ms, which is usually sufficient to perform a valid PEF without adversely affecting the quality of service.

[0038] In some embodiments, the verification time can be determined based on data included within the QoS Feature Information Element (IE), such as mandatory traffic periods, arrival interval ranges, and optional start times. For example, for video conferencing data characterized by an arrival interval range of 20 ms, the verification time can be defined as observing N periods (e.g., where N is set to 10, for a total of 200 ms). This time period allows the AP / WLC 205 to capture sufficient data packets to make informed decisions regarding the nature of the traffic and / or application classification.

[0039] In some embodiments, an SCS response indicating that SCS verification is in progress (e.g., a status of "SCS in progress") is sent in step 235 only if the defined verification time is expected to exceed a period that the application can reasonably tolerate (potentially leading to service degradation). In such a configuration, the AP / WLC 205 can proactively communicate with the STA 210 and provide an estimated resolution time (e.g., 250 ms). By informing the STA 210 of the latency, the AP / WLC 205 can maintain a stable and reliable connection with the STA 210, even when extensive packet analysis is required.

[0040] After defining the verification time, the AP / WLC 205 performs packet analysis, such as DPI or NBAR2, on its received and / or transmitted UL / DL packets within this specified time frame (step 245). In some embodiments, packet analysis such as DPI may involve a deep inspection of the data payload of the packets. This inspection can allow the AP / WLC 205 to extract and analyze various metrics that can be used to identify the actual service type or application classification of the UL / DL traffic. These metrics may include, but are not limited to, media format, application signature (e.g., URL or application ID), and protocol-specific data that can indicate the type of application being used (e.g., Real-time Transport Protocol (RTP) for real-time applications or HTTPS for secure network traffic).

[0041] In some embodiments, packet analysis, such as DPI, can be extended to analyze SCS metadata, such as packet frequency, burst patterns, and arrival intervals, to determine traffic behavior patterns. The AP / WLC 205 can then use the detected patterns to differentiate between different types of traffic (e.g., distinguishing between interactive video and bulk data transmission). In some embodiments, DPI can involve inspections across layers 4 through 7, including the transport, session, presentation, and application layers, including Domain Name System (DNS) or FQDN / URL verification. In some embodiments, DPI can be extended to include analysis across layers 2 and 3, including the data link and network layers, further broadening the scope of traffic analysis and enforcement capabilities.

[0042] If the identified service type is used, the AP / WLC evaluates whether the unclassified traffic is consistent with any updated or newly identified application profile, or whether the service type is consistent with TCLAS information and is permitted according to certain network policies, even if it does not match any existing profile. An example of a permitted non-matching implementation may include the following situation: the TCLAS information within the SCS request includes DSCP "46" and an associated TID "7" indicating a high-priority request, but the 5-tuple data or other identifiers do not exactly match any existing profile. The traffic is identified as being used for video conferencing via DPI. In this configuration, the WLC can confirm that the requested TCLAS (and / or QoS profile) processing (e.g., TID 7) is permitted based on a general policy of mapping video conferencing traffic to a high-priority level, even if specific details differ slightly from those in any existing profile. In some embodiments, the AP / WLC 205 may update the cached application profile to include this new application type. This update facilitates more efficient and faster processing of similar SCS requests in the future.

[0043] Based on the packet analysis results, if the traffic is compliant, AP / WLC 205 sends a positive SCS response to STA 210 (step 250). This SCS response may include a "success" indication, confirming that the requested TCLAS (and / or QoS profile) processing is reasonable and consistent with the identified profile, or acceptable according to the current network policy. After or simultaneously with sending the SCS response, AP / WLC 205 allocates the necessary network resources and / or prioritizes the traffic in the network queue according to the requested TCLAS (and / or QoS profile) processing (step 255). If a policy violation exists, such as traffic from a known application being disallowed, or unclassified traffic not meeting any policy criteria, AP / WLC 205 sends an SCS response to STA 210, rejecting the requested TCLAS (and / or QoS profile) processing (step 260). Subsequently, in some embodiments, AP / WLC 205 may reclassify UL / DL traffic to a new priority level, typically lower than the originally requested priority level. Then, AP / WLC 205 can allocate resources and / or prioritize traffic based on the new priority level (step 265). Reclassification can be based on the service type identified by DPI. For example, if the expected TID mapping in the SCS request indicates a high priority (e.g., TID 7), but DPI identifies the traffic as web browsing (a less important service) (e.g., TID 3), AP / WLC 205 can reclassify it to a lower priority. In some embodiments, after reclassification, AP / WLC 205 can send an additional SCS response to STA 210. This SCS response can indicate the new priority level (e.g., TID 3) and confirm that the corresponding TCLAS (and / or QoS profile) processing has been assigned to the data flow.

[0044] In embodiments where packet analysis identifies traffic as posing a security risk, the AP / WLC 205 can completely block the traffic or significantly restrict its transmission during further security checks (step 270). This operation ensures that only secure and compliant traffic is allowed to flow through the AP / WLC 205, thereby effectively maintaining network integrity and security.

[0045] In some embodiments, SCS responses 225 and 245 acknowledging processing of the original TCLAS (and / or QoS profile) may be sent after the resource allocation process. This response informs STA 210 that UL / DL traffic has been processed according to the acknowledged priority allocation and resource settings. In some embodiments, SCS response 255 rejecting processing of the original TCLAS (and / or QoS profile) may be sent after the resource allocation process. This response informs STA 210 that UL / DL traffic has been processed according to a new priority level with adjusted priority allocation and resource settings.

[0046] Figure 3 An example SCS policy verification sequence 300 with temporary resource allocation is depicted according to some embodiments of this disclosure. In some embodiments, STA 310 may correspond to Figure 1 The STA 110 is depicted in the diagram. In some embodiments, entity 305, which receives SCS requests and performs policy checks and packet analysis, can be various network devices configured with PEF. Entity 305 may correspond to... Figure 1 The AP 105 or WLC 155 depicted, or any other dedicated network device designed to handle such policy enforcement functions.

[0047] As shown in the figure, STA 310 initiates the procedure (step 315) by sending an SCS request to AP / WLC 305. Figure 2 The SCS request may include detailed data indicating the type of service or priority of incoming (or being processed) UL / DL traffic received and / or transmitted by the AP / WLC 305. Specifically, in some embodiments, the SCS request may include: a DSCP value and its associated TID to indicate the desired QoS level, and 5-tuple data to identify and classify the traffic.

[0048] Upon receiving an SCS request, the AP / WLC 305 temporarily allocates network resources and prioritizes traffic based on the TCLAS information within the request (step 320). This temporary allocation is designed to continue until the initial policy preflight and / or on-demand packet analysis are completed. Implementing temporary allocation ensures that traffic specified in the SCS request receives temporary but immediate priority and resource support, even before its actual type or application classification is confirmed through policy preflight or packet analysis. This approach reduces disruption to quality of service and maintains network performance, particularly for time-sensitive applications.

[0049] For applications that provide video conferencing services (e.g., Figure 1(Application 125) The SCS request can specify DSCP "46" and desired TID mapping "7", values ​​which are typically reserved for high-priority voice and video traffic. Based on the TID, the AP / WLC305 then allocates appropriate bandwidth and processing resources to ensure that the traffic specified in the SCS request is processed with the necessary priority and quality.

[0050] Following the temporary resource allocation (or simultaneously in some embodiments), the AP / WLC 305 sends an initial SCS response (step 325) to the STA 310 indicating a status of "SCS in progress," and confirms that the temporary allocation is complete but subject to further adjustments based on the results of additional analysis.

[0051] Following the temporary resource allocation, AP / WLC 305 initiates a policy pre-check by comparing the information in the SCS request with the cached application profile (step 330). If a match is found with the cached profile, indicating that the UL / DL traffic corresponds to a known application, AP / WLC 305 sends a second SCS response to STA 310 (step 335). In some embodiments, the second SCS response may confirm the temporary allocation and indicate that, based on compatibility with the known profile, the temporary state will be changed to a permanent state.

[0052] If no match is found with the existing application profile, AP / WLC 305 continues to perform on-demand packet analysis. As shown in the figure, AP / WLC 305 first defines the verification time for performing detailed packet analysis (step 340). Then, AP / WLC 305 performs packet analysis such as DPI within a predefined time frame to determine the actual nature or classification of the UL / DL traffic (step 345). If the UL / DL traffic matches the updated application profile, or if no exact match is found but the traffic type is permitted for the requested TCLAS (and / or QoS profile) processing under certain general network policies, AP / WLC 305 sends a second response to STA 310 (step 350), confirming that the temporary allocation will continue.

[0053] If a policy violation is found, such as traffic from a known application being disallowed, or traffic not meeting any policy criteria, the AP / WLC 305 sends a second SCS response to the STA 310 (step 355), indicating that the original TCLAS (and / or QoS profile) processing specified in the SCS request is rejected. After or simultaneously with sending the second response, the AP / WLC 305 reclassifies the traffic to a new policy level consistent with the service type identified via DPI, and typically lower than the level originally requested. The AP / WLC 305 can then allocate resources and prioritize the traffic based on the new priority level (step 360). In embodiments where a security risk is identified during packet analysis, the AP / WLC 305 may choose to completely block the traffic or significantly restrict its transmission during further security checks (step 365).

[0054] In some embodiments, the AP / WLC 305 can trigger policy verification and on-demand packet analysis independently of received SCS requests. Instead, the AP / WLC can proactively inspect the UL / DL packets it receives and / or transmits in the network. This continuous inspection allows the AP / WLC 305 to compare the packet streams being processed with cached application profiles and / or predefined policy rules to determine the appropriate priority level for each stream. Following analysis, the AP / WLC 305 can allocate relevant network resources and prioritize traffic accordingly. This proactive and continuous packet monitoring and analysis approach helps maintain effective management of all traffic based on real-time conditions and conforms to established network standards. While this approach may not be particularly computationally efficient (e.g., due to continuous inspection), it is simpler to implement in current WLAN systems.

[0055] Figure 4 An example method 400 for performing policy validation and on-demand packet analysis for enhanced QoS management, according to some embodiments of the present disclosure, is described. In some embodiments, method 400 may be performed by one or more network devices having the necessary policy validation and packet analysis capabilities, such as... Figure 1 The WLC 155 and / or AP 105 depicted in the text Figure 2 The AP / WLC 205 depicted in the text, and Figure 3 The AP / WLC 305 is depicted in the image.

[0056] In box 405, WLC (or AP) (e.g., Figure 1 155) from the associated STA (e.g., Figure 1(110-2) Receives an SCS request. The SCS request is used to communicate how incoming or ongoing UL / DL traffic should be managed to meet predefined QoS standards. In some embodiments, the SCS request may include TCLAS information indicating data characteristics and desired priority levels. This information may include, but is not limited to: a DSCP value with a desired TID mapping, 5-tuple data (e.g., source IP, destination IP, protocol, source port, destination port), and / or an application identifier (e.g., application ID or FQDN / URL). In some embodiments, metadata such as mandatory traffic period, start time, burst size, and arrival interval range may also be included to further characterize specific traffic requirements.

[0057] In box 410, the WLC (or AP) compares the details provided in the SCS request with cached application profiles. In some embodiments, these profiles may include predefined settings and characteristics of known applications and services that have been previously analyzed and validated. Initial policy checks can quickly match incoming (or processing) UL / DL traffic with established application-specific policies without requiring real-time and extensive packet analysis (e.g., DPI, NBAR2) for each request. In some embodiments, a profile of a known application may include: a specific DSCP value and / or TID corresponding to a priority level suitable for the application's traffic, and predefined IP addresses, ports, and protocols typically used by the application. In some embodiments, the profile may also include an application ID, URL, or other signature that uniquely identifies the application. In some embodiments, detailed parameters indicating typical traffic patterns of the application (e.g., burst size, traffic cycle, and arrival interval) may be included in the profile to provide additional reference for accurate application classification and policy enforcement of incoming (or ongoing) UL / DL traffic.

[0058] In box 415, WLC determines whether there is a match between the SCS request and the cached application profile. For example, if the SCS request includes a DSCP value "46", an expected TID mapping "7", a protocol such as "UDP", and a port number "4006", this matches the profile of a video conferencing application such as Webex. This match indicates that the traffic belongs to an identified application and is eligible for high-priority processing.

[0059] If such a match is found, method 400 proceeds to box 430, where the WLC sends an affirmative SCS response to the STA. This response can indicate that the network has acknowledged the traffic type and priority level indicated in the SCS request and is ready to manage the specified UL / DL traffic based on that acknowledgment.

[0060] Following approval, in box 435, the WLC manages traffic according to the rules and configurations pre-established in the profile. In the example above, when traffic is identified as belonging to a high-priority video conferencing application, the WLC can apply appropriate QoS processing, including prioritizing traffic in the network queue and allocating sufficient bandwidth to maintain the quality of the video conference.

[0061] If no match is found during the initial policy check, indicating that the specified UL / DL traffic may correspond to an unknown application, then in box 420, WLC specifically sets a verification time for on-demand packet analysis (e.g., DPI, NBAR2). The verification time is used to narrow down the scope of packet analysis to the most relevant packets, thereby saving network computational resources. In some embodiments, the duration of the verification time may be determined based on the QoS characteristics of the traffic (e.g., mandatory traffic period, arrival interval range, and optional start time usage) and is set to ensure thorough checking while avoiding excessive latency that could degrade service quality. For applications providing real-time video conferencing services (e.g., Figure 1 (Application 125) Video data arrives every 20 ms, and WLC can be configured to observe 10 consecutive groups, with a total observation period of 200 ms. This duration allows for comprehensive group analysis without negatively impacting service quality.

[0062] In some embodiments, particularly when the defined verification time is excessively long, potentially exceeding the time that the application or STA can reasonably tolerate and posing a risk of service degradation, the WLC can send an additional SCS response to the STA. This response can indicate that the SCS verification process is still in progress and provide the estimated completion time (e.g., 250 ms). This communication helps manage STA expectations and maintain a stable connection when extended analytics are required.

[0063] In box 425, the WLC performs detailed packet analysis on UL / DL traffic falling within the defined verification time to determine its nature, type, or application classification. Techniques such as DPI and NBAR2 can be used to examine packet payloads. With DPI or NBAR2, the WLC can look for data format, application signatures (e.g., FQDN / URL or application ID), protocol usage (e.g., "RTP" or "HTTPS"), and other identifiers indicating the application or service type. The WLC can perform behavioral analysis by processing metadata such as packet frequency, burst patterns, and arrival intervals. This analysis can help differentiate between different types of traffic, such as video streaming and web browsing traffic, each with different data flow characteristics.

[0064] In box 440, WLC monitors whether the defined validation period has expired. If the validation period has expired, method 400 moves to box 445. If it has not expired, method 400 returns to box 425, where WLC continues group analysis until the validation period ends.

[0065] In box 445, the WLC identifies the service type of the UL / DL data stream being processed based on the results of packet analysis. This identification ensures that the network appropriately processes traffic according to its actual characteristics, not just the classification it requests. For example, suppose the SCS includes DSCP "46" and its expected TID mapping "7," which is typically reserved for real-time applications requiring high priority and low latency (e.g., video conferencing). However, after detailed packet analysis performed during the verification period, it is determined that the traffic being processed is actually for bulk data downloads. This type of traffic typically does not require the high priority indicated by the expected TID "7." Therefore, in this configuration, according to the general QoS policy, this traffic does not meet the priority level stated in the SCS request. The WLC can reclassify the traffic to a lower priority to ensure fair bandwidth allocation and network efficiency.

[0066] In box 450, using the service type identified through packet analysis, the WLC assesses whether the traffic is consistent with any updated or newly identified application profile, or whether, even if it doesn't match any existing profile, the service type is consistent with the TCLAS information specified in the SCS request. This consistency indicates that, according to certain network policies, the traffic being processed meets the priority level described in the SCS request. For example, suppose the SCS includes DSCP "46" and its expected TID mapping "7," which is typically reserved for high-priority real-time applications. Packet analysis reveals that the traffic is for a video streaming service that hasn't been profiled yet, but its characteristics are similar to those of other high-priority services. Although the traffic doesn't match any existing cached profile, its characteristics (e.g., consistent data rate and arrival interval, minimal jitter) are consistent with the network's general policies for handling high-priority traffic. In this configuration, even without a direct profile match, the WLC can determine that the traffic is permissible and allocate network resources accordingly.

[0067] If positive agreement is confirmed, method 400 proceeds to box 455, where the WLC updates the profile or creates a new profile to include the new application type. This update allows for faster approval of future similar SCS requests during the policy preflight phase. Afterward, method 400 moves to boxes 430 and 435, where the WLC sends a positive response confirming agreement and applies the requested QoS processing to the UL / DL data stream.

[0068] If the traffic is inconsistent with any profile and the service type is inconsistent with the TCLAS information specified in the SCS request, and is therefore not permitted according to the policy criteria (e.g., the SCS request indicates DSCP "46" and its expected TID mapping "7", requesting high priority, but the actual service type is for bulk data download), then method 400 proceeds to box 460. In box 460, the WLC sends a negative response to the STA, indicating that the requested TCLAS (and / or QoS profile) processing is rejected.

[0069] In box 465, the WLC reclassifies UL / DL traffic to a lower priority compatible with the identified server type of the traffic. In embodiments where packet analysis reveals security risks or threats, the WLC may block or significantly restrict the transmission of UL / DL traffic while awaiting further security checks.

[0070] Example method 400 is provided for conceptual clarity. In some embodiments, upon receiving an SCS request, the WLC may temporarily allocate resources to incoming (or ongoing) UL / DL traffic without waiting for the initial policy preflight to complete. In such a configuration, an initial SCS response may be sent to the STA, indicating that SCS verification is in progress and that resource allocation and traffic processing are temporary and will be confirmed or adjusted based on further analysis. The initial SCS response informs the STA that the processing of its traffic may still change. After sending the initial SCS response, the WLC continues to perform a policy preflight. If the preflight reveals a match with an existing application profile, the WLC sends a second SCS response to the STA, confirming that the temporary resource allocation will continue until the transmission is complete. A positive response indicates that the initially allocated resources and processing are appropriate and will be maintained. In embodiments where no match is found, the WLC may perform detailed packet analysis (e.g., DPI, NBAR2) to identify the nature of the traffic or the actual service type. If packet analysis determines that the traffic's service type matches the TCLAS information specified in the SCS request and is permitted according to the general network policy, the WLC sends a second SCS response to the STA, confirming that the temporary resource allocation will continue until the transmission ends. A positive response indicates that the traffic, although initially unfiled, meets the policy criteria for the requested priority. If packet analysis reveals an inconsistency between the actual service type and the requested processing, indicating that the traffic does not meet the priority level stated in the SCS request, the WLC sends a second response to the STA, rejecting the requested processing. The WLC can then reclassify the traffic to a lower priority consistent with the traffic's actual service type, or block the traffic if a security threat exists.

[0071] In some embodiments, the WLC can initiate policy preflight or on-demand packet analysis without waiting for an SCS request. Instead, the WLC can continuously monitor and evaluate each UL / DL data stream it processes. The WLC can then apply dynamic resource allocation and prioritization based on the real-time evaluation. As part of continuous traffic management, the WLC can compare packet streams with cached application profiles. These profiles may contain detailed characteristics of known applications, including DSCP values ​​and preferred TIDs, typical 5-tuple configurations, and expected traffic patterns such as burst size and arrival intervals. When each packet arrives, the WLC can evaluate its metadata to see if the packet matches any existing profiles. If a match is found, the WLC can quickly apply the appropriate QoS settings to manage the known traffic type. For packets that do not match any existing profiles, the WLC can perform detailed packet analysis to determine the nature of the traffic. This may involve deep inspection using DPI or NBAR2 techniques to examine the payload of each packet and discover the underlying application signature, data format, and behavioral patterns. Based on this analysis, the WLC can determine the appropriate priority and resource allocation for the traffic. Proactive and continuous assessment allows WLC to effectively adapt to changes in network conditions and traffic types. By not relying on SCS requests, WLC maintains a high level of network control and preemptively manages resources to prevent congestion.

[0072] Figure 5 This is a flowchart depicting an example method 500 for enhanced SCS policy verification according to some embodiments of the present disclosure.

[0073] In box 505, the network device receives a Flow Classification Service (SCS) request (such as...) from the associated site (STA). Figure 2 As shown in step 215), the SCS request specifies one or more sets of Traffic Classes (TCLAS) information for the data stream transmitted between the network device and the STA.

[0074] In some embodiments, the set or more sets of TCLAS information may include at least one of the following: a 5-tuple for the data stream, or a Differential Service Code Point (DSCP) value, and the 5-tuple may include a source IP address, a destination IP address, a source port, a destination port, or a protocol type.

[0075] In some embodiments, the associated QoS profile information may include one or more QoS characteristics for the data stream, the one or more QoS characteristics including at least one of the following: desired data rate, latency limit, traffic arrival interval, traffic service period, flow start time, and priority level indicated by traffic identifier (TID).

[0076] In box 510, the network device compares one or more sets of TCLAS information and associated QoS profile information with one or more cached application profiles (e.g., ...). Figure 2 (See step 220).

[0077] In box 515, the network device determines that one or more sets of TCLAS information and associated QoS profile information do not match any of one or more cached application profiles.

[0078] In box 520, in response to the determination, the network device performs packet analysis to determine the service type of the data flow (e.g., ...). Figure 2 (See step 245).

[0079] In box 525, the network device verifies, based on one or more defined network policies, that a set of or more sets of TCLAS information and associated QoS profile information are consistent with the determined type of service.

[0080] In box 530, in response to this acknowledgment, the network device applies one or more processing steps (such as...) to the data stream based on one or more sets of TCLAS information and associated QoS profile information received in the SCS request. Figure 2 As shown in step 255), wherein one or more processes are consistent with at least one of the following: the determined service type, or one or more defined network policies.

[0081] In some embodiments, after determining that one or more sets of TCLAS information and associated QoS profile information do not match any of one or more cached application profiles, the network device may send a first SCS response to the STA, indicating that SCS authentication is in progress (e.g., Figure 2 (as shown in step 235). In some embodiments, the first SCS response may also include an indication specifying a time period after which one or more processes will be assigned to the STA.

[0082] In some embodiments, after confirming that a set of or more sets of TCLAS information and associated QoS profile information are consistent with the determined service type based on one or more defined network policies, the network device may send a second SCS response to the STA to confirm the SCS request (such as...). Figure 2 (See step 250).

[0083] In some embodiments, the network device may further define a verification time for packet analysis based on one or more network characteristics of the data flow (e.g., Figure 2 (See step 235).

[0084] In some embodiments, in order to apply one or more processing to a data stream, a network device may allocate network resources to the data stream to satisfy one or more of the following: data rate requirements, latency limit requirements, or traffic arrival intervals, and service cycle requirements.

[0085] In some embodiments, in order to apply one or more processing to a data stream, a network device may prioritize the data stream in a network queue to meet one or more priority level requirements of the data stream.

[0086] In some embodiments, the network device can receive a second request from the STA (such as...). Figure 2 As shown in step 215), the second SCS request specifies a second set or more sets of TCLAS information for the second data stream transmitted between the network device and the STA, each set of second TCLAS information accompanied by associated QoS profile information. The network device can compare the second set or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles (e.g., ...). Figure 2 (See step 220). The network device can determine that a second set of one or more sets of TCLAS information and associated QoS profile information matches an application profile in one or more cached application profiles. The network device can apply one or more second processes (such as...) to the second data stream that are consistent with the matched profile. Figure 2 (See step 230).

[0087] In some embodiments, the network device may further send an SCS response to the STA (such as...). Figure 2 As shown in step 225), it is confirmed that a second set or more sets of TCLAS information and associated QoS profile information have been received in the second SCS request for the second data stream.

[0088] In some embodiments, the network device can receive a second SCS request from the STA (such as...). Figure 2 As shown in step 215), the second SCS request specifies a second set or more sets of TCLAS information for the second data stream transmitted between the network device and the STA, each set of TCLAS information accompanied by associated QoS profile information. The network device can compare the second set or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles (e.g., ...). Figure 2 (See step 220). The network device can determine that the second set of one or more sets of TCLAS information and associated QoS profile information does not match any of the one or more cached application profiles. Then, the network device can perform packet analysis to determine the service type of the second data stream (e.g., ...). Figure 2(See step 240). The network device can, based on one or more defined network policies, confirm that the second set or more sets of TCLAS information and associated QoS profile information are inconsistent with the service type of the determined second data stream.

[0089] In some embodiments, after determining that the second set or more sets of TCLAS information and associated QoS profile information do not match any of one or more cached application profiles, the network device may send a first SCS response to the STA, indicating that SCS authentication is in progress (e.g., Figure 2 (See step 235). After the network device confirms, based on one or more defined network policies, that the second set of one or more sets of TCLAS information and associated QoS profile information are inconsistent with the determined service type of the second data stream, the network device may send a second response to the STA indicating that the request has been rejected (e.g., ...). Figure 2 (as shown in step 260). The network device can then reclassify the second data stream to a second priority level lower than the priority level specified in the second set of one or more sets of TCLAS information and associated QoS profile information (e.g., ...). Figure 2 (As shown in step 265). The network device may assign one or more second processes to the second data stream that are consistent with the second priority level.

[0090] In some embodiments, the network device may send a third SCS response to the STA, indicating a second priority level and indicating that one or more second processes have been assigned by the network device to the second data stream.

[0091] In some embodiments, after determining that the second set or more sets of TCLAS information and associated QoS profile information do not match any of one or more cached application profiles, the network device may send a first SCS response to the STA, indicating that SCS authentication is in progress (e.g., Figure 2 (See step 235). After the network device confirms, based on one or more defined network policies, that the second set of one or more sets of TCLAS information and associated QoS profile information are inconsistent with the determined service type of the second data stream, the network device may send a second response to the STA indicating that the request has been rejected (e.g., ...). Figure 2 (See step 260). Then, the network device can block the transmission of the second data stream to the STA.

[0092] In some embodiments, the network device may include at least one of an access point (AP), a wireless local area network controller (WLC), a network security device, or a gateway, wherein the network device is integrated with a network policy enforcement function (PEF).

[0093] In some embodiments, in response to an SCS request, a network device may temporarily apply one or more second processes (such as...) to the data stream within a defined time frame. Figure 3 (as shown in step 320), wherein one or more second processes are consistent with one or more sets of TCLAS information according to one or more defined network policies.

[0094] Figure 6 An example network device 600 configured to perform various aspects of this disclosure is depicted. In some embodiments, the example network device 600 may correspond to... Figure 1 The AP 105 or WLC 155 depicted in the text Figure 2 The AP / WLC 205 depicted in the text, and Figure 3 The AP / WLC 305 is depicted in the image.

[0095] As shown in the figure, the example network device 600 includes a processor 605, a memory 610, a storage device 615, one or more transceivers 620, one or more I / O interfaces 680, and one or more network interfaces 625. In some embodiments, an I / O device 640 is connected via one or more I / O interfaces 680. Furthermore, via network interfaces 625, the network device 600 can be communicatively coupled to one or more other devices and components (e.g., via a network, which may include the Internet, one or more local area networks, etc.). Each of these components is communicatively coupled via one or more buses 630. In some embodiments, one or more antennas 635 may be coupled to transceiver 620 for transmitting and receiving wireless signals.

[0096] Processor 605 typically represents a single central processing unit (CPU) and / or graphics processing unit (GPU), multiple CPUs and / or GPUs, a microcontroller, an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). Processor 605 processes information received through transceiver 620, I / O interface 680, and network interface 625. Processor 605 retrieves and executes programming instructions stored in memory 610, and stores and retrieves application data residing in storage device 615.

[0097] Storage device 615 can be any combination of disk drives, flash-based storage devices, etc., and can include fixed and / or removable storage devices, such as fixed disk drives, removable storage cards, caches, optical storage, network-attached storage (NAS), or storage area networks (SANs). Storage device 615 can store various types of data used for efficient system operation.

[0098] Memory 610 may include random access memory (RAM) and read-only memory (ROM). Memory 610 may store processor-executable software code containing instructions that, when executed by processor 605, enable network device 600 to perform the various functions described herein for wireless communication. In the illustrated example, memory 610 includes four software components: profile management component 645, policy enforcement function (PEF) component 650, flow classification service (SCS) management component 655, and resource allocation component 660. In some embodiments, profile management component 645 may be configured to create, update, and manage application profiles. These profiles may contain information about identified applications, their typical network behavior, and preferred QoS settings. In some embodiments, PEF component 650 may handle policy pre-detection and / or on-demand packet analysis. PEF component 650 may first evaluate incoming UL / DL traffic relative to cached application profiles to determine if it conforms to established criteria, and then use analysis techniques such as DPI to further examine traffic that initially does not match known profiles. In some embodiments, SCS management component 655 may be designed to handle SCS requests and responses. SCS management component 655 can extract and analyze all incoming SCS requests from the STA. SCS management component 655 can route information within these requests to PEF component 650 for detailed policy inspection and packet analysis. Upon completion of the analysis, SCS management component 655 can generate relevant SCS responses based on findings from the PEF. In some embodiments, resource allocation component 660 can allocate bandwidth and other network resources among various types of traffic based on priority levels. Resource allocation component 660 can further prioritize different types of traffic in the network queue to ensure that time-sensitive services such as real-time audio and video communications can be transmitted with low latency and high reliability.

[0099] Although depicted as discrete components for clarity of concept, in some embodiments, the operation of the depicted components (and other components not shown) can be combined or distributed across any number of components. Furthermore, although depicted as software residing in memory 610, in some aspects, the operation of the depicted components (and other components not shown) can be implemented using hardware, software, or a combination of hardware and software.

[0100] Figure 7 An example client device 700 configured to perform various aspects of this disclosure is depicted according to some embodiments of the present disclosure. In some embodiments, the example client device 700 may correspond to Figure 1 The STA 110 depicted in the text Figure 2 The STA 210 depicted in the text, or Figure 4 The STA 310 depicted in the text.

[0101] As shown in the figure, the example client device 700 includes a processor 705, a memory 710, a storage device 715, one or more transceivers 720, one or more I / O interfaces 780, and one or more network interfaces 725. In some embodiments, an I / O device 740 is connected via one or more I / O interfaces 780. Furthermore, via the network interface 725, the client device 700 can be communicatively coupled to one or more other devices and components (e.g., via a network, which may include the Internet, one or more local area networks, etc.). Each of these components is communicatively coupled via one or more buses 730. In some embodiments, one or more antennas 735 may be coupled to the transceiver 720 for transmitting and receiving wireless signals.

[0102] Processor 705 typically represents a single central processing unit (CPU) and / or graphics processing unit (GPU), multiple CPUs and / or GPUs, a microcontroller, an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). Processor 705 processes information received via transceiver 720, I / O interface 770, and network interface 725. Processor 705 retrieves and executes programming instructions stored in memory 710, and stores and retrieves application data residing in storage device 715.

[0103] Storage device 715 can be any combination of disk drives, flash-based storage devices, etc., and can include fixed and / or removable storage devices, such as fixed disk drives, removable storage cards, caches, optical storage, network-attached storage (NAS), or storage area networks (SANs). Storage device 715 can store various types of data used for efficient system operation.

[0104] Memory 710 may include random access memory (RAM) and read-only memory (ROM). Memory 710 may store processor-executable software code containing instructions that, when executed by processor 705, enable client device 700 to perform the various functions described herein for wireless communication. In the illustrated example, memory 710 includes two software components: an SCS management component 745 and a performance monitoring component 750. In some embodiments, SCS management component 745 may create an SCS request to the AP or WLC based on the QoS requirements of each application. SCS management component 745 may generate relevant data from applications running on the STA, such as DSCP values ​​and preferred TIDs, 5-tuple data, and other QoS parameters. Furthermore, SCS management component 745 may analyze SCS responses from the WLC to determine appropriate actions or adjustments based on network feedback. For example, if the SCS response indicates approval for the requested TCLAS (and / or QoS profile) processing, SCS management component 745 may locally adjust QoS settings to ensure efficient reception or transmission of traffic at the STA level. If the response indicates that certain requests cannot be fulfilled (due to inconsistencies with application profiles or policy restrictions), the SCS management component 745 can adjust the STA's network behavior accordingly, for example, by adjusting QoS parameters locally or notifying users or applications of these changes. In some embodiments, the performance monitoring component 750 can monitor the received quality of service, adjust local settings, and / or report differences to the WLC. The performance monitoring component 750 can track parameters such as latency, packet loss, and jitter to assess the quality of network connectivity and provide feedback to the WLC as necessary.

[0105] Although depicted as discrete components for clarity of concept, in some embodiments, the operation of the depicted components (and other components not shown) can be combined or distributed across any number of components. Furthermore, although depicted as software residing in memory 710, in some aspects, the operation of the depicted components (and other components not shown) can be implemented using hardware, software, or a combination of hardware and software.

[0106] Various embodiments have been referenced in this disclosure. However, the scope of this disclosure is not limited to the specific embodiments described. Rather, any combination of the described features and elements is contemplated for implementing and practicing the contemplated embodiments, whether or not it is associated with different embodiments. Furthermore, when elements of an embodiment are described in the form of "at least one of A and B" or "at least one of A or B," it should be understood that embodiments including a single element A, embodiments including a single element B, and embodiments including elements A and B are contemplated respectively. Moreover, while some embodiments disclosed herein may have advantages over other possible solutions or prior art implementations, whether a particular embodiment achieves a particular advantage does not limit the scope of this disclosure. Therefore, the aspects, features, embodiments, and advantages disclosed herein are merely illustrative and should not be considered elements or limitations of the appended claims unless expressly stated in the claims. Similarly, references to "the invention" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered elements or limitations of the appended claims unless expressly stated in the claims.

[0107] Those skilled in the art will understand that the embodiments disclosed herein can be implemented as systems, methods, or computer program products. Therefore, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which are generally referred to herein as “circuit,” “module,” or “system.” Furthermore, embodiments can take the form of computer program products embodied in one or more computer-readable media, on which computer-readable program code is embodied.

[0108] Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, radio frequency, or any suitable combination thereof.

[0109] Computer program code used to perform the operations of embodiments of this disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and traditional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The program code may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] This document describes aspects of the disclosure with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0111] These computer program instructions may also be stored in a computer-readable medium that may instruct a computer, other programmable data processing apparatus, or other device to operate in a particular manner, such that the instructions stored in the computer-readable medium produce an article of writing, which includes instructions that implement the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0112] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, provide for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each box in a flowchart or block diagram may represent a module, segment, or portion of code, including one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the boxes may not occur in the order indicated in the drawings. For example, two boxes shown consecutively may actually execute substantially simultaneously, or these boxes may sometimes execute in reverse order, depending on the functions involved. It should also be noted that each box in the block diagrams and / or flowcharts, and combinations of boxes in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware, or a combination of dedicated hardware and computer instructions, that performs the specified functions or actions.

[0114] In view of the foregoing, the scope of this disclosure is defined by the appended claims.

Claims

1. A method comprising: A network device receives a Flow Classification Service (SCS) request from an associated station (STA), wherein the SCS request specifies one or more sets of Traffic Classes (TCLAS) information for a data stream transmitted between the network device and the STA, and each set of TCLAS information is accompanied by an associated Quality of Service (QoS) profile for the data stream. The network device compares the one or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles; The network device determines that the set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles; In response to the determination, the network device performs packet analysis to determine the service type of the data stream; The network device confirms, based on one or more defined network policies, that the set of or more sets of TCLAS information and the associated QoS profile information are consistent with the determined service type; as well as In response to the confirmation, the network device applies one or more processing steps to the data stream based on the set or more sets of TCLAS information received in the SCS request and the associated QoS profile information, wherein the one or more processing steps are consistent with at least one of the following: the determined service type, or the one or more defined network policies.

2. The method according to claim 1, further comprising: After determining that the set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles, the network device sends a first SCS response to the STA, the first SCS response indicating that SCS verification is in progress; as well as After confirming that the set of one or more sets of TCLAS information and the associated QoS profile information are consistent with the determined service type based on the one or more defined network policies, the network device sends a second SCS response to the STA, and the second SCS response confirms the SCS request.

3. The method of claim 2, wherein the first SCS response further includes an indication specifying a time period after which the one or more processes will be assigned to the STA.

4. The method according to any one of the preceding claims, wherein the associated QoS profile information includes one or more QoS characteristics of the data stream, the one or more QoS characteristics including at least one of the following: expected data rate, latency limit, traffic arrival interval, traffic service period, flow start time, and priority level indicated by traffic identifier (TID).

5. The method according to claim 4, further comprising: The network device defines the verification time for the packet analysis based on one or more QoS characteristics of the data stream.

6. The method according to any one of the preceding claims, wherein the set or more sets of TCLAS information include at least one of a 5-tuple or a Differential Service Code Point (DSCP) value of the data stream, the 5-tuple including a source IP address, a destination IP address, a source port, a destination port, or a protocol type.

7. The method according to any one of the preceding claims, wherein applying the one or more processing steps to the data stream comprises: The network device allocates network resources for the data stream to meet one or more of the following requirements: data rate requirements, latency limit requirements, traffic arrival intervals, and service cycle requirements.

8. The method according to any one of the preceding claims, wherein applying the one or more processing to the data stream comprises: The network device prioritizes the data streams in the network queue to meet one or more priority level requirements of the data streams.

9. The method according to any one of the preceding claims further comprises: The network device receives a second SCS request from the STA, wherein the second SCS request specifies a second set or more sets of TCLAS information for a second data stream transmitted between the network device and the STA, and each set of second TCLAS information is accompanied by associated QoS profile information. The network device compares the second set or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles; Determine that the second set or more sets of TCLAS information and the associated QoS profile information match the application profile of one of the one or more cached application profiles; as well as The network device applies one or more second processes to the second data stream that are consistent with the matched profile.

10. The method of claim 9, further comprising: The network device sends an SCS response to the STA, which confirms that the second set of one or more sets of TCLAS information and the associated QoS profile information have been received in the second SCS request for the second data stream.

11. The method according to any one of the preceding claims, further comprising: The network device receives a second SCS request from the STA, wherein the second SCS request specifies a second set or more sets of TCLAS information for a second data stream transmitted between the network device and the STA, and each set of second TCLAS information is accompanied by associated QoS profile information. The network device compares the second set or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles; Determine that the second set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles; In response to the determination, the network device performs packet analysis to determine the service type of the second data stream; as well as Based on one or more defined network policies, the network device confirms that the second set or more sets of TCLAS information and the associated QoS profile information are inconsistent with the service type of the determined second data stream.

12. The method of claim 11, further comprising: After determining that the second set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles, the network device sends a first SCS response to the STA, the first SCS response indicating that SCS verification is being processed; After the network device confirms, based on one or more defined network policies, that the second set of or more sets of TCLAS information and the associated QoS profile information are inconsistent with the determined service type of the second data stream, the network device sends a second SCS response to the STA, the second SCS response indicating that the second SCS request has been rejected; The network device reclassifies the second data stream to a second priority level, which is lower than the priority level specified in the second set of one or more sets of TCLAS information and the associated QoS profile information; as well as The network device allocates one or more second processes to the second data stream that are consistent with the second priority level.

13. The method of claim 12, further comprising: The network device sends a third SCS response to the STA, the third SCS response indicating the second priority level and indicating that the one or more second processes have been assigned by the network device to the second data stream.

14. The method according to any one of claims 11 to 13, further comprising: After determining that the second set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles, the network device sends a first SCS response to the STA, the first SCS response indicating that SCS verification is being processed; After the network device confirms, based on one or more defined network policies, that the second set of or more sets of TCLAS information and the associated QoS profile information are inconsistent with the determined service type of the second data stream, the network device sends a second SCS response to the STA, the second SCS response indicating that the second SCS request has been rejected; as well as The network device blocks the transmission of the second data stream to the STA.

15. The method according to any one of the preceding claims, wherein the network device includes at least one of an access point (AP), a wireless local area network controller (WLC), a network security device, or a gateway, and wherein the network device is integrated with a network policy enforcement function (PEF).

16. The method according to any one of the preceding claims further comprises: In response to the SCS request, the network device temporarily applies one or more second processes to the data stream within a defined time frame, wherein the one or more second processes are consistent with the one or more sets of TCLAS information according to the one or more defined network policies.

17. A system for a network device, comprising: One or more computer processors; as well as One or more memories, the one or more memories collectively containing one or more programs, the one or more programs performing operations when executed by the one or more computer processors, the operations including: A network device receives a Flow Classification Service (SCS) request from an associated station (STA), wherein the SCS request specifies one or more sets of Traffic Classes (TCLAS) information for a data stream transmitted between the network device and the STA, and each set of TCLAS information is accompanied by an associated Quality of Service (QoS) profile for the data stream. Compare the one or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles; Determine that the set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles; Perform group analysis to determine the service type of the data stream; Based on one or more defined network policies, confirm that the set or more sets of TCLAS information and the associated QoS profile information are consistent with the determined service type; and In response to the confirmation, based on the set of or more sets of TCLAS information received in the SCS request and the associated QoS profile information, one or more processes are applied to the data stream, wherein the one or more processes are consistent with at least one of the following: the determined service type and the one or more defined network policies.

18. The system of claim 17, wherein the one or more programs perform the operation when executed by the one or more computer processors, the operation further comprising: After determining that the set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles, the network device sends a first SCS response to the STA, the first SCS response indicating that SCS verification is in progress; as well as After confirming that the set of one or more sets of TCLAS information and the associated QoS profile information are consistent with the determined service type based on the one or more defined network policies, the network device sends a second SCS response to the STA, and the second SCS response confirms the SCS request.

19. The system of claim 17 or 18, wherein the set or more sets of TCLAS information include at least one of a 5-tuple or a Differential Service Code Point (DSCP) value of the data stream, the 5-tuple including a source IP address, a destination IP address, a source port, a destination port, or a protocol type.

20. One or more non-transitory computer-readable media containing, in any combination, computer program code that performs operations when executed by an operation of a computer system, the operations including: A network device receives a Flow Classification Service (SCS) request from an associated station (STA), wherein the SCS request specifies one or more sets of Traffic Classes (TCLAS) information for a data stream transmitted between the network device and the STA, and each set of TCLAS information is accompanied by an associated Quality of Service (QoS) profile for the data stream. The network device compares the one or more sets of TCLAS information and the associated QoS profile information with one or more cached application profiles; The network device determines that the set or more sets of TCLAS information and the associated QoS profile information do not match any of the one or more cached application profiles; The network device performs packet analysis to determine the service type of the data stream; The network device confirms, based on one or more defined network policies, that the set of or more sets of TCLAS information and the associated QoS profile information are consistent with the determined service type; as well as In response to the confirmation, the network device applies one or more processing steps to the data stream based on the set or more sets of TCLAS information received in the SCS request and the associated QoS profile information, wherein the one or more processing steps are consistent with at least one of the following: the determined service type and the one or more defined network policies.

Images