Enhanced congestion report for 802.11 streams

Abstract

The management and reporting of congestion in hybrid networks subject to congestion at MAC level requires adaptation of the L4S mechanism. Regarding uplink traffic, an AP receives a MAC frame marked with MAC congestion indication, reports to IP layer, the indication and the IP packet of the received frame, and responsive to the reporting, marks the packet with a CE codepoint. To speed up congestion reporting, a communication device detects congestion in a local transmit MAC queue storing MAC frames of a first flow of data traffic, and responsive to the detection, reports, to IP layer, a MAC congestion indication using a MAC service primitive. In particular, a communication device has a MAC service configured to communicate with an upper layer using a primitive that includes an ECN codepoint to report congestion and / or a MA-UNITDATA-STATUS.indication primitive that includes an ECE bit to report congestion.

Description

[0001] ENHANCED CONGESTION REPORT FOR 802.11 STREAMS

[0002] FIELD OF THE DISCLOSURE

[0003] The present disclosure relates generally to communication and more particularly to congestion reporting in wireless, wired and hybrid networks.

[0004] BACKGROUND OF THE DISCLOSURE

[0005] The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section.

[0006] Low-Latency, Low-Loss, Scalable Throughput (L4S) is a recent standard, developed by the Internet Engineering Task Force (IETF - RTM), for congestion control on the Internet. For example, publication “RFC 9330: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture” (January 2023) describes an L4S architecture.

