Method and apparatus for managing low-latency data transmission in wireless networks

Abstract

SOLUTION: There are provided a method and an apparatus for managing low latency data transmission in a wireless network, in which the 802.11be wireless network implements a low latency reliable service criterion for prioritizing LLRS traffic over conventional non-LLRS traffic, an AP dynamically defines and modifies LLRS traffic configurations consisting of concerned traffics and associated QoS through transmission of management frames to non-AP stations, and the AP guarantees the declared QoS applicable to each type of declared traffic profile by scheduling appropriate resources to the LLRS traffic configurations.EFFECT: Monitoring a correct use of scheduled resources by non-AP stations helps avoid abuses. Multiple LLRS traffic configurations can be defined in parallel within the same frame using sequential listing or inheritance scheme.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] The present disclosure relates to a method and a device for managing low-latency transmission in a wireless network. More specifically, for example, from the perspective of latency in transmission, it relates to a method that can guarantee transmission constraints such as quality of service constraints.

Background Art

[0002] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcasting, etc. These wireless networks can be multi-connection networks that can serve multiple users by sharing available network resources. Such multi-connection networks can include, for example, code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal FDMA (OFDMA) networks, and single carrier FDMA (SC-FDMA) networks.

[0003] The standard 802.11 family introduced by the Institute of Electrical and Electronics Engineers (IEEE - registered trademark) provides a number of mechanisms for wireless communication between stations.

[0004] Using latency-sensitive applications such as online gaming, real-time video streaming, virtual reality, drone or robot remote control, etc., the requirements and problems of better QoS such as low latency, as well as robustness requirements, need to be considered. For example, 99.9% of latency-sensitive packets should be delivered to the end device within the range of 2 ms latency.

[0005] These issues are currently being considered by the IEEE 802.11 Working Group as a primary objective in issuing the next major 802.11 release, known as 802.11be or EHT for "Extremely High Throughput".

[0006] Low Latency High Reliability Services (LLRS) are defined as a target for these primary objectives. LLRS is a service provided to higher-layer traffic streams that prioritize carrying MSDUs (Data Units) within a worst-case latency budget with a given reliability / packet deliverability (PDR) and low jitter. Traffic streams prioritized by LLRS are referred to as LLRS traffic.

[0007] Several low latency (LL) criteria are being considered to prioritize LLRS traffic within the Basic Service Set (BSS) managed by access point (AP) stations, with the aim of meeting quality of service (QoS) constraints.

[0008] Several LL criteria have been proposed for when an AP schedules a protected and limited TWT service period for a given LLRS traffic. As proposed in the IEEE 802.11-20 / 1046r2 document, non-AP stations (i.e., passive stations) that are not participating in the LLRS traffic must cease their current transmit opportunity (TXOP) before the protected TWT service period begins, with the aim of reducing their impact on the network.

[0009] Another non-restrictive example of the LL criterion is its application by non-AP stations (active stations) radiating or receiving LLRS traffic. For example, certain LLRS resources, such as frequency, time, or spatial resources, are allocated and used by AP stations for LLRS traffic. An example of using a TID greater than 7 to signal network resources for LLRS traffic is provided in the IEEE 802.11-20 / 0418r4 document.

[0010] Efficient QoS management in BSS is necessary to provide LL high-reliability services. [Overview of the project]

[0011] This invention has been devised to address one or more of the aforementioned concerns.

[0012] Firstly, it is a method of communication in a wireless network, In an access point (AP) station of the Basic Service Set (BSS), Declaring one or more QoS parameters applicable to traffic matching a defined traffic profile to one or more non-AP stations, Based on the applicable declared QoS parameters, the BSS schedules the resources of the wireless network for traffic that matches the defined traffic profile, This concerns communication methods, including those mentioned above.

[0013] A set of traffic profiles and associated applicable QoS parameters forms a configuration for LLRS traffic, which is hereafter referred to as the LLRS traffic configuration.

[0014] Unlike statically defined 802.11e access categories, the AP station according to the present invention can dynamically declare and update LLRS traffic settings, i.e., which traffic is intended to be processed as LLRS traffic using LL criteria. Therefore, the proposed scheduling ensures that the resources provided to the BSS satisfy the declared QoS constraints.

[0015] In fact, an AP station may first receive the needs of non-AP stations in terms of LLRS traffic that matches one or more traffic profiles (for example, through a dedicated Buffer Status Report (BSR) procedure). The AP station may then determine the radio resources (e.g., multi-user uplink resource units) in terms of bandwidth and duration to ensure that the traffic profile under consideration provides the appropriate QoS to the non-AP stations whose needs are given.

[0016] The present invention relates to a communication method in a wireless network, At a non-access point (AP) station, Receiving a frame from an AP station of the Basic Service Set (BSS) that declares one or more QoS parameters applicable to traffic matching a defined traffic profile, In order to receive or transmit traffic that matches the defined traffic profile, access to the resources of the wireless network scheduled by the AP in the BSS for such traffic, This also relates to communication methods, including those mentioned above.

[0017] In this way, non-AP stations recognize the LLRS traffic configuration, that is, their own QoS constraints, that the traffic in that LLRS configuration should be processed as LLRS traffic by the AP station. The non-AP station can then use the appropriate scheduled resources provided by the AP station.

[0018] Furthermore, the present invention provides a wireless communication device having at least one microprocessor configured to perform any of the steps of the above-described method.

[0019] Optional features of embodiments of the present invention are defined in the appended claims. Some of these features are described below with reference to the method, but can be translated into device features.

[0020] In some embodiments, the declaration includes using a management frame, such as a beacon frame or probe response frame, transmitted by the AP station during the association of the non-AP station with the AP station. This helps the non-AP station decide whether to actually join the BSS depending on whether the declared LLRS traffic configuration matches its needs.

[0021] In another embodiment, the declaration includes the use of a management frame, such as a beacon frame or action frame, transmitted by the AP station to the non-AP station of the BSS. In this manner, the AP station can dynamically advertise and modify its LLRS traffic settings (traffic profile and corresponding QoS constraints) for the lifetime of its BSS, for example, in response to network load. The non-AP station that receives the management frame can then adapt its actions and, if appropriate, even decide to move to a different BSS.

[0022] In some embodiments, the declaration includes identifying an index that refers to a predetermined (LLRS traffic) setting that associates the defined traffic profile with the QoS parameters. This makes it possible to reduce signaling overhead as long as the pre - defined LLRS traffic settings are known to the station.

