WO2026005362A1

WO2026005362A1 - Predicting network congestion in a wireless network system

Info

Publication number: WO2026005362A1
Application number: PCT/KR2025/008260
Authority: WO
Inventors: Irlanki SANDEEP; Madhan Raj Kanagarathinam; Jayendra Reddy KOVVURI
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2024-06-26
Filing date: 2025-06-16
Publication date: 2026-01-02
Anticipated expiration: 2026-12-26

Abstract

The disclosure provides a method for predicting network congestion by a user equipment (UE) in a wireless network system. The method comprises establishing a connection between the UE and an application server in the wireless network system. The UE detects a plurality of network parameters associated with the wireless network system and predicts network congestion based on the plurality of network parameters. The UE marks congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets in response to the predicted network congestion. Further, the UE transmits the congestion status data using accurate ECN congestion window reduced ECN echo (ACE) flags and a transport protocol header of the CE marked L4S data packets to the application server for dynamically adjusting a transmission rate at the application server.

Description

PREDICTING NETWORK CONGESTION IN A WIRELESS NETWORK SYSTEM

The disclosure relates to a field of wireless communication. More particularly, the disclosure relates to methods and systems for proactive low latency, low loss, and scalable throughput (L4S), a smart congestion detection solution.

With the increasing reliance on mobile devices for real-time interactive applications such as augmented reality (AR), virtual reality (VR), online gaming, and ultra-high-definition video streaming, the demand for low-latency and seamless user experiences is rising rapidly. These applications require not only high throughput but also minimal latency and packet loss to ensure a high-quality user experience. However, traditional network architectures often fall short in maintaining consistent quality of service (QoS) for latency-sensitive traffic, leading to reduced performance and user dissatisfaction.

Low-latency low-loss scalable throughput (L4S) is an emerging standard designed by the internet engineering task force (IETF) to address these requirements. L4S aims to enable ultra-low latency communication while maintaining high throughput and minimizing packet loss. Despite the potential benefits of L4S, several challenges remain in its implementation and operation.

In any client-server communication, overall performance is dictated by the slowest segment in the transmission path, known as the bottleneck. When the sender's data rate exceeds the capacity of this bottleneck, congestion occurs. This leads to higher latency and possible packet loss. In L4S, congestion detection primarily occurs at routers or access points in the wireless network. These network devices mark the congestion experienced (CE) bit when their buffers approach full capacity.

The main challenge with this reactive approach is that it may lead to queue build-ups and dropped packets due to the influx of data from multiple devices. This can result in increased queuing delays and retransmissions, which exacerbate latency issues. Additionally, packet loss and increased queuing delays can lead to suboptimal performance, particularly for latency-sensitive applications.

It is desired to address the above-mentioned disadvantages or other shortcomings, or at least provide a useful alternative.

The above information is presented as background information only to assist with an understanding of the disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as related art with regard to the disclosure.

Aspects of the disclosure are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide a method for predicting network congestion in a wireless network system.

Additional aspects will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be learned by practice of the presented embodiments.

According to an example embodiment of the disclosure, a method for predicting network congestion in a wireless network system is provided. The method comprises establishing by a UE a connection between the UE and an application server, detecting by the UE a plurality of network parameters associated with the wireless network system, predicting by the UE a network congestion based on the plurality of network parameters, marking by the UE congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets in response to the predicted network congestion, and transmitting by the UE a congestion status data using 3-bit accurate ECN congestion window reduced ECN echo (ACE) flags and AccECN option of transport protocol header of the CE marked L4S data packets to the application server.

According to an example embodiment of the disclosure, a method for predicting network congestion in a wireless network system is provided. The method comprises establishing by the application server a connection between the application server and a UE, receiving by the application server a congestion status data using a 3-bit accurate congestion window reduced ECN echo (ACE) flags of transport protocol header of CE marked L4S data packets from the UE, adjusting by the application server a transmission rate based on the congestion status data, and transmitting by the application server a plurality of data packets based on the adjusted transmission rate.

According to an example embodiment of the disclosure, a UE for predicting network congestion in a wireless network system is provided. The UE comprises memory storing instructions and at least one processor communicatively coupled to the memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the UE to establishe a connection between the UE and the application server, detect a plurality of network parameters associated with the wireless network system, predict a network congestion based on the plurality of network parameters, mark congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets based on the predicted network congestion, and transmit the CE marked L4S data packets to the application server.

According to an example embodiment of the disclosure, an application server for predicting network congestion in a wireless network system is provided. The application server comprises a memory storing instructions and at least one processor communicatively coupled to the memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the application server to establishe a connection between the application server and the UE in the wireless network system, receive CE marked L4S data packets from the UE, adjust a transmission rate based on the CE marked data packets, and transmit a plurality of data packets based on the adjusted transmission rate.

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the disclosure.

The above and other aspects, features, and advantages of certain embodiments of the disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

Fig. 1 illustrates latency-sensitive applications in a wireless network.

Fig. 2a and Fig. 2b illustrate a scenario of the flow of application data and the L4S feedback between user equipment/base station and an application server according to the related art.

Fig. 2c illustrates congestion between an L4S-enabled server and an L4S-enabled receiver according to the related art.

Fig. 3a illustrates user equipment connected to an application server through a wireless network system in accordance with an embodiment of the disclosure.

Fig. 3b illustrates congestion assessment using Machine Learning (ML) models according to various embodiments of the disclosure.

Fig. 4 is a flow diagram that illustrates the ML model flow according to various embodiments of the disclosure.

Fig. 5 is a flow diagram that illustrates the flow of congestion detection in a UE according to various embodiments of the disclosure.

Fig. 6 illustrates an architecture of the Proactive L4S architecture in accordance with an embodiment of the disclosure.

Fig. 7 illustrates a flow chart indicating operations of a method for predicting network congestion in a wireless network system performed at user equipment according to various embodiments of the disclosure.

Fig. 8 illustrates a flow chart indicating operations of a method for predicting network congestion in a wireless network system performed at an application server in accordance with an embodiment of the disclosure.

Fig. 9a illustrates streamlined traffic identification in the IP header according to various embodiments of the disclosure.

Fig. 9b illustrates a TCP header in accordance with an embodiment of the disclosure.

Fig. 10 illustrates a flow of data collection according to various embodiments of the disclosure.

Fig. 11a illustrates a correlation matrix for downlink (DL) in accordance with an embodiment of the disclosure.

Fig. 11b illustrates a correlation matrix for uplink (UL) according to various embodiments of the disclosure.

Fig. 11c illustrates a correlation matrix heatmap for other metrics in accordance with an embodiment of the disclosure.

Fig. 11d illustrates an another correlation matrix heatmap for additional metrics according to various embodiments of the disclosure.

Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures.

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

It should be understood at the outset that although illustrative implementations of the embodiments of the disclosure are illustrated below, the disclosure may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