[0007] In some situations, parts of the Internet are unable to quickly service all the packets that arrive because users send more packets than that part of the network can accommodate, thus defining a bottleneck point or link (e.g., a household's Internet access or Wi-Fi). When the arrival rate exceeds the service rate, packets form queues that introduce increasing latency. Latency is detrimental to applications such as interactive web, web services, voice, conversational video, high-definition video, advanced telemedicine, interactive video, interactive remote presence, instant messaging, online and cloud-rendered gaming, remote desktop, cloud-based applications, cloud-rendered virtual reality or augmented reality, and video-assisted remote control of machinery and industrial processes.

[0008] The L4S architecture allows Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control ensuring that as network demands grow, performance does not degrade significantly. Contrary to congestion control algorithms that cause substantial queuing delay, the L4S architecture adopts a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of an Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have low latency and low loss while simultaneously maintaining high throughput in networks.

[0009] The L4S mechanism is based on an Active Queue Management (AQM) simultaneously applied to two queues, one dedicated to the low latency or“L4S” traffic and the other to the legacy or “Classic” traffic. The L4S mechanism uses the Explicit Congestion Notification (ECN) protocol defined in RFC 3168 (2001), but it signals the very start of queue growth immediately, without the smoothing delay typical of Classic AQMs. Because ECN support is essential to the L4S mechanism, senders use the ECN field for the network to identify which packets are L4S and which are Classic, respectively using the ECT(1) and Non-ECT codepoints (or values) in the ECN field of the IP (Internet Protocol) packet header.

[0010] Upon detecting any congestion for an L4S or Classic traffic over the IP layer, any ECN- aware IP router marks the packets of the concerned traffic with the Congestion Experienced (CE) codepoint (in the ECN field) instead of dropping the packets, in order to signal impending congestion. The receiver of the packets echoes the congestion indication to the packet sender, by setting proper bits in the header of the transport protocol, typically by setting the so-called ECE bit in the header of the TCP (Transmission Control Protocol) packet. In response, the packet sender reduces its transmission rate as if it detected a dropped packet.

[0011] Due to the echoing operation at the packet receiver, the responsiveness of the L4S mechanism to adapt the rate may reach up to the round-trip time of the congestion indication.

[0012] As today's communication systems may be hybrid by including separate wireless and wireline portions, discussions have emerged in the IEEE (RTM) 802.11 bn work group to enable support of the L4S mechanism for end-to-end transportation. As it operates at Layer 3, the L4S mechanism is deficient to report congestion occurring at Layer 2, such as the MAC layer. However, the MAC layer may become a root of congestion in the wireless portions, e.g., due to a high number of wireless stations or to Overlapping Basic Service Sets (OBSSs).

[0013] A recent publication, IEEE (RTM) 802.11-24 / 0384r3 (entitled “Low Latency based on L4S”), addresses this issue. It proposes to extend the ECN signal of L4S to the MAC layer for downlink traffic regardless of which AQM used, that is to say for traffic coming from the Internet and delivered downlink to the wireless network by an AP (e.g. hosted in an Internet router) towards an end-user client (that is a non-AP station). In particular, a new L4S(ECN capable) field is proposed in the TCLAS element to classify L4S packets, in case SCS (Stream Classification Service) is supported, or a new parameter in the MU-UNITDATA. request primitive of the Layer2- Layer3 interface is proposed to classify L4S packets in case SCS is not supported. Furthermore, for the downlink, the AP may provide congestion notification to the corresponding STA if the congestion occurs in the AP MAC queue. In response, at the STA, when a packet comes to the LLC layer from the MAC layer, a congestion flag (L4S-CE) is added in the MA- UNITDATA. indication primitive to report the packet was congested in the AP MAC queue.

[0014] The contribution of this publication is however insufficient to address all the scenarios of a wireless network, e.g. when the wireless non-AP stations are the sources of L4S or Classic traffic.

[0015] Accordingly, there is a need to improve the known techniques. SUMMARY OF THE DISCLOSURE

[0016] No solution exists to adapt the L4S mechanism to the uplink, that is to say for traffic coming from an end-user client (that is a non-AP station), that is delivered uplink in the wireless network to the AP (e.g. hosted in an Internet router), which forwards it towards the Internet.

[0017] In this respect, the disclosure proposes a method of reporting congestion, comprising, in an access point (AP) of a wireless network: receiving, from a non-AP station of the wireless network, a Layer-2 frame (e.g. a MAC frame known as MAC protocol data unit or MPDU) marked with a Layer-2 congestion indication relating to a data traffic, and responsive to the receiving, marking a Layer-3 packet (e.g. a MAC service data unit or MSDU included in the frame) of the data traffic, with a Congestion Experienced (CE) codepoint.

[0018] From non-AP station perspective, a method of reporting congestion, comprises, in a non- access point (non-AP) station of a wireless network: detecting congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a data traffic, and transmitting, to an AP of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to the data traffic.

[0019] Correspondingly, an access point (AP) of a wireless network is proposed that comprises: a communication interface configured to receive, from a non-AP station of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to a data traffic, and a Layer-3 service configured to mark, responsive to the receiving, a Layer-3 packet of the data traffic with a Congestion Experienced (CE) codepoint.

[0020] Also, a non- access point (non-AP) station of a wireless network comprises: a Medium Access Control (MAC) service configured to detect congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a data traffic, and a communication interface configured to transmit, to an AP of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to the data traffic.

[0021] “Layer-2 indication” is meant to designate any way at Layer 2 to provide the indication. Layer 2 typically designates the MAC (Medium Access Control) layer.

[0022] The Layer-3 packet (typically an IP packet, handled as an MSDU at MAC level) is therefore marked according to the ECN and L4S mechanisms. The rest of the mechanisms can be performed in a conventional way. In particular, the marked Layer-3 packet can be transmitted in an IP network, by the AP operating as an IP router. As a result, it can be reported that the MAC frame (MPDU) was congested in the non-AP station’s MAC queue.

[0023] It turns out that congestion control and reporting is ensured for uplink traffic (i.e., upstream), even when the congestion occurs in a MAC queue (Classic or L4S queue) of the wireless non-AP station. Although the Layer-2 congestion indication can be provided in a report solicited by the AP (e.g., a buffer status report in response to a polling BSRP frame), preferred embodiments provide that the Layer-3 packet of the data traffic is a Layer-3 packet of the received Layer-2 frame. In other words, the congestion marking is made in the frames carrying the data traffic experiencing the congestion.

[0024] In some embodiments, the Layer-2 congestion indication is included in a MAC header of the Layer-2 frame.

[0025] In some embodiments, the non-AP station includes MAC queues to which respective data traffics are assigned, detects congestion in one of its MAC queues, and marks one or more Layer- 2 frames of the data traffic assigned to the congested MAC queue with a Layer-2 congestion indication. This is to notify the AP about the congestion at MAC level. Indeed, the frames in the transmit queue of the non-AP station are dedicated to transmission to the AP.

[0026] In some embodiments, the CE codepoint is signalled in an Explicit Congestion Notification (ECN) field according to the ECN protocol.

[0027] In some embodiments, the AP is embedded in an IP router of a wired network.

[0028] In some embodiments, the method at the AP further comprises reporting, to Layer 3, the Layer-2 congestion indication and a Layer-3 packet of the received Layer-2 frame, wherein the marking step is responsive to the reporting. A Medium Access Control (MAC) service can therefore be configured to report, to Layer 3, the Layer-2 congestion indication and a Layer-3 packet (MSDU) of the received Layer-2 frame (MPDU).

[0029] In particular embodiments, reporting the Layer-2 congestion indication to Layer 3 includes providing, by a MAC service of the AP, the Layer-2 congestion indication in a MA- UNITDATA. indication primitive. The “MAC service” refers to the functions implemented at MAC level, i.e., handling MAC (or Layer 2) data or frames such as MPDUs. The primitives are those functions linking a (sub-)layer to a higher (sub-)layer. The mentioned primitive may belong to a MAC interface to the upper LLC (Logical Link Control) layer. The MA-UNITDATA. indication primitive may request transfer of the Layer-3 packet to an upper layer, further to providing the Layer-2 congestion indication. The Layer-3 packet may be first transferred in an LLC protocol data unit (PDU) to the LLC layer (as the above primitive belongs to a MAC interface to the LLC layer), and then be transferred by the LLC layer to the network layer (Layer 3).

[0030] Furthermore, the disclosure proposes a method of reporting congestion, comprising, in a communication device: reporting, to Layer 3 and using a MAC service primitive, a congestion indication indicating congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames (e.g. MAC protocol service data units or MPDUs) of a first flow of data traffic (e.g., Classic or L4S).

[0031] Correspondingly, a communication device is proposed that comprises a Medium Access Control (MAC) service configured to report, to Layer 3 and using a MAC service primitive, a congestion indication indicating congestion in a local transmit MAC queue storing MAC frames of a first flow of data traffic (e.g., Classic or L4S).

[0032] A “local” queue is a queue belonging to the communication device. Layer 3 (or Network layer) may of course be the IP layer.

[0033] The proposed method provides a local (to the communication device) management of congestion control, without involving the destination device. This is achieved by the Layer2(MAC)- to-Layer3 reporting.

[0034] In some embodiments, the method comprises, at the communication device, a step of detecting congestion in the local transmit MAC queue storing MAC frames of the first flow of data traffic, wherein the reporting is responsive to the detection.

[0035] In some embodiments, the communication device is a non-access point station. In that case, the proposed method enhances the congestion control of uplink transmissions.

[0036] In alternative embodiments dedicated to the downlink transmissions, the communication device is an access point (AP) managing a wireless network.

[0037] In some embodiments, the communication device may mark a Layer-3 packet or a Layer- 4 segment belonging to a flow that is reverse to the first flow, with a congestion indication. In case the communication device is the AP, it may be done before transmitting the packet typically to a wireless non-AP station. In case the communication device is a non-AP station, it may be done for the upper layer to keep a conventional processing of the Layer-3 (e.g., ECN field in the IP header) or Layer-4 (e.g., ECE flag in the TCP header) marking if the non-AP station is the L4S sender, or to pass the information upstream the end-to-end communication path earlier than in the known techniques.

[0038] In some embodiments, a TCP service in the communication device adjusts a transmission rate of the data traffic responsive to the congestion indication reported to Layer 3. This particularly applies to a communication device being a non-AP station generating data (e.g., video data from a security camera). The “TCP service” refers to the functions implemented at TCP level, i.e., handling TCP (or Layer 4) data or segments.

[0039] In some embodiments, reporting the congestion indication to Layer 3 includes providing, by a MAC service of the communication device, the congestion indication in a MA- UNITDATA. indication primitive or a MA-UNITDATA-STATUS. indication primitive of a MAC sublayer of the MAC service, or in a primitive of a MAC layer management entity (MLME) of the MAC service. The “MAC service” refers to the functions implemented at MAC level, i.e., handling MAC (or Layer 2) data or frames (MPDUs). The MAC service or layer consists of two major functional entities: the MAC sublayer and the MAC layer management entity (MLME), each of which has its own primitives. The primitives are those functions linking a (sub-)layer to a higher (sub-)layer. The above-mentioned primitives may belong to a MAC interface to the upper LLC (Logical Link Control) layer. In particular embodiments, the MA-UNITDATA. indication primitive includes a field set to an Explicit Congestion Notification (ECN) codepoint. A CE codepoint in that field of the primitive for instance reports congestion.

[0040] In particular embodiments, the MA-UNITDATA-STATUS. indication primitive includes a field set to an Explicit Congestion Notification (ECN) codepoint and / or a Congestion Experienced (CE) bit (or flag, e.g. set like the ECN-Echo (ECE) bit). For instance, a CE codepoint in the ECN field of the primitive reports congestion. A CE bit / flag enabled also reports congestion.

[0041] The above fields in the primitives may be additional to any flag reporting a L4S flow and / or any identifier specifying a flow (e.g., a L4S identifier or a SCS identifier).

[0042] In particular embodiments, the MA-UNITDATA-STATUS. indication primitive is reported periodically. This allows a congestion status (whether or not congestion occurs) to be reported on a periodic basis.

[0043] In some embodiments, the method further comprises receiving a MAC frame of a reverse (or ‘return’) flow of the data traffic in a reverse direction to the first flow, wherein the congestion indication is reported together with a Layer-3 packet of the received MAC frame using the MA- UNITDATA. indication primitive. Indeed, the MA-UNITDATA. indication primitive may be invoked upon receiving a MAC frame to request its transfer to an upper layer. The two flows correspond to the same data traffic; they are linked and established between the same devices but in opposite directions. The data traffic has a first flow from a source (traffic sender) to a destination (traffic receiver), and the reverse traffic from the destination to the source. The data traffic may rely on a TCP connection established between the source and the destination.

[0044] The Layer-3 packet may be first transferred in an LLC protocol data unit (PDU) to the LLC layer (as the above primitive belongs to a MAC interface to the LLC layer), and then transferred by the LLC layer to the Network layer (Layer 3).

[0045] In this context, the disclosure also proposes a communication device having a Medium Access Control (MAC) service, wherein the MAC service is configured to communicate with an upper layer using a primitive that includes an Explicit Congestion Notification (ECN) codepoint to report congestion and / or a MA-UNITDATA-STATUS. indication primitive that includes an ECN- Echo (ECE) bit to report congestion. The upper layer may be an LLC layer or Layer 3.

[0046] Correspondingly, a communication method in a communication device having a Medium Access Control (MAC) service is proposed, wherein the MAC service communicates with an upper layer using a primitive that includes an Explicit Congestion Notification (ECN) codepoint to report congestion and / or a MA-UNITDATA-STATUS. indication primitive that includes an ECN- Echo (ECE) bit to report congestion.

[0047] Given the conventional use of the primitives, the reported congestion concerns the data traffic of the MSDU transferred by the primitive. Thanks to the reporting (possibly via the LLC layer), a TCP service in the communication device can adjust a transmission rate of transmitted data traffic responsive to the reported congestion. In this context, the used primitive may request transfer of a Layer-3 packet to an upper layer, wherein the Layer-3 packet belongs to a data traffic experiencing congestion in a transmit MAC queue local to the communication device.

[0048] In some embodiments, the transferred Layer-3 packet is a received MAC service data units (MSDU) of a reverse (or ‘return’) flow of the data traffic in a reverse direction to a first flow of MSDUs transmitted through the local MAC queue.

[0049] For example, the two flows may be two flows marked as Low-Latency, Low-Loss, Scalable Throughput (L4S) flows that are in opposite directions. Hence, the communication device only has to provide the congestion information with the return L4S flow, to the upper layer.

[0050] In some embodiments, the used primitive includes both an ECN codepoint and an ECE bit.

[0051] In some embodiments, the primitive that includes the ECN codepoint is a MA- UNITDATA. indication primitive or a MA-UNITDATA-STATUS. indication primitive of a MAC sublayer of the MAC service or a primitive of a MAC layer management entity (MLME) of the MAC service.

[0052] In some embodiments, the communication device is a non-access point station of a wireless network.

[0053] Furthermore, the disclosure proposes a method of reporting congestion, comprising, in a network equipment: detecting congestion affecting a first flow of data traffic (e.g., Classic or L4S) established from a traffic sender to a traffic receiver, and responsive to the detection, marking a reverse (or ‘return’) flow of the data traffic in a reverse direction to the first flow, with a congestion indication.

[0054] The network equipment is an intermediary device between the traffic sender and the traffic receiver, i.e., it is distinct from them.

[0055] Correspondingly, a network equipment is proposed that comprises: a congestion unit configured to detect congestion affecting a first flow of data traffic established from a traffic sender to a traffic receiver, and a marking unit configured to mark, responsive to the detection, a reverse flow of the data traffic in a reverse direction to the first flow, with a congestion indication.

[0056] The two flows correspond to the same data traffic; they are linked and established between the same devices but in opposite directions. The data traffic has a first flow from the source (traffic sender) to the destination (traffic receiver), and a second and reverse traffic from the destination to the source. The data traffic may rely on a TCP connection established between the source and the destination.

[0057] The proposed method therefore intercepts the packets in the reverse direction to those experiencing the congestion, in order to signal the congestion directly in those packets in the reverse direction instead of conveying such indication in the affected flow to the destination. As a consequence, the source receives the congestion indication earlier, compared to known techniques, resulting in an improved responsiveness of the source to adapt its transmission rate.

[0058] In some embodiments, marking the reverse flow includes marking one or more pure acknowledgments acknowledging reception of the first flow (usually reception of Layer-4 - e.g., TCP - segments). A “pure acknowledgment” is meant to designate a message - such as a TCP segment - which is only an acknowledgement, i.e. has no payload or actual data.

[0059] In some embodiments, marking the reverse traffic includes setting an Explicit Congestion Notification (ECN)-Echo (ECE) bit in the header of a TCP segment forming the reverse flow. In particular, it may be in the header of a TCP pure ack.

[0060] In alternative embodiments, marking the reverse traffic includes setting an Explicit Congestion Notification (ECN) field to a congestion indication value, in a header of a Layer-3 packet, typically an IP packet.

[0061] In particular embodiments, the ECN field is made of two bits, and setting the ECN field to a congestion indication value includes setting the second bit to 1 . As a result, the ECN field is set to the ECT(1) codepoint when original ECN value was 00 (Non-ECN codepoint), or set to the CE codepoint when original ECN value was 10 (ECN(O) codepoint).

[0062] In particular embodiments, the Layer-3 packet includes a pure acknowledgment acknowledging reception of the data traffic. This configuration takes advantage of the fact that the ECN field is meaningless for acknowledgments, to use it to convey the congestion indication. No additional signalling bits are therefore required.

[0063] In other alternative embodiments, marking the reverse traffic includes reporting, from Layer 3 to Layer 2, a congestion indication, and marking a MAC frame (e.g. MAC protocol data unit - MPDU) forming the reverse flow with the congestion indication.

[0064] In particular embodiments, reporting the congestion indication to Layer 2 includes providing, to a MAC service of the network equipment, the congestion indication in a MA- UNITDATA. Request primitive. The “MAC service” refers to the functions implemented at MAC level, i.e., handling MAC (or Layer 2) data or frames or MSDUs. The primitives are those functions linking a (sub-)layer to a higher (sub-)layer.

[0065] In some embodiments, the network equipment does not modify a Congestion Experienced (CE) codepoint of the packets of the affected first flow. This avoids risks that the congestion indication reaches the traffic receiverand are echoed by the latter to provide additional congestion control to the traffic sender, in which case the latter could further reduce the transmission rate at the source, although it is the same congestion event that is reported.

[0066] Although the traffic sender should not react to multiple congestion indications within the same time window (more or less a theoretical round-trip time), there exist some scenarios where the round-trip time may substantially degrade, such as when there is a wireless section in the transmission path. In these scenarios, it is highly beneficial to avoid the traffic receiver to keep control on the congestion in case congestion indication is already provided in the return flow. In alternative embodiments, responsive to detecting the congestion, the network equipment modifies a Congestion Experienced (CE) codepoint of the packets of the affected first flow into non-CE codepoints (e.g. ECT(1) or ECT(O)). This avoids modifying conventional processing. As mentioned above, a time window at the traffic sender to discard successive congestion indications may protect the system against undesired multiple transmission rate adjustments resulting from the same congestion event.

[0067] In some embodiments, the network equipment includes an access point (AP) managing a wireless network.

[0068] In particular embodiments, detecting congestion at the network equipment includes receiving a MAC frame marked with a Layer-2 congestion indication, from a non-AP station of the wireless network.

[0069] In alternative embodiments, detecting congestion at the network equipment includes detecting congestion in one queue of the network equipment.

[0070] In some embodiments, packets in the reverse direction are identified as belonging to the reverse flow, based on: a source IP address, a destination IP address, a source port and a destination port that are inverted compared to packets of the first flow, a Stream Classification Service (SCS) description of one stream in a pair of SCS downlink stream and SCS uplink stream set up with a client station - typically a non-access point (AP) station in a wireless network - wherein the other stream of the pair corresponds to the first flow.

[0071] In particular, the one stream is a downlink stream. That means the first flow is an uplink stream from the client station (non-AP station) to the network equipment (AP).

[0072] Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above.

[0073] Another aspect of the disclosure relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as defined above.

[0074] At least parts of the methods according to the disclosure may be computer implemented. Accordingly, it may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, it may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0075] Since the proposed mechanisms can be implemented in software, they can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal.

[0076] BRIEF DESCRIPTION OF THE DRAWINGS

[0077] Some embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

[0078] Figure 1 illustrates a typical wireless communication system in which embodiments of the disclosure may be implemented;

[0079] Figure 2A illustrates an exemplary partial OSI-layered architecture for a communication device;

[0080] Figure 2B illustrates the L4S mechanism at transmit queue level;

[0081] Figure 2C illustrates the 13thand 14thbytes of a TCP segment header;

[0082] Figure 2D illustrates an overall operation of the L4S mechanism, in each network node on an exemplary network path in between an L4S sender and an L4S receiver;