[0023] In other embodiments, the declaration includes identifying the one or more QoS parameters in association with a profile identifier that identifies the defined traffic profile. Thus, the traffic profile may be pre - defined and may be known to all stations. The AP identifies only the QoS constraints for one of the predetermined traffic profiles. This reduces the overhead for the declaration.

[0024] In other embodiments, the declaration includes identifying the one or more QoS parameters in association with one or more traffic characteristic values that define the defined traffic profile. This gives the AP station the freedom to dynamically and finely define or change any LLRS traffic settings not only in relation to QoS constraints but also in relation to the type of the concerned data or traffic.

[0025] In some embodiments, the one or more traffic characteristic values include a minimum value and a maximum value of the same traffic characteristic. This efficiently defines the LLRS traffic. In fact, the first limit value (e.g., the minimum bit rate) sets when the AP station determines that specific management is required to achieve the applicable QoS. The second limit value (e.g., the maximum bit rate) sets when the AP station determines that it is no longer necessary to guarantee the associated QoS.

[0026] In some embodiments, the declaration includes declaring a plurality of sets of QoS parameters applicable to a plurality of traffics that each match a respective defined traffic profile. Thus, the AP station declares a plurality of LLRS traffic settings. A joint declaration reduces the network overhead.

[0027] The plurality of sets (LLRS traffic settings) may be self - defined or may be inherited from another set that is still defined.

[0028] For example, the following set of QoS parameters for the following defined traffic profile may be defined by inheriting from the previous QoS parameters for the previously defined traffic profile. Thus, the following LLRS traffic settings are inherited from the LLRS traffic settings.

[0029] According to a particular feature, declaring the following QoS parameters for the following defined traffic profile includes declaring a replacement value that replaces one or more of the QoS parameter values, the set of the previous QoS parameters, and the traffic characteristic values of the previous traffic profile.

[0030] According to another particular feature, the set of the previous QoS parameters is the first set of QoS parameters among the plurality of declared ones. Thus, this first - declared LLRS traffic setting is the reference setting for inheritance. This contributes to reducing the signaling overhead of the following LLRS traffic settings.

[0031] In embodiments relating to the AP station, scheduling is performed in response to the detection of a need from one or more of the stations (i.e., itself or any other non-AP station) to transmit traffic matching the defined traffic profile. This may depend, for example, on the AP station detecting local LLRS traffic in its own memory or receiving a buffer status report indicating LLRS traffic (or needs) from a non-AP station. Then, as described above, the AP station can determine the wireless resources (e.g., multi-user uplink resource units) in terms of bandwidth and duration that will be provided (i.e., scheduled) to the given non-AP station for each need, in order to ensure QoS applicable to the traffic profile under consideration.

[0032] Scheduled resources may be used by AP stations to transmit downlink LLRS traffic to non-AP stations of the BSS, and / or may be used by non-AP stations of the BSS to transmit uplink LLRS traffic to AP stations or direct link (DiL) traffic (also known as peer-to-peer (P2P) traffic) to other non-AP stations, whether belonging to or not belonging to the BSS.

[0033] In some embodiments, scheduling includes scheduling protected Target Wake Time (TWT) service periods for traffic that matches the defined traffic profile. Thus, the TWT service periods are provided in association with a given LLRS traffic configuration.

[0034] In other embodiments, frequency, time, or spatial resources (e.g., resource units in a multi-user OFDMA method) are provided by AP stations as random RUs or as scheduled RUs assigned to specific non-AP stations for traffic that matches the defined traffic profile.

[0035] In some embodiments, the method further includes monitoring the use of the scheduled resource on the AP station to transmit the traffic that matches the defined traffic profile.

[0036] In some embodiments, the method further includes, in response to the AP station detecting a non-AP station transmitting traffic that does not match the defined traffic profile on the scheduled resources, applying corrective action to the detected non-AP station. Various corrective actions may be considered, ranging from temporarily penalizing the non-AP station (for example, by reducing the amount of resources scheduled to it) to removing the non-AP station from the BSS.

[0037] In some embodiments, the method further includes determining at the non-AP station whether the local traffic matches the defined traffic profile, and, in response to that determination, accessing the scheduled resource to transmit the local traffic.

[0038] In another embodiment, the method further includes the non-AP station declaring to the AP station local traffic that matches the defined traffic profile. The declaration may include the amount of such local traffic so as to help the AP station determine which resources should be scheduled to achieve applicable QoS.

[0039] Another aspect of the present invention relates to a non-temporary computer-readable medium storing a program that causes a wireless device to perform any of the methods defined above when executed by a microprocessor or computer system in the wireless device.

[0040] At least a portion of the methods according to the present invention can be implemented in a computer. Therefore, the present invention may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may collectively be referred to here as a “circuit,” “module,” or “system.” Furthermore, the present invention may take the form of a computer program product embedded in any tangible medium of expression having computer-usable program code embedded in the medium.

[0041] Since the present invention is software-implementable, it can be embodied as computer-readable code for provision to a programmable device on any suitable transport medium. Tangible non-temporary transport mediums may include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid-state memory devices. Temporary transport mediums may include signals such as electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals, such as microwave or RF signals. [Brief explanation of the drawing]

[0042] Herein, embodiments of the present invention will be described using only examples with reference to the following drawings. [Figure 1] Figure 1 shows an exemplary network environment in which the present invention may be implemented to carry LLRS. [Figure 2]This diagram illustrates, using flowcharts, the general steps in an AP for managing QoS for LLRS traffic according to several embodiments of the present invention. [Figure 3] This diagram illustrates, using flowcharts, the general steps for QoS management of such an LLRS at a non-AP station according to some embodiments of the present invention. [Figure 4] This figure illustrates a variant for signaling LLRS traffic configuration according to an embodiment of the present invention. [Figure 5] This diagram illustrates various embodiments for advertising one or more LLRS traffic configurations in an advertising frame. [Figure 6] This figure illustrates an example table of predefined LLRS traffic settings according to an embodiment of the present invention. [Figure 7a] This figure schematically illustrates a communication device, which is either a non-AP station or an AP of a wireless network, configured to implement at least one embodiment of the present invention. [Figure 7b] This is a block diagram illustrating a schematic architecture of a communication device adapted to at least partially implement the present invention. [Modes for carrying out the invention]

[0043] The technologies described herein can be used in a variety of broadband wireless communication systems, including communication systems based on orthogonal multiplexing schemes. Examples of such communication systems include spatial division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single-carrier frequency division multiple access (SC-FDMA) systems. SDMA systems can utilize sufficiently different directions to transmit data belonging to multiple user terminals, i.e., wireless devices or stations, in parallel. TDMA systems can enable multiple user terminals to share the same frequency channel by dividing the transmitted signal into different time slots or resource units, each assigned to a different user terminal. OFDMA systems utilize frequency division multiplexing (OFDM), a modulation technique that divides the entire system bandwidth into orthogonal subcarriers or resource units. These subcarriers may also be called tones or bins. Using OFDM, each subcarrier can be independently modulated with data. The SC-FDMA system can utilize interleaved FDMA (IFDMA), which transmits data using subcarriers distributed across the system bandwidth; localized FDMA (LFDMA), which transmits data using a single block of adjacent subcarriers; or enhanced FDMA (EFDMA), which transmits data using multiple blocks of adjacent subcarriers.

[0044] The teachings herein can be incorporated into various devices (e.g., stations) (e.g., implemented or performed within them). In some embodiments, wireless devices or stations implemented according to the teachings herein may include access points (so-called APs) or non-access points (so-called non-AP stations or STAs).

[0045] Although the example is given in the context of a Wi-Fi® network, the present invention can be used in any type of wireless network, such as a mobile phone cellular network that implements a very similar mechanism.

[0046] AP includes, and may be implemented as, or known as, 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"), Wireless Router, Wireless Transceiver, Basic Service Set ("BSS"), Extended Service Set ("ESS"), Radio Base Station ("RBS"), or several other terms.

[0047] Non-AP stations include, and may be implemented as, or known as, subscriber stations, subscriber units, mobile stations (MS), remote stations, remote terminals, user terminals (UT), user agents, user devices, user terminals (UE), user stations, or several other terms. In some implementations, an STA may include a mobile phone, cordless phone, Session Initiation Protocol ("SIP") phone, Wireless Local Loop ("WLL") station, Personal Digital Assistant ("PDA"), handheld device with radio connectivity capabilities, or several other suitable processing devices connected to a wireless modem. Thus, one or more embodiments taught herein may be incorporated into a telephone (e.g., a mobile phone or smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal digital assistant), an entertainment device (e.g., a music or video device or satellite radio), a Global Positioning System (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. In some embodiments, a non-AP station may be a wireless node. Such wireless nodes may, for example, provide access to or from a network (e.g., the Internet or a wide area network such as a cellular network) via wired or wireless communication links.

[0048] An access point (AP) manages a collection of stations that collectively organize access to a wireless medium for communication. These stations (including the AP) form a service set, hereafter referred to as a Basic Service Set (BSS), although other terminology may be used. An identical physical station operating as an access point may manage two or more BSSs (and thus corresponding WLANs), each BSS uniquely identified by a specific Basic Service Set Identification (BSSID) and managed by a separate virtual AP implemented within the physical AP.

[0049] Low Latency High Reliability Service (LLRS) is a service provided to higher-layer traffic streams that has a given reliability / packet deliverability rate (PDR) and low jitter, and prioritizes carrying MSDUs (data units of this data stream) within a worst-case latency budget. Traffic that may be subject to LLRS includes latency-sensitive data, such as data from applications like gaming, media streaming, augmented reality, and virtual reality.

[0050] Figure 1 illustrates an exemplary network environment 100 in which the present invention may be implemented to carry LLRS traffic.

[0051] Each communication station 101-107 registers with the central station or access point (AP) 100 during the association procedure in which the AP assigns a unique association identifier (AID) to the requesting non-AP station. For example, the AID, a 16-bit value that uniquely identifies a non-AP station, may be used to identify the station in the exchanged frames. AP 110 and the associated non-AP stations 102-107 may represent a basic service set (BSS) or an extended service set (ESS).

[0052] In the example shown in the figure, non-AP station 101 has not yet associated with AP110, but intends to associate with AP110 by initiating the association procedure via sending a probe request frame or by continuing the association procedure following the reception of a probe response frame broadcast by the AP.

[0053] Once associated with the BSS, communication stations 101-107 and 110 exchange data frames over the wireless transmission channel 100 of the wireless local area network (WLAN) under the control of AP 110. The wireless transmission channel 100 is defined by an operating frequency band consisting of a single channel or multiple channels forming a composite channel.

[0054] Non-AP stations may communicate directly via a direct radio link (DiL indicating a direct link), that is, without the mediation of an AP relaying their messages. Exemplary situations of direct communication include peer-to-peer (P2P) transmission between non-AP stations sharing the same primary channel.

[0055] Stations 101-107 and 110 can compete with each other using EDCA (Extended Distributed Channel Access) contention to gain access to the radio medium 100 in order to transmit data frames (Single User (SU)) after being granted a Transmit Opportunity (TXOP). Stations may use a multi-user (MU) procedure that allows a single station, typically AP110, to schedule MU transmissions, i.e., multiple parallel transmissions to or from other stations, between granted TXOPs in the radio network. One implementation of such an MU procedure is adapted, for example, in the IEEE 802.11ax amendment as a multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedure. Thanks to the MU function, non-AP stations have the opportunity to gain access to the radio medium through two access procedures: the MU procedure and the conventional Extended Distributed Channel Access-EDCA (Single User) procedure.

[0056] During MU DL transmission on an assigned communication channel, the AP performs multiple parallel basic transmissions on so-called resource units (RUs) to various non-AP stations. For example, resource units divide the communication channels of a radio network in the frequency domain, for example, based on orthogonal frequency division multiple access (OFDMA) technology. The assignment of RUs to non-AP stations is signaled at the beginning of the MU downlink frame by providing an association identifier (AID) for each RU defined at the transmission opportunity (obtained individually by each station during the association procedure with the AP).

[0057] During a MU UL transmission, various non-AP stations can transmit data to the AP in parallel via resource units that form a communication channel. To control MU UL transmissions by non-AP stations, the AP preemptively transmits a control frame known as a trigger frame (TF), or uses the TRS control subfield (representing Trigger Response Scheduling) in a DL data frame that the AP preemptively transmits. The trigger frame or TRS allocates resource units to non-AP stations of the same BSS using the association identifier (AID) assigned to them upon registration with the AP, and / or using a reserved AID that specifies a group of non-AP stations. The TF also determines the start and duration of the MU UL transmission by the non-AP station.

[0058] Quality of Service (QoS) management is implemented at the station level in wireless networks through the well-known EDCA mechanism defined in the IEEE 802.11e standard. The EDCA (Extended Distributed Channel Access) mechanism defines four traffic access categories (ACs) or "priorities" to manage access to the medium: the voice access category (AC_VO) and video access category (AC_VI), both reserved for real-time applications (e.g., voice or video transmission); the best-effort category (AC_BE) for standard applications; and the background access category (AC_BK) for low traffic.

[0059] Four corresponding transmit buffers, or transmit / traffic queues or buffers, are provided, and each AC has its own traffic queue / buffer for storing the corresponding traffic as data frames such as MSDUs or A-MSDUs transmitted over the network. Each data frame, i.e., MSDU, arriving from the upper layers of the protocol stack is assigned a traffic type (TID - abbreviation for Traffic Identifier) ​​which can take the 802.1D priority or user priority (UP) or a value in the range of 0 to 7. Based on that TID, the MSDU is mapped to one of the four AC queues / buffers using mapping rules and stored in the mapped AC buffer. Naturally, another number of traffic queues can be assumed.

[0060] Returning to Figure 1, non-AP stations may represent various devices such as gaming clients, augmented / virtual reality headsets, smartphones, and wireless displays, some of which, over time, need to exchange (i.e., transmit or receive) traffic that has more constrained QoS requirements regarding PDR, jitter, and latency, unlike other traffic coexisting within WLAN 100, for example.

[0061] For example, as described in the IEEE 802.11-21 / 34r4 document, traffic from many real-time applications has stringent latency requirements, including not only very low average and worst-case values ​​on the order of milliseconds to tens of milliseconds, but also small amounts of jitter.

[0062] This type of traffic is called latency-sensitive traffic, low-latency (LL) traffic, or LLRS traffic.

[0063] To meet the QoS requirements for such LLRS traffic and optimize network performance, the AP110 can select one or more links and provide differentiated quality of service on those links. Low-latency operation reduces average and worst-case latency and jitter. This includes defining QoS management mechanisms to distinguish LLRS traffic from other traffic (i.e., non-LLRS traffic) and defining mechanisms to prioritize the transmission of LLRS traffic.

[0064] All of these LL operations are known as AP's Low Latency High Reliability Service (LLRS), which prioritizes carrying MSDUs (Data Units) of LLRS traffic within a worst-case latency range that includes a given reliability / packet deliverability rate (PDR) and low jitter (and more generally, QoS constraints).

[0065] On the other hand, non-LLRS traffic is managed using the conventional 802.11e access category scheme described above.

[0066] An exemplary LLRS includes a protected TWT service period scheduled by AP110 for LLRS traffic. As proposed in the IEEE 802.11-20 / 1046r2 document, non-AP stations must suspend the current transmit opportunity (TXOP) before the protected TWT service period begins. This ensures that the resources scheduled for LLRS traffic are used and, therefore, that the QoS constraints for LLRS traffic are met.

[0067] Another LLRS may consist of providing a dedicated RU or transmit link exclusively for LLRS traffic.

[0068] Ensuring QoS constraints for LLRS traffic is a challenging task for AP110s managing BSSs. In reality, network conditions can change over time, BSSs can expand or contract, and multiple BSSs may exist simultaneously, or legacy stations outside of BSSs may emerge, occupying the wireless medium to a greater or lesser extent.

[0069] Thus, the ability of an AP to satisfy QoS constraints for LLRS traffic can evolve. Therefore, it is appropriate for the AP to dynamically regulate QoS constraints and / or associated traffic, i.e., more generally, to dynamically adjust the LLRS traffic configuration.

[0070] Therefore, wireless networks need to provide enhanced QoS management, especially with respect to LLRS traffic.

[0071] As shown in the following embodiment, AP110 declares LLRS traffic settings, i.e., one or more QoS parameters applicable to traffic that matches a defined traffic profile, to one or more non-AP stations. The non-AP stations receive the declaration and, based on the declared QoS, recognize which traffic (thanks to the traffic profile) is LLRS traffic. Thus, AP110 can dynamically define the LLRS traffic and associated QoS guaranteed by the AP, for example, in response to evolving network conditions.

[0072] Next, based on the station's needs regarding LLRS traffic, for example, the AP schedules wireless network resources within the BSS to traffic that matches a defined traffic profile, based on the applicable declared QoS parameters. More resources can be scheduled for transmission with stricter QoS and more LLRS traffic. The scheduled resources can then be accessed by the station, either for transmitting or receiving its own LLRS traffic. Such LLRS traffic can be UL, DL, or even DiL traffic.

[0073] Advantageously, the AP110 may define multiple LLRS traffic configurations, i.e., multiple sets of traffic characteristic values ​​and multiple separate sets of applicable QoS parameters or requests.

[0074] Figure 2 shows, using flowcharts, the general steps at an AP for managing QoS for LLRS traffic according to several embodiments of the present invention. Similarly, Figure 3 shows, using flowcharts, the general steps at a non-AP station for such LLRS QoS management according to several embodiments of the present invention.

[0075] In step 200, AP110 advertises one or more LLRS traffic settings at the frame level to one or more non-AP stations. This involves declaring one or more QoS parameters applicable to one or more LLRS traffics, i.e., traffic that matches each defined traffic profile.

[0076] Advertisements may be provided to non-AP stations that have not yet been associated, such as Station 101. In this case, management frames sent by AP 110 during the association of the non-AP station with the BSS may be used, such as beacon frames or probe response frames transmitted during the association procedure.

[0077] A dedicated information element (IE), called an LLRS IE, may be used to advertise one or more LLRS traffic configurations, i.e., a combination of a traffic profile (which defines the traffic to be targeted) and associated QoS constraints or parameters. An LLRS IE can simply complement an existing IE in the management frame.

[0078] Figure 4a shows an exemplary LLRS IE400 consisting of Type, Length, and Value (TLV) fields. Naturally, one or more of these parts can be combined in any way. For example, if the length of the IE is fixed and known to all stations, the length value can be omitted.

[0079] In the example shown in the figure, the Element ID subfield 401 identifies IE400 as an LLRS IE according to an embodiment of the present invention. This can take values ​​in the range [245-254] reserved in the 802.11 standard. For illustrative purposes, in some embodiments, the value 247 may be selected.

[0080] The Length subfield 402 indicates the number of bytes that make up the LLRS IE400, which includes the Element ID subfield 401 and the Length subfield 402.

[0081] The LLRS traffic Configuration subfield 403 contains one or more LLRS traffic settings specified by AP110. The number of LLRS traffic settings defined by the AP can vary. For example, a single LLRS traffic setting may be defined. Naturally, if the AP wishes to provide different QoS levels for different types of data / traffic, multiple LLRS traffic settings (i.e., multiple sets of traffic profiles and associated sets of QoS parameters) may be defined.

[0082] An exemplary embodiment of the LLRS traffic configuration subfield 403 is given later with reference to Figure 5.

[0083] In the above-described variation, advertisements can be provided to already associated non-AP stations, such as stations 102-107, i.e., while BSS is running. This is advantageous because it allows AP110 to adjust or modify the LLRS traffic configuration over time, for example, as the network conditions evolve.

[0084] In that case, management frames transmitted by AP110 to non-AP stations of the BSS, such as beacon frames or action frames, may be used throughout the lifetime of the BSS.

[0085] The declaration of one or more LLRS traffic settings in a beacon frame can be made using LLRS IE400, as described above with reference to Figure 4a.

[0086] Insofar as it relates to action frames, a new category of action frames that carry LLRS traffic configurations may be defined.

[0087] Figure 4b shows the structure of an action frame as defined in Section 9.6 of the standard P802.11-REVmd / D5.0. This includes an action field 450 which contains a Category subfield 451, an EHT Action subfield 452, and an Action Body subfield 453.

[0088] The Category subfield 451 is set to a value corresponding to the “EHT Action frame” validated in the 802.11be(v0.3) standard. This can take values ​​within the range [21-125] reserved in the 802.11 standard to date. For illustrative purposes, in some embodiments, the value 21 may be selected.

[0089] The EHT Action subfield 452 is set to a value that identifies the LLRS identification frame. This can take a value within the range [1 to 125] reserved in the 802.11be(v0.3) standard. For illustrative purposes, in some embodiments, a value of 1 may be selected. This allows a non-AP station receiving the frame to directly understand that the frame contains one or more LLRS traffic settings (in subfield 453).

[0090] Similar to the LLRS traffic Configuration subfield 403 described above, the Action Body subfield 453 contains one or more LLRS traffic configurations identified by AP110, an exemplary implementation of which is illustrated with reference to Figure 5.

[0091] Figure 5 shows two main embodiments for advertising one or more LLRS traffic configurations in an advertising frame.

[0092] Essentially, LLRS traffic configuration combines a traffic profile with applicable QoS constraints or parameters. The traffic profile defines which data or traffic is relevant to the definition of this LLRS traffic configuration, i.e., the data or traffic to which QoS can be applied. This is for the type of traffic to which AP110 guarantees QoS (matching the traffic profile).

[0093] Traffic is defined by its characteristics, which are, for example, a list of parameters that characterize the traffic in question.

[0094] Exemplary and non-exclusive traffic characteristics include traffic type, data rate (e.g., minimum and / or maximum or peak), MSDU size (e.g., minimum, maximum), burst size, service interval (e.g., minimum and / or maximum), session type, and discard period.

[0095] The traffic type defines the type of traffic or data, depending on the application at a higher layer, for example. For example, as defined in the IEEE 802.11-20 / 1852r1 document, it could be set to 0 for real-time gaming, 1 for cloud gaming, 2 for real-time video, etc.

[0096] The minimum / peak data rate is the minimum / maximum allowable data rate. The minimum / maximum MSDU size is the minimum / maximum size of the MSDU. The burst size is the maximum (and / or possibly minimum) aggregated size of the MSDU allowed within a service interval.

[0097] The minimum / maximum service interval is the minimum / maximum MSDU arrival time interval.

[0098] The session type indicates the type of transmission, for example, 0 for infrastructure transmissions and 1 for point-to-point transmissions.

[0099] The disposal period is the maximum lifespan of the MSDU, as defined, for example, in the IEEE 802.11-20 / 1693r1 document, and the maximum period after which the transmitter must dispose of the MSDU.

[0100] Therefore, a traffic profile consists of one or more traffic characteristic values, for example, values ​​for all or some of the traffic characteristics described above.

[0101] On the other hand, QoS parameters are values ​​that represent transmission constraints that an AP must guarantee through proper scheduling of network resources.

[0102] Exemplary and non-exclusive QoS parameters include latency limits, jitter, and packet delivery rate (PDR), as proposed in the IEEE 802.11-20 / 0418r4 document.

[0103] The latency (or delay) limit defines the time required for the successful transmission of an MSDU / A-MPDU. This can be defined as the maximum value allowed for any MSDU, the average value for a group or all MSDUs, the 99th percentile (i.e., where 99% of MSDU transmissions are guaranteed to be successful), the 95th percentile (or any other arbitrary percentile), etc.

[0104] Jitter is the expected variation in latency. Again, this can be defined as the maximum allowed jitter value, the mean value, the 99th percentile value (i.e., the jitter guaranteed for 99% of the transmitted MSDU), the 95th percentile value (or any other arbitrary percentile value), etc.

[0105] Packet delivery rate (PDR) is the percentage of MSDUs transmitted within the latency limits specified in the latency limit. PDR may also be defined as the maximum PDR value or the average PDR value, etc.

[0106] For example, an LLRS traffic configuration could be defined as traffic with a data rate (i.e., a traffic profile) between a minimum data rate and a maximum data rate, requiring a maximum latency limit (i.e., a QoS constraint) of 2ms. Another exemplary LLRS traffic could be defined as any real-time video with a given maximum MSDU size (i.e., a traffic profile), requiring a minimum PDR along with a maximum latency limit (i.e., a QoS constraint) of 10ms.

[0107] Thus, each LLRS traffic configuration may consist of an LLRS traffic configuration identifier, a set (or list) of one or more traffic characteristic values ​​(traffic profiles), and a set (or list) of one or more applicable QoS parameters.

[0108] Traffic profiles may be predefined, in which case AP110 can simply refer to them using, for example, a unique identifier. Traffic profiles may also be dynamically defined by AP110 over time.

[0109] Several LLRS traffic configurations may be defined within the same advertising frame.

[0110] Figure 5a shows an embodiment in which LLRS traffic settings 510 are defined sequentially (if multiple exist). These embodiments enable the advertising of a single LLRS traffic setting 510.

[0111] According to the first format, the LLRS traffic setting 510 is declared with an LLRS setting index field 520 and a predetermined LLRS setting index field 521.

[0112] According to the second format, the LLRS traffic configuration 510 is declared with the LLRS configuration index field 520, the traffic profile field 522, and the QoS parameter field 523.

[0113] Two LLRS traffic configurations 510 in different formats may be combined within the same frame, in which case appropriate signaling of the format used will be performed.

[0114] The LLRS configuration index field 520 carries the identifier or index of the LLRS traffic configuration 510. This is a value assigned by AP110 to uniquely identify each LLRS traffic configuration. In operation, this identifier may be used within an 802.11 frame to indicate the LLRS traffic configuration corresponding to the traffic transmitted in the payload. It may also be used by AP110 to tag each scheduled network resource with a specific (or multiple alternative) LLRS traffic configuration that defines the type of traffic allowed. Typically, identifier assignment may be performed incrementally by the AP.

[0115] The predefined LLRS configuration index field 521 refers to a predefined LLRS traffic configuration. Therefore, the first format in Figure 5a declares an LLRS traffic configuration by identifying an index that refers to a predefined LLRS configuration, which associates the defined traffic profile with the QoS parameters.

[0116] Typically, predefined LLRS traffic settings are issued from a table that stores a set of predefined LLRS traffic settings. Such a table is stored in the memory module of each station. Figure 6 shows an exemplary table 600.

[0117] Table 600 contains a list of predefined LLRS traffic configurations 610.

[0118] Each of the predefined LLRS traffic settings 610 is defined by an LLRS setting index 620, a traffic profile 621, and QoS parameters 622 that specify the QoS requirements guaranteed by the AP for traffic matching the associated traffic profile.

[0119] A traffic profile 621 consists of one or more traffic characteristic values ​​that define the data or traffic in question. For example, a list of traffic characteristics may be provided or defined, and for each traffic characteristic, a field is provided in the traffic profile where a value (traffic characteristic value) is defined if applicable. An example of a traffic characteristic is shown above.

[0120] QoS parameter 622 contains QoS constraints applicable to traffic profile 621. A list of QoS parameters may be provided or defined, with a field provided for each QoS parameter where a value is defined, if applicable. Example QoS parameters are provided above.

[0121] Now, returning to the second format in Figure 5a, the traffic profile field 522 contains traffic characteristic values ​​to define the data or traffic in question (similar to field 621). Similarly, the QoS parameter field 523 contains QoS constraints applicable to any traffic that matches the traffic profile in field 522 (similar to field 622).

[0122] In this embodiment, the declaration of LLRS traffic settings is made by identifying one or more QoS parameters in relation to one or more traffic characteristic values ​​that define the defined traffic profile.

[0123] Alternatively, traffic profiles may be predefined (for example, in a table in memory for all stations), and the traffic profile field 522 may simply identify an index that references one of the predefined traffic profiles. This reduces signaling overhead. In this alternative, the declaration of the LLRS traffic configuration is done by identifying one or more QoS parameters in relation to a profile identifier that identifies a defined traffic profile.

[0124] Figure 5b shows another embodiment of defining LLRS traffic settings in the handover method.

[0125] The illustrated format advertises the main LLRS traffic configuration 560 and a list of one or more inherited LLRS traffic configurations 570. Thus, multiple QoS parameter sets applicable to multiple traffics matching each defined traffic profile are declared.

[0126] The main LLRS traffic setting 560 is the first LLRS traffic setting in the frame and can match any self-contained format of the LLRS traffic setting 510 in Figure 5a. In some embodiments, multiple main LLRS traffic settings 560 may be signaled using a self-contained format.

[0127] An inherited LLRS traffic configuration 570 follows an inheritance format. This is defined by referencing the main (or one main) LLRS traffic configuration 560. This means that the next LLRS traffic configuration (i.e., the next QoS parameters for the next defined traffic profile) is defined by inheritance from the previous (in this case, the main) LLRS traffic configuration (i.e., the previous QoS parameters for the previously defined traffic profile).

[0128] The inherited LLRS traffic configuration 570 includes the LLRS configuration index field 520, the partial traffic profile field 572, and the partial QoS parameter field 573. If several main LLRS traffic configurations 560 are defined, an optional LLRS Main Configuration index field 571 (not shown) may be provided to specify from which main LLRS traffic configuration the current inherited LLRS traffic configuration 570 is inherited. This may be useful if the multiple main LLRS traffic configurations do not have the same list of traffic characteristics and / or QoS parameters.

[0129] The partial traffic profile field 572 provides replacement traffic characteristic values ​​that, if specified, replace the corresponding values ​​522 from the main LLRS traffic configuration 560. This means that the traffic characteristic values ​​(forming the traffic profile) of the inherited LLRS traffic configuration 570 correspond to the traffic characteristic values ​​522 of the main LLRS traffic configuration 560, except for the traffic characteristics contained in the partial traffic profile field 572, and for the traffic characteristics contained in the partial traffic profile field 572, those values ​​are replaced with the values ​​specified in the traffic profile 522 of the main LLRS traffic configuration 560.

[0130] The partial QoS parameter field 573 provides a replacement QoS value that, if specified, replaces the corresponding value 523 from the main LLRS traffic configuration 560. This means that the QoS parameters of the inherited LLRS traffic configuration 570 correspond to the QoS parameter 523 of the main LLRS traffic configuration 560, except for the QoS parameters contained in the partial QoS parameter field 573, and that for the QoS parameters contained in the partial QoS parameter field 573, their values ​​are replaced with the value 523 identified in the QoS parameter of the main LLRS traffic configuration 560.

[0131] In the handover, the declaration of the next (in this case, the inherited) LLRS traffic configuration (i.e., the next set of QoS parameters for the next defined traffic profile) includes a declaration of replacement values, which replaces one or more QoS parameter values ​​and traffic characteristic values ​​from the previous (in this case, the main) LLRS traffic configuration (i.e., the previous QoS parameters and defined traffic profile).

[0132] Returning to Figures 2 and 3, once the advertising frame described above is ready, in step 200, the AP110 transmits the frame. In step 300, the frame is received by one or more non-AP stations.

[0133] The advertising frame may be multicast or broadcast to all non-AP stations, for example, if it is a beacon frame, or it may be multicast or broadcast to a group of non-AP stations, for example, using an action frame. Alternatively, during the association procedure, it may be unicast to stations that have not yet been associated, for example, using a probe response frame.

[0134] Upon receiving one (or more) advertising frames, the non-AP station recognizes the LLRS traffic, where AP110 uses the appropriate LLRS mechanism to schedule resources, ensuring the declared QoS.

[0135] A station that is not yet associated with a BSS and is looking for a BSS to handle specific LLRS traffic (i.e., QoS for specific LL data) can determine if this specific LLRS traffic is managed by the BSS's AP by reading the declared LLRS traffic configuration. If the specific LLRS traffic matches any of the declared LLRS traffic configurations, the station may decide to complete its association with that BSS. On the other hand, if the specific LLRS traffic does not match any of the declared LLRS traffic configurations, the station may decide not to complete its association with that BSS. Thus, the decision to associate with a BSS may be based on the LLRS traffic configuration declared by the AP.

[0136] Next, the associated non-AP station may determine in step 305 whether it has LLRS traffic to transmit (for example, in the transmit buffer or as a need declared by a higher-layer application). Step 305 may simply check whether the station has traffic that matches one of the declared LLRS traffic configurations 510 / 560 / 570.

[0137] If affirmative, the station may (still in step 305) transmit its LLRS needs to AP110. This can be done using any type of signaling, for example, a buffer status report (BSR) that enables signaling of LLRS traffic (optionally distinguishing the various LLRS traffic configurations declared by the AP). A non-AP station may signal, for example, a first amount of stored data corresponding to a first LLRS traffic configuration and a second amount of stored data corresponding to a second LLRS traffic configuration.

[0138] In other words, a non-AP station declares to the AP that local traffic matches a defined traffic profile, as previously declared by the AP.

[0139] This signaling of LLRS needs by non-AP stations helps APs efficiently schedule appropriate network resources to stations to meet the applicable declared QoS parameters for all declared LLRS traffic configurations. It also allows for the analysis of network load changes and the adaptation of LLRS traffic configurations as needed. For example, QoS parameters may change as network conditions change. Furthermore, if network conditions deteriorate excessively, LLRS traffic configurations may cease to exist (and thus be deleted), and new LLRS traffic configurations may be declared or reactivated once network conditions have sufficiently improved.

[0140] In step 205, AP110 receives and collects all needs from various non-AP stations. Since non-AP stations can be polled periodically to obtain BSRs, this step can be performed continuously over time.

[0141] Based on the collected LLRS needs, in step 210, AP110 determines the network resources in terms of bandwidth and duration to be provided for the LLRS traffic configuration in order to ensure the declared QoS constraints. AP110 then schedules the determined network resources.

[0142] For example, one or more protected TWT service periods may be provided, dedicated to one or more LLRS traffic configurations received by a station. Alternatively, or in combination, specific resource units for LLRS traffic configurations may be provided in MU OFDMA transmissions. Naturally, any method of scheduling network resources for stations with LLRS needs can be used.

[0143] More generally, a low-latency operation might be envisioned that prioritizes such LLRS traffic over conventional 802.11e AC traffic, scheduling resources specifically for LLRS traffic. This includes high-reliability LL services at access points.

[0144] Scheduled resources can be individually tagged with an identifier (see field 520) in the LLRS traffic configuration that defines the traffic allowed on the resource.

[0145] Following step 210, the AP operates the scheduled resources in step 215. This may include sending LLRS data to one or more non-AP stations (DL transmission) and / or receiving LLRS traffic from such non-AP stations (UL transmission).

[0146] On the other hand, non-AP stations involved in LLRS traffic discover scheduled LLRS resources in step 310. These may be resources specifically assigned to them (e.g., RUs scheduled in MU OFDMA transmissions) or general resources that stations may need to compete to access. Each scheduled LLRS resource may be tagged using an indication in the LLRS traffic configuration, thus restricting the types of data that stations are permitted to send or receive on the resource.

[0147] If it is positive that the scheduled resource can operate, the next step is to operate the scheduled resource by either receiving DiL or DL ​​LLRS traffic from another station (step 315) or by determining whether there is LLRS traffic that matches the LLRS traffic configuration of the scheduled resource to send it to (step 320), and then operating the scheduled resource by either sending such matching LLRS traffic on the scheduled resource (UL or DiL transmission) (step 325). In other words, a non-AP station determines that its local traffic matches the defined traffic profile and, accordingly, accesses the scheduled resource to send its local traffic.

[0148] Steps 215, 315-325 are repeated over time as AP110 schedules new network resources for LLRS traffic, thereby ensuring that the declared QoS is met.

[0149] To prevent unauthorized use of scheduled resources, AP110 may optionally monitor the use of scheduled resources in step 220, in particular, to ensure that the traffic transmitted thereto matches an applicable defined traffic profile.

[0150] This can be done by analyzing the transmitted data and verifying that it matches the traffic profile associated with the LLRS traffic configuration assigned to the scheduled resource. For example, an AP might check if the stream of packets transmitted to the scheduled resource has traffic characteristics that match the traffic profile.

[0151] If the AP detects a non-AP station sending traffic that does not match the traffic profile defined in the scheduled resource (Test 225), in step 230, it applies corrective action to the detected non-AP station that has committed a breach. The corrective action may consist only of ceasing (or temporarily ceasing to provide) new scheduled resources to the non-AP station for any LLRS traffic, or only for breached LLRS traffic. An alternative corrective action may be to disconnect the non-AP station that has committed a breach from the BSS. Of course, other corrective actions are also possible.

[0152] Figure 7a schematically shows a communication device 700, which is one of the non-AP stations 101-107 or AP 110 of the wireless network 100, configured to implement at least one embodiment of the present invention. The communication device 700 may preferably be a device such as a microcomputer, workstation, or lightweight portable device. The communication device 700 preferably has a communication bus 713 to which the following are connected: A central processing unit such as a CPU (CPU) 701; A memory 703 for storing executable code or steps of a method according to an embodiment of the present invention, and registers adapted for recording variables and parameters necessary for performing the method; and At least one communication interface 702 is connected via a transmitting / receiving antenna 704 to a wireless communication network, such as a communication network conforming to one of the standards of the IEEE 802.11 family.

[0153] Preferably, the communication bus provides communication and interoperability between various elements included in or connected to the communication device 700. The representation of the bus is not limited, and in particular, the central processing unit can operate to communicate instructions directly to any element of the communication device 700 or via another element of the communication device 700.

[0154] The executable code can be stored in read-only memory, a hard disk, or a removable digital medium such as a disk. According to an optional modification, the program's executable code may be received by a communication network via interface 702 so that it is stored in the memory of communication device 700 before execution.

[0155] In one embodiment, the device is a programmable device that implements embodiments of the present invention using software. Alternatively, embodiments of the present invention may be implemented in whole or in part in hardware (for example, in the form of an application-specific integrated circuit (ASIC)).

[0156] Figure 7b is a schematic block diagram showing the architecture of a communication device 700, which is either AP110 or one of stations 101-107, adapted to at least partially carry out the present invention. As shown, the device 700 has a physical (PHY) layer block 723, a MAC layer block 722, and an application layer block 721.

[0157] The PHY layer block 723 (here typically an 802.11 standardized PHY layer) has the task of formatting, modulating on any 802.11 channel, or demodulating from an 802.11 channel, and thus transmits or receives frames over the radio medium 100 used, such as 802.11 frames which are management frames and MPDUs.

[0158] The MAC layer block or controller 722 preferably includes an 802.11 MAC layer 724 that implements conventional 802.11ax / be MAC operation and an additional block 725 for at least partially carrying out embodiments of the present invention. The MAC layer block 722 may optionally be implemented in software, the software being loaded into RAM 703 and executed by CPU 701.

[0159] Preferably, an additional block 725, called the LLRS management module, implements part of the embodiment of the present invention (from the perspective of the station or from the perspective of the AP). This block performs the operation shown in Figure 2 or Figure 3, depending on the role of the communication device 700.

[0160] The 802.11 MAC layer 724 and LLRS management module 725 interact with each other to accurately process LLRS communication over a wireless medium, according to embodiments of the present invention.

[0161] At the top of the diagram, the application layer block 721 runs applications that generate and receive data packets, such as video streams and video games. The application layer block 721 represents all stack layers above the MAC layer, according to ISO standards.

[0162] Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to these specific embodiments, and various modifications within the scope of the present invention will be apparent to those skilled in the art.

[0163] By referring to the exemplary embodiments described above, those skilled in the art will readily conceive of many further modifications and variations. These exemplary embodiments are presented for illustrative purposes only and are not intended to limit the scope of the invention; the scope of the invention is defined solely by the appended claims. In particular, different features of different embodiments may be substituted as needed.

[0164] In the claims, the term “comprising” does not preclude other elements or steps, and the indefinite article “a” or “an” does not preclude the plural. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

Claims

1. An access point (AP) device that provides a wireless network identified by a Basic Service Set (BSS), Notification means for notifying one or more non-AP station devices in the BSS of a frame containing information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream, A storage means for storing information indicating the quality of service (QoS) expected to be applied to the traffic stream, associated with the traffic identifier, A receiving means that receives the need for radio resources to communicate latency-sensitive traffic streams from a non-AP station device that has received the aforementioned notification, A scheduling means that schedules radio resources so that a non-AP station device that transmitted the aforementioned needs can preferentially perform communication within a predetermined period using the information indicating the QoS associated with the traffic identifier, and a traffic stream corresponding to the traffic identifier. It has, The access point device is characterized in that the frame includes multiple sets of information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream.

2. The access point device according to claim 1, wherein the radio resources scheduled by the scheduling means are used by the non-AP station device to perform direct link (DiL) communication using information indicating the QoS held in association with the traffic identifier of the delay-sensitive traffic stream.

3. The aforementioned predetermined period is the Target Wake Time (TWT) Service Period. The access point device according to claim 1, characterized in that the scheduling means schedules the TWT Service Period and the bandwidth of the wireless resources provided in the TWT Service Period.

4. The access point device according to claim 3, characterized in that the scheduling means schedules the TWT Service Period and the bandwidth based at least on reports obtained from one or more non-AP station devices.

5. A method for controlling an access point (AP) device that provides a wireless network identified by a Basic Service Set (BSS), A notification step of notifying one or more non-AP station devices in the BSS of a frame containing information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream, A retention step of storing information indicating the quality of service (QoS) expected to be applied to the traffic stream, associated with the traffic identifier, A receiving step of receiving the need for radio resources to communicate a latency-sensitive traffic stream from a non-AP station device that has received the aforementioned notification, A scheduling step in which a non-AP station device that transmitted the aforementioned needs schedules radio resources so that the traffic stream corresponding to the traffic identifier can be preferentially communicated within a predetermined period using the information indicating the QoS associated with the traffic identifier. It has, The control method is characterized in that the frame includes multiple sets of information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream.

6. The control method according to claim 5, wherein the radio resources scheduled in the scheduling step are used by the non-AP station device to perform direct link (DiL) communication using information indicating the QoS held in association with the traffic identifier of the delay-sensitive traffic stream.

7. The aforementioned predetermined period is the Target Wake Time (TWT) Service Period. The control method according to claim 5, characterized in that the scheduling step involves scheduling the TWT Service Period and the bandwidth of the wireless resources provided in the TWT Service Period.

8. The control method according to claim 7, characterized in that, in the scheduling step, the TWT Service Period and the bandwidth are scheduled based at least on reports obtained from one or more non-AP station devices.

9. A computer included in an access point device that provides a wireless network identified by the Basic Service Set (BSS) A notification procedure for notifying one or more non-AP station devices in the BSS of a frame containing information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream, A retention procedure for storing information indicating the quality of service (QoS) expected to be applied to the traffic stream in a retention means, associated with the traffic identifier, A receiving procedure for receiving the need for radio resources to communicate latency-sensitive traffic streams from a non-AP station device that has received the aforementioned notification, A scheduling procedure which involves a non-AP station device that transmitted the aforementioned needs scheduling radio resources so that the traffic stream corresponding to the traffic identifier can be preferentially communicated within a predetermined period using the information indicating the QoS associated with the traffic identifier, and A program to execute, The program is characterized in that the frame includes multiple sets of information indicating a traffic identifier that should be classified as a delay-sensitive traffic stream.

Images