Method for operating a wireless communication system

Abstract

Wireless communication systems that dynamically adjust system parameters to manage network congestion, methods for manufacturing / using such systems, and vehicles equipped with such systems are presented. One method for operating a wireless communication system features a control system that monitors various network traffic factors influencing network congestion to generate raw network traffic data and uses a trained machine learning model to transform the raw network traffic data based on a set of processing rules to generate processed traffic data. The control system calculates a congestion score as a function of traffic factor values ​​within the processed traffic data, each weighted using a respective weighting factor assigned to the corresponding traffic factor within the network traffic factors.In response to a determination that the congestion rating exceeds a congestion threshold, the system controller modulates the operation of the wireless communication system by adjusting several system WiFi parameters based on the congestion rating.

Description

Technical field This description applies generally to wireless communication systems. In particular, aspects of this description relate to control protocols for wireless networks for adjusting wireless system parameters to manage network congestion. Introduction Modern vehicles, such as the contemporary automobile, may initially be equipped with a network of onboard controls, sensors, and communication devices that enable a variety of vehicle services, such as navigation assistance, wireless connectivity, and multimedia entertainment. To provide occupants with telecommunications and computing functionality, many passenger compartments are now equipped with a central telematics unit that functions as both a human-machine interface (HMI) and an in-vehicle computing device. Generally, the telematics unit acts as a bidirectional radio transceiver capable of simultaneously sending and receiving data in various formats, including network data packets for Wi-Fi connectivity.Data packets can be sent from a mobile phone mast to a mobile phone-enabled vehicle via downlink (or “download”) transmission using ultra-high frequency (UHF) or super-high frequency (SHF) radio signals, and can be sent in reverse from the vehicle to the mast via uplink (or “upload”) transmission. Many modern automobiles provide occupants with Wi-Fi connectivity, which can be used for various applications, from accessing the internet to streaming digital radio and video content, and providing a Wi-Fi hotspot for devices brought into the vehicle. Along with Wi-Fi network access, vehicles may offer other wireless features, such as Bluetooth® and ultra-wideband (UWB) connectivity, which operate on the same radio frequency (RF) bands as Wi-Fi, thus increasing network congestion and impacting quality of service. Current WLAN (Wireless Local Access Network) systems typically manage network traffic using a Wi-Fi access point (AP), which controls traffic priority using fixed QoS (Quality of Service) settings known as EDCA (Enhanced Distributed Channel Access) parameters.However, these EDCA parameters are typically set to fixed "default" values ​​in current WiFi standards. Using fixed default EDCA parameters in congested scenarios can lead to more frequent frame collisions and a consequent degradation of network performance. US Patent 2020 / 0296739A1 describes a device comprising an Enhanced Distributed Channel Access (EDCA) selection agent configured to receive a multitude of measurements relating to a multitude of clients, which uses these measurements to calculate a set of optimal EDCA parameters and provides an EDCA configuration for the multitude of clients. The device also includes a client behavior predictor configured to receive these measurements, which also receives the set of optimal EDCA parameters and calculates a multitude of client mode predictions. These client mode predictions can be evaluated and potentially used for additional EDCA parameter optimization by the EDCA selection agent. "CISCO SYSTEMS, Inc.: RF Profile. San Jose, 2019. 8 p." describes RF profiles. According to the document, RF profiles allow a group of access points (APs) with a common coverage area to be grouped together, and the way RRM (Remote Resource Management) operates the APs within that coverage area can be selectively modified. For example, a university might deploy a high density of APs in an area where many users gather or meet. The document describes how, in this situation, both data rates and power must be adjusted to accommodate the cell density while also managing co-channel interference. Normal coverage is provided in adjacent areas, and the document states that such adjustments would result in a loss of coverage.RF profiles and RF tags allow you to optimize RF settings for a number of access points (APs) operating in different environments or coverage areas. RF profiles are created for IEEE 802.11 radios and applied to all APs associated with a specific RF tag, ensuring that all APs with that tag share the same profile settings. “ETSI: Intelligent transport systems (ITS); decentralized congestion control mechanisms for intelligent transport systems operating in the 5 GHz range; access layer part. V1.1.1. Valbonne, 2011 (ETSI TS 102 687). 45 pp.” describes ITS systems for traffic safety and efficiency, encompassing both vehicle-to-vehicle communication and related communication between vehicles and roadside equipment in highly dynamic ad-hoc vehicle networks. These systems (ITS stations) are based on a set of protocols and parameters known as ITS-G5, defined in the European profile standard for the physical and media access layer of 5 GHz ITS. Many ITS applications and services rely on the cooperative behavior of vehicles and roadside units forming an ad-hoc vehicle network (VANET).VANET enables time-critical traffic safety applications where rapid information exchange is required to warn and assist drivers in a timely manner. It is described that particular attention should be paid to ensuring the proper functioning of VANET, including the decentralized traffic control (DCC) for the ITS-G5 channels. DCC is described as a cross-layer function, meaning it has features located on multiple layers of the ITS station's reference architecture. Therefore, the document defines which DCC components reside on which layer of the ITS station's communication architecture. Furthermore, the document specifies the DCC mechanisms at the access layer (DCC_access), including per-packet transmit power control (TPC), transmit rate control (TRC), and transmit data rate control (TDC).The latter two control functions modify the average transmit power by adjusting the duty cycle of the ITS station, i.e., the proportion of time the ITS station is in "transmit state." Additionally, DCC sensitivity control (DSC) adjusts the clear channel rating to address local channel congestion. Higher-priority packets are treated less restrictively through the implementation of a transmission queue and transmission access control (TAC). DCC mechanisms rely on channel information. Channel state information is obtained through channel queries. Channel query measures are defined, enabling the DCC methods TPC, TRC, and TDC. These measures are based on received signal level thresholds or preamble information from detected packets.The document does not define the mechanisms at levels other than the access level, nor the administrative aspects. These other mechanisms and administrative aspects are necessary for DCC to function properly. Description of the invention The invention is defined by the claims. This paper presents wireless communication systems with associated control logic for dynamically adjusting communication system parameters to manage network congestion, methods for manufacturing and operating such communication systems, and motor vehicles equipped with such systems. For example, systems and methods for mitigating WiFi network congestion by dynamically adjusting EDCA (Enhanced Distributed Channel Access) parameters, PD (Energy Detection) thresholds, and PD (Packet Detection) are presented.In contrast to using fixed / standard system settings initiated by a commercial access point (AP), EDCA, ED, and PD parameters can be adjusted based on a predictive congestion assessment calculated as a function of predefined network congestion characteristics (also referred to as "traffic factors") to, for example, help ensure fairness and compatibility with legacy equipment while offering flexible coordination options (local, centralized, or hybrid). A significant challenge in dynamically adjusting EDCA parameters is ensuring equitable access and functionality across heterogeneous user devices, as changing the parameters for one device can negatively impact the use of others. To address this issue, disclosed wireless communication systems can implement several improvement mechanisms, including a closed-loop feedback system to re-evaluate parameter changes and a set of predefined failover features to rectify unwanted parameter changes. In congestion scenarios, existing network architectures often feature a mix of devices, some of which use legacy DCF (Distributed Coordination Function) settings or static EDCA-based access control settings.To help ensure compatibility and coexistence between legacy devices and those with dynamic EDCA capabilities, the disclosed framework can selectively adjust specific parameters to prevent any reversal of priorities, thus helping to ensure smooth coexistence and minimal disruption for both types of devices. Due to the complexity involved in deriving real-time network conditions, which can be critical for effective evaluation and adjustment of system parameters, existing network protocols are typically unable to provide intelligent dynamic adjustment of EDCA parameters. In contrast, revealed wireless communication architectures can implement a novel system and algorithm for monitoring and measuring network congestion. This algorithm calculates a congestion score that predicts network congestion using raw, real-time network traffic data. This score provides a dynamic basis for adjusting EDCA parameters, ensuring they can be continuously optimized in response to changing congestion levels.Furthermore, a flexible coordination framework is introduced to adapt EDCA / ED / PD parameters through local, centralized and / or hybrid coordination in order to provide adaptable network management strategies based on the specific requirements of the environment. Aspects of this description are directed toward methods for constructing and methods for using any of the wireless communication systems described herein. An example is presented of a method for operating a wireless communication system, such as a WiFi-enabled central unit for motor vehicle telematics. This representative method includes, in any order and in any combination, any of the options and features disclosed above and below: monitoring, for example, via a resident or remote microprocessor, central controller, control module, programmable logic device, or a network of processors / controllers / modules / devices (collectively, "system controller"), through an API, SDN, or WiFi driver, a mixture of network traffic factors influencing network congestion of the wireless communication system to generate raw network traffic data; transforming, for example, through a network of network traffic factors that influence ...B. via the control panel, raw network traffic data based on a processing rule set to generate processed traffic data; Calculate, e.g. via the control panel using a trained machine learning (ML) model, a congestion score as a function of the network traffic factor values ​​within the processed traffic data, each weighted using a respective weighting factor assigned to its corresponding traffic factor within the network traffic factors; Determine, e.g. via the control panel, whether the congestion score exceeds a congestion threshold; and, in response to determining that the congestion score exceeds the congestion threshold, modulate the operation of the wireless communication system by adjusting one or more system WiFi / WLAN parameters based on the congestion score. Aspects of this description also extend to computer-readable media (CRM) containing instructions executable by a controller to provide dynamic adjustment of WiFi / WLAN parameters for network congestion management. In one example, a non-volatile CRM stores instructions executable by a wireless communication system's control panel. When executed, these CRM-stored instructions cause the control panel to perform operations that include: monitoring multiple network traffic factors influencing network congestion of the wireless communication system to generate a raw network traffic record; and transforming the raw network traffic record based on a set of processing rules to generate a processed traffic record.Calculate, using a trained machine learning (ML) model, a congestion score as a function of multiple traffic factor values ​​within the processed traffic dataset, each weighted using a respective weighting factor assigned to a corresponding traffic factor within the network traffic factors; determine whether the congestion score exceeds a congestion threshold; and modulate, in response to the determination that the congestion score exceeds the congestion threshold, the operation of the wireless communication system by adjusting several system WiFi / WLAN parameters based on the congestion score. Additional aspects of this description are directed at motor vehicles equipped with intelligent wireless communication systems that dynamically adjust system parameters to manage fluctuations in network congestion. As used herein, the terms "vehicle" and "motor vehicle" can be used interchangeably and synonymously to refer to any relevant vehicle platform, such as passenger cars, commercial vehicles, industrial vehicles, all-terrain vehicles and off-road vehicles, tracked vehicles, agricultural equipment, motorcycles, watercraft, aircraft, spacecraft, etc. In an example, a motor vehicle has a vehicle body with a passenger cabin, multiple road wheels attached to the vehicle body (e.g., via corner modules coupled to a unibody or body-to-frame chassis), and other standard original equipment.A propulsion unit, which may be an electric traction motor and / or an internal combustion engine (ICE), is located within the vehicle body and drives the road wheel(s) to propel the vehicle. A wireless communication system, such as a central telematics unit, is located within the vehicle's passenger cabin and wirelessly exchanges network data packets with a remote distributed computing system. Continuing with the discussion of the preceding example, the vehicle is also equipped with a resident or remote control unit programmed to monitor a mixture of network traffic factors that affect network congestion of the wireless communication system in order to generate a set of raw network traffic data. The control unit then transforms the raw network traffic data based on a predefined set of processing rules to generate a set of processed traffic data. Using a trained machine learning model, the control unit then calculates a congestion score as a function of the traffic factor values ​​contained in the processed traffic data set, each weighted using a respective weighting factor assigned to its corresponding traffic factor within the network traffic factors.In response to a determination that the congestion assessment exceeds a system-calibrated congestion threshold, the system controller modulates the operation of the wireless communication system by adjusting one or more system WiFi parameters based on the congestion assessment. For any of the disclosed wireless communication systems, vehicles, and methods, the congestion score can be calculated as a combination of wireless medium congestion indicator features. For example, the congestion score can be calculated as: where Steine ​​is the congestion score for a vehicle v within a traffic type t, fiein is the i-th congestion indicator traffic factor value, v is the reporting vehicle, t, and wider is the respective weighting factor assigned to the corresponding i-th congestion indicator traffic factor. After adjusting the WiFi / WLAN parameters of the system, closed-loop feedback control can be provided by adjusting the network traffic factors (e.g.,Wireless medium congestion indicator features are monitored to generate a new set of raw network traffic data, and this new raw network traffic data is transformed based on the processing rule set to generate a new set of processed traffic data. For example, instantaneous / average latency or throughput values ​​can be collected from all stations in the WLAN network. These new values ​​provide amplification that can be used to recalculate a new congestion score. In one example, a new congestion score can then be calculated as a function of the new traffic factor values ​​in the new processed traffic data, each weighted using its respective weighting factor.In response to the new congestion rating exceeding the previous congestion rating, indicating an increase in network congestion, the control panel may reset the system's WiFi parameters to a set of system-calibrated default WiFi settings. For one of the disclosed systems, vehicles, and methods, the control system can retrieve a set of system-calibrated maximum and minimum (max / min) allowable WiFi parameter values; in this case, the adjustment of the system's WiFi parameters can be limited by the system's maximum / min allowable WiFi parameter values. The congestion threshold can be delimited into a hierarchy of thresholds, including low, moderate, and high congestion thresholds. Upon determining that the congestion assessment exceeds the moderate congestion threshold, the control system can, in response, adjust the system's WiFi parameters to a set of moderate congestion parameter values ​​that prioritize selected data transmission types to / from the wireless communication system.In response to a determination that the overload assessment exceeds the high overload threshold, the system control may adjust the system's WiFi parameters to a set of high overload parameter values ​​that significantly limit preselected data transmission types to / from the wireless communication system. For one of the disclosed systems, vehicles, and methods, adjusting the WiFi parameters of the system may include: increasing respective parameter values ​​for a set of EDCA parameters (e.g., aCwmin, aCwmax, AIFSN, TXOP, etc.) and thereby prioritizing selected types of data packets received by the wireless communication system; increasing a PD threshold (e.g., RX-SOP (Receiver Start of Packet Detection Threshold)) and thereby limiting a signal level at which the wireless communication system demodulates and decodes data packets; and / or increasing an ED threshold (e.g., 802.11 transmission ED threshold, measured in decibel milliwatts (dBm)) and thereby limiting a noise level at which the wireless communication system detects an RF transmission.As another option, transforming raw network traffic data can include aggregating, averaging, smoothing raw data and / or extracting a min, max or mean deviation value from raw data within the raw network traffic dataset within a specified time window. For one of the disclosed vehicles, systems, and methods, the control unit can actively determine whether the overload rating is below the overload threshold (e.g., "low overload rating"). If so, the control unit can respond by modulating the operation of the wireless communication system by setting the system's WiFi parameters to a set of system-calibrated standard WiFi settings. In this case, the control unit can also lower a PD threshold and / or an ED threshold of the wireless communication system in response to the overload rating not exceeding the moderate or high overload thresholds.As another option, monitoring network traffic factors can involve the control system communicating with a WiFi driver and / or a WiFi application programming interface (API) via a WiFi network module and / or a software-defined networking (SDN) device to measure network traffic variables in real time and generate raw network traffic data. Each of the wireless system control protocols described herein is intended to be used equally well in vehicle and non-vehicle applications. The above description does not represent every embodiment or aspect of the present description. Rather, the foregoing description merely provides a summary of some of the novel concepts and features set forth herein. The above features and advantages, as well as other features and associated benefits of this description, will be readily apparent from the following detailed description of the illustrated examples and representative ways of carrying out the description, in conjunction with the accompanying drawings and claims. Furthermore, this description expressly includes all combinations and subcombinations of the elements and features described above and below. Brief description of the drawings Fig. 1 is a partially schematic side view of a representative motor vehicle with a network of in-vehicle controls, sensors, and communication devices for providing dynamic adjustment of wireless communication system parameters to manage network congestion according to aspects of the present description. Fig. 2 is a flowchart illustrating a representative system control protocol for evaluating network congestion and dynamically adjusting EDCA / ED / PD parameters of a WiFi-enabled wireless communication system, which may correspond to non-volatile, memory-stored instructions executable by a resident or remote microprocessor, control module, programmable logic circuit, central controller, or other integrated circuit device (IC), or a network of controllers / processors / modules / devices / etc. according to aspects of the disclosed concepts.Figure 3 is a flowchart illustrating a representative system control subroutine for dynamically adjusting EDCA parameters within the control protocol of Figure 2. The present description is accessible for various modifications and alternative forms, and some representative embodiments of the description are shown by way of example in the drawings and are described in detail herein. It is understood, however, that the novel aspects of this description are not limited to the specific forms illustrated in the drawings listed above. Rather, this description covers all modifications, equivalents, combinations, permutations, groupings, and alternatives that fall within the scope of protection of this description, as included, for example, by the attached claims. Detailed description This description is receptive to embodiments in many different forms. Representative embodiments of the description are shown in the drawings and are described in detail herein, it being understood that these embodiments are provided as an illustration of the disclosed principles and not as limitations of the broad aspects of the description. To this extent, elements and limitations described, for example, in the Abstract, Introduction, Description, Brief Description of the Drawings, and Detailed Description sections, but not explicitly set forth in the claims, should not be incorporated into the claims individually or collectively by conclusion, inference, or otherwise. Furthermore, the use of terms such as "first," "second," "third," etc., is recommended.The terms are not used per se in the description or the claims to establish a serial or numerical limitation; unless expressly stated otherwise, these designations may be used to facilitate reference to similar features in the description and the drawings and to distinguish between similar elements in the claims. For the purposes of this description, unless expressly excluded: the singular includes the plural and vice versa (e.g., indefinite articles "a" and "an" should generally be interpreted as meaning "one or more"); the words "and" and "or" are to be understood as both subjunctive and disjunctive; the words "any" and "all" are to mean both "any" and "all"; and the words "including," "containing," "comprising," "exhibiting," and the like are each to mean "including without limitation." Furthermore, words of approximation, such as "about," "almost," "essentially," "generally," "approximately," and the like, may each be used herein to denote, for example, "at, near, or close to," or "within 0-5% of," or "within acceptable manufacturing tolerances," or any logical combination thereof.Finally, directional adjectives and adverbs, such as front, back, inside, outside, starboard, port, vertical, horizontal, upwards, downwards, forwards, backwards, left, right, etc., may refer to a motor vehicle, such as the forward direction of travel of a motor vehicle when the vehicle is operationally oriented on a horizontal driving surface. With reference to the drawings, in which the same reference numerals in the different views refer to the same features, Fig. 1 shows a representative motor vehicle, generally designated 10, which is presented herein for discussion as an electric-powered sedan. The depicted automobile 10—hereafter also referred to simply as the “motor vehicle” or “vehicle”—is merely an exemplary application with which aspects of this description can be put into practice. Similarly, the use of the present concepts for dynamically adapting the operation of a WiFi-enabled telematics central unit should also be considered a non-restrictive implementation of disclosed features.It is understood that novel aspects of this description can be used to operate other WiFi-enabled devices, can be applied to any logically relevant type of motor vehicle, and can be implemented in both vehicle and non-vehicle applications. Furthermore, only selected components of the motor vehicle and the wireless communication system are shown and described in detail herein. Nevertheless, the vehicles and systems discussed below may possess numerous additional and alternative features and other available peripheral hardware for performing the various procedures and functions described. The representative vehicle 10 of Fig. 1 is originally equipped with a vehicle telecommunications and information technology (“telematics”) unit 14, which communicates wirelessly, e.g., via a cellular network, satellite service, wireless modem, hotspot, etc., with a remotely located cloud computing host service 24 (e.g., OnStar®). Some of the other vehicle hardware components 16, shown generally in Fig. 1, include, by way of non-limiting examples, an electronic video display device 18, a microphone 28, one or more audio speakers 30, and various user input controls 32 (e.g., buttons, knobs, switches, touchpads, touchscreens, etc.). These hardware components 16 function, in part, as a human-machine interface (HMI), enabling a user to communicate with the telematics unit 14 and other components located in and remote from the vehicle 10.The microphone 28, for example, provides occupants with a means of entering verbal commands; the vehicle 10 may be equipped with an embedded speech processing unit that uses audio filtering, processing, and analysis modules. Conversely, the loudspeaker 30 provides an audible output to a vehicle occupant and may either be a standalone loudspeaker assigned to the telematics unit 14 or be part of an in-cabin audio system 22. The audio system 22 is connected to a network interface 34 and an audio bus 20 to receive analog information via one or more loudspeaker components and reproduce it as sound. A network interface 34 is communicatively coupled to the telematics unit 14. Suitable examples of such interfaces include twisted-pair / fiber optic Ethernet switches, parallel / serial communication buses, local area network (LAN) interfaces, controller area network (CAN) interfaces, and the like. The network interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems both on board and outside the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as modulating the powertrain output, activating friction and regenerative braking systems, controlling the vehicle steering, and other automated functions.For example, the telematics unit can exchange signals with a powertrain control module (PCM) 52, an ADAS module 54 (Advanced Driver Assistance System), a motor control module (MCM) 56, a body control module (BCM) 58, a sensor system interface module (SSIM) 60 and various other vehicle ECUs, such as a transmission control module (TCM), a sensing and diagnostics module (SDM), a brake system control module (BSCM), etc. With further reference to Fig. 1, the telematics unit 14 is an onboard computing device that provides a mix of services, both individually and through its communication with other networked devices. This telematics unit 14 can generally consist of one or more processors 40, each of which can be implemented as a discrete microprocessor, an application-specific integrated circuit (ASIC), or a dedicated control module.The vehicle 10 can offer centralized vehicle control via a central processing unit (CPU) 36, which is operationally coupled with a real-time clock (RTC) 42, and one or more electronic storage devices 38, each of which can take the form of a CD-ROM, a magnetic disk, an IC device, a solid-state drive (SSD), a hard disk drive (HDD), a phase-change memory, a flash memory, a semiconductor memory (e.g., various types of RAM or ROM), etc. Long-range communication (LRC) capabilities with remote, external devices can be provided by one, more, or all of a cellular chipset / component, a navigation and location chipset / component (e.g., a GPS (global positioning system) transceiver), a wireless modem, or a mobile hotspot, all of which are shown together at 44 in Fig. 1. Short-range wireless connectivity can be provided by a short-range communication (SRC) device 46 (e.g., a Bluetooth® unit or a near-field communications (NFC) transceiver), a dedicated short-range communications (DSRC) component 48, and / or a dual antenna 50.The communication devices described above can provide data exchange as part of a periodic broadcast in a vehicle-to-vehicle (V2V) communication system or a vehicle-to-everything (V2X) communication system, e.g., vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), vehicle-to-device (V2D), vehicle-to-cloud (V2C), etc. The vehicle CPU 36 receives sensor data from one or more sensing devices, which in non-limiting examples may employ photodetection, radar, laser, ultrasonic, optical, infrared, or other suitable technologies, including short-range communication technologies (e.g., DSRC) or ultra-wideband (UWB) radio technologies, for performing controller-automated (AV / ADAS) driving operation or vehicle navigation services. According to the illustrated example, the automobile 10 may be equipped with one or more digital cameras 62, one or more range sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any necessary filtering, classification, fusion, and analysis hardware and software for processing raw sensor data.The type, placement, number, and interoperability of the distributed arrangement of in-vehicle sensors can be individually or collectively adapted to a given vehicle platform to achieve a desired level of automated vehicle operation. To propel the automobile 10, a vehicle powertrain is operated to generate traction torque and deliver it to one or more of the vehicle's drive wheels 26. The powertrain is represented in Fig. 1 by an electric traction motor (M) 78, which is operationally connected to a rechargeable energy storage system (RESS), which may be in the form of a chassis-mounted traction battery pack 70. The traction battery pack 70 generally consists of one or more battery modules 72, each containing a group of battery cells 74, such as lithium-class, zinc-class, nickel-class, or organosilicon-class cells of pouch, prismatic, or cylindrical type. One or more drive units, such as traction motor / generator units (M units) 78, draw electrical power from the battery pack 70 and optionally supply it with electrical power.A power inverter module (PIM) 80 electrically connects the battery pack 70 to the motor(s) 78 and modulates the transmission of electrical current between them. The battery pack 70 can include an integrated electronics package, such as a wireless cell monitoring unit (CMU) 76, which enables in-module management, cell detection, etc. The following discusses intelligent wireless communication systems with control logic for actively managing network congestion using a framework that dynamically evaluates and adjusts EDCA parameters and ED / PD thresholds based on a predictive congestion score calculated as a function of measurable network congestion characteristics (also referred to herein as "traffic factors"). Disclosed systems and logic can help ensure fairness and compatibility with legacy devices for device access and functionality while offering flexible system coordination. A system congestion measurement subcomponent of this framework derives a congestion score that predicts real-time network traffic congestion. A congestion score can be calculated based on a weighted combination of congestion factors. The factor weights can be fixed, predetermined values ​​(e.g.,Weighting values ​​can be learned through a supervised and trained machine learning model) or variable values ​​(e.g., systematically adjusted with respect to system response). For example, weighting values ​​can depend on the type of network traffic: (a) for real-time voice users, factors such as latency, jitter, and packet loss may be weighted more heavily because there is no buffering in voice traffic; and (b) for video streaming users, factors such as jitter and latency may be weighted less heavily because there is buffering in video traffic, whereas throughput may be weighted more heavily. Jitter, latency, and similar factors may be weighted less heavily because there is usually some buffering when streaming videos; for example, when a user streams a video from the internet, some of it may be preloaded into temporary memory.By comparison, an occupant using in-vehicle voice services to talk to another person via a phone call is a real-time use case; as such, latency and jitter may be considered more important for voice users. A host vehicle can calculate a congestion score independently or in conjunction with multiple crowdsourcing vehicles. In the latter option, each vehicle can independently calculate a congestion score based on individual factor measurements and then report its score to a shared access point; the AP aggregates the reported scores to calculate a collective congestion score. Alternatively, a host vehicle can perform V2V exchange with neighboring vehicles to share congestion scores and thereby gain a broader view of network congestion.Non-restrictive examples of network congestion factors include channel utilization, packet loss rate, average queue length, retransmission rate, signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio (SINR), throughput, latency, jitter, bandwidth utilization, and a clear channel assessment (CCA) failure / collision rate. A practical network congestion factor that can be accessed and exposed in a Wi-Fi chipset might be a limited time interval of an 802.11 MAC layer transmit opportunity (TXOP). For practical implementation, network traffic factors retrieved from only one layer may be more easily tracked (e.g., MAC layer characteristics only); the remainder can be considered optional based on latency and computational complexity requirements / constraints. Coexistence-related traffic factors that can be monitored for congestion assessment exhibit a sampled, detected energy level in the WiFi channels or bands. A host vehicle can monitor such characteristics through several tools: tools or libraries can be integrated into a host vehicle's WiFi system to monitor network performance; for example, an SDN-like controller could monitor an overall vehicle health; a vehicle WiFi module can monitor these metrics through native WiFi drivers and APIs that provide access to these measurements; a host vehicle can passively monitor these factors by listening for management frameworks, such as beacon and probe requests / responses from other access points and stations (STAs) in its vicinity.A traffic information map (TIM) is an information element in beacon frames that informs STAs about the status of buffered data at the AP; a packet-sniffing device for capturing and analyzing data packet traffic at the MAC layer using tools or libraries (e.g., the Wireshark open-source analyzer); vehicles can send probe requests to APs (e.g., round-trip time (RTT) can be used to estimate latency); and / or 802.11k with radio resource management (RRM) (e.g., the 802.11k standard) can provide information to discover the best available access point. These methods for retrieving network congestion characteristics / factors are not limited to congestion-related features but can be implemented for other characteristics, including SINR, throughput, latency, queue length, packet loss rate, etc. Access points can also collect and share information about their radio environment, such as channel usage, signal strength, and interference levels. As another option, an AP can collect Simple Network Management Protocol (SNMP) or a resident Wi-Fi interface directly from the MAC layer (e.g., the vehicle can monitor queue length). This section also presents system control methods for dynamically adjusting the EDCA operating parameters of the wireless communication system and, optionally, ED / PD thresholds to address changes in network congestion. For example, using multimodal congestion assessment, the method adaptively adjusts system parameters based on a set of predefined, system-calibrated rules. These predefined rules can be derived from empirical analysis and testing, statistical / machine-learning models (e.g., decision trees), network simulation and modeling, industry standards and best practices, or any combination thereof. A continuous feedback loop can be implemented after each system parameter change to provide error correction and continuous improvement of the control algorithm.For the feedback loop, a new set of traffic factor values ​​is fed back into the congestion assessment and evaluation algorithm, and if the congestion score decreases, the adjusted EDCA parameter values ​​are retained. Conversely, if the congestion score increases and thus the adjusted parameters worsen the congestion, the system parameters can be switched to a set of standard EDCA parameters. The disclosed intelligent wireless communication system can take fairness into account when adjusting system parameters in order to mitigate any negative impact a parameter change might have on other user devices. This can be achieved through several mechanisms: a feedback loop can systematically evaluate the impact of parameter changes and revert to default parameter values ​​if the changes in question cause fairness issues; Limits can be set on the max / min EDCA parameter values ​​to ensure that all parameter changes remain within predefined limits; AP involvement in the solution can ensure a high degree of coordination; In the event of extreme congestion, each AP can randomly select a percentage of its clients and move them to a best-effort or background location, for example, to give those clients an opportunity to connect, and then select another set of clients, and so on. This percentage can be based on the amount of congestion detected around the AP; and / or existing load balancing techniques can be combined more aggressively when dynamic EDCA is enabled (e.g., in a multi-AP scenario, ensuring clients automatically connect to the least congested AP). The system can accommodate compatibility with DCF-only “older” devices by adjusting only selected EDCA system parameters (e.g., changing CWmax and not CWmin) when older DCF is available, in order to avoid an unwanted reversal of priorities. In addition to dynamically adjusting EDCA parameters, disclosed wireless communication systems and control protocols can also adjust ED and PD thresholds to compensate for changes in traffic congestion. Current 802.11 standards implement fixed values ​​for ED thresholds (e.g., set to 20 dB above the signal detection threshold). However, this fixed threshold can be suboptimal in high-congestion scenarios. Instead of using a fixed ED threshold, disclosed systems and methods can use a calculated congestion assessment to dynamically adjust the ED threshold to mitigate network traffic congestion. For example, ED thresholds can be increased in high-congestion scenarios to reduce the likelihood of interference, detection of irrelevant signals, false detections, and to prevent further congestion.Conventional control algorithms also set PD thresholds to a predefined radio standard value. Like fixed ED thresholds, fixed PD thresholds can be suboptimal for congestion scenarios. Disclosed systems and methods can use the calculated congestion assessment to dynamically adjust the PD threshold to mitigate network traffic congestion. For example, PD thresholds can be increased in high-congestion scenarios to reduce the likelihood of interference, detection of irrelevant signals, false detections, and to prevent further congestion. Similar fairness mechanisms to those described above for adjusted EDCA parameters can be used for adjusted ED and PD thresholds. Depending on a given operational scenario, EDCA / PD / ED adjustments can be applied at a global level (e.g., centrally coordinated AP-centric), at a local level (e.g., device- or STA-centric), or according to a hybrid local-global approach. For AP-centric approaches, an AP can gather traffic information by continuously monitoring network conditions and receiving feedback from STAs regarding metrics such as SINR, PER, etc. Based on the collected data, the AP can calculate a set of "optimal" EDCA parameters for a given operational scenario. The AP can then broadcast current EDCA parameters, calculated "optimal" parameters, and / or, using existing signaling such as action or beacon frames, indicate when a change is required. Individual STAs can then update their system parameters according to the broadcast instructions from the AP. In STA-centric approaches, an STA can independently evaluate and adjust its own EDCA parameters based on local measurements and network conditions. Each STA can, for example, monitor local conditions such as PER, SINR, etc., and then adjust parameters locally. The AP can still provide coordination if needed, such as providing general guidelines or thresholds through beacon or action frames. If an STA requires assistance from an AP to make network-wide decisions, the STA can optionally transmit feedback data to its AP through action frames regarding its conditions and adjustments. The AP can then respond with an action log and parameter updates. In hybrid approaches, the AP can provide a set of general network-wide parameter guidelines and thresholds (e.g., maximum or minimum allowable values ​​for CWmin, CWmax, and other parameters). Each STA can make fine-grained adjustments within these limits based on its own local conditions. This can provide both the benefits of coordination and the flexibility of local customization. With reference to the flowchart of Fig. 2, an improved method or control protocol for evaluating network congestion and dynamically adjusting system operating parameters of a wireless communication system, such as the WiFi-enabled vehicle telematics unit 14 of Fig. 1, is generally described at 200 according to aspects of the present description. In Fig. 3, a representative system control subroutine 215 for dynamically adjusting EDCA parameters is presented as part of the control protocol 200 of Fig. 2. Some or all of the operations illustrated in Fig. 2 and Fig. 3 and described in detail below may be representative of an algorithm corresponding to non-volatile, processor-executable instructions that may be stored, for example, in main, auxiliary, or remote memory (e.g., resident vehicle memory 38 and / or remote cloud host service database 24 of Fig. 1).These instructions can be executed, for example, by a resident or remote microprocessor, a central controller, a dedicated control module, a programmable logic circuit, or any other module or device or network of processors / controllers / modules / devices (e.g., vehicle CPU 36 and / or cloud host service server-class computer terminal 24 of Fig. 1) to perform any or all of the functions described above and below that are associated with the disclosed concepts. It is understood that the order of execution of the illustrated operation blocks can be changed, additional operation blocks can be added, and some of the operations described herein can be modified, combined, or eliminated. The procedure 200 can begin at the start terminal block 201 of Fig. 2 with memory-stored, computer-readable instructions for initializing a WiFi EDCA parameter adjustment control protocol for a wireless communication system. This routine can be initialized in real time, near real time, continuously, systematically, sporadically, and / or at predefined time intervals, for example, every 10 or 100 milliseconds during the operation of the vehicle 10. As a further option, the terminal block 201 can initialize in response to a user command request (e.g., via telematics input controls 28, 32), a request from a resident vehicle control unit (e.g., from the CPU 36), or a broadcast request signal received from a centralized BO vehicle service system (e.g., from the cloud host service 24).As a non-restrictive example, the method 200 can be automatically initialized during a key-on event, in which a driver, owner, occupant, or other authorized operator of the vehicle 10 (collectively, "user") turns on the vehicle powertrain or enters the vehicle accessory mode. Upon completion of some or all of the control operations shown in Fig. 2, the method 200 can transition to the terminal block 213 and temporarily terminate, or optionally loop back to the terminal block 201 and run in a continuous loop. The terminal block 213 can be automatically triggered in response to a key-off event, in which a user turns off the vehicle powertrain, or in response to a user turning off the vehicle's accessory mode. From the terminal block 201, the procedure 200 can transition to the traffic factor data input block 203 to aggregate traffic congestion feature information, which is used by the control protocol to derive a congestion score that predicts real-time network traffic congestion. Using the vehicle telematics unit 14 of Fig. 1 as a non-limiting example, the CPU 36 can monitor and measure a variety of different network traffic factors that affect network congestion of the vehicle's wireless LRC system 44 to generate raw network traffic data. Exemplary traffic congestion factors may include: channel utilization, packet loss rate, packet queue length, data retransmission rate, SNR / SINR, packet throughput, data latency ("ping"), data jitter, bandwidth utilization, CCA failure / collision rate, TXOP (e.g.,(accessible and exposed in a WiFi chipset), a sampled detected energy level in channels / bands, etc. As mentioned above in the discussion of available traffic monitoring tools, network traffic factors can be monitored by the system controller through communication via a WiFi network module and / or an SDN device with a WiFi driver and / or WiFi API to measure one or more of the network traffic variables in real time. After aggregating traffic feature information and simultaneously generating raw network traffic data, the procedure 200 executes a data preprocessing subroutine 205 to perform real-time data preprocessing and feature extraction. The vehicle CPU 36 of Fig. 1 can employ a supervised and trained machine learning model, such as a decision tree-based algorithm or a k-nearest neighbor (kNN) model, to transform raw network traffic data based on a set of predefined processing rules to generate processed traffic data. Transforming raw network traffic data to extract traffic factor values ​​can—within a specified time window—include aggregating, averaging, and smoothing the raw data, which can then be analyzed to identify maximum, minimum, and / or mean deviation values ​​in the dataset.The traffic congestion factors described in the previous paragraph can be categorized as "raw features." In an AI model training pipeline, these raw features can be transformed by first preprocessing the data to make the information more insightful; preprocessed data can then be fed into a machine learning model or used to develop a non-machine learning model. Example preprocessed features might include: a packet loss rate over a specific time window, averaged or smoothed (rather than using instantaneous values); latency averaged over multiple packets to obtain an average / min / max latency; and jitter processed using mean deviation smoothing or moving averages.Other traffic congestion factors can be aggregated and filtered to remove outliers, discretize continuous data streams, and fuse data from discrete sources. Processed network traffic data can be output to subroutine 207 to calculate a predictive congestion score and to subroutine 215 to facilitate dynamic adjustment of the system's operating parameters. The procedure 200 can then execute an OVERLOAD PREDICTION subroutine 207, in which a pretrained ML model uses the various traffic factor values ​​contained in the processed traffic data to estimate a real-time level of network congestion. For example, the vehicle CPU 36 of Fig. 1 can compute a congestion rating as a function of several traffic factor values ​​within a processed traffic data set, each of which can be weighted using a respective weighting factor assigned to its corresponding traffic factor in the set of network traffic factors (e.g., a latency value Lvi weighted by a latency weighting factor wL assigned to a data latency within a memory-stored collection of traffic factors).For a vehicle application, the congestion score can be calculated as: where Steine ​​is the congestion score for a given (host) vehicle v within a traffic type t; fiein is the i-th traffic factor value of the traffic factor values ​​in the processed traffic dataset; and wider is the respective weighting factor assigned to the corresponding traffic factor of the i-th traffic factor value. As noted above, each weighting factor w can be a fixed, predetermined value or it can be a dynamically variable value. According to the latter, a weighting factor w can depend on the current type of traffic t experienced by the host vehicle v. It should be understood that the preceding mathematical formula is only an example of how a congestion score can be calculated. In the equation above, some indices can be considered implicit, such as the traffic factor fi, which may also have hidden indices v and t. For example, the first feature may be an average latency, and f1 is an average latency value based on the raw feature latency. This average latency value belongs to a vehicle v, and each vehicle v may also contain multiple devices and multiple traffic types t. Similarly, the weighting factor w may have an implicit index t. A supplementary summation can be calculated for f from j = 1 to T, where T is the traffic type, because a host vehicle v may experience more than one type of traffic t. After calculating the congestion score, the procedure 200 proceeds to the congestion score decision block 209 to determine whether the wireless communication system is experiencing elevated levels of network traffic congestion. As illustrated in the example shown in Fig. 1, the vehicle CPU 36 can determine if and when the calculated congestion score exceeds a predefined congestion threshold (Svt > SCT) calibrated to the vehicle's wireless LRC system 44.If the overload assessment does not exceed the overload threshold (Block 209 = NO), Procedure 200 can respond by executing the SYSTEM PARAMETER STANDARD process block 211 with memory-stored, processor-executable instructions for the vehicle CPU 36 to modulate the operation of the telematics central unit 14, which is mounted inside the passenger cabin 11, by setting the system's WiFi parameters to a set of system-calibrated standard WiFi settings. If the wireless communication system parameters are already set to factory default values, the vehicle CPU 36 cannot take any action other than verifying that the default values ​​are set correctly.On the other hand, process block 211 may: (1) adjust the currently set EDCA parameter values ​​of the system to their respective default parameter values; (2) lower the current PD threshold of the system from a moderate / high overload PD value to a default PD value; and / or (3) lower the current ED threshold of the system from a moderate / high overload ED value to a default ED value. At this point, process 200 may transition to terminal block 213 and temporarily terminate, or it may automatically loop back to data input block 203. After determining that the calculated congestion score exceeds the congestion threshold (Block 209 = YES), Procedure 200 can, in response, execute the SYSTEM PARAMETER ADJUSTMENT subroutine 215 and dynamically adjust the system's EDCA / ED / PD parameters. To help improve traffic congestion, packet prioritization over a given Wi-Fi channel can be dictated by the values ​​set for the system's EDCA parameters. In other words, a system's EDCA settings can delineate high-priority network traffic, which is more likely to be sent, from low-priority network traffic, which is less likely to be sent on the wireless channel. For example, a high-priority data packet might, on average, wait less time before being sent to / from a particular device compared to a low-priority data packet.This can be achieved by using a shorter contention window (CW) and a shorter arbitration inter-frame space (AIFS) for high-priority packets. The exact parameter values ​​set for CW / AIFS may depend on the physical WiFi layer used to transmit the data. EDCA can also provide "competition-free" access to a channel for a fixed period, known as a transmit opportunity. Similar functionality for replaying a high-priority channel could also be achieved by using upper-layer protocol components, such as transmission control protocol (TCP) variants that manipulate a backoff window of TCP protocols. When an overload score is received and shown to exceed an overload threshold, the overload measurement and assessment model predicts that sufficient network overload exists to activate a dynamic EDCA / ED / PD adjustment algorithm. Referring again to the use case example in Figure 1, the vehicle CPU 36 can respond to a determination that the calculated overload score exceeds the overload threshold by adjusting several system WiFi parameters based, at least partially, on the overload score. Before initializing any new system settings, the vehicle CPU 36 can first retrieve a set of system-calibrated max / min WiFi parameter values ​​(e.g., those output by subroutine 205); any adjustments to the system's WiFi parameters can be constrained by these system-calibrated max / min WiFi parameter values.Adaptive adjustment of system parameters to manage network congestion can also be governed by a predefined parameter adjustment rule set. These rules can be derived from empirical analysis and testing, statistical / machine learning models, industry standards and best practices, network simulation, emulation, and modeling, or any combination thereof. As further indicated by the arrow connecting subroutine 205 to subroutine 215 in Figure 2, some or all of the extracted feature values ​​output by subroutine 205 can be used to generate the parameter adjustment rules. However, it may be desirable for these rules to be predetermined, fixed constraints and thus not generated in real time. Congestion-based adjustment of WiFi or non-WiFi system operating parameters can involve increasing the respective parameter value for each of the system's EDCA parameters to prioritize the transmission of selected types of network data packets. Figure 3 presents a representative system control subroutine or procedure 215 for dynamically adjusting EDCA parameters. In this non-restrictive example, the congestion threshold is not a single value (as described above) but can instead be delimited into a hierarchy of thresholds: (1) a low congestion range (e.g., SLCT = 0.02 to 0.39), (2) a moderate congestion threshold (e.g., SMCT = 0.40), and (3) a high congestion threshold (e.g., SHCT = 0.70).For low congestion in process block 219, procedure 200 can determine that the calculated congestion score is within the low congestion range and therefore predict that the wireless communication system is currently experiencing low traffic congestion (Svt < 0.4). In response, procedure 200 can execute EDCA process block 221 without making any changes to the EDCA parameters. Procedure 200 can then transition from process block 221 to subroutine 217 or terminal block 213. It should be noted that the figures shown in Fig. 3 are provided for illustrative purposes only and are therefore not restrictive. For process block 223 with MODERATE OVERLOAD from Fig. 3, procedure 200 can determine that the calculated overload score is greater than the moderate overload threshold (0.40 < Svt < 0.70). In this case, procedure 200 can respond by executing the KEY SERVICES process block 225 and adjusting the system's EDCA parameters to a set of moderate overload parameter values ​​that prioritize selected data transmission types, "Priority Services," to / from the wireless communication system. To prioritize Key Services, the system's EDCA parameters can be adjusted as follows: (i) minimum contest window integer (aCwmin[AC_BE]): 15→31; (ii) maximum contest window integer (aCwmax[AC_BE]): 1023→2047; (iii) Arbitration Interframe Space Number AC-BE Parameter Record (AIFSN[AC_BE]): 5→7; (iv) Arbitration Interframe Space Number AC-BK Parameter Record (AIFSN[AC_BK]): 7→15; and (v) TXOP[AC_VO]: 1.5→3.The procedure 200 can then transition from process block 225 to subroutine 217. For process block 227 with HIGH OVERLOAD from Fig. 3, procedure 200 can determine that the calculated overload score is greater than the high overload threshold (Svt > 0.7). In this case, procedure 200 can respond by executing process block 229 for ESSENTIAL SERVICES and adjusting the system's EDCA parameters to a set of high overload parameter values ​​that significantly limit preselected "non-essential" data transmission types to / from the wireless communication system. To prioritize essential data transmissions, the system's EDCA parameters can be adjusted as follows: (i) aCwmin[AC_BE]: 15→63; (ii) aCwmax[AC_BE]: 1023→4095; (iii) AIFSN[AC_BE]: 5→9; (iv) AIFSN[AC_BK]: 7→31; and (v) TXOP[AC_VO]: 1,5→5. The procedure 200 can then transition from process block 229 to subroutine 217. Simultaneously with changes to the EDCA parameter settings of the system, Procedure 200 can add an additional layer of system improvement by dynamically adjusting the system's energy detection and packet detection thresholds, thereby modulating when and how the system's receiver can decode received data. The ED threshold can be implemented when non-WiFi signals are present, and the PD detection threshold can be implemented when WiFi signals are present. Both of these thresholds can be a core component of a clear channel evaluation, which can be used by a competition-based channel access mechanism employed by EDCA to prioritize different types of traffic. During low network congestion scenarios, Procedure 200 can lower the ED and PD thresholds to reduce the signal energy level at which the system detects a signal, respectively.to lower the measured energy at which the system determines that a complete data packet has been received. Conversely, during periods of high network congestion, procedure 200 can increase the ED and PD thresholds to limit which signals are detected and which packets are received. In a congested network environment, for example, subroutine 215 can increase the PD threshold, thereby limiting the signal level at which the wireless communication system demodulates and decodes data packets. Simultaneously, the system can increase the ED threshold, thereby limiting the noise level at which the system detects RF transmission. In a congested environment, there is a higher probability that weak signals, such as those from nearby devices or sources of interference, can affect communication.By increasing the ED and PD thresholds, the system would ignore these weaker, irrelevant signals, thus reducing device interference and noise outside the intended communication range. For context, an 802.11-compliant wireless system can decode an incoming 802.11 preamble transmission with a received signal approximately 4 decibels (dB) above the noise floor. The system's energy detection threshold can be adjusted to allow it to detect other types of RF transmissions during a clear channel assessment (CCA). For example, if the noise floor of channel 36 were -95 dBm, the SD threshold for detecting 802.11 transmissions could be set to approximately -91 dBm, and the ED threshold for detecting other / non-WiFi RF transmissions could be set to approximately -71 dBm. In this example, the ED threshold can be lowered during a low overload / coexistence rating and can be increased during a high overload / coexistence rating to filter out noise and reduce false positives.Comparatively, a receiver's RX-SOP (Receiver Start of Packet Detection Threshold) determines the Wi-Fi signal level in dBm at which an access point (AP) radio will demodulate and decode a packet. Increasing the system's RX-SOP limiting the AP radio to decoding packets with a higher RSSI value. If the congestion assessment indicates low congestion, the PD threshold can be lowered to accept more packets; conversely, in unstable, congested conditions, the PD threshold can be raised to reduce unnecessary processing. After adjusting the system's WiFi operating parameters at subroutine 215, procedure 200 of Fig. 2 can implement a continuous feedback loop (represented by the arrow connecting block 217 to block 213) to systematically evaluate the effect of the parameter changes and, if the latest changes cause congestion or fairness issues, revert to default parameters. To initiate the feedback loop, procedure 200 can execute data input block 217 for NEW FEATURE VALUES and retrieve new traffic congestion feature information using the adjusted parameters to derive a new congestion assessment that predicts any resulting changes in traffic congestion. For example, in response to the adjustment of the system WiFi parameters, the vehicle CPU 36 of Fig.1. Monitor and measure the network traffic factors to generate a new set of raw network traffic data, for example, in a manner similar to that described above with respect to data input block 203. After generating new raw network traffic data, the vehicle CPU 36 can again employ the trained SML model to process the new raw network traffic data using the processing rule set to generate a new set of processed traffic data and extract relevant traffic factor values ​​from it, for example, at data input block 205. Procedure 200 can then re-execute the OVERLOAD PREDICT subroutine 207 and calculate a new congestion score as a function of the new traffic factor values ​​extracted from the new set of processed traffic data, each weighted by its respective weighting factor. Procedure 200 can then compare the new congestion score with the previous congestion score; if the new congestion score exceeds the previous congestion score, i.e., indicates that network traffic congestion has increased with the adjusted WiFi parameters, Procedure 200 can, in response, reset the system's WiFi parameters to the system-calibrated default WiFi settings. Conversely, if the new congestion score is lower than the previous one, i.e.,If it indicates that network traffic congestion has decreased with the adjusted WiFi parameters, the procedure 200 can either retain the adjusted parameter values ​​or make additional adjustments to mitigate the traffic congestion. Additional mechanisms can be implemented to ensure compatibility with legacy devices; for example, if a legacy device is detected, the system can, in response, modify only a selected subset of parameters without altering other system parameters that could cause traffic priority reversals (e.g., modifying only the EDCA CWmax parameter to ensure legacy device compatibility). Orchestration of the dynamic adaptation systems and procedures described above can be performed using an access point (AP)-centric decision-making protocol, a station / device (STA)-centric decision-making protocol, or a hybrid AP / STA decision-making protocol. For AP-centric decision-making, an AP can gather network traffic information by continuously monitoring network conditions and receiving feedback from individual STAs regarding network metrics such as SINR, packet error rate (PER), etc. Using the gathered data, the AP can evaluate current operating parameters and, if necessary, calculate optimal operating parameters with respect to estimated network congestion.The AP can then broadcast a notification to maintain current operating parameters or a warning with a set of "optimal" system operating parameters and instructions that a change is required, using existing signaling, such as action or beacon frames. The STAs can then update their individual parameter values ​​according to the AP's instructions. For STA-centric decision-making, each STA can independently determine its own EDCA parameters based on local traffic factor measurements and network conditions, such as PER, SINR, etc. In this case, each STA can adjust its respective parameter settings locally. If necessary, the AP can provide coordination for the STA, including general guidelines or thresholds through beacon or action frames. The STAs can also send operating condition data and optional feedback to the AP through action frames and can request instructions if the STA needs assistance from the AP to make network-wide decisions. The AP can then respond with an acknowledgment and recommended parameter updates. For the hybrid AP / STA approach, the AP can provide general network-wide parameter guidelines or thresholds (e.g., maximum or minimum allowable values ​​for CWmin, CWmax, and other parameters).Each STA can use this information to make fine-grained adjustments within these limits based on its own local conditions. This can provide both coordination and flexibility in local adaptation. Aspects of this description can, in some embodiments, be implemented by a computer-executable program of instructions, such as program modules, commonly referred to as software applications or application programs, which are executed by any controller or the control variations described herein. In non-limiting examples, software may include routines, programs, objects, components, and data structures that perform specific tasks or implement specific types of data. The software may provide an interface to enable a computer to respond according to an input source. The software may also interact with other code segments to initiate a variety of tasks in response to data received in conjunction with the source of the received data.The software can be stored on any of a variety of storage media, such as a CD-ROM, a magnetic disk, and semiconductor memory (e.g., various types of RAM or ROM). Furthermore, aspects of this description can be practiced with a wide variety of computer system and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframes, and the like. Additionally, aspects of this description can be practiced in distributed computing environments where tasks are performed by resident and remote processing devices connected by a communication network. In a distributed computing environment, program modules can reside in both local and remote computer storage media, including storage devices. Therefore, aspects of this description can be implemented in conjunction with various hardware, software, or a combination thereof in a computer system or other processing system. Any of the methods described herein may include machine-readable instructions for execution by: (a) a processor, (b) a controller, and / or (c) any other suitable processing device. Each algorithm, software, control logic, protocol, or method disclosed herein may be executed as software stored on a tangible medium, such as flash memory, a solid-state drive (SSD), a hard disk drive (HDD), a CD-ROM, a DVD (digital versatile disk), or other storage devices.The entire algorithm, control logic, protocol, or procedure, and / or parts thereof, may alternatively be executed by a device other than a controller and / or implemented in firmware or dedicated hardware in an available manner (e.g., implemented by an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field-programmable logic device (FPLD), discrete logic, etc.). While specific algorithms may be described with reference to flowcharts and / or workflow diagrams presented herein, many other methods may alternatively be used to implement the exemplary machine-readable instructions.

Claims

A method for operating a wireless communication system, comprising: monitoring, via a control panel, a variety of network traffic factors that affect network congestion of the wireless communication system to generate a raw network traffic record; transforming, via the control panel, the raw network traffic record based on a set of processing rules to generate a processed traffic record; calculating, using a trained machine learning (ML) model, a congestion score as a function of traffic factor values ​​within the processed traffic record, each weighted using a respective weighting factor assigned to a corresponding traffic factor within the network traffic factors; and determining, via the control panel, whether the congestion score exceeds a congestion threshold.and modulating, via the system control in response to determining that the congestion rating exceeds the congestion threshold, the operation of the wireless communication system by adjusting a variety of system WiFi parameters based on the congestion rating; wherein the congestion threshold is a moderate congestion threshold, and wherein modulating the operation of the wireless communication system involves adjusting the system WiFi parameters to a set of moderate congestion parameter values ​​configured to prioritize selected data transmission types for the wireless communication system; and wherein the method further comprises: determining, via the system control, whether the congestion rating exceeds a high congestion threshold greater than the moderate congestion threshold;and modulating, via the system control in response to determining that the congestion assessment exceeds the high congestion threshold, the operation of the wireless communication system by adjusting the system WiFi parameters to a set of high congestion parameter values ​​that are configured to significantly limit preselected data transmission types for the wireless communication system. Method according to claim 1, wherein the overload assessment is calculated as Svt: S t = ∑ i = 1 I wifi where f i an i-th traffic factor value of the traffic factor values ​​is and w i the respective weighting factor that is assigned to the corresponding traffic factor of the i-th traffic factor value. The method of claim 1, further comprising: monitoring, via the system control after adjusting the system WiFi parameters, the network traffic factors to generate a new raw network traffic data set; transforming, via the system control, the new raw network traffic data set based on the processing rule set to generate a new processed traffic data set; and calculating a new congestion score as a function of new traffic factor values ​​within the new processed traffic data set, weighted using the respective weighting factors. The method of claim 3, further comprising: determining whether the new overload rating exceeds the overload rating; and setting, via the system control panel in response to the fact that the new overload rating exceeds the overload rating, the system WiFi parameters to a set of system-calibrated standard WiFi settings. The method according to claim 1, further comprising retrieving a set of system-calibrated maximum and minimum (max / min) WiFi parameter values, wherein the adjustment of the system WiFi parameters is limited by the set of system-calibrated max / min WiFi parameter values. The method of claim 1, wherein the adjustment of the system WiFi parameters comprises: increasing respective parameter values ​​for a set of EDCA parameters (EDCA) and thereby prioritizing selected types of data packets received by the wireless communication system; increasing a PD threshold (PD) and thereby limiting a signal level at which the wireless communication system demodulates and decodes data packets; and / or increasing an ED threshold (ED) and thereby limiting a noise level at which the wireless communication system detects an RF transmission (RF). The method of claim 1, further comprising: determining, via the system control, when the overload assessment does not exceed the overload threshold; and modulating, via the system control in response to determining that the overload assessment does not exceed the overload threshold, the operation of the wireless communication system by setting the system WiFi parameters to a set of system-calibrated standard WiFi settings. The method of claim 7, further comprising lowering a PD threshold (PD) and / or an ED threshold (ED) of the wireless communication system in response to determining that the overload assessment does not exceed the overload threshold.

Images