The term "some" as used herein is defined as "none, or one, or more than one, or all." Accordingly, the terms "none," "one," "more than one," "more than one, but not all" or "all" would all fall under the definition of "some." The term "some embodiments" may refer to no embodiments, to one embodiment or to several embodiments or to all embodiments. Accordingly, the term "some embodiments" is defined as meaning "no embodiment, or one embodiment, or more than one embodiment, or all embodiments."

The terminology and structure employed herein is for describing, teaching, and illuminating some embodiments and their specific features and elements and does not limit, restrict, or reduce the spirit and scope of the claims or their equivalents.

More specifically, any terms used herein such as but not limited to "includes," "comprises," "has," "consists," and grammatical variants thereof do NOT specify an exact limitation or restriction and certainly do NOT exclude the possible addition of one or more features or elements, unless otherwise stated, and furthermore must NOT be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated with the limiting language "MUST comprise" or "NEEDS TO include."

Whether or not a certain feature or element was limited to being used only once, either way, it may still be referred to as "one or more features" or "one or more elements" or "at least one feature" or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element does NOT preclude there being none of that feature or element, unless otherwise specified by limiting language such as "there NEEDS to be one or more . . ." or "one or more element is REQUIRED."

Unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

As used herein, each of such phrases as "A or B," "at least one of A and B," "at least one of A or B," "A, B, or C," "at least one of A, B, and C," and "at least one of A, B, or C," may include any one of, or all possible combinations of the items enumerated together in a corresponding one of the phrases. It is to be understood that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with," "coupled to," "connected with," or "connected to" another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wired), wirelessly, or via a third element.