[0083] Figure 3 illustrates an overall operation of the L4S mechanism as enhanced by the IEEE (RTM) 802.11-24 / 0384r3 contribution;

[0084] Figure 4A illustrates, using a flowchart, general steps of a communication method involving MAC-level congestion notification for ECN signalling for uplink / upstream traffic, according to the first embodiments;

[0085] Figure 4B illustrates an exemplary wireless-wired communication system in which the notification scheme according to the first embodiments is implemented for uplink / upstream flow;

[0086] Figure 5A illustrates, using a flowchart, steps of a communication method involving enhanced ECN notification according to the second embodiments;

[0087] Figure 5B illustrates an exemplary wireless-wired communication system in which the notification scheme according to the second embodiments is implemented for uplink / upstream or downlink / downstream traffic;

[0088] Figure 6A illustrates, using a flowchart, steps of a communication method involving an enhanced congestion notification locally managed, according to the third embodiments;

[0089] Figure 6B illustrates an exemplary wireless-wired communication system in which the local notification scheme according to the third embodiments is implemented;

[0090] Figure 7 illustrates exemplary modifications of a MAC interface proposed to LLC layer;

[0091] Figure 8A shows a schematic representation of a communication device; and

[0092] Figure 8B illustrates schematically the architecture of the communication device of Figure 8A.

[0093] DETAILED DESCRIPTION

[0094] The invention will now be described by means of specific non-limiting exemplary embodiments and by reference to the figures. The management and reporting of congestion in hybrid networks subject to congestion at MAC level requires adaptation of the L4S mechanism. Regarding uplink traffic, an AP receives a MAC frame marked with MAC congestion indication, reports to IP layer, the indication and the IP packet of the received frame, and responsive to the reporting, marks the packet with a CE codepoint. To speed up congestion reporting, a communication device detects congestion in a local transmit MAC queue storing MAC frames of a first flow of data traffic, and responsive to the detection, reports, to IP layer, a MAC congestion indication using a MAC service primitive. In particular, a communication device has a MAC service configured to communicate with an upper layer using a primitive that includes an ECN codepoint to report congestion and / or a MA- UNITDATA-STATUS. indication primitive that includes an ECE bit to report congestion. Finally, a network equipment detects congestion affecting a first flow of data traffic, and responsive to the detection, marks a reverse flow of the data traffic in a reverse direction to the first flow, with a congestion indication.

[0095] Exemplary communication devices experiencing congestion at MAC level include wireless devices, such as 802.11 devices.

[0096] The WLAN (Wireless Local Area Network) technology based on the IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 family standards provides a very simple distributed channel access mechanism. Distributed channel access means that a wireless device, in IEEE 802.11 terminology known as a station (STA), either access point (AP) or a non-access point (non-AP), tries to access an operating channel when it has data to send, usually using contention schemes on a so-called primary channel.

[0097] In such wireless networks, the AP that manages the set of wireless non-AP stations (registered to it or associated with it) that together organize their accesses to the wireless medium for communication purposes. The STAs (including the AP to which they register) form a service set, also referred to as basic service set, BSS (although other terminology can be used).

[0098] Often, the AP interfaces the non-AP stations to other networks, such as the Internet, e.g. through wired networks. For example, the AP operates as an IP router of IP traffic.

[0099] An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC”), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (“BSC”), Base Transceiver Station (“BTS”), Base Station (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base Station (“RBS”), or some other terminology.

[0100] A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a non-AP STA may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (“SIP”) phone, a wireless local loop (“WLL”) station, a personal digital assistant (“PDA”), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

[0101] Figure 1 illustrates a communication system 100 in which several communication devices or stations (or “nodes”) 101-107 exchange data frames over a radio transmission channel 100 of a wireless local area network (WLAN), under the management of a central station, or access point (AP) 1 10, also seen as a station of the network. The radio transmission channel 100 is defined by an operating frequency band constituted by a single channel or a plurality of channels (usually each of 20MHz width) forming a composite or operating channel. Below the “medium” or “wireless medium” is considered synonymous with the radio transmission or composite or operating channel.

[0102] The STAs may be affiliated stations of multi-link devices (MLD) as defined in the IEEE P802.11 be-2024 standard (known in the industry as Wi-Fi 7), and / or stations implementing multiuser transmission features as defined in the IEEE 802.11 ax standard (known in the industry as Wi-Fi 6), and / or stations implementing any previous version of the 802.1 1 standard.

[0103] Access to the shared radio medium to send data frames is managed by the Layer 2, usually the Medium Access Control layer, in short “MAC”. The medium access is primarily based on the CSMA / CA technique, for sensing the carrier and avoiding collision by separating concurrent transmissions in space and time. Carrier sensing in CSMA / CA is performed by both physical and virtual mechanisms. Virtual carrier sensing is achieved by transmitting control frames to reserve the medium prior to transmission of data frames.

[0104] Next, a source or transmitting station, including the AP, first attempts through the physical mechanism, to sense a medium that has been idle for at least one interframe time period known as DIFS (standing for DCF InterFrame Spacing), before transmitting data frames. However, if it is sensed that the shared radio medium is busy during the interframe period, the source station continues to wait until the radio medium becomes idle.

[0105] Once the radio medium is idle, the station performs a random backoff countdown until when the backoff reaches 0, in which case it transmits over the medium and obtains the medium for a duration (specified in the transmitted frame) known as transmission opportunity or “TXOP.

[0106] Two directions of communication are defined: “downlink” for traffic from the AP to the non-AP STAs and “uplink” for traffic from any non-AP STA to the AP.

[0107] The AP bridges traffic inside the BSS: the non-AP STAs of the BSS first communicate with the AP only (uplink traffic), which is in charge of relaying the received data frames to another non-AP STA of the BSS should the data frames be targeting this non-AP STA (downlink traffic). The AP also bridges downstream traffic or data flow, from other networks (e.g., wired networks) to the BSS: the AP operates as a router, receives traffic from other networks and is in charge of relaying the received data frames to the non-AP STAs of the BSS should the data frames be targeting its non-AP STAs. Those data frames form downlink traffic in the BSS.

[0108] Reversely, the AP bridges upstream traffic or data flow, from non-AP STAs of the BSS to other networks (e.g., wired networks): the non-AP STAs of the BSS first communicate with the AP only, which is in charge of relaying the received data frames to other networks - hence operating as a router - should the data frames be addressed to devices of the other networks. Those data frames form uplink traffic in the BSS.

[0109] Management of quality of service (QoS) has been introduced at station level in the wireless networks, through well-known EDCA mechanism defined in the IEEE 802.1 1 e standard (Enhanced Distributed Channel Access). EDCA enhances or extends the functionality of the original DCF scheme.

[0110] EDCA adds four independent enhanced distributed channel access functions (EDCAFs) to provide differentiated priorities to transmitted traffic, through the use of four different access categories (ACs), each having its own transmit queue. The four ACs are the following in decreasing priority order: voice (or “AC_VO”), video (or “AC_VI”), best effort (or “AC_BE”) and background (or“AC_BK”). In embodiments, QoS may be extended to support a different - higher - number of access categories.

[0111] A mapping of UP (user priorities specified in the MAC service data units or MSDUs, which are the packets from the upper layer, e.g. IP packets) to the transmit queue and the mapping to AC is well-known and not reproduced here for brevity.

[0112] A backoff procedure is invoked by each EDCAF (i.e., independently for each AC) to gain access to the medium for the associated AC, i.e. to transmit data or MAC frames comprising the MSDUs stored in the corresponding transmit queue. The ACs within the same STA thus compete one with each other (using their EDCAF) to access the wireless medium and to obtain a TXOP.

[0113] Prioritization between the ACs is obtained by different arbitration interframe space or AIFS values for the four ACs, which AIFS value is used in replacement of the single deferring (DIFS) period before decrementing the associated backoff counter. For example, AC_VO has the highest priority and as such has the lowest AIFS

[0114] The other EDCA parameters specific to each AC (e.g., the contention windows) also contribute to prioritization of the ACs (hence QoS). For instance, the use of lower AIFSN values, additional to the use of an on-average lower CW for high priority ACs compared to low priority ACs makes that traffic of a high priority AC has a higher chance to be transmitted than traffic from a low priority AC: a STA having high priority AC traffic statistically waits less, on average, to be granted a TXOP and then send its packet than a STA having low priority AC traffic.

[0115] That is said, EDCA gives priority to traffics with higher priority over traffics with lower priority; but competition between different competing 802.11 devices and within the same 802.11 device still lead to congestion at MAC level, especially in dense wireless networks. To increase bandwidth and decrease latency requirements, multi-user (MU) schemes have been developed through the IEEE 802.11 ax standard that allows the AP managing the BSS to schedule MU transmissions, i.e., multiple simultaneous transmissions to non-AP stations (for downlink traffic - known as MU DL transmissions) or from non-AP stations (for uplink traffic - known as MU UL transmissions) triggered by the AP using a Trigger frame. The Trigger Frame allocates resource units to the non-AP stations of the same BSS, using Association IDentifiers (AIDs) assigned to them upon registration to the AP and / or using reserved AIDs designating a group of non-AP stations. The TF also defines the start of the MU UL transmission by the non- AP stations as well as the length thereof. After a non-AP station has performed MU UL transmissions, it performs medium access using EDCA contention with, at least temporarily, a different (from the legacy ones) set of EDCA parameters, known as MU EDCA parameters (defined in a Multi-User (MU) EDCA Parameter Set provided by the AP).

[0116] The MU schemes do not remove the risks of contention at MAC level. It still appears that the AP’s scheduling is poor (and also the granularity remains at AC level, that does not support to trigger a specific low latency traffic).

[0117] Recently-created IEEE 802.11 bn Task group works on ultra-reliable low-latency communication (URLLC) requirements, focusing on some aspects such as tail latency and jitter, and high priority access for latency-sensitive applications. Applications with data having tight latency requirements include high-definition video, advanced telemedicine, ultra-low latency gaming, AR / VR (augmented / virtual reality) data, and so on.

[0118] Time-Sensitive Networking (TSN) is another exemplary targeted extension of 802.11 / WiFi communications with deterministic elements and time-sensitive capabilities. TSN enables reliable and timely communication over networks by providing a suite of mechanisms and protocols that enable networked devices to exchange critical data with very low latency and high reliability.

[0119] IEEE 802.11 bn is therefore investigating new QoS mechanisms, including the L4S mechanism as introduced in RFC 9330 “Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture”.

[0120] L4S seeks to improve end-to-end network performance by addressing queuing delay, the single largest and most frequently overlooked cause of latency and latency variation, reducing it to near-zero values. By using congestion packet marking instead of packet delaying and dropping for controlling application data rates, L4S offers an unrivalled experience responsiveness with low delay and packet loss.

[0121] The most dominant source of latency is network queuing delay.

[0122] L4S requires two parts to work: 1) the senders and receivers must implement L4S- capable congestion control; and 2) L4S AQMs (Active Queue Management generally refers to techniques for controlling the filling levels and delays of queues) and isolation mechanisms are deployed in the bottleneck node(s) on the end-to-end path within the network. L4S defines new rules for the Internet congestion controls. It therefore operates at Layer 3 level, in particular at the IP (Internet Protocol) level. Figure 2A recalls various layers that are implemented in communication devices. Data Link layer 2, referenced 200, interfaces with the PHY layer (not shown) to provide medium access. In wireless devices, it comprises for instance a MAC sublayer 202, an LLC (Logical Link Control) sublayer 204 above sublayer 202, and a MAC layer Management Entity MLME 206. Each of these sublayers has dedicated service access points (SAP) that are used as interfaces between them and / or with other (upper or lower) layers. SAPs usually implement so-called primitives that are standardized functions to allow layers to communicate one with the other. For instance, a primitive can be a Request to indicate a request to initiate a service, an Indication to signal some occurred event, or of other types (Response, Confirm, and so on.).

[0123] For example, the MSAP (MAC SAP) interfaces the MAC sublayer 202 with the LLC sublayer 204. The LSAP (LLC SAP) interfaces the LLC sublayer 204 with the upper layer, Layer 3. The PSAP (PHY SAP) interfaces the MAC sublayer 202 with the PHY layer. Network layer 3, referenced 210, is typically the IP layer to route protocol data units or packets from one network node to the other. Transport layer 4, referenced 220, is for example the TCP layer to convey a data flow from the sender to the receiver. Layer 4 provides end-to-end communication services, such as flow control.

[0124] The congestion-control algorithm leveraged by L4S is called “TCP Prague congestion control”, a so-called “scalable” congestion-control algorithm that uses packet marking and partly operates at Layer 3 and partly at Layer 4. It derives from the Explicit Congestion Notification (ECN) scheme defined in RFC3168, that is an extension of IP and TCP to provide end-to-end notification of network congestion without dropping packets.

[0125] Without this algorithm, congestion indication echo is achieved indirectly by the detection of lost packets. With the algorithm, the congestion is indicated by setting a so-called Explicit Congestion Notification (ECN) field within an IP packet to CE (Congestion Experienced) value and is echoed back by the receiver to the sender by setting proper bits in the header of the transport protocol. For example, when using TCP, the congestion indication is echoed back by setting the ECE bit in the header of TCP segments. In other words, packets are “marked” instead of dropped to signal congestion to the sender.

[0126] The L4S mechanism uses the two least significant (right-most) bits of the Traffic Class field in the IP header of the packets to encode four different codepoints. These two bits are known as the ECN field or bits.

[0127] Value 00 signals a Not ECN-Capable Transport, Not-ECT, packet.

[0128] Value 10 signals an ECN Capable Transport(O), ECT(0), packet.

[0129] Value 01 signals an ECN Capable Transport(l), ECT(1), packet that belongs to a L4S data flow. In otherwords, values 10 (ECT(0)) and 01 (ECT(1)) allows to discriminate between the ECN Capable Classic data flows and the ECN Capable L4S data flows.

[0130] Value 11 signals a Congestion Experienced, CE, packet. When both endpoints support ECN they mark their packets with ECT(O) (Classic data) or ECT(1) (L4S data). Routers use the ECT(O) and ECT(1) codepoints to handle differently the Classic packets and the L4S packets, in particular to ensure low latency transmission for the L4S packets. For example, as illustrated by Figure 2B, the incoming L4S traffic is placed in one L4S- dedicated transmit queue (250, also called “shallow” queue), while the incoming classic traffic is placed in the other transmit queue (260, “classic” or deep queue). Thus, L4S device (e.g. network node) classifies packets based on the ECN field in the IP headers :

[0131] ECT(1) (possibly with CE into) to the low latency L4S transmit queue, non-ECN and ECT(O) to the Classic transmit queue.

[0132] The L4S-dedicated transmit queue is scheduled with priority over the Classic transmit queue, even if priority is managed to prevent starvation of Classic traffic. This role is performed by the active queue management, AQM, mechanism.

[0133] Of course, other L4S tagging element may be used instead of the ECN field to allow the classifier to sort the incoming traffic into each of the two transmit queues correctly. The two transmit queues of Figure 2B are active queue management (AQM) queues and can be provided for one or more or all ACs (i.e., within one or more or all EDCAFs).

[0134] If the packet traverses a transmit queue that is experiencing congestion and the corresponding router supports ECN, it may change the codepoint (ECT(O) or ECT(1)) to CE instead of dropping the packet. This act is referred to as "marking" and its purpose is to inform the receiving endpoint of impending congestion. At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol such as TCP) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate.

[0135] TCP supports ECN using two flags in the TCP header. The first, ECN-Echo (ECE) is used to echo back the congestion indication indicated through the ECN field set to CE in the received packets. Upon receiving such ECE bit set to 1 , the sender reduces the transmission rate of the concerned data flow. The second, Congestion Window Reduced (CWR), is used by the sender to acknowledge that the congestion-indication echoing has been received. The receiver keeps transmitting TCP segments with the ECE bit set until it receives a segment with the CWR bit set.

[0136] Figure 2C illustrates the 13thand 14thbytes of a TCP segment header, wherein the CWR bit is the first bit (MSB) of the 14thbyte and the ECE bit is the next bit. As defined in RFC3168, a TCP Client indicates that it supports Classic ECN feedback by setting (CWR, ECE) = (1 ,1) in the TCP SYN packet, and an ECN-enabled TCP Server confirms Classic ECN support by setting (CWR, ECE) = (0,1) in the TCP SYN / ACK packet. On reception of a CE-marked packet at the IP layer, the Data Receiver for that half-connection starts to set the Echo Congestion Experienced (ECE) flag continuously in the TCP header of ACKs, which gives the signal resilience to loss or reordering of ACKs. The Data Sender for the same half-connection confirms that it has received at least one ECE signal by responding with the congestion window reduced (CWR) flag, which allows the Data Receiver to stop repeating the ECN-Echo flag. This always leads to a full RTT of ACKs with ECE set. Figure 2D illustrates the overall operation of the L4S mechanism, in each network node on an exemplary network path 20 in between an L4S sender 21 and an L4S receiver 22. It is expected that more and more network nodes in the Internet will implement L4S, and notably its dual queue, in order to reduce queuing delay to achieve improved end-to-end latency.

[0137] ECN is negotiated on a TCP connection for a given data flow. The L4S sender indicates that IP packets that carry TCP segments of that connection / flow are carrying L4S traffic from an ECN Capable Transport by marking them with the ECT(1) codepoint 23. The TCP segments carrying Classic traffic from an ECN Capable Transport are marked with the ECT(O) codepoint (not shown).

[0138] The network nodes or intermediate routers 24 (the illustrated network path 20 shows three routers 24, while there may be any other number of them) that support ECN mark those IP packets with the CE codepoint instead of dropping them when they detect local early-approaching congestion; otherwise they keep the ECT(1) codepoint. For example, the first IP router 24 does not experience any congestion, hence the codepoint of the L4S IP packets it routes remains as ECT(1). On the other hand, the second IP router 24 detects local congestion - hence it is a bottleneck node - in which case the codepoint of the L4S IP packets is changed into CE. The codepoints are propagated along the network path 20 up to the L4S receiver 22.

[0139] Upon receiving an IP packet with the CE codepoint, the L4S receiver echoes back this congestion indication using the ECE flag in the TCP header of the TCP segments in the reverse / return path of the connection. The return path conveys the return flow from the L4S receiver to the L4S sender, typically acknowledgments (‘ack’). Reference 26 illustrates the processing of the CE codepoint at Layer 3 level (IP) to generate the ECE marking at Layer 4 level (TCP). Arrow 27 illustrates the echoing feedback through the ECE marking.

[0140] When the L4S sender 21 receives a TCP segment with the ECE bit, it reduces its congestion window - hence transmission rate - as it was a packet drop. The L4S sender then acknowledges the congestion indication by sending back a segment with the CWR bit set, to the L4S receiver.

[0141] The L4S mechanism sounds to efficiently reduce queuing delay on wired network portions, where the main source of latency and jitter is Layer 3. It is however not a fully efficient solution when the network path includes wireless sections because Layer 2 of wireless networks, such as the 802.11 / Wi-Fi MAC layer, remains a significant source of latency and jitter, for instance by introducing delays, especially when the number of connected devices increases.

[0142] This situation has been addressed in the IEEE (RTM) 802.11-24 / 0384r3 contribution (entitled “Low Latency based on L4S”), as illustrated by Figure 3. The contribution proposes to extend the ECN signal of L4S to the MAC layer for downlink traffic regardless of which AQM used, that is to say for traffic coming from the Internet and delivered downlink to the wireless network by an AP (e.g. hosted in an internet router) towards an end-user client (that is a non-AP station).

[0143] In the scenario, the exemplary network path 30 includes a wired section 30a (like in Figure 2D) and a wireless section 30b, e.g. formed by an 802.1 1 BSS. The wired section 30a is composed of the L4S sender 21 and at least one network node or intermediate router 24, implementing L4S. The wireless section 30b is composed of an L4S AP 34, acting as the network node (or router) providing connection to the Internet and administrating a wireless BSS, and an L4S receiver 32 that is a non-AP station of the BSS.

[0144] The contribution aims to address the reporting of any congestion encountered at the MAC of the AP to deliver traffic to its BSS. Typically, the AP sees its queues growing up and being close to be congested due to various wireless factors (dense population of wireless devices that provides collisions, OBSS traffic, etc.).

[0145] When a congestion (MSDU queuing delay, and overflow) occurs (300) on the MAC layer of the AP 34, the AP reports (301) the ECN status via an 802.11 frame. Typically, this is performed in the (MAC) data frame transporting the MSDU packet, which frame is set with congestion flag in the MAC header (i.e., QoS field or A-control field). Alternatively, a dedicated frame (e.g., an action frame) can be used to report such congestion, while this solution is less efficient as bandwidth consuming. There is therefore no modification of the upper layer headers of the MSDU as the congestion notification can only be added in the MAC layer of the data frame.

[0146] At the non-AP STA (L4S receiver) 32, upon reception of the data frame marked with the congestion information, this congestion notification is reported to the above layerto finally mitigate the queuing delay, when congestion occurs in the MAC layer. This is done in two steps. First, when the MSDU comes from the MAC layer to the LLC layer (upper layer to the MAC), the congestion flag is added (302) in the MAC interface or MSAP (in particular in the so-called MA- UNITDATA. indication primitive) to report that the MSDU was congested in the AP MAC queue. Next, the upper layer (outside the 802.1 1 MAC, typically the IP layer) modifies (303) the ECN field of the IP header of the MSDU.

[0147] Then, it comes to the current L4S standard where the TCP layer at the L4S receiver 32 echoes (26) back the congestion indication using the ECE flag in the TCP header of the TCP segments in the reverse / return path of the TCP connection.

[0148] The L4S sender 21 can then adjust its TCP congestion window (i.e., lower sending rate) to mitigate queuing delay experienced by the AP at MAC level for its downlink traffic. As a result, it is clear than the CE notification at MAC layer follows the MSDU packet, to be finally reported to the upper layer at the L4S receiver 32.

[0149] This contribution addresses the congestion issues at the AP MAC queues, i.e., for downlink traffic, in particular with respect to L4S traffic. The congestion issues at the non-AP MAC queues, i.e., for uplink traffic, are not handled. There is a need to efficiently manage these situations of congestion at MAC level.

[0150] Furthermore, the wireless section 30b - as well as any other wireless section that may exist along the end-to-end communication path - may drastically increase the round time required by the L4S mechanism to notify back the sender about any impeding contention. As a result, the contention may be effective and may already degrade the latency of L4S traffics, when the sender becomes aware of it. There is a need to improve congestion reporting to the sender, in particular when occurring at MAC level.

[0151] Embodiments as described below overcome all or part of these deficiencies.

[0152] First embodiments of the disclosure, as illustrated through Figures 4A and 4B, deal with MAC-level congestion reporting in case of uplink traffic.

[0153] Figure 4A illustrates, using a flowchart, general steps of a communication method involving MAC-level congestion notification for ECN signalling for uplink / upstream traffic, according to the first embodiments.

[0154] Figure 4B illustrates an exemplary wireless-wired communication system in which the notification scheme according to the first embodiments is implemented for uplink / upstream flow.

[0155] The operations on the left side of Figure 4A take place in a wireless non-AP station that has data or MAC frames (MPDUs) to send over a wireless medium to an AP (hence it is uplink traffic for the wireless section 30b) connected to other networks towards a receiver, preferably L4S receiver 22. The AP is typically embedded in an IP router of a wired network. The wireless non-AP station may be the L4S sender 21 , or any intermediary network node that belongs to a wireless section within the end-to-end communication path from sender 21 to receiver 22. This is this wireless non-AP station that experiences congestion at MAC level, i.e., in one of its transmit queues at MAC level. As explained above with reference to Figure 2B, the wireless non-AP station may have a Classic transmit queue 260 and a L4S transmit queue 250, per AC. The MAC- level contention may occur in the L4S transmit queue 250. In these first embodiments, an 802.1 1 MAC frame of the uplink / upstream stream to be delivered towards the AP conveyed the marking of the congestion experienced at MAC level.

[0156] The operations on the right side of Figure 4A take place in the AP to which the non-AP station is associated and sends the data or MAC frames (MPDUs).

[0157] The process at the non-AP station starts at step 400 where it receives incoming data packets to be transmitted to the AP of its BSS.

[0158] In some embodiments where the non-AP station is sender 21 of a TCP session, the incoming data packets are received from upper layers.

[0159] In some embodiments where the non-AP station is an intermediary network wireless node, the incoming data packets are received from upstream network nodes.

[0160] At step 410, the received packets, or at least a portion of them, are encapsulated into data (or MAC) frames and then placed in a buffer (transmit) queue, where they will remain until they are forwarded or, in some cases, discarded.

[0161] The non-AP station may analyse the header of the received packets to determine prioritization based on predefined criteria.

[0162] The determination may be made by an ECN classifier or similar apparatus. As example, ECT(1) bit of the IP header is used to classify the incoming packet into the L4S transmit queue 250, whereas the other packets are directed to the Classic transmit queue 260. In embodiments, the non-AP station monitors uplink traffic and keeps a dynamic stream entry table for L4S streams.

[0163] In variants to having a L4S transmit queue and a Classic transmit queue (per AC or not), alternative architectures may rely on a single transmit queue (per AC or not) wherein the L4S packets are placed at the head queue position compared to the Classic packets, to take priority in the transmission process.

[0164] In some embodiments, additional parameters (or criteria) are derived to classify the incoming traffic, once identified by the L4S support bit in the ECN field.

[0165] In particular embodiments, the TCLAS information element (Traffic Classification, defined in IEEE Std 802.11 ™-2020) is considered since it contains a set of parameters to identify incoming packets with a particular traffic stream and is often linked to a particular TSPEC or QoS_Char (traffic specification or QoS characteristic information). IEEE Std 802.11 ™-2020 defines several capabilities that make use of TCLAS elements for packet classification, notably the Stream Classification Service (SCS) (subclause 11 .25.2) and TS operations (subclause 11 .4). For the time being, those parameters are usually used by a non-AP station to request the AP to apply rules to downlink traffic that, on transmission, assign a specified User Priority (UP) to frames containing IP packets that match the TCLAS element(s) classifier. This for instance allows to classify the incoming packets into a specific AC. Hence, the combination of the L4S support bit in the ECN field and the additional parameters allows the non-AP station to direct the incoming packets to the appropriate Classic or L4S transmit queue of the appropriate AC.

[0166] Alternatively, the classification may be based on DSCP marking (instead of TCLAS classifier-based rules), or creates an entry for each such stream (i.e., source IP, destination IP, source port, and destination port) with its L4S value.

[0167] Other alternatives may consist in Mirrored Stream Classification Service (MSCS) and Stream Classification Service (SCS) to learn the correct parameters (e.g. specifies a stream by its IP and port addresses as well as Transport Layer (layer-4) protocols (i.e., TCP, UDP)) of any given traffic stream with the assistance of the application at the non-AP station-side.

[0168] Those additional parameters therefore allow a specific data traffic to be identified, which may for instance correspond to a TCP connection between two TCP end points. The specific data traffic can be made of a first-way flow (e.g. from first end point to second end point) and a return flow in the reverse direction (i.e., from second end point to first end point). Information such as source IP, destination IP, source port, and destination port of step 410 allows to discriminate between the two flows of the same data traffic, as explained below with respect to step 430.

[0169] As a result of step 410, the non-AP station may assign and route an incoming packet (hence the corresponding data frame) to appropriate Access Categories (AC) and Traffic Identifications (TID) based on the prioritization. If dual queuing is established for each for the AC (e.g. comprising a deep buffer queue and a shallow buffer queue), the non-AP station may direct prioritized, low latency frames (L4S) to the shallow buffer queue 250; and standard network traffic frames with traditional latency requirements into the classic deep queue 260. If single queuing is established for each for the AC, the low latency frames (L4S) can be directed at the head queue positions compared to the standard network traffic frames.

[0170] At step 420, the non-AP station monitors whether its transmit queue or queues experience or are about to experience congestion, i.e., whether congestion at MAC level occurs.

[0171] In embodiments, the congestion-management step includes a queue measurement function that measures or derives one or more parameters from the traffic going through a specific transmit queue.

[0172] The parameters may include, for example and not by way of limitation, instantaneous queue length, average queue length, packet sojourn time, incoming traffic rate, outgoing traffic rate, instantaneous packet queue overflow, average queue overflow rate, and so on. Congestion may arise when the non-AP station does not gain TXOP in due time for a considered data traffic.

[0173] Of course, the same monitoring can be performed for each transmit queue. Alternatively, only the L4S transmit queue(s) are monitored for MAC-level congestion detection.

[0174] Alternatively, the congestion may be detected at the receiver, based for example on a frame from the sender or on delay bound violation (mirroring a number of failed retransmissions).

[0175] In case there is no congestion, the data frame comprising the incoming packet can be transmitted to the AP over the wireless medium. This is step 440.

[0176] Otherwise, a congestion indication is prepared at step 430, that is provided in association with the data traffic experiencing the congestion.

[0177] In some embodiments, the non-AP station may reply to a polling frame (e.g., BSRP frame) from the AP with buffer status reports that indicate the congestion of a specific transmit queue and / or of a specific data traffic (e.g., a L4S stream).

[0178] In preferred embodiments, the data frame embedding a packet of the concerned data traffic is marked at step 430 with a MAC-layer congestion indication. In other words, the non-AP station includes MAC queues to which respective traffics are assigned, detects congestion in one of its MAC queues, and marks one or more Layer-2 frames (e.g. a MAC frame known as MAC protocol data unit or MPDU) of the traffic assigned to the congested MAC queue with a Layer-2 congestion indication. The Layer-2 congestion indication may be included in a MAC header of the Layer-2 frame. For example, an ECN-like field may be signalled in the MAC header (using for example reserved bits in the current version of the standard), having the same values as defined above at the IP layer level: ‘11 ’ (CE) to signal contention, ‘01 ’ (ECT(1)) to signal ECN-capable L4S packets, ‘10’ (ECT(0)) to signal ECN-capable Classic packets, or ‘00’ (Non-ECT) to signal non ECN-capable packets.

[0179] Next, the marked data frame is transmitted to the AP at step 440. That is a Layer-2 frame marked with a Layer-2 congestion indication is transmitted to the AP.

[0180] That is, in some embodiments, incoming packets associated with L4S flows, on the one hand, are selectively ECN marked, and an AQM controls the number of receive packets that will be marked and forwarded toward their intended destination; whereas incoming packets associated with classic flows, on the other hand, are selectively dropped, and an AQM controls the number of receive packets that will be dropped ratherthan be forwarded toward their intended destination. Selectively dropping packets is done under certain traffic conditions to reduce or eliminate high latency and jitter that often occur when too many packets have been buffered at network nodes.

[0181] Turning now to the AP side, at step 450, the AP receives, from the non-AP station, incoming data frames at MAC level. As apparent from above, they may or not include the MAC- level (Layer 2) congestion indication in their MAC header or not. Therefore, at step 460, the AP may detect I determine whether a received data frame is marked with the MAC-level congestion indication. For example, if an ECN-like field is present in the MAC header, a MAC-level (Layer 2) congestion indication is detected in case the ECN-like field is CE (value 1 1).

[0182] In the negative, the packet (MSDU) of the data frame is reported to the upper layer, namely to the LLC layer 204 (see Figure 2A) and then to Layer 3 210 (IP layer), in a conventional way (not illustrated in the Figure).

[0183] Otherwise, the Layer-2 congestion indication and the packet (MSDU) of the received data frame are reported to upper layers (LLC layer and then Layer 3) at step 470. Such reporting is performed by the Medium Access Control (MAC) service, more precisely by the MSAP through e.g., the use of the MA-UNITDATA.indication primitive. Such MA-UNITDATA. indication primitive requests transfer of the received packet to the upper layer, and also provides the Layer-2 congestion indication.

[0184] It is recalled that the MAC sublayer 202 sends the MA-UNITDATA.indication to the LLC sublayer to transfer a data frame from the MAC layer to the LLC. This occurs only if the MAC has found that the data frame it receives from the Physical layer is valid and has no errors and the destination address indicates the correct MAC address of the station (non-AP station, or AP station acting as final destination or relay). In short, MA-UNITDATA.indication is passed from the MAC sublayer to the LLC sublayer to indicate the arrival of an MSDU.

[0185] The MA-UNITDATA.indication may be enhanced from its current definition in IEEE P802.11-REVme / D6.0 (June 2024), as follows:

[0186] The MA-UNITDATA.indication( source address, - MAC address of transmiter which transmits the frame destination address, - MAC address of destination routing information, data, - The MSDU to be transmited by the MAC reception status, priority, -- 802.11 User Priority (UP) 0 ... 7, used in TID field drop eligible, -- Boolean that indicates whether this MSDU can be discarded service class, - "QoSAck" or "QoSNoAck" station vector, - used to set transmit parameters on a per-MSDU basis

[0187] MSDU format, radio environment status vector -- information to configure the PPDU format, encoding, and MPDU handling for NGV transmission flow identifier

[0188] CE information

[0189] ) wherein ‘flow identifier’ is an optional identifier that gives a unique identifier of the concerned flow; and the CE information is made of a CE_flag (or any other name) and an ECN field. The CE_flag is set if a congestion has been experienced for the received MSDU (i.e., a MAC-level congestion indication is present in the received data frame). The ECN field is set to the MAC-level congestion indication of the received data frame (hence to the value of the ECN- like field of the MAC header). This is to report the experienced congestion.

[0190] Next, at step 480, responsive to the reporting of step 470 (hence to the receiving of step 450), the AP can mark the reported packet (MSDU) of the received data frame, with a Congestion Experienced (CE) codepoint. Preferably, the CE codepoint is signalled in an Explicit Congestion Notification (ECN) field according to the ECN protocol, i.e., in the IP header (the two least significant (right-most) bits of the Traffic Class field).

[0191] Next, at step 490, the AP is able to forward the reported and CE-marked packet to the next downstream portion of the communication end-to-end path, usually toward the Internet.

[0192] In that way, the 802.11 recipient (AP) of the marked data frame reports the MAC-level congestion notification back to its IP layer when routing the packet to the Internet.

[0193] Figure 4B illustrates a notification scheme according to the first embodiments.

[0194] The CE bit would be set by any router in the network route to indicate congestion to the end nodes.

[0195] The scenario 40 shows an upstream flow from L4S sender 41 in the wireless section 30b to L4S receiver 22 in the Internet. The non-AP station in the wireless section can notify the experienced congestion (400) by a specific MAC-level congestion indication (401) in the MAC frame delivered to the AP 44, acting as an IP router in the end-to-end communication path.

[0196] Upon receiving the marked MAC frame, the AP 44 reports the MAC marking with the IP packet (MSDU) to upper layers. When the MSDU comes from the MAC layer to the LLC layer, the congestion marking is added (402) in the MA-UNITDATA. indication primitive to report that the MSDU was congested in the non-AP station’s MAC queue. Next, the IP layer modifies (403) the ECN field of the IP header of the MSDU before it is transmitted in the wired section 30a (up to the L4S receiver 22).

[0197] In that way, the AP 44 maps the 802.11 (MAC-level) congestion indication to its MAC interface, in order to that the upper IP layer can set CE bit prior to transfer the packet to the Internet. Compared to legacy routers where the CE bit of an ECN-Capable packet should only be set in case the router would otherwise have dropped the packet as an indication of congestion to the end nodes, here the CE bit of an ECN-Capable packet is set in case the remote client (L4S sender) would otherwise have dropped the packet in its 802.11 MAC layer. In other words, the router (here the AP 44) sets the CE flag on behalf of its clients (associated non-AP stations) that encounter congestion (not a local congestion). This implies to perform IP header checksum recalculation.

[0198] Note that when the CE packet is received by any router (24), the CE bit is left unchanged, and the packet transmitted as usual. Finally, the L4S receiver 22 sets (26) the ECN-Echo flag in the TCP header of the reverse flow so that it can inform (27) the L4S sender 41 when a CE packet has been received.

[0199] Second embodiments of the disclosure, as illustrated through Figures 5A and 5B, deal with fast (improved) reporting of congestion, applicable to downlink and uplink traffic. The second embodiments do not rely on the ECE marking by the L4S receiver 22 to warn the L4S sender 21 of the congestion. Rather, they provide anticipated signalling of congestion by a network node that can intercept and accordingly mark the flow that is reverse to the flow experiencing congestion. In other words, the congestion notification is provided to the L4S sender in advance, prior to receiving the TCP Echo by the remote L4S receiver (that mandates a RTT delay).

[0200] Figure 5A illustrates, using a flowchart, steps of a communication method involving enhanced ECN notification according to the second embodiments.

[0201] Figure 5B illustrates an exemplary wireless-wired communication system in which the notification scheme according to the second embodiments is implemented for uplink / upstream or downlink / downstream traffic.

[0202] The operations of Figure 5A take place in a network equipment which may be any intermediary network node along the end-to-end communication path between the L4S sender and the L4S receiver.

[0203] The process starts at step 400 / 450 already described with reference to Figure 4A, in which the network equipment receives, on a first communication interface from a previous network equipment, incoming packets or data frames of a first flow of data traffic.

[0204] At step 420 / 460, the network equipment monitors any contention affecting the first flow. This step aims at detecting congestion affecting a first flow of data traffic (e.g., Classic or L4S) established from a traffic sender to a traffic receiver.

[0205] This may consist in detecting congestion in one queue of the network equipment, e.g., a L4S transmit queue 250. In variants, this may consist in detecting a CE marking in the ECN field of the packets of the first flow. In further variants, this may consist in receiving a MAC frame marked with a Layer-2 congestion indication, from a non-AP station of a wireless network. It happens for instance when the network equipment includes an access point (AP) managing the wireless network and acting as an IP router for the wired section of the end-to-end communication path.

[0206] At step 530, the network equipment identifies packets of the reverse (or ‘return’) flow of the same data traffic, on a second communication interface of the network equipment. The two flows correspond to the same data traffic; they are linked and established between the same devices but in opposite directions. The data traffic may rely on a TCP connection established between the source and the destination.

[0207] Step 530 may consider applying the additional parameters described above with respect to step 410 in order to determine that an incoming packet on the second communication interface relates to the same data traffic as received on the first communication interface. One example is to consider the parameters specified as TCLAS element: source IP, destination IP, source port, and destination port are reverse. Alternatively, an SCS for downlink (with reverse identification information in a TCLAS element, even if the transport parameters such as throughput may be different in the reverse direction) may have been set up by the client device in addition to an SCS for uplink, so that the non-AP client can request the AP to apply specific identification and QoS treatment of downlink IP flows.

[0208] In other words, packets in the reverse direction may be identified as belonging to the reverse flow, based on: a source IP address, a destination IP address, a source port and a destination port that are inverted compared to packets of the first flow, a Stream Classification Service (SCS) description of one stream in a pair of SCS downlink stream and SCS uplink stream set up with a client station - typically a non-access point (AP) station in a wireless network - wherein the other stream of the pair corresponds to the first flow.

[0209] Usually, the reverse flow includes pure acknowledgments acknowledging reception of the packets of the first flow.

[0210] Pure ack packet is a TCP segment which does not contain any payload, and only has the ACK flag set. Therefore, such packet can be detected in the reverse direction if its length is up to 40 bytes in case of no options (20-byte IP header and a 20-byte TCP header). A classifier can therefore identify packets as pure TCP ACKs, then extracts the salient header fields and looks up to the TCP socket associated with the ACK using the source and destination address / port pairs (which may correspond to those used for the first flow).

[0211] At step 540, responsive to the detection of step 420 / 460, the network equipment marks the reverse flow, with a congestion indication. Pure acknowledgments are therefore marked with congestion information, contrary to the requirements of RFC3168 that forbids ECN-capability of the pure ack packets.

[0212] The network equipment, e.g. an IP router in the wired section 30a, may merely set the ECN-Echo (ECE) bit in the header of a TCP segment forming the reverse flow. In that case, the network equipment performs the echoing instead of the L4S receiver 22.

[0213] In variants relying to the fact that the ECN field is not used with pure acknowledgments, the network equipment may set the ECN field to a congestion indication value, in a header of the pure ack (IP) packet. For example, the second bit of the ECN field may be set to 1 , meaning the ECN field is set to the ECT(1) codepoint when original ECN value was 00 (Non-ECN codepoint), or set to the CE codepoint when original ECN value was 10 (ECN(0) codepoint). In other variants, in particular applicable at an AP ofthe wireless section 30b that operates as a router in the wired section 30a, the AP may report, from its Layer 3 (IP layer) to its Layer 2 (MAC layer), a congestion indication, and mark a MAC frame forming the reverse flow with the congestion indication. This may be done by providing, to a MAC service of the AP, the congestion indication in a MA-UNITDATA.Request primitive.

[0214] It is recalled that the MA-UNITDATA.Request of the MAC sublayer 202 may be invoked by the LLC sublayer to request the transfer of a data frame from a local LLC entity to a specific peer LLC entity or group of peer entities on different stations. The data frame could be an information frame containing data from a higher layer or a control frame that the LLC generates internally to communicate with its peer LLC. In short, the MA-UNITDATA.request is passed from the LLC sublayer to the MAC sublayer to request the transmission of MAC service data unit (MSDU).

[0215] The MA-UNITDATA. Request may be enhanced from its current definition in IEEE P802.11 be / D7.0 (August 2024), as follows:

[0216] MA-UNITDATA. request( source address, destination address, routing information, data, priority, drop eligible, service class, station vector,

[0217] MSDU format, radio environment request vector

[0218] SCSID -- nonzero value that identifies the SCS stream to which the MSDU belongs flow identifier

[0219] CE information

[0220] ) wherein the ‘flow identifier’ is mandatory, whereas the CE information includes the CE_flag (or any other name) which indicates, if present, that the flow is a L4S flow and includes the ECN field set to a non-significative value (e.g., ‘00’).

[0221] In other words, at step 540, the network equipment marks one or more ‘reverse’ frames as indication that the first flow has experienced congestion, that is to say marking the MAC frame encapsulating corresponding traffic in the reverse direction as the MSDU suffering from network congestion that was already marked as experiencing congestion. This allows the network equipment to report earlier the congestion to the L4S sender. Next, at optional step 550, the network equipment may modify or not the ECN signalling of the packets of the first flow (experiencing the congestion and to be forwarded to the receiver 22), in order to propagate or not the congestion indication up to the L4S receiver 22.

[0222] The received packets may already be marked with a CE indication, allowing the network equipment to perform the reverse flow marking according to the second embodiments. In that case, optional step 550 may decide to erase or not the congestion indication: in one option, the network equipment does not modify the CE codepoint of the packets of the affected first flow; in the other option, responsive to detecting the congestion, the network equipment modifies the CE codepoint of the packets of the affected first flow into non-CE codepoints (e.g. ECT(1) or ECT(O)) to remove the CE indication.

[0223] In case the received packets are not already be marked, option step 550 may decide to mark them with the CE marking in the ECN field or not.

[0224] By propagating the congestion indication in the upstream packet, there is a risk that the echoing by the L4S receiver 22 triggers end-to-end congestion control at the L4S sender 21 , and then reduces even more the rate of the first flow. Normally, TCP should not react to congestion indications more often than once every window of data (or more loosely, more than once every round-trip time - RTT). That is, the TCP sender's congestion window is reduced only once in response to a series of dropped and / or CE packets within a single window of data. However, in the second embodiments where the congestion can be notified at the early beginning of the upstream path, since latency over the Internet is fluctuant, there is risk that RTT fluctuates and the legacy congestion notification is received “twice” up to the limit of an RTT timing. Therefore, in embodiments, the CE marking in the packets of the first flow is erased or not performed by the network equipment.

[0225] Further to step 550, the network equipment sends (560) the marked ‘reverse’ flow (packets / data frames) to the upstream part of the end-to-end communication path and sends (570) the packets of the first flow to the downstream part of the end-to-end communication path.

[0226] Figure 5B illustrates a notification scheme according to the second embodiments.

[0227] In the proposed scenario 50, the network equipment is the AP 54 of the wireless section 30b, which AP operates as router for the wired section 30a. As mentioned above, the network equipment performing reverse marking according to the second embodiments could be a network node 24 of the wired section 30a.

[0228] In the proposed scenario too, the congestion occurs at the non-AP station 51 that, here, is the L4S sender. As mentioned above, the congestion could happen at the AP side when transmitting in the wired section 30a.

[0229] Congestion 500 may be notified to the AP 54 using notification 501 similar to indication 401 described above. MAC-layer notification 501 can be reported (502) to upper layer using the MA-UNITDATA. indication primitive. Alternatively, the AP 54 may be able to determine that a congestion occurred at the non-AP device 51 . This can be determined through buffer reports (including buffer occupancy, delay bounds information) regularly sent by the non-AP station 51 in the uplink frames, but also (or in complement) with local determining means able to monitor the upstream race compared to the scheduling contract (SCS negotiation containing traffic specification in terms of medium access and traffic identification like TCLAS elements).

[0230] When the AP 54 becomes aware of the congestion encountered at the non-AP station 51 , it may need to report this information back to the L4S sender 51 as early as possible.

[0231] The AP 54 is able to recognize the reverse flow (dashed arrow) corresponding to the first flow, e.g., thanks to the source IP addresses, destination IP addresses, source ports and destination ports that are inverted.

[0232] The AP’s upper layer then can proceed to the congestion notification 57 towards the L4S sender 51 using one of the following features: setting an ECN-Echo (ECE) in the TCP segments of the reverse flow. If the L4S sender 51 receives an ECE-marked ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then it knows that congestion was encountered in the network on the path from the sender to the receiver (even if in that case the congestion is local to the wireless network). setting the CE marking in the IP packets of the reverse flow. The AP 54 modifies either of the bits in the ECN field of the reverse flow, so that a congestion is advertised (either ECT(1) when original ECN value was 0, or CE when original ECN value was 01). Preferably, the new codepoint is applied to pure acknowledgement packets (e.g., packets that do not contain any accompanying data). setting an ECN-like field (to CE value) in the MAC header of the MAC frames conveying the reverse flow. This operation is supported by the MA- UNITDATA. Request primitive, where the CE_Flag is not set and the ECN value is set to the CE value, in the CE information field. In embodiments, any value other than CE - e.g. ECT(1) or ECT(O) - can be used in the ECN field to signal the congestion back to the L4S sender 51 .

[0233] With either options, the L4S sender 51 can treat the ECE flag, CE codepoint in the packet header or frame header as a valid indication of congestion, and therefore return ECN-CWR indications to the L4S receiver 22. As discussed, a TCP receiver uses the CWR flag received from the TCP senderto determine when to stop setting the ECN-Echo flag: this will be transparent (no action) if the TCP receiver has not issued the ECN-Echo flag set in the TCP header (e.g. when step 550 avoids having the CE marking to be propagated to the L4S receiver 22).

[0234] Third embodiments of the disclosure, as illustrated through Figures 6A and 6B, deal with fast (improved) reporting of congestion in uplink or downlink traffic, at a communication device. The third embodiments do not rely on the ECE marking by the L4S receiver 22 to warn the L4S sender 21 of the congestion. Rather, they provide anticipated signalling of congestion at the wireless station experiencing MAC-level congestion by internal reporting using the MSAP primitives. The third embodiments relate for example to notification of congestion of uplink traffic, locally managed by a non-AP station and / orto notification of congestion of downlink traffic, locally managed by the AP.

[0235] Figure 6A illustrates, using a flowchart, steps of a communication method involving an enhanced congestion notification locally managed, according to the third embodiments.

[0236] Figure 6B illustrates an exemplary wireless-wired communication system in which the local notification scheme according to the third embodiments is implemented.

[0237] The operations of Figure 6A take place in a communication device, typically of a wireless network, that transmits data traffic of an end-to-end communication (e.g., TCP session) in the wireless network. In this respect, a non-AP station may have uplink data traffic to transmit to its AP operating as a router in the end-to-end communication path to an end-to-end receiver. Reversely, the AP may have downlink data traffic to transmit to one of its non-AP stations operating as L2S receiver of the end-to-end communication or operating as a router in the end- to-end communication path to an end-to-end receiver.

[0238] The communication device may be the L4S sender or any wireless station of a wireless section 30b in the end-to-end communication path.

[0239] The process starts at step 400 already described, where the communication device receives incoming packets a first flow of data traffic, to be transmitted in the BSS.

[0240] At step 410 already described, the received packets, or at least a portion of them, are encapsulated into data (or MAC) frames and then placed in a buffer (transmit) queue, where they will remain until they are forwarded or, in some cases, discarded.

[0241] At step 420 already described, the communication device monitors whether its transmit queues experience or are about to experience congestion, i.e., whether congestion at MAC level occurs.

[0242] In case there is no congestion, the data frame comprising the incoming packet can be transmitted in the BSS (to the AP for uplink traffic or to one non-AP station for downlink traffic) over the wireless medium. This is step 440 already described.

[0243] Otherwise, the communication device reports (630), to Layer 3 (e.g., IP layer via LLC sublayer) and using a MAC service primitive, a congestion indication indicating congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames (e.g. MAC protocol service data units or MPDUs) of a first flow of data traffic (e.g., Classic or L4S). In that case, the communication device may detect the congestion in the local transmit MAC queue and the reporting may be responsive to the detection. Hence, a ‘local’ indication about congestion is (locally) provided to the upper layers.

[0244] In order to report that an MSDU of the first flow was congested in the local MAC queue, the communication device may report using the MA-UNITDATA.Indication primitive or the MA- UNITDATA-STATUS. Indication primitive of the MSAP interface.

[0245] The MA-UNITDATA.Indication primitive has already been described above. In particular, this primitive is invoked upon receiving MAC frames. In the third embodiments, it may be invoked when receiving MAC frames belonging to the flow reverse to the first flow that is experiencing local congestion. In other words, the communication device receives a MAC frame of a reverse (or ‘return’) flow of the data traffic in a reverse direction to the first flow, in which case the congestion indication is reported to the Layer 3 (IP layer) together with a Layer-3 packet (MSDU) of the received MAC frame using the MA-UNITDATA. indication primitive. For instance, the MA- UNITDATA. indication primitive may include a field set to an Explicit Congestion Notification (ECN) codepoint to report the congestion (typically a CE codepoint). The ECN codepoint may be provided in the ECN subfield of the CE information field of the primitive.

[0246] The MA-UNITDATA-STATUS. Indication primitive can be enhanced compared to its current definition in IEEE P802.11-REVme / D6.0 (June 2024) to allow such reporting.

[0247] It is recalled that the MA-UNITDATA-STATUS. indication is used by the MAC sublayer 202 to provide status information about the service provided for a previous MA- UNITDATA. request primitive, to the LLC sublayer 204. This primitive has local significance and provides the LLC sublayer with status information for the corresponding preceding MA- UNITDATA. request primitive, so it may be used to report the congestion information according to embodiments. In this respect, the primitive may be extended as follows:

[0248] MA-UNITDATA-STATUS. indication source address, destination address, transmission status, provided priority, provided service class, radio environment request vector flow identifier

[0249] CE information

[0250] ) wherein the ‘flow identifier’ is mandatory, and the CE information includes the optional CE_flag (or any other name), the ECN field described above (to report an ECN codepoint) and an ECE-Echo flag (one bit) to report the experienced congestion for an emitted MSDU. Thanks to the ECE-Echo flag in the CE information, this primitive clearly indicates that a congestion is (or is about to be) experienced for the first flow, and can be seen as equivalent (however, at MAC layer) to the ECE flag in the TCP header of an ACK of the reverse flow that the receiver usually would have set.

[0251] As a consequence, the MA-UNITDATA-STATUS. indication primitive may include a field set to an Explicit Congestion Notification (ECN) codepoint that reports congestion and / or a Congestion Experienced (CE) bit that also reports congestion (or flag, e.g. set like the ECN-Echo (ECE) bit).

[0252] It is to be noted that the MA-UNITDATA-STATUS. Indication primitive can be invoked independently to any MSDU reception (contrary to the MA-UNITDATA. Indication primitive). As a consequence, it is possible to periodically report the congestion status of the MAC transmit queues of the communication device. The flow identifier allows the communication device to know which transmit queue is concerned by the report.

[0253] In alternative embodiments, a primitive of the MLME 206 can be used instead of the above MSAP primitives. A MLME primitive of the MAC service is therefore defined as a congestion-specific primitive, i.e., that is able to report congestion.

[0254] As an example, the following MLME primitive can be defined:

[0255] MLME-CE_ADVERTISEMENT ( flow identifier

[0256] CE Information

[0257] )•

[0258] Preferably, the MLME-CE_ADVERTISEMENT primitive follows the format of the MA- UNITDATA-STATUS. indication described above.

[0259] When receiving such congestion notification from step 630, the upper layer of the communication device, in particular its TCP service, may adjust (640) a transmission rate of the data traffic responsive to the congestion indication reported to Layer 3. This applies when the communication device is the L4S sender of the end-to-end communication.

[0260] As an alternative step (640a), in particular when the communication device is not the L4S sender of the end-to-end communication, it may be worth signalling the congestion as early as possible to the L4S sender. In that case, the communication device may mark a Layer-3 (IP) packet belonging to the reverse flow with a congestion indication before transmitting it typically to a wireless non-AP station. Proposed markings are described above with reference to Figure 5A (second embodiments).

[0261] Purpose of the modified MAC interface (MSAP) is to avoid any cross-layer header modification inside the MAC, and let the upper layer do the flow adaptation operation (generally performed by software, compared to hardware / firmware operations in the MAC chipset, that is easier implementable).

[0262] After step 640 or 640a or in case of absence of congestion, the MAC frames of the first flow in the transmit queues are transmitted (440) in the BSS (to the AP for uplink traffic or to a non-AP station for downlink traffic) over the wireless medium.

[0263] Note that the third embodiments may be combined with the first embodiments to allow for instance a non-AP station to report the congestion to its AP for further notification to the L4S receiver and / or with the second embodiments to allow the communication device or any network node downstream (according to the first flow) to provide earlier congestion notification of the L4S sender by intercepting and marking the reverse flow.

[0264] Figure 6B illustrates a local notification scheme according to the third embodiments.

[0265] In the proposed scenario 60, the communication device is the non-AP station 61 operating as L4S sender that has uplink data of a first flow, to transmit to the AP, for further forwarding to the L4S receiver 22. The congestion 600 occurs in one MAC transmit queue of the non-AP station 61 that handles the data frames embedding the packets of the first flow. Congestion notification 601 is local to the MAC SAP, using any MSAP primitive as mentioned above.

[0266] Based on the report of the congestion, the non-AP station adjusts (602) its transmission rate of the first flow of data. In embodiments that rely on conventional processing of the upper layers, the non-AP station 61 can manage to update (602) either or both the IP header I TCP header (hence ECN field or ECE flag) of any incoming data (hence corresponding reverse flow) towards the L4S application. Indeed, the L4S application is able to interpret this signalling to control the transmission rate of the first flow. In other words, the communication device marks a Layer-3 packet or a Layer-4 segment belonging to a flow that is reverse to the first flow, with a congestion indication.

[0267] In some embodiments, the AP 64 may indicate 603 it will encounter difficulties to serve the non-AP station 61 before the non-AP station is able to detect any congestion. Typically, this can be performed by any data frame of the reverse flow, for instance by setting a congestion flag in the MAC header (i.e., QoS field or A-control field). Alternatively, a dedicated frame (e.g. an Action frame, or a specific indication field in a Trigger frame that triggers transmission of the first flow intended to the L4S receiver) can be used to report such impeding congestion.

[0268] In some embodiments (not shown), the non-AP station 61 may inform the AP 64 about the congestion (using the first embodiments above), which AP may forward this information to the L4S receiver 22 by setting the ECN field in the IP header of the packets to be forwarded.

[0269] The above embodiments show that existing primitives can be adapted and new primitive can be defined to report congestion between layers of a communication device. The goal of the Medium Access Control (MAC) service of such communication device is to communicate with an upper layer using a primitive that includes an Explicit Congestion Notification (ECN) codepoint to report congestion and / or a MA-UNITDATA-STATUS. indication primitive that includes an ECN- Echo (ECE) bit to report congestion.

[0270] Some primitives of the MSAP can only be invoked upon receiving a MAC frame. In this respect, the used primitive requests transfer of a Layer-3 packet (MSDU) to an upper layer, and the Layer-3 packet belongs to a data traffic experiencing congestion in a transmit MAC queue local to the communication device. As described in embodiments above, the transferred Layer-3 packet is a received MAC service data units (MSDU) belonging to the flow of the data traffic that is in a reverse direction to a first flow of MSDUs transmitted through the local MAC queue (that experiences the congestion). The data traffic may relate to L4S traffic, meaning the packets are marked as L4S flows (e.g., using the ECT(1) value in the ECN field of the IP packets).

[0271] Figure 7 illustrates possible modifications of the MAC interface proposed to LLC layer. Depending on the embodiments, the new interface may be involved in non-AP station 41 , 51 , 61 and AP 44, 54, 64. The LLC layer communicates with its associated MAC layer through known service primitives such as the MA-UNITDATA. request primitive, the MA-UNITDATA. indication primitive and the MA-UNITDATA-STATUS. indication primitive.

[0272] As apparent from above, one way to extend the MAC Data Service is to define a new Congestion-specific parameterto these MAC Data Service primitives, including the ‘flow identifier’ and ‘CE information’. The illustrated congestion parameters provide to the higher layers with statuses about the current congestion in the wireless environment encountered by a specific traffic flow.

[0273] Here is an exemplary format of the CE Information parameter as introduced above. Of course, any variant of the presented parameters (e.g. only part of) may be envisaged.

[0274] The CE_Flag boolean is used in the MA-UNITDATA. Request primitive to indicate that the MSDU belongs to an L4S flow, and in the MA-UNITDATA. indication primitive to report that the received MSDU was congested.

[0275] THE ECN value is used at reception to determine if the incoming MSDU coming from the wireless network is to be marked as CE by this value. The illustrated format based on a 2-bit field is preferable, as easily be written as-is in the two-bit field of the IP header.

[0276] Preferably, when the CE_Flag is present, the SCSID is used as a nonzero value that identifies the SCS / L4S stream to which the MSDU belongs (otherwise, a dedicated L4S identifier may be considered to be present as new parameter on the primitives). Concerning MA-UNITDATA-STATUS. indication primitive, the table presents two alternatives. Either the 2-bit ECN field is used or the ECE flag is used to report the experienced congestion (ECN field is set to CE or ECE flag is enabled). One may consider using a specific flow identifier value (e.g. OxFF), not dedicated to a specific flow, that could be used by the MAC entity to alert about a general wireless network congestion to its upper layer.

[0277] Figure 8A schematically illustrates a communication device 800, which may be any stations of radio network 100 of Figure 1 , configured to implement at least one embodiment of the present disclosure. The communication device 800 may preferably be a device such as a micro-computer, a workstation or a light portable device.

[0278] It should also be appreciated that the communication device is configured to operate in different modes (TXOP holder, TXOP share participant, source, intermediate, destination, first AP, other AP, stations associated with the first AP, stations associated with another AP, coordinator, coordinate, AP in an OBSS, STA in an OBSS, and so forth), depending on what role it is performing in the current communication context.

[0279] The communication device 800 comprises a communication bus 813 to which there are preferably connected: a central processing unit 801 , such as a processor, denoted CPU; a memory 803 for storing an executable code of methods or steps of the methods according to embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 802 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards and / or Wireless-Fidelity (Wi-Fi) specifications, via transmitting and receiving antennas 804.

[0280] Optionally - in particular for an AP that operates as a router in a wired section 30a of an end-to-end communication path - the communication device 800 further comprises a communication interface to the wired section (e.g. LAN or Ethernet interface).

[0281] Preferably the communication bus 813 provides communication and interoperability between the various elements included in the communication device 800 or connected to it. The representation of the bus is not limiting and in particular the central processing unit 801 is operable to communicate instructions to any element of the communication device 800 directly or by means of another element of the communication device 800.

[0282] The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 802, in order to be stored in the memory of the communication device 800 before being executed.

[0283] In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the disclosure. However, alternatively, embodiments of the present disclosure may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

[0284] Figure 8B is a block diagram schematically illustrating the architecture of the communication device 800, adapted to carry out, at least partially, some embodiments of the disclosure. As illustrated, device 800 comprises a physical (PHY) layer block 823, a MAC layer block 822, and an application layer block 821 .

[0285] The PHY layer block 823, here a plurality of 802.11 standardized PHY layer modules in case the device is a MLD (however a single PHY layer module may be contemplated when the device is single link), has the task of formatting, modulating on or demodulating from any 20MHz channel or composite channel or resource unit. The PHY layer thus sends or receives data or MAC frames over the radio medium NETW, such as 802.1 1 frames. These data frames may include congestion signalling as described above and other conventional 802.11 frames.

[0286] The MAC layer block or controller 822 preferably comprises a MAC 802.11 layer 824 implementing conventional 802.1 1 MAC operations. It may comprise additional block 825 for carrying out, at least partially, embodiments of the disclosure. MAC layer block 822 may optionally be implemented in software, which software is loaded into RAM 803 and executed by CPU 801 . MAC 802.11 layer 824 may implement an Upper-MAC stack 824a along with one or more Lower- MAC modules 824b in case the device is a MLD. Of course, a single-link architecture is supported (whereas not illustrated here). A MAC layer block preferably includes the subblocks shown in Figure 2A.

[0287] Preferably, additional block 825, referred to as “congestion reporting module” module, implements, in collaboration with MAC 802.11 layer 824, embodiments of the present disclosure to perform queue measurement in order to monitors the status of queue buffer(s), to report congestion indication to the upper layers and / or to other communication devices using dedicated signalling as described above. As an example, block 825 performs the operations of the methods described above with reference to Figures 4A to 7.

[0288] On top of the Figure, application layer block 821 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 821 represents all the stack layers above MAC layer according to the ISO standardization. For example, in embodiments described above, they include the IP layer and, above the latter, the TCP layer.

[0289] Although the present disclosure has been described herein above with reference to specific embodiments, it is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present disclosure.

[0290] Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the disclosure, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

37CLAIMS1. A communication device having a Medium Access Control (MAC) service, wherein the MAC service is configured to communicate with an upper layer using a primitive that includes an Explicit Congestion Notification (ECN) codepoint to report congestion.

2. The communication device of Claim 1 , wherein a TCP service in the communication device adjusts a transmission rate of transmitted data traffic responsive to the reported congestion.

3. The communication device of Claim 1 , wherein the used primitive requests transfer of a Layer-3 packet to an upper layer, wherein the Layer-3 packet belongs to a data traffic experiencing congestion in a transmit MAC queue local to the communication device.

4. The communication device of Claim 3, wherein the transferred Layer-3 packet is a received MAC service data units (MSDU) of a reverse flow of the data traffic in a reverse direction to a first flow of MSDUs transmitted through the local MAC queue.

5. The communication device of Claim 4, wherein the two flows are two flows marked as Low-Latency, Low-Loss, Scalable Throughput (L4S) flows that are in opposite directions.

6. The communication device of Claim 1 , wherein the used primitive includes both an ECN codepoint and an ECE bit.

7. The communication device of Claim 1 , wherein the primitive that includes the ECN codepoint is a primitive of a MAC layer management entity (MLME) of the MAC service.

8. A communication method in a communication device having a Medium Access Control (MAC) service, wherein the MAC service communicates with an upper layer using a primitive that includes an Explicit Congestion Notification (ECN) codepoint to report congestion.

9. A method of reporting congestion, comprising, in a communication device: reporting, to Layer 3 and using a MAC service primitive, a congestion indication indicating congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a first flow of data traffic.

10. The method of Claim 9, comprising, at the communication device, a step of detecting congestion in the local transmit MAC queue storing MAC frames of the first flow of data traffic, wherein the reporting is responsive to the detection.

11. The method of Claim 9, wherein the communication device marks a Layer-3 packet or a Layer-4 segment belonging to a flow that is reverse to the first flow, with a congestion indication.

12. The method of Claim 9, wherein a TCP service in the communication device adjusts a transmission rate of the data traffic responsive to the congestion indication reported to Layer 3.3813. The method of Claim 9, wherein reporting the congestion indication to Layer 3 includes providing, by a MAC service of the communication device, the congestion indication in a primitive of a MAC layer management entity (MLME) of the MAC service.

14. The method of Claim 13, wherein the primitive includes a field set to an Explicit Congestion Notification (ECN) codepoint and / or a Congestion Experienced (CE) bit.

15. The method of Claim 9, wherein the primitive is reported periodically.

16. The method of Claim 9, further comprising receiving a MAC frame of a reverse flow of the data traffic in a reverse direction to the first flow, wherein the congestion indication is reported together with a Layer-3 packet of the received MAC frame using the primitive.

17. A communication device comprising a Medium Access Control (MAC) service configured to report, to Layer 3 and using a MAC service primitive, a congestion indication indicating congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a first flow of data traffic.

18. A method of reporting congestion, comprising, in an access point (AP) of a wireless network: receiving, from a non-AP station of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to the data traffic, and responsive to the receiving, marking a Layer-3 packet of the data traffic, with a Congestion Experienced (CE) codepoint.

19. A method of reporting congestion, comprises, in a non- access point (non-AP) station of a wireless network: detecting congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a data traffic, and transmitting, to an AP of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to the data traffic.

20. An access point (AP) of a wireless network, comprising: a communication interface configured to receive, from a non-AP station of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to a data traffic, and a Layer-3 service configured to mark, responsive to the receiving, a Layer-3 packet of the data traffic with a Congestion Experienced (CE) codepoint.21 . A non- access point (non-AP) station of a wireless network comprising: a Medium Access Control (MAC) service configured to detect congestion in a local transmit Medium Access Control (MAC) queue storing MAC frames of a data traffic, and a communication interface configured to transmit, to an AP of the wireless network, a Layer-2 frame marked with a Layer-2 congestion indication relating to the data traffic.

22. A method of reporting congestion, comprising, in a network equipment: detecting congestion affecting a first flow of data traffic established from a traffic sender to a traffic receiver, and responsive to the detection, marking a reverse flow of the data traffic in a reverse direction to the first flow, with a congestion indication.

23. A network equipment comprising: a congestion unit configured to detect congestion affecting a first flow of data traffic established from a traffic sender to a traffic receiver, and a marking unit configured to mark, responsive to the detection, a reverse flow of the data traffic in a reverse direction to the first flow, with a congestion indication.

24. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method of Claim 8, 9, 18, 19 or 22

Images