It should be appreciated that the blocks in each flowchart and combinations of the flowcharts may be performed by one or more computer programs which include computer-executable instructions. The entirety of the one or more computer programs may be stored in a single memory device or the one or more computer programs may be divided with different portions stored in different multiple memory devices.

Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and includes circuitry like an application processor (AP, e.g., a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphical processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a wireless-fidelity (Wi-Fi) chip, a Bluetooth^TM chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display drive integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.

Referring now to the drawings, and more particularly to Figs. 1-11 where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

Embodiments disclosed herein provide a method and system for predicting network congestion in a wireless network system. The disclosure specifically addresses the challenges related to congestion prediction and management in low latency, low loss, scalable throughput (L4S) networks. The disclosure proposes a proactive approach to network congestion management for low latency applications. By utilizing machine learning algorithms, ProActive L4S aims to detect and mitigate network congestion before it manifests at the access point (AP) or router level. This proactive approach reduces queuing delays and improves end-to-end latency, ensuring a smoother and more responsive user experience. By incorporating diverse metrics from various network layers, ProActive L4S provides a comprehensive understanding of network conditions, enabling accurate and efficient congestion control.

The ProActive L4S system leverages advanced machine learning models trained on historical network data to predict congestion events with high accuracy. These models analyze patterns and trends in network traffic, such as packet arrival rates, transmission delays, and error rates, to forecast potential congestion scenarios. By predicting congestion before it occurs, ProActive L4S may dynamically adjust network parameters, such as transmission rates and routing paths, to prevent congestion from impacting the network. This preemptive adjustment helps maintain optimal network performance and minimizes the risk of packet loss and latency spikes, which are critical for applications requiring real-time data transmission, such as online gaming, video conferencing, and autonomous vehicle communication.

Furthermore, the ProActive L4S system's ability to incorporate metrics from various network layers, including the physical, data link, network, and transport layers, provides a holistic view of the network's health. This multi-layered approach allows the system to detect subtle signs of congestion that may not be apparent when examining a single layer in isolation. For example, fluctuations in signal strength at the physical layer, combined with increased retransmission rates at the data link layer, may indicate potential congestion issues that need to be addressed. By integrating these diverse metrics, ProActive L4S may implement more precise and effective congestion management strategies, ultimately enhancing the quality of service (QoS) for end-users.

The use of machine learning techniques to proactively detect and mitigate congestion sets it apart from existing solutions. Further, the incorporation of diverse metrics from various network layers to provide a comprehensive understanding of network conditions further enhances its uniqueness. The disclosure achieves early congestion identification, reduced packet loss, enhanced QoS, optimized latency, improved throughput and user experience, efficient resource utilization, synchronized sender-receiver communication, prevention of router buffer overflows, adaptive congestion management, and scalability and compatibility with existing L4S architecture.

In addition to its technical advantages, ProActive L4S also offers significant economic and operational benefits. By preventing congestion-related issues before they occur, network operators may reduce the need for costly infrastructure upgrades and maintenance. This proactive approach may extend the lifespan of existing network equipment and delay the need for new investments. Further, the improved network performance and reliability provided by ProActive L4S may lead to higher customer satisfaction and retention, as users experience fewer disruptions and better service quality.

Fig. 1 illustrates latency-sensitive applications in a wireless network. The figure categorizes different types of latency-sensitive applications that are crucial for maintaining optimal user experience by minimizing packet drop and delay.

The first category shown is Interactive Web, which includes applications such as Google Search, Facebook, Twitter, etc. These applications require real-time interaction and quick response times to ensure seamless user engagement. The second category is conversational video, comprising applications like Zoom, Microsoft Teams, Google Meet, etc. These applications facilitate video conferencing and require low latency to maintain the flow of conversation without interruptions. Voice applications are represented in the third category, including Skype, Whatsapp, Discord, etc. These applications are used for voice communication and demand minimal latency to avoid delays and ensure clear audio transmission. The fourth category is interactive video, which includes Twitch, Youtube live, Facebook live, etc. These platforms are used for live streaming and require low latency to provide real-time interaction between the streamer and the audience. The fifth category is Interactive Web for instant messaging applications such as Whatsapp, Messenger, Telegram, etc. These applications need low latency to ensure messages are delivered and received promptly.

Online gaming is the sixth category, including applications like PUBG, Fortnite, Stadia etc. These games require extremely low latency to provide a smooth and responsive gaming experience, as any delay may significantly affect gameplay. Remote Desktop applications are represented in the seventh category, including Team Viewer, Any Desk, Real VNC etc. These applications allow users to control another computer remotely and require low latency to ensure real-time control and interaction. Further category is augmented reality/virtual reality (AR/VR), which includes Samsung XR, Oculus VR, HoloLens etc. These applications demand minimal latency to provide an immersive experience, as any delay may disrupt the user's sense of presence and interaction within the virtual environment.

Figs. 2a and 2b illustrate a scenario of the flow of application data and the L4S feedback between user equipment/base station and an application server according to the related art. In a wireless network (100), the UE (102) and an application server (108) are shown. Both the UE (102) and the application server (108) are L4S compatible. The UE (102) may connect either to Wi-Fi or cellular networks. When the UE (102) is connected to Wi-Fi (100), the traffic flows through an access point (AP) (104) and other middleboxes (106) before reaching the application server (108). When the UE (102) is connected to a corresponding radio access network (RAN) (110) such as 4G or 5G (100), the traffic passes through the 5G backhaul (112). A bottleneck link could be present at any point between the UE (102) and the application server (108). According to the existing L4S architecture, the application server (108) sends data packets, and when congestion is detected at the bottleneck link, the data packets are marked with the CE bit in the IP header. This marking may induce additional delays which are intolerable for ultrasensitive applications. The UE (102) gets application data from the application server (108) and transfers the L4S feedback to the application server in return. This L4S feedback contains marked packets. However, the marked packets reach the application server (108) after the congestion has occurred.

Fig. 2c illustrates congestion between an application server and receiver in a wireless network system according to related art. The figure illustrates the latency-sensitive traffic and normal traffic from the application server (108) to the UE (102) through the wireless network. The network devices like the middleboxes (106), AP (104), RAN (110), and 5G backhaul (112) mark the CE bit of the IP header of the L4S traffic when their buffers approach full capacity. These marked packets reach UE (102), which sends a feedback signal to the application server (108). The application server (108) changes its data transmission rate. However, as the buffers have already reached their full capacity, the queue starts building up and packet dropping occurs due to the influx of data from multiple devices. As a result, increased queuing delays occur and retransmissions further exacerbate latency issues.

Fig 3a illustrates an exemplary wireless network system comprising of user equipment and an application server (108) in a wirelsss communication network system, in accordance with an embodiment of the disclosure. The UE (102) may include memory (102a) connected to a processor (102b), and an L4S data packet controller (102c).

The L4S data packet controller (102c) is a hardware implementation integrated into the UE (102). The L4S data packet controller (102c) incorporates a multi-core architecture that facilitates the dynamic marking the CE bits in advance of the L4S data packets in the communicaton system, contributing to the technical advancement of wireless network operations. Each core of the multi-core architecture is specifically optimized for distinct tasks such as establishing connections between the UE (102) and the application server (108) in the wireless network system (100), detecting network parameters, and marking data packets. The integrated circuit achieves this functionality through a combination of analog and digital components, demonstrating its technical contribution to the field. The analog components, including a low-noise amplifier and a high-precision analog-to-digital converter, ensure accurate signal processing, which is critical for real-time network performance. The digital components, consisting of a microcontroller unit (MCU) and a digital signal processor (DSP), collaboratively predict network congestion within the wireless network system. This technical arrangement enhances the efficiency and reliability of communication systems.

The L4S data packet controller (102c) detects a plurality of network parameters associated with the wireless network system (100). In an embodiment, the plurality of network parameters comprises at least one of a throughput at least one of physical (Phy) layer, a MAC layer, a packet data convergence protocol (Pdcp) layer, and a radio link control (Rlc) layer for both receiving (Rx) and transmitting (Tx); a link speed for Wi-Fi, a buffer status report, a reference signal received power (RSRP), a Signal-to-Interference-plus-noise ratio (SINR), a grant ratio, a duplex mode in frequency division duplex (FDD), a duplex mode in a time division duplex (TDD), an available bandwidth in uplink and downlink, a reduction in power density, a total packet error count, a RLC protocol data units (PDUs) received on dedicated traffic channel (DTCH), a RLC Rx/Tx PDUs requested for retransmission, a total power for physical uplink shared channel (PUSCH) transmission, a power per resource block for PUSCH, an average and maximum jitter, an error count at physical downlink shared channel (PDSCH), an average downlink (DL) and uplink (UL) block error rate, a round-trip time (RTT) value, a cellular and Wi-Fi frequency bands, a packet loss count, a number of retransmitted packets, a number of bad transmitted packets, a number of control element (CE) marked packets.

The AI/ML model is embedded in the memory (102a) of UE (102). The ML model is trained using various network parameters. Now this trained ML model is utilized for predicting an impending network congestion based on the plurality of network parameters. In order to predict the impending network congestion, the L4S data packet controller (102c) inputs, the plurality of network parameters into an artificial intelligence (AI) model, detects patterns indicative of an impending network congestion at the UE (102) using the AI model, predicts the impending network congestion based on the impending network congestion using the AI model before the impending network congestion manifests at the application server (108). The impending network congestion is determined at the UE using the AI model before a router queue builds up.

The L4S data packet controller (102c) marks CE bits in advance of L4S data packets of a plurality of data packets in response to the predicted impending network congestion. The plurality of data packets may include the L4S data packets including data packets with IP header marked as explicit congestion notification (ECN) capable transport, ECT(1), and a classis traffic including data packets with IP header marked as Not-ECT, ECT(0). In an embodiment, the L4S data packet controller (102c) marks the CE bits for the L4S data packets comprises modifying an explicit congestion notification (ECN) field in an internet protocol (IP) header to signal impending congestion to the application server (108), wherein the CE bits are marked before the predicted impending network congestion manifests into the wireless network system (100).

Further, the L4S data packet controller (102c) transmits a congestion status data using 3-bit accurate ECN congestion window reduced ECN Echo (ACE) flags and AccECN option of transport protocol header of the CE marked L4S data packets to the application server (108) for adjusting a transmission rate at the application server (108).

Furthermore, the L4S data packet controller (102c) classifies congestion events in the wireless network system using deep neural network (DNN) model, trains the AI model using historical data comprising the plurality of network parameters and the classified congestion events, and dynamically updates predictions of the AI model based on real-time monitoring of the plurality of network parameters.

Further, as disclosed in the FIG. 3b, the application server (108) may include a memory (108a), a processor (108b), and a transmission rate controller (108c).

The transmission rate controller (108c) is a hardware implementation integrated into the application server (108). The transmission rate controller (108c) incorporates a multi-core architecture that facilitates the dynamic adjustment for adjusting the transmission rate based on the on the congestion status data the communication system, contributing to the technical advancement of wireless network operations. The integrated circuit achieves this functionality through a combination of analog and digital components, demonstrating its technical contribution to the field. The analog components, including a low-noise amplifier and a high-precision analog-to-digital converter, ensure accurate signal processing, which is critical for real-time network performance. The digital components, consisting of a microcontroller unit (MCU) and a digital signal processor (DSP), collaboratively adjusting the transmission rate based on the on the congestion status data. This technical arrangement enhances the efficiency and reliability of communication systems.

The transmission rate controller (108c) establishes connection between the UE (102) and the supplication server (108). The transmission rate controller (108c) receives a congestion status data using a 3-bit ACE flags of transport protocol header of the CE marked L4S data packets from the UE (102) from the UE (102). Further, the transmission rate controller (108c) of the application server (108) adjusts the transmission rate based on the congestion status data. Furthermore, the transmission rate controller (108c) of the application server (108) transmits a plurality of data packets based on the adjusted transmission rate.

The memory (102a or 108a) is configured to store instructions to be executed by the processor. The memory (102a or 108a) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (102a or 108a) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory is non-movable. In some examples, the memory (102a or 108a) is configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that may, over time, change (e.g., in Random Access Memory (RAM) or cache).

The processor (102b or 108b) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU). The processor (102b or 108b) may include multiple cores and is configured to execute the instructions stored in the memory (102a or 108a). Furthermore, the processor (102b or 108b) may include various processing circuitry and/or multiple processors. For example, as used herein, including the claims, the term "processor" may include various processing circuitry, including at least one processor, wherein one or more of at least one processor, individually and/or collectively in a distributed manner, may be configured to perform various functions described herein. As used herein, when "a processor", "at least one processor", and "one or more processors" are described as being configured to perform numerous functions, these terms cover situations, for example and without limitation, in which one processor performs some of recited functions and another processor(s) performs other of recited functions, and also situations in which a single processor may perform all recited functions. Additionally, the at least one processor may include a combination of processors performing various of the recited /disclosed functions, e.g., in a distributed manner. At least one processor may execute program instructions to achieve or perform various functions.

Examples of the wireless communication network system include, but are not limited to, Cellular Networks (such as 2G, 3G, 4G, 5G, Beyond 5G (B5G)/6G, or advanced cellular networks), local area networks (LANs) (such as Wi-Fi, Li-Fi, etc.), personal area networks (PANs) (such as Bluetooth, Zigbee, Z-Wave, etc.), wide area networks (WANs) (such as satellite communication networks, long range wide area network, narrowband IoT, low-bandwidth communication for IoT, etc.), metropolitan area networks (MANs), machine-to-machine (M2M), Ad Hoc and mesh networks, emerging and advanced networks.

Examples of the UE (102) may include, but are not limited to, consumer electronics (such as mobile phones and smartphones), tablets, wearable devices, computing devices (such as laptops, notebooks, desktops, workstations, etc.), IoT devices, automotive systems (such as connected cars, autonomous vehicles, vehicle-to-everything (V2X) communication devices, etc.), enterprise devices such as robotics, specialized equipment (such as medical devices, public safety devices, etc.), media devices (such as gaming consoles, streaming devices, etc.).

Fig 3b illustrates congestion assessment using ML models in accordance with an embodiment of the disclosure. A wireless network system (100) connection is established between the UE (102) and the application server (108). The UE (102) detects a plurality of network parameters associated with the wireless network system (100). The processor (102b) of the user equipment (102) has an AI model. The UE (102) predicts an impending network congestion before it actually occurs based on the plurality of network parameters using the AI model. The UE 102 marks CE bits in advance of low latency low loss scalable throughput L4S data packets of a plurality of data packets in response to the predicted impending network congestion. The UE (102) transmits the CE marked L4S data packets to the application server (108), which adjusts its transmission rate of the data packets. Thus, the congestion in the wireless network for L4S data is prevented by proactively marking the data packets after predicting an impending network congestion. The AI model uses machine learning techniques to enhance congestion detection on the UE (102).

Below tabular column illustrates different Wi-Fi and cellular network parameters in accordance with an embodiment of the disclosure.

In an embodiment, machine learning (ML) techniques enhance congestion detection on the device side, leveraging a comprehensive set of metrics for a proactive approach. The ML model is trained to analyze diverse parameters of cellular and Wi-Fi networks, providing an intelligent and dynamic congestion management system. ML analyzes various parameters and predicts congestion before the router queue builds up.

The flow diagram in Fig. 4 illustrates the ML model flow according to the embodiments disclosed herein, in accordance with an embodiment of the disclosure. The process begins with obtaining input data from Wi-Fi and cellular parameters. A plurality of network parameters is detected by the UE (102), including at least one of throughput, physical (Phy) layer, MAC layer, packet data convergence protocol (Pdcp) layer, and radio link control (Rlc) layer for both receiving (Rx) and transmitting (Tx), link speed for Wi-Fi, buffer status report, reference signal received power (RSRP), signal-to-interference-plus-noise ratio (SINR), grant ratio, duplex mode in frequency division duplex (FDD), duplex mode in time division duplex (TDD), available bandwidth in uplink and downlink, reduction in power density, total packet error count, RLC protocol data units (PDUs) received on dedicated traffic channel (DTCH), RLC Rx/Tx PDUs requested for retransmission, total power for physical uplink shared channel (PUSCH) transmission, power per resource block for PUSCH, average and maximum jitter, error count at physical downlink shared channel (PDSCH), average downlink (DL) and uplink (UL) block error rate, round-trip time (RTT) value, cellular and Wi-Fi frequency bands, packet loss count, number of retransmitted packets, number of bad transmitted packets, and number of control element (CE) marked packets.

At F1, these detected parameters are provided as input data to the ML model. The ML model is trained using feature selection At F2, where a feature is selected from the input data. F3 involves training the data collection. Subsequently, At F4, the ML model is trained to analyze diverse parameters of Cellular and Wi-Fi networks. The ML model classifies congestion events based on the dataset. Given the intricate and non-linear nature of the data, three primary supervised learning approaches are opted: deep neural networks (DNN), non-linear support vector machines (SVM), and extreme gradient boosting (XGBoost). A trained ML model is obtained at F5.

The DNN architecture was chosen for its capability to capture complex patterns inherent in the dataset. This specific DNN architecture may include an input layer, dropout layers, and an output layer. The input layer is configured to match the number of features in the dataset. Multiple hidden layers are used, each incorporating a varying number of neurons (e.g., 64, 128, 256) utilizing ReLU activation functions to introduce non-linearity and enhance model expressiveness. Dropout layers are strategically applied to mitigate overfitting by randomly deactivating a fraction of neurons during training. The output layer employs a softmax activation function for multi-class classification, generating probability distributions across congestion classes.

Below tabular column summarizes the optimal hyperparameters for each model according to an embodiment of the disclosure.

A radial basis function (RBF) kernel is utilized for the non-linear SVM model to handle the non-linear separability of the dataset. Key parameters include the kernel trick, regularization parameter (C), and gamma parameter. The kernel trick is implemented via the RBF kernel to transform the input space into a higher-dimensional feature space, effectively separating congestion classes. The regularization parameter (C) is tuned to strike a balance between minimizing training error and controlling model complexity during optimization. Adjusting the gamma parameter regulates the influence of individual training samples on the decision boundary, with higher values allowing for more intricate decision boundaries.

An XGBoost model, known for its robustness and efficiency in handling structured data, was selected for the XGBoost model. Configured as a boosting framework, XGBoost uses a gradient boosting framework that builds trees sequentially, where each tree aims to correct the errors of its predecessor. This approach enhances the model's accuracy and performance. Decision trees serve as base learners, which are combined to form a strong predictive model. Each tree in the sequence is built to minimize the loss function using gradient descent. Incorporating L1 (Lasso) and L2 (Ridge) regularization prevents overfitting, ensuring that the model generalizes well to unseen data.

Below tabular column presents the model performance metrics in accordance with an embodiment of the disclosure.

Below, the tabular column describes the accuracy metrics of DNN and Non-linear SVM models and F1-Scores according to an embodiment of the disclosure.

Hyperparameter tuning is performed. Hyperparameters include learning rate, max depth, subsample, and colsample bytree. The learning rate controls the contribution of each tree to the final model, with lower values making the model robust but requiring more trees. Max depth determines the maximum depth of each tree, allowing the model to capture complex patterns in the data. Subsample specifies the fraction of the training data to be used for fitting each tree, which helps prevent overfitting. Colsample bytree defines the fraction of features to be used for constructing each tree, further aiding in reducing overfitting. Further, the classification of congestion events may be done using a long short-term memory (LSTM) model.

Fig. 5 is a flow diagram that illustrates the flow of congestion detection in a UE in accordance with an embodiment of the disclosure. At T1, the UE (102) periodically verifies the data traffic and distinguishes L4S traffic from the normal data traffic. If the data packets are L4S traffic, at T2, the trained ML model is used for the prediction of congestion. The plurality of network parameters received by the UE (102) are provided as input into the trained ML model. At T3, a real-time inference is performed using the ML model. Further, the UE (102) detects patterns indicative of impending network congestion at the UE (102) using the ML model. After the inference, it is checked for congestion at T4. If the congestion is detected, the CE bit is marked at T5, else, the flow is terminated.

In an embodiment, marking the CE bits for the L4S data packets comprises modifying an explicit congestion notification (ECN) field in an internet protocol (IP) header to signal impending congestion to the application server (108), wherein the CE bits are marked before the predicted impending network congestion manifests into the wireless network system (100).

In an embodiment, the impending network congestion is determined at the UE using the AI model before a router queue builds up.

Fig. 6 illustrates an L4S architecture in accordance with an embodiment of the disclosure. The L4S acts proactively. The UE (102) and the application server (108) may connect to either Wi-Fi or cellular networks. The application server (108) sends data packets to the UE (102) through the wireless network (100). When the UE (102) is connected to Wi-Fi, the traffic flows through an access point (AP) and other middleboxes before reaching the application server (108). When the UE (102) is connected to a corresponding radio access network (RAN) such as 4G or 5G, the traffic passes through the 5G backhaul. A bottleneck link could be present at any point between the UE (102) and the application server (108). The UE (102) receives input parameters from the wireless network (100) and predicts impending network congestion based on the plurality of network parameters using an artificial intelligence (AI) model before the actual occurrence of the congestion. When the congestion is predicted, the UE (102) marks congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets in response to the predicted impending network congestion. After marking the CE bits, the UE (102) transmits congestion status data using a 3-bit ACE flags of the transport protocol header of the CE marked L4S data packets to the application server (108), which thereby adjusts the transmission rate and transmits a plurality of data packets based on the adjusted transmission rate to the UE (102).

Fig 7 illustrates a flow chart indicating operations of method for predicting network congestion in a wireless network system performed at a user equipment according to an embodiment of the disclosure. At S1, the UE (102) establishes a connection with an application server (108) in the wireless network system (100). The connection establishment involves a handshake process that includes authentication and authorization protocols to ensure secure communication. At S2, the UE (102) detects a plurality of network parameters associated with the wireless network system (100). These network parameters may include signal strength, packet loss rate, latency, jitter, and current bandwidth utilization. At S3, an impending network congestion is predicted by the UE (102) based on the plurality of network parameters using an AI model. The AI model may utilize machine learning algorithms such as neural networks or support vector machines to analyze historical data and real-time network conditions to predict congestion with high accuracy.

At S4, the UE (102) marks congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets in response to the predicted impending network congestion. The marking of CE bits is performed in accordance with the ECN protocol to signal congestion to the network. At S6, the UE (102) transmits a congestion status data using 3-bit ACE flags and AccECN option of transport protocol header of the CE marked L4S data packets to the application server (108) for adjusting a transmission rate at the application server (108). The congestion status data may also include additional metrics such as queue length and buffer occupancy to provide a comprehensive view of the network state.

Fig 8 illustrates a method for adjusting a transmission rate by the application server after prediction of network congestion in a wireless network system accordance with an embodiment of the disclosure. At S1, the application server (108) establishes a connection with the UE (102) in the wireless network system (100). This connection setup may include negotiating QoS parameters to ensure optimal data transmission. At S2, the application server (108) receives a congestion status data using a 3-bit ACE flags of transport protocol header of CE marked L4S data packets from the UE (102). The received congestion status data is processed by the application server's congestion control algorithm to determine the appropriate transmission rate. At S3, the application server (108) adjusts the transmission rate based on the congestion status data received from the UE (102) at S4. The adjustment may include dynamically scaling the transmission window size or modifying the packet sending rate to alleviate congestion. At S5, the application server (108) transmits a plurality of data packets based on the adjusted transmission rate to the UE (102). The data packets is prioritized based on their type and importance, ensuring critical data is transmitted with minimal delay.

Fig. 9a illustrates a streamlined traffic identification in the IP header, in accordance with an embodiment of the disclosure. The L4S incorporates 'Scalable' congestion control, enabling more frequent control signals from the network and finer-grained adjustments in response. Low queuing delays are maintained while maximizing link utilization, allowing TCP-like traffic to achieve high bandwidth and low delay simultaneously, even under heavy traffic loads. L4S employs AccECN protocol in the IP layer, designed to provide congestion signals frequently, even multiple times within one RTT. When a congestion is predicted at the UE 102, the packets are marked with a CE codepoint in the IP header. Further, with L4S, traffic identification is streamlined by introducing a new ECN identifier (L4S codepoint) in the IP header. ECN bits are used to distinguish L4S traffic from classic traffic by using ECT(1) for L4S. In both the IPV4 and IPV6 header, ECN protocol uses the two bits after the DSCP value. Two ECN bits allow 4 combinations of ECN codepoints: 00-Not ECT, 01-ECT(1), 10-ECT(0), 11-CE.

In an embodiment, the network deploys an L4S active queue management (AQM) system, such as DualQ or Fair Queueing (FQ), at intermediate links called as middle boxes. When ECT(1) is detected by middleboxes/intermediate network devices such as routers, the traffic is enqueued into L4S queues, while other traffic is enqueued into standard queues. This selective queuing further optimizes network performance by ensuring that latency-sensitive L4S traffic is given priority handling over regular traffic. Thus, the introduction of L4S and its robust congestion management techniques not only improves user satisfaction but also optimizes overall network efficiency and reliability.

Fig. 9b illustrates a TCP header, in accordance with an embodiment of the disclosure. At the start of a TCP connection during a three-way handshake, both the client and server i.e., the UE 102 and the application server 108, negotiate the use of AccECN by using the redefined 'ACE' flags in the TCP header. Once the TCP and IP header negotiation is completed and support for AccECN is confirmed, ACE is used for congestion feedback from the client. The negotiation process ensures that both ends of the connection support the enhanced feedback mechanism by setting and recognizing these ACE flags accordingly. As the data packets traverse the network 100 and reach the UE 102, the UE 102 predicts an impending congestion based on the plurality of network parameters using an AI model. The UE 102 marks CE bits in advance of L4S data packets in response to the predicted impending network congestion the packets using the ECN field in the IP header. Upon receiving the marked packets, the UE 102 relays the congestion status data back to the application server/sender using the ACE flags in the TCP acknowledgment packets. Additional TCP-accurate ECN options may also be added to provide more detailed feedback. L4S require ECN feedback in the TCP header per RTT. The 3-bit field is used in L4S - AE (Accurate ECN), CWR, ECE. The 3 bits of the ACE counts number of CE packets. The ACE flags and AccECN option of transport protocol header of the CE marked L4S data packets comprises at least one of a number of the data packets of L4S data packets marked with congestion experienced CE and a number of bytes marked with the CE bits. Upon receiving the congestion status feedback, the application server dynamically adjusts its transmission rate to alleviate congestion and prevent delays at the bottleneck.

Fig. 10 illustrates a flow of data collection in accordance with an embodiment of the disclosure. The UE detects a plurality of network parameters associated with the wireless network system when the UE is connected to the wireless network, fetching data from the L1 (PHY), L2 (MAC/RLC/PDCP), L3, and RRC layers. The UE further comprises a communication processor (CP) and an application processor (AP). The CP transfers the detected data to the AP via a shared inter-process communication (SIPC).

In an embodiment of the disclosure, the AP framework of the UE comprises a client module, the data comm controller, which establishes a connection with the application server and uploads data on the Linux-based Ubuntu data storage server as shown in Fig. 10. The collected data was for over a period of three months continuously with more than 15 UE (which were used as user trial devices). The size of data stored in the data storage device may amount to over 1TB of data.

The data was meticulously preprocessed to include samples with recorded congestion events, resulting in a refined dataset of 8, 95, 261 rows. The data is categorized separately for each radio access technologies (RAT: NR or LTE), encompassing 75 parameters. Principal component analysis (PCA) was employed to further refine the parameter set by identifying underlying patterns and reducing multicollinearity among the variables. This statistical technique facilitated the extraction of a smaller subset of orthogonal components that capture the variability in the original dataset while minimizing information loss.

Fig 11a illustrates a correlation matrix for down link (DL) in accordance with an embodiment of the disclosure. The correlation matrix is a graphical representation that shows the relationship between various parameters associated with down link performance. Each cell in the matrix contains a correlation coefficient that quantifies the degree to which two parameters are linearly related.

The parameters represented in the correlation matrix include RSRP, RxPducnt, PdschResErrCnt, DLPhyTput, ReRxPducnt, TotDLPhyTput, AvgDLAlloc, AvgDLBler, AvgDLNumRb, PUSCHPwr, RSSI, and PDCPDLTput.

Reference signal received power (RSRP) is shown to have a strong negative correlation with physical uplink shared channel power (PUSCHPwr) and received signal strength indicator (RSSI), indicating that as RSRP increases, both PUSCHPwr and RSSI tend to decrease. Conversely, RSRP has a positive correlation with down link physical throughput (DLPhyTput) and total down link physical throughput (TotDLPhyTput), suggesting that higher RSRP values are associated with higher throughput values.

Received PDU count (RxPducnt) shows a moderate negative correlation with RSRP and a weak positive correlation with PUSCHPwr. This implies that as the count of received PDUs increases, the RSRP tends to decrease while the PUSCHPwr tends to increase slightly. Physical downlink shared channel resource error count (PdschResErrCnt) has weak correlations with most other parameters, indicating that it does not have a strong linear relationship with them.

DLPhyTput and TotDLPhyTput are highly positively correlated with each other, which is expected as both parameters measure throughput. They also show positive correlations with average down link allocation (AvgDLAlloc) and weak correlations with other parameters.

Re-transmitted PDU count (ReRxPducnt) shows weak correlations with most parameters, indicating that re-transmission counts do not strongly affect other metrics.

AvgDLAlloc shows moderate positive correlations with DLPhyTput, TotDLPhyTput, and average down link number of resource blocks (AvgDLNumRb), indicating that better resource allocation is associated with higher throughput and more resource blocks.

Average down link block error rate (AvgDLBler) has weak correlations with most parameters, suggesting that block error rates do not significantly impact other metrics.

AvgDLNumRb shows weak correlations with most parameters except for AvgDLAlloc, indicating that the number of resource blocks is primarily influenced by allocation efficiency.

PUSCHPwr shows strong positive correlations with RSSI and moderate positive correlations with AvgDLAlloc and AvgDLNumRb, suggesting that higher uplink power is associated with better signal strength and resource allocation.

RSSI has moderate positive correlations with PUSCHPwr and weak correlations with other parameters, indicating that signal strength is primarily influenced by uplink power.

Packet data convergence protocol down link throughput (PDCPDLTput) shows strong positive correlations with DLPhyTput, TotDLPhyTput, and AvgDLAlloc, indicating that higher PDCP throughput is associated with higher physical throughput and better resource allocation.

Fig 11b illustrates a correlation matrix for uplink (UL) in accordance with an embodiment of the disclosure. The correlation matrix provides a visual representation of the relationships between various metrics associated with the UL performance. Each cell in the matrix contains a correlation coefficient that quantifies the degree to which two metrics are linearly related.

The metrics represented in the matrix include RSRP, transport block (TxPduCnt), retransmission block (ReTxPduCnt), physical downlink shared channel (PdscheResErrCnt), total UL physical throughput (TotULPhyTPut), average UL allocation (AvgUlAlloc), grant, physical uplink shared channel power (PUSCHPwr), RSSI, and physical downlink control channel UL throughput (PDCpULTput).

The correlation coefficients range from -1 to 1, where -1 indicates a perfect negative correlation, 0 indicates no correlation, and 1 indicates a perfect positive correlation. The color gradient in the matrix aids in quickly identifying the strength and direction of the correlations, with red hues indicating positive correlations and blue hues indicating negative correlations.

For instance, the correlation coefficient between RSRP and PUSCHPwr is -0.91, indicating a strong negative correlation. This suggests that as the RSRP decreases, the PUSCHPwr tends to increase. Conversely, the correlation between TotULPhyTPut and PDCpULTput is 1.00, indicating a perfect positive correlation, meaning that these two metrics increase and decrease together in perfect unison.

The matrix also reveals weaker correlations, such as the correlation between TxPduCnt and AvgUlAlloc, which is -0.05, indicating a very weak negative correlation. This suggests that changes in TxPduCnt have minimal impact on AvgUlAlloc.

Fig 11c illustrates a correlation matrix heatmap for other metrics in accordance with an embodiment of the disclosure. The correlation matrix heatmap visually represents the correlation coefficients between various metrics. The metrics included in the heatmap are RSRP, RSRQ, RSSNR, PdSchResErrCnt, RePdunct, CINR, BSR, PUSCHPwr, and RSSI.

The heatmap uses a color gradient to indicate the strength and direction of the correlation between pairs of metrics. Red shades represent positive correlations, while blue shades represent negative correlations. The intensity of the color corresponds to the magnitude of the correlation coefficient, with darker colors indicating stronger correlations.

For example, the correlation coefficient between RSRP and RSRQ is 0.97, indicating a strong positive correlation. Similarly, the correlation coefficient between RSRP and RSSI is -0.58, indicating a moderate negative correlation.

Fig 11d illustrates another correlation matrix heatmap for additional metrics, in accordance with an embodiment of the disclosure. The metrics included in this heatmap are RSRP, RSRQ, DRPC, PRRC, DLT, ULT, SUDL, SUUL, BLER, GRNT, and POWR.

Similar to Fig 11c, the heatmap in Fig 11d uses a color gradient to represent the correlation coefficients between pairs of metrics. For instance, the correlation coefficient between RSRP and RSRQ is 0.91, indicating a strong positive correlation. On the other hand, the correlation coefficient between RSRP and POWR is -0.91, indicating a strong negative correlation.

These correlation matrix heatmaps provide a comprehensive overview of the relationships between various metrics, allowing for easy identification of patterns and insights that may be used for further analysis and optimization in the relevant field.

In an embodiment, the machine learning models employed to classify congestion events based on the dataset is described. Given the intricate and non-linear nature of the data, three primary supervised learning approaches are opted: deep neural networks (DNN), non-linear support vector machines (SVM), and extreme gradient boosting (XGBoost).

The chosen DNN architecture demonstrates a capability to capture complex patterns inherent in our dataset. This specific DNN architecture may include several key components: An input layer is configured to match the number of features in our dataset. Multiple hidden layers are incorporated, each layer containing a varying number of neurons (e.g., 64, 128, 256) and utilizing ReLU activation functions to introduce non-linearity and enhance model expressiveness. Dropout layers are strategically applied to mitigate overfitting by randomly deactivating a fraction of neurons during training. An output layer employs a softmax activation function for multi-class classification, generating probability distributions across congestion classes.

Non-linear support vector machines (SVM): For the non-linear SVM model, we utilized the radial basis function (RBF) kernel to handle the non-linear separability of our dataset. Key parameters included:

1. Kernel trick: Implemented via the RBF kernel to transform the input space into a higher-dimensional feature space, effectively separating congestion classes.

2. Regularization parameter (C): Tuned to strike a balance between minimizing training error and controlling model complexity during optimization.

3. Gamma parameter: Adjusted to regulate the influence of individual training samples on the decision boundary, with higher values allowing for more intricate decision boundaries.

4. Boosting framework: XGBoost uses a gradient boosting framework that builds trees sequentially, where each tree aims to correct the errors of its predecessor. This approach enhances the model's accuracy and performance.

5. Dropout layers: Strategically applied to mitigate overfitting by randomly deactivating a fraction of neurons during training.

6. Output layer: Employing a softmax activation function for multi-class classification, generating probability distributions across congestion classes.

Extreme gradient boosting (XGBoost): XGBoost was selected for its robustness and efficiency in handling structured data. The XGBoost model was configured as follows:

1. Boosting framework: XGBoost uses a gradient boosting framework that builds trees sequentially, where each tree aims to correct the errors of its predecessor. This approach enhances the model's accuracy and performance.

2. Decision trees: Utilizes decision trees as base learners, which are combined to form a strong predictive model. Each tree in the sequence is built to minimize the loss function using gradient descent.

3. Regularization: Incorporates L1 (Lasso) and L2 (Ridge) regularization to prevent overfitting, ensuring that the model generalizes well to unseen data.

In an embodiment, hyperparameters include important parameters such as: Learning rate: Controls the contribution of each tree to the final model, with lower values making the model robust but requiring more trees.

1. Max depth: Determines the maximum depth of each tree, allowing the model to capture complex patterns in the data.

2. Subsample: Specifies the fraction of the training data to be used for fitting each tree, which helps prevent overfitting.

3. Colsample bytree: Defines the fraction of features to be used for constructing each tree, further aiding in reducing overfitting:

In an embodiment the UE (102) classifies congestion events in the wireless network system using deep neural network (DNN) model. The UE (102) trains the AI model using historical data comprising the plurality of network parameters and the classified congestion events. Further, the predictions of the ML/AI model based on real-time monitoring of the plurality of network parameters is dynamically updated.

In an embodiment the congestion events in the wireless network system may be classified using a long short-term memory (LSTM) model.

In an embodiment the plurality of data packets comprises at least one of: the L4S data packets including data packets with IP header marked as ECN capable transport ECT(1) and a classis traffic including data packets with IP header marked as Not-ECT, ECT(0).

In an embodiment the UE (102) detects L4S data packets from the plurality of data packets based on whether the data packets are explicit congestion notification (ECN)-capable. The UE (102) maintains separate queues for the L4S data packets and a classic traffic.

Wherein the detecting comprises:

i. determining, by the UE (102), an IP header of each of the received data packets to determine if the IP header is marked with an ECN-capable transport ECT(1), and

ii. when the IP header is marked with an ECT(1), placing the data packet in a queue designated for the L4S data packets, and

iii. when the IP header is not marked with the ECT(1), placing the data packet in a queue designated for classic traffic.

In an embodiment the UE (102) transmits the congestion status data using the 3-bit ACE flags and AccECN option of transport protocol header of the CE marked L4S data packets comprises at least one of: a number of the data packets of L4S data packets marked with congestion experienced CE, and a number of bytes marked with the CE bits.

In an embodiment the congestion status data using the 3-bit ACE flags and AccECN option of transport protocol header of the CE marked L4S data packets comprises at least one of: a number of the data packets of L4S data packets marked with congestion experienced CE, and a number of bytes marked with the CE bits.

In an embodiment the application server (108) establishes a connection with the UE (102) in the wireless network system (100). The application server (108) receives a congestion status data using a 3-bit ACE flags of transport protocol header of CE marked L4S data packets from the UE (102). The application server (108) transmits a plurality of data packets based on the adjusted transmission rate.

In an embodiment, an objective function is configured for multi-class classification, optimizing the logarithmic loss function to handle multiple congestion classes.

In an embodiment, hyper-parameter tuning was conducted for each model using grid search and cross-validation to identify the best set of parameters.

The disclosure provides a method for proactively predicting congestion in a wireless network. L4S provides an early congestion identification, reduced packet loss with enhance QoS. Further the embodiment provides optimized latency with improved throughput and user experience. The novel solution ensures the efficient resource utilization, synchronized sender-receiver communication, prevention of router buffer overflows, adaptive congestion management. The proposed L4S is a future proof architecture which enhances scalability and compatibility (with existing L4S architecture).

It will be appreciated that various embodiments of the disclosure according to the claims and description in the specification can be realized in the form of hardware, software or a combination of hardware and software.

Any such software may be stored in non-transitory computer readable storage media. The non-transitory computer readable storage media store one or more computer programs (software modules), the one or more computer programs include computer-executable instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform a method of the disclosure.

Any such software may be stored in the form of volatile or non-volatile storage, such as, for example, a storage device like read only memory (ROM), whether erasable or rewritable or not, or in the form of memory, such as, for example, random access memory (RAM), memory chips, device or integrated circuits or on an optically or magnetically readable medium, such as, for example, a compact disk (CD), digital versatile disc (DVD), magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are various embodiments of non-transitory machine-readable storage that are suitable for storing a computer program or computer programs comprising instructions that, when executed, implement various embodiments of the disclosure. Accordingly, various embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a non-transitory machine-readable storage storing such a program.

While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

Claims

A method for predicting network congestion in a wireless network system, comprising:

establishing, by a user equipment (UE) (102), a connection between the UE (102) and an application server (108) in the wireless network system (100);

detecting, by the UE (102), a plurality of network parameters associated with the wireless network system (100);

predicting, by the UE (102), an impending network congestion based on the plurality of network parameters;

marking, by the UE (102), congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets based on the predicted impending network congestion; and

transmitting, by the UE (102) to the application server (108), a congestion status data using accurate explicit congestion notification (ECN) congestion window reduced ECN echo (ACE) flags and a transport protocol header of the CE marked L4S data packets.
The method of claim 1, wherein the plurality of network parameters comprises at least one of a throughput at least one of physical (Phy) layer, a media access control (MAC) layer, a packet data convergence protocol (Pdcp) layer, and a radio link control (RLC) layer for both receiving (Rx) and transmitting (Tx); a link speed for Wi-Fi, a buffer status report, a reference signal received power (RSRP), a signal-to-interference-plus-noise ratio (SINR), a grant ratio, a duplex mode in frequency division duplex (FDD), a duplex mode in a time division duplex (TDD), an available bandwidth in uplink and downlink, a reduction in power density, a total packet error count, a RLC protocol data units (PDUs) received on dedicated traffic channel (DTCH), a RLC Rx/Tx PDUs requested for retransmission, a total power for physical uplink shared channel (PUSCH) transmission, a power per resource block for PUSCH, an average and maximum jitter, an error count at physical downlink shared channel (PDSCH), an average downlink (DL) and uplink (UL) block error rate, a round-trip time (RTT) value, a cellular and Wi-Fi frequency bands, a packet loss count, a number of retransmitted packets, a number of bad transmitted packets, a number of control element (CE) marked packets.
The method of claim 1, wherein predicting, by the UE (102), the impending network congestion comprises:

inputting, by the UE (102), the plurality of network parameters into an artificial intelligence (AI) model;

detecting, by the UE (102), patterns indicative of an impending network congestion at the UE (102) using the AI model; and

predicting, by the UE (102), the impending network congestion based on the impending network congestion using the AI model before the impending network congestion manifests at the application server (108).
The method of claim 1, wherein marking the CE bits for the L4S data packets comprises modifying an ECN field in an internet protocol (IP) header to signal impending congestion to the application server (108),

wherein the CE bits are marked before the predicted impending network congestion manifests into the wireless network system (100).
The method of claim 1, wherein the impending network congestion is determined at the UE using an artificial intelligence (AI) model before a router queue builds up.
The method of claim 1, comprises:

classifying, by the UE (102), congestion events in the wireless network system using deep neural network (DNN) model;

training, by the UE (102), an artificial intelligence (AI) model using historical data comprising the plurality of network parameters and the classified congestion events; and

updating, by the UE (102), predictions of the AI model based on real-time monitoring of the plurality of network parameters.
The method of claim 6, wherein classifying, by the UE (102), congestion events in the wireless network system using the DNN model comprises:

providing a dataset with a plurality of features related to the congestion events;

employing the DNN model to capture complex patterns in the dataset, wherein the DNN model includes:

an input layer configured to match a number of features in the dataset;

a plurality of hidden layers, each hidden layer incorporating a varying number of neurons and utilizing rectified linear unit (ReLU) activation functions to introduce non-linearity and enhance model expressiveness;

one or more dropout layers strategically applied to mitigate overfitting by randomly deactivating a fraction of neurons during training; and

an output layer employing a softmax activation function for multi-class classification to generate probability distributions across congestion classes; and

training the DNN model on the dataset to classify the congestion events.
The method of claim 6, wherein classifying, by the UE (102), the congestion events in the wireless network system comprises using a long short-term memory (LSTM) model.
The method of claim 1, wherein the plurality of data packets comprises at least one of:

the L4S data packets including data packets with internet protocol (IP) header marked as ECN capable transport; and

a classic traffic including data packets with IP header marked as not-ECT.
The method of claim 1, comprises

detecting, by the UE (102), L4S data packets from the plurality of data packets based on whether the data packets are ECN-capable transport, wherein the detecting comprises:

determining, by the UE (102), an IP header of each of the received data packets to determine if the IP header is marked with an ECN-capable transport (ECT); and

based on the IP header being marked with the ECT, placing the data packet in a queue designated for the L4S data packets; and

based on the IP header being not marked with the ECT, placing the data packet in a queue designated for classic traffic; and

maintaining, by the UE (102), separate queues for the L4S data packets and a classic traffic.
The method of claim 1, wherein transmitting, by the UE (102) to the application server (108), the congestion status data using the ACE flags and the transport protocol header of the CE marked L4S data packets comprises at least one of:

a number of the data packets of L4S data packets marked with congestion experienced (CE); and

a number of bytes marked with the CE bits.
A method for predicting network congestion in a wireless network system, comprising:

establishing, by an application server (108), a connection between the application server (108) and the user equipment (UE) (102) in the wireless network system (100);

receiving, by the application server (108) from the UE (102), a congestion status data using a accurate congestion window reduced explicit congestion notification (ECN) echo (ACE) flags and a transport protocol header of congestion experienced (CE) marked low latency low loss scalable throughput (L4S) data packets; and

adjusting, by the application server (108), a transmission rate based on the congestion status data; and

transmitting, by the application server (108), a plurality of data packets based on the adjusted transmission rate.
The method of claim 12, wherein the congestion status data using the ACE flags and a transport protocol header of the CE marked L4S data packets comprises at least one of:

a number of the data packets of L4S data packets marked with CE; and

a number of bytes marked with the CE bits.
A user equipment (UE) for predicting network congestion in a wireless network system, comprising:

memory (102a) storing instructions; and

at least one processor (102b) communicatively coupled to the memory (102a),

wherein the instructions, when executed by the at least one processor individually or collectively, cause the UE to:

establishe connection between the UE (102) and an application server (108) in the wireless network system (100);

detect a plurality of network parameters associated with the wireless network system (100);

predict a network congestion based on the plurality of network parameters;

mark congestion experienced (CE) bits in advance of low latency low loss scalable throughput (L4S) data packets of a plurality of data packets based on the predicted network congestion; and

transmit a congestion status data using accurate congestion window reduced explicit congestion notification (ECN) echo (ACE) flags and transport protocol header of the CE marked L4S data packets to the application server (108).
An application server for predicting network congestion in a wireless network system, comprising:

memory (108a) storing instructions; and

at least one processor (108b) communicatively coupled to the memory (108a); and

wherein the instructions, when executed by the at least one processor individually or collectively, cause the application server to:

establishe a connection between the application server (108) and the UE (102) in the wireless network system (100);

receive a congestion status data using accurate congestion window reduced explicit congestion notification (ECN) echo (ACE) flags and a transport protocol header of the congestion experienced (CE) marked low latency low loss scalable throughput (L4S) data packets from the UE (102); and

adjust a transmission rate based on the congestion status data; and

transmits a plurality of data packets based on the adjusted transmission rate.