Method and apparatus for managing low latency data transmission in a wireless network

Abstract

A method and apparatus for managing low latency data transmission in a wireless network. 802.11be wireless networks implement 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 pending traffic and associated QoS through the transmission of management frames to non-AP stations. The AP guarantees the declared QoS applicable to each type of declared traffic profile by scheduling appropriate resources to the LLRS traffic configurations. Monitoring the correct usage of scheduled resources by non-AP stations helps to avoid misuse. Multiple LLRS traffic configurations can be defined in parallel in the same frame using a sequential listing or inheritance procedure.

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 have been widely deployed to provide various communication services such as voice, video, packet data, messaging, and broadcasting. These wireless networks can be multi-connection networks that can accommodate 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 numerous 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 issues 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 terminal device within the range of 2 ms latency.

[0005] Such problems are currently being considered by the IEEE 802.11 working group as a major objective in issuing the next major 802.11 release, known as 802.11be or "Extremely High Throughput" (EHT).

[0006] Low-latency high-reliability service (LLRS) is defined as a target for such major objectives. LLRS is a service provided to upper-layer traffic streams that preferentially carry MSDUs (data units) within the range of worst-case latency budgets with a given reliability / packet delivery ratio (PDR) and low jitter. The traffic streams prioritized by this LLRS are named LLRS traffic.

[0007] Several low-latency (LL) criteria are being considered to prioritize LLRS traffic within a basic service set (BSS) managed by an access point (AP) station from the perspective of meeting quality of service (QoS) constraints.

[0008] Several LL criteria have been proposed for the case where the AP schedules a protected and restricted 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) not participating in LLRS traffic must stop their current transmission opportunities (TXOPs) before the start of the protected TWT service period from the perspective of reducing their impact on the network.

[0009] Another non - limiting example of the LL criterion is applied by a non - AP station (active station) that radiates or receives LLRS traffic. For example, specific LLRS resources such as frequency, time, or spatial resources are allocated and used for LLRS traffic by an AP station. An example where a TID greater than 7 is used to signal network resources for LLRS traffic is provided in the IEEE802.11 - 20 / 0418r4 document.

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

Summary of the Invention

[0011] The present invention is devised to address one or more of the above - mentioned concerns.

[0012] It is, firstly, a communication method in a wireless network, at an access point (AP) station of a basic service set (BSS), declaring one or more QoS parameters applicable to traffic that matches a defined traffic profile to one or more non - AP stations; scheduling resources of the wireless network for traffic that matches the defined traffic profile in the BSS based on the applicable declared QoS parameters; and relates to a communication method including these.

[0013] A set consisting of a traffic profile and associated applicable QoS parameters forms one configuration of LLRS traffic, hereinafter referred to as the LLRS traffic setting.

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

[0015] In fact, the AP station can first receive the needs of the non-AP station in terms of LLRS traffic that matches one or more traffic profiles (e.g., through a dedicated buffer status report (BSR) procedure). Then, the AP station can determine the wireless resources (e.g., multi-user uplink resource units) in terms of bandwidth and period to guarantee the QoS applicable to the considered traffic profile to the non-AP station given each need.

[0016] The present invention relates to a communication method in a wireless network, at a non-access point (AP) station, receiving from an AP station of a basic service set (BSS) a frame declaring one or more QoS parameters applicable to traffic that matches a defined traffic profile; accessing, for the traffic that matches the defined traffic profile, to receive or transmit the traffic, the resources of the wireless network scheduled by the AP in the BSS; and also relates to a communication method including the above.

[0017] In this way, the non-AP station will recognize that the LLRS traffic setting, that is, using its own QoS constraints, the traffic of that LLRS traffic setting should be processed as LLRS traffic by the AP station. And the non-AP station can use the appropriate scheduled resources provided by the AP station.

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

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

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

[0021] In other embodiments, the announcement includes using a management frame, such as a beacon frame or an action frame, transmitted by the AP station to the non-AP station of the BSS. In this way, the AP station can dynamically advertise and change the LLRS traffic setting (traffic profile and corresponding QoS constraints) during the lifetime of its BSS, for example, according to the network load. And the non-AP station that receives the management frame can adapt its behavior and, if appropriate, even decide to move to another 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 enables reducing 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. In this way, 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 data or traffic in question.

[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. In this way, the AP station declares a plurality of LLRS traffic settings. The 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 next QoS parameters for the next 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 next LLRS traffic settings.

[0031] In an embodiment related to the AP station, scheduling is performed in response to detecting the needs of one or more of the stations (i.e., itself or any other non-AP station) for transmitting traffic that matches the defined traffic profile. This may depend, for example, on the AP station detecting local LLRS traffic in its memory or receiving a buffer status report indicating LLRS traffic (or needs) from a non-AP station. And, as described above, the AP station determines the radio resources (e.g., multi-user uplink resource units) in terms of bandwidth and duration that are provided (i.e., scheduled) to each non-AP station given its respective needs in order to guarantee the QoS applicable to the traffic profile under consideration.

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

[0033] In some embodiments, scheduling includes scheduling a protected Target Wake Time (TWT) service period for traffic that matches the defined traffic profile. Thus, the TWT service period is provided in relation to a given LLRS traffic setting.

[0034] In other embodiments, a frequency, time, or spatial resource (e.g., a resource unit in a multi-user OFDMA technique) is provided by the AP station as a random RU or as a scheduled RU assigned to a particular non-AP station for traffic that matches the defined traffic profile.

[0035] In some embodiments, the method further includes monitoring, at the AP station, use of the scheduled resources on which the traffic matching the defined traffic profile is transmitted.

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

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

[0038] In other embodiments, the method further includes, at the non-AP station, declaring to the AP station local traffic that matches the defined traffic profile. The declaration can include the amount of such local traffic to assist the AP station in determining the resources to be scheduled to achieve applicable QoS.

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

[0040] At least a part of the method according to the present invention can be implemented by a computer. Thus, the present invention can take the form of an all - hardware embodiment, an all - software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software aspects and hardware aspects that can generally be referred to here as "circuits", "modules", or "systems". Further, the present invention can take the form of a computer program product incorporated in any tangible expression medium having computer - usable program code incorporated therein.

[0041] Since the present invention can be implemented in software, the present invention can be embodied as computer - readable code for providing to a programmable device on any suitable carrier medium. Tangible non - transitory carrier media can include storage media such as floppy disks, CD - ROMs, hard disk drives, magnetic tape devices, or solid - state memory devices. Transitory carrier media can include electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals such as microwave or RF signals. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Here, embodiments of the present invention will be described by way of mere example with reference to the following drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7a

Figure 7b

Mode for Carrying Out the Invention

[0043] The techniques 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. An SDMA system can utilize sufficiently different directions to transmit data belonging to multiple user terminals, i.e., wireless devices or stations, in parallel. A TDMA system can enable multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each of which is assigned to a different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that divides the entire system bandwidth into orthogonal subcarriers or resource units. These subcarriers can also be referred to as tones, bins, etc. Using OFDM, each subcarrier can be independently modulated with data. An SC-FDMA system can utilize interleaved FDMA (IFDMA) that transmits over subcarriers dispersed across the system bandwidth, localized FDMA (LFDMA) that transmits over a single block of adjacent subcarriers, or enhanced FDMA (EFDMA) for transmitting over multiple blocks of adjacent subcarriers.

[0044] The teachings herein can be incorporated (e.g., implemented therein or executed thereby) into various apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein can include an access point (so-called AP) or otherwise (so-called non-AP station or STA).

[0045] Although an example is described in the context of a WiFi (registered trademark) 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, for example.

[0046] AP includes, is implemented as, or is 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), Transmission Function (TF), Wireless Router, Wireless Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or some other terms.

[0047] Non-AP Station includes, is implemented as, or is known as, Subscriber Station, Subscriber Unit, Mobile Station (MS), Remote Station, Remote Terminal, User Terminal (UT), User Agent, User Device, User Equipment (UE), User Station, or some other terms. In some implementations, the STA may include a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, Personal Digital Assistant (PDA), handheld device with wireless connectivity, or some other suitable processing device connected to a wireless modem. Thus, one or more aspects taught herein may be incorporated into a phone (e.g., cellular phone or smartphone), computer (e.g., laptop), tablet, portable communication device, portable computing device (e.g., personal digital assistant), entertainment device (e.g., music or video device or satellite radio), Global Positioning System (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such a wireless node may provide connectivity to, or for, a network (e.g., a wide area network such as the Internet or a cellular network) via, for example, a wired or wireless communication link.

[0048] An AP manages a set of stations that collectively orchestrate access to the wireless medium for communication. Stations (including the AP), which may be referred to by other terms, form a service set, hereinafter called a Basic Service Set (BSS). The same physical station operating as an access point may manage two or more BSSs (and thus the corresponding WLANs), with each BSS uniquely identified by a specific Basic Service Set Identifier (BSSID) and managed by a separate virtual AP implemented within the physical AP.

[0049] A Low Latency High Reliability Service (LLRS) is a service provided to upper layer traffic streams that has a given reliability / Packet Delivery Ratio (PDR) and low jitter, and preferentially transports MSDUs (data units of this data stream) within the worst-case latency budget. Traffic that may be relevant to LLRS includes latency-sensitive data, i.e., data from applications such as gaming, media streaming, augmented reality, virtual reality, etc.

[0050] FIG. 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 a central station or access point (AP) 100 during an association procedure in which the AP assigns a unique Association Identifier (AID) to the requesting non-AP station. For example, an AID, a 16-bit value that uniquely identifies a non-AP station as an example, may be used to identify a station in the exchanged frame. The 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 of the figure, non-AP station 101 has not yet associated with AP 110, but has the intention to associate with AP 110 by initiating the association procedure via the transmission of a probe request frame or by continuing the association procedure following the reception of a probe response frame broadcast by the subsequent AP.

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

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

[0055] Stations 101 to 107, 110 may compete with each other using EDCA (Enhanced Distributed Channel Access) contention to acquire access to the wireless medium 100 in order to transmit (single user (SU)) data frames upon receiving a transmission opportunity (TXOP). A station may use a multi-user (MU) procedure, in which a single station, typically AP 110, can schedule MU transmissions, i.e., multiple parallel transmissions to or from other stations, during the TXOP granted in the wireless network. One implementation of such an MU procedure is compliant, for example, with the IEEE 802.11ax amendment standard as multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedures. Thanks to the MU function, non-AP stations have the opportunity to acquire access to the wireless medium through two access procedures: the MU procedure and the conventional enhanced distributed channel access - EDCA (single user) procedure.

[0056] During MU DL transmission on the granted communication channel, the AP performs multiple parallel basic transmissions on so-called resource units (RUs) for various non-AP stations. As an example, resource units divide the communication channel of the wireless 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 the association identifier (AID) of the non-AP station for each RU defined in the transmission opportunity (individually obtained by each station during the association procedure with the AP).

[0057] During 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 transmission by non-AP stations, the AP either transmits a control frame known as a trigger frame (TF) beforehand, or uses the TRS control subfield (representing Trigger Response Scheduling) in the DL data frame transmitted by the AP beforehand. The trigger frame or TRS allocates resource units to non-AP stations in the same BSS using the association identifiers (AIDs) assigned to them upon registration with the AP and / or using reserved AIDs that specify groups of non-AP stations. Also, the TF determines the start and length of MU UL transmission by non-AP stations.

[0058] Quality of Service (QoS) management is introduced at the station level in a wireless network through the well-known EDCA mechanism defined in the IEEE802.11e standard. The EDCA (Enhanced Distributed Channel Access) mechanism defines four traffic access categories (ACs) or 'priorities' to manage access to the medium, which are 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 corresponding traffic as data frames such as MSDUs or A-MSDUs transmitted over the network. A data frame arriving from an upper layer of the protocol stack, i.e., an MSDU, is given an 802.1D priority or user priority (UP) or a traffic type (abbreviation for traffic identifier TID) with a value in the range of 0 to 7. Based on the TID, the MSDU is mapped to one of the four AC queues / buffers using a mapping rule and stored in the mapped AC buffer. Of course, a different number of traffic queues can be assumed.

[0060] Returning to FIG. 1, the non-AP station may represent various devices such as a gaming client, an extended reality / virtual reality headset, a smartphone, a wireless display, etc., some of which need to exchange (i.e., transmit or receive) traffic with more restricted QoS requirements for PDR, jitter, and latency over time, for example, different from other traffic coexisting within the WLAN 100.

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

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

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

[0064] All these LL operations are known as the low latency high reliability service (LLRS) of the AP, and, for example, within the range of worst-case latency including a given reliability / packet delivery ratio (PDR) and low jitter (and more generally QoS constraints), prioritize the conveyance of MSDUs (data units) of LLRS traffic.

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

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

[0067] Another LLRS can consist of providing a RU or transmission link dedicated only to LLRS traffic.

[0068] Guaranteeing QoS constraints for LLRS traffic is a difficult task for the AP110 that manages the BSS. In fact, the state of the network can change over time, the BSS can expand or contract, and multiple simultaneous BSSs or legacy stations outside the BSS can appear and occupy the wireless medium, more or less.

[0069] Thus, the ability of an AP to meet QoS constraints for LLRS traffic can evolve. Therefore, it is appropriate for the AP to dynamically regulate QoS constraints and / or related traffic, that is, more generally, to dynamically adjust the LLRS traffic settings.

[0070] Therefore, there is a need for the wireless network to provide enhanced QoS management, especially with respect to LLRS traffic.

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

[0072] Next, for example, based on the needs of the stations regarding LLRS traffic, the AP schedules the resources of the wireless network to traffic that matches the defined traffic profile within the BSS, based on the applicable declared QoS parameters. With more stringent QoS and more LLRS traffic, more resources can be scheduled for transmission. Subsequently, the scheduled resources can be accessed by the stations either for the stations to transmit their own LLRS traffic or to receive LLRS traffic. Such LLRS traffic can be UL, DL, or even DiL traffic.

[0073] Advantageously, the AP110 may define a plurality of LLRS traffic settings, i.e., a plurality of sets of traffic characteristic values and a plurality of individual sets of applicable QoS parameters or requirements.

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

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

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

[0077] A dedicated information element (IE), called the LLRS IE, can be used to advertise one or more LLRS traffic settings, i.e., a combination of a traffic profile (defining the traffic of interest) and associated QoS constraints or parameters. The LLRS IE can simply complement existing IEs within a management frame.

[0078] Figure 4a shows an exemplary LLRS IE 400 consisting of type-length-value (TLV) fields. Of course, it is possible to arbitrarily combine one or more of these parts. 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 of the figure, the Element ID subfield 401 identifies that the IE 400 is an LLRS IE according to an embodiment of the present invention. This can take a value in the range [245 - 254] that has been reserved in the 802.11 standard so far. For illustrative purposes, in some embodiments, the value 247 can be selected.

[0080] The Length subfield 402 indicates the number of bytes forming the LLRS IE 400 including the Element ID subfield 401 and the Length subfield 402.

[0081] The LLRS traffic Configuration subfield 403 includes one or more LLRS traffic settings specified by the AP 110. The number of LLRS traffic settings defined by the AP can vary. For example, a single LLRS traffic setting can be defined. Of course, if the AP desires to provide various QoS for various types of data / traffic, multiple LLRS traffic settings (i.e., with 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 FIG. 5.

[0083] In the above variation, the advertisement can be provided to already associated non-AP stations such as stations 102 to 107, i.e., during the operation of the BSS. This is advantageous in that it allows the AP 110 to adjust or modify the LLRS traffic settings over time, for example when the network state evolves.

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

[0085] The declaration of one or more LLRS traffic settings in the beacon frame can be done, as described above with reference to FIG. 4a, i.e., using the LLRS IE 400.

[0086] As far as action frames are concerned, a new category of action frames carrying LLRS traffic settings may be defined.

[0087] Figure 4b shows the structure of the action frame defined in section 9.6 of the standard P802.11-REVmd / D5.0. This includes an action field 450 that 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" verified in the 802.11be (v0.3) standard. This can take a value within the range [21-125] that has been reserved in the 802.11 standard so far. For illustration, in some embodiments, the value 21 can 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-125] that has been reserved in the 802.11be (v0.3) standard so far. For illustration, in some embodiments, the value 1 can be selected. This enables a non-AP station receiving the frame to directly understand that the frame contains one or more LLRS traffic configurations (in subfield 453).

[0090] Similar to the above-mentioned LLRS traffic Configuration subfield 403, the Action Body subfield 453 contains one or more LLRS traffic configurations specified by the AP110, and an exemplary implementation thereof will be described with reference to Figure 5.

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

[0092] Basically, the LLRS traffic setting combines a traffic profile with applicable QoS constraints or parameters. The traffic profile defines which data or traffic is relevant in the definition of this LLRS traffic setting, i.e., it defines the data or traffic to which QoS is applicable. This is for this type of traffic that the AP110 guarantees (matches the traffic profile).

[0093] Traffic is defined by traffic characteristics. They are, for example, a list of parameters that characterize the relevant traffic.

[0094] Exemplary and non - exhaustive 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, discard period.

[0095] The traffic type defines the type of traffic or data, for example, according to the upper - layer application. For example, as defined in the IEEE802.11 - 20 / 1852r1 document, 0 can be set 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 MSDUs allowed within the service interval.

[0097] The minimum / maximum service interval is the arrival - time interval of the minimum / maximum MSDUs.

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

[0099] The discard period is the maximum period of the MSDU, as defined, for example, in the IEEE802.11-20 / 1693r1 document, after which the transmitter must discard the MSDU.

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

[0101] On the other hand, the QoS parameter is a value representing the transmission constraints that the AP must guarantee through appropriate scheduling of network resources.

[0102] Exemplary and non-exhaustive QoS parameters include latency bounds, jitter, and packet delivery ratio (PDR) proposed in the IEEE802.11-20 / 0418r4 document.

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

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

[0105] The packet delivery ratio (PDR) is the percentage of MSDUs transmitted within the range of the delay bounds specified in the latency bounds. The PDR may be defined as the maximum PDR value or the average PDR value, etc.

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

[0107] Thus, each LLRS traffic setting can be composed of an LLRS traffic setting identifier, a set (or list) of one or more traffic characteristic values (traffic profile), and a set (or list) of one or more applicable QoS parameters.

[0108] The traffic profile may be predefined, in which case the AP110 can simply refer to them using, for example, unique identifiers. The traffic profile may be dynamically defined by the AP110 over time.

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

[0110] FIG. 5a shows an embodiment for sequentially defining (if multiple exist) an LLRS traffic setting 510. These embodiments enable advertising 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 setting 510 is declared with an LLRS setting index field 520, a traffic profile field 522, and a QoS parameter field 523.

[0113] The LLRS traffic settings 510 according to the two formats may be combined within the same frame, in which case appropriate signaling of the format used is performed.

[0114] The LLRS setting index field 520 carries an identifier or index of the LLRS traffic setting 510. It is a value assigned by the AP110 to uniquely identify each LLRS traffic setting. During operation, this identifier can be used within an 802.11 frame, in the payload, to indicate the LLRS traffic setting corresponding to the traffic being transmitted. Also, this can be used by the AP110 to tag each of the scheduled network resources with the specific (or alternative) LLRS traffic setting that defines the type of traffic permitted. Typically, the assignment of the identifier can be performed by the AP in an incremental manner.

[0115] The pre - defined LLRS setting index field 521 refers to pre - defined LLRS traffic settings. Thus, the first format of Figure 5a performs the declaration of the LLRS traffic setting by identifying an index that refers to a pre - defined LLRS setting that associates a defined traffic profile and QoS parameters.

[0116] Typically, the pre - defined LLRS traffic settings are issued from a table that stores a set of pre - defined LLRS traffic settings. Such a table is stored in the memory module of each station. An exemplary table 600 is shown in Figure 6.

[0117] Table 600 includes a list of pre - defined LLRS traffic settings 610.

[0118] Each of the pre - defined 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 the traffic that matches the associated traffic profile.

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

[0120] The QoS parameters 622 include QoS constraints applicable to the traffic profile 621. A list of QoS parameters may be provided or defined, and for each of the QoS parameters, a field is provided where a value is defined if applicable. Exemplary QoS parameters are provided above.

[0121] Returning now to the second format of FIG. 5a, the traffic profile field 522 includes traffic characteristic values for defining the relevant data or traffic (similar to field 621). Similarly, the QoS parameter field 523 includes QoS constraints applicable to any traffic that matches the traffic profile of field 522 (similar to field 622).

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

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

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

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

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

[0127] The inherited LLRS traffic setting 570 follows an inheritance format. This is defined by referring to the main (or one main) LLRS traffic setting 560. This means that the next LLRS traffic setting (i.e., the next QoS parameter for the next defined traffic profile) is defined as an inheritance from the previous (here the main) LLRS traffic setting (i.e., the previous QoS parameter for the previously defined traffic profile).

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

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

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

[0131] Inheritance involves the declaration of replacement values in the next (here, inherited) LLRS traffic setting (i.e., the next set of QoS parameters for the traffic profile to be defined next) that replace one or more QoS parameter values and traffic characteristic values of the previous (here, main) LLRS traffic setting (i.e., the previous QoS parameters and defined traffic profile).

[0132] Returning to FIGS. 2 and 3, when the above-mentioned advertising frame is ready, at step 200, the frame is transmitted by AP110. At 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 may be multicast or broadcast to a group of non-AP stations, for example, using an action frame. Also, during the association procedure, it may be unicast to stations that are not yet associated, for example, using a probe response frame.

[0134] A non-AP station that has received one (or more) advertising frames here recognizes LLRS traffic that guarantees the declared QoS by using an appropriate LLRS mechanism for the AP 110 to schedule resources.

[0135] A station that has not yet associated and is looking for a BSS that processes specific LLRS traffic (i.e., QoS for specific LL data) can check whether this specific LLRS traffic is managed by the AP of the BSS by reading the declared LLRS traffic settings. If the specific LLRS traffic matches any of the declared LLRS traffic settings, the station can decide to complete the association with that BSS. On the other hand, if the specific LLRS traffic does not match any of the declared LLRS traffic settings, the station can decide not to complete the association with that BSS. Therefore, the decision of whether to associate with a BSS can be based on the LLRS traffic settings declared by the AP.

[0136] Next, the associated non-AP station can determine in step 305 whether there is LLRS traffic to be transmitted (e.g., in the transmit buffer or as the needs declared by the upper-layer application). Step 305 can simply check whether the station has traffic that matches any of the traffic profiles of the declared LLRS traffic settings 510 / 560 / 570.

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

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

[0139] This signaling of the LLRS needs by the non-AP station helps the AP to efficiently schedule appropriate network resources for the station to meet the applicable declared QoS parameters for all of the declared LLRS traffic settings. Also, this enables analyzing changes in network load and adapting the LLRS traffic settings as needed. For example, when the network state changes, the QoS parameters may be changed. Also, when the network state deteriorates excessively, the LLRS traffic settings may cease to exist (and thus be removed), and when the network state improves sufficiently, new LLRS traffic settings may be declared or reactivated.

[0140] In step 205, AP110 receives and collects all the needs from various non-AP stations. Since the non-AP stations may be polled periodically to obtain a BSR, this step may be continuously executed over time.

[0141] Based on the needs of the collected LLRS, at step 210, AP110 determines network resources in terms of the bandwidth and period provided for the LLRS traffic setting in order to guarantee the declared QoS constraints. Next, AP110 schedules the determined network resources.

[0142] For example, one or more protected TWT service periods dedicated to one or more received LLRS traffic settings of the station may be provided. Alternatively, or in combination, specific resource units for the LLRS traffic setting may be provided in MU OFDMA transmission. Of course, any manner of scheduling network resources for stations having LLRS needs can be used.

[0143] More generally, a low-latency operation of scheduling resources specific to such LLRS traffic that prioritizes such LLRS traffic over conventional 802.11e AC traffic can be assumed. This includes high-reliability services of the LL at the AP.

[0144] The scheduled resources can be individually tagged with the identifier of the LLRS traffic setting (see field 520) that defines the traffic permitted in the resource.

[0145] After step 210, the AP, at step 215, operates the scheduled resources. This can include the transmission of LLRS data (DL transmission) to one or more non-AP stations and / or the reception of LLRS traffic (UL transmission) from such non-AP stations.

[0146] On the one hand, a non-AP station related to LLRS traffic detects the scheduled LLRS resources in step 310. This can be, in particular, the resources allocated to it (e.g., the RUs scheduled in MU OFDMA transmission), or the common resources that need to compete to access it. Each scheduled LLRS resource may be tagged with an indication of the LLRS traffic configuration, and thus the type of data that the station is permitted to transmit or receive on the resource is restricted.

[0147] If the scheduled resource can operate positively, the next step consists of operating the scheduled resource by 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 for transmitting it (step 320), and either transmitting such matching LLRS traffic on the scheduled resource (UL or DiL transmission) (step 325). In other words, the non-AP station determines that the local traffic matches the defined traffic profile and accordingly accesses the scheduled resource to transmit the local traffic.

[0148] Steps 215, 315 to 325 are repeated over time when the AP 110 schedules new network resources for LLRS traffic, so as to ensure that the declared QoS is met.

[0149] To avoid improper use of scheduled resources, the AP 110 may, in step 220, optionally monitor the use of scheduled resources and, in particular, monitor that the traffic sent there conforms to an applicable defined traffic profile.

[0150] This can be done by analyzing the data sent and verifying that it conforms to the traffic profiles associated with the LLRS traffic settings assigned to the scheduled resources. For example, the AP checks whether a stream of packets sent on a scheduled resource has traffic characteristics that conform to the traffic profile.

[0151] When the AP detects a non-AP station that has sent traffic that does not conform to the traffic profile defined for the scheduled resource (test 225), in step 230, a corrective action is applied to the detected misbehaving non-AP station. The corrective action may consist only of withholding (or temporarily withholding) new scheduled resources from the misbehaving non-AP station, either for any LLRS traffic or only for the misbehaving LLRS traffic. An alternative corrective action may consist of disconnecting the misbehaving non-AP station from the BSS. Of course, other corrective actions are also conceivable.

[0152] FIG. 7a schematically shows a communication device 700, which is either a non-AP station 101-107 or an AP 110 of a 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, a workstation, or a lightweight portable device. The communication device 700 preferably has a communication bus 713 to which the following are connected: A central processing unit 701, such as a processor represented as a CPU; A memory 703 for storing executable code of a method or steps of a method according to an embodiment of the present invention, and registers adapted to record variables and parameters necessary for executing the method; and At least one communication interface 702 connected to a wireless communication network, for example a communication network according to any of the standards of the IEEE802.11 family, via a transceiver antenna 704.

[0153] Preferably, the communication bus is included in or connected to the communication device 700, and provides communication and interoperability between various elements. The representation of the bus is not limiting, and in particular, the central processing unit is operable 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 any of a memory, a hard disk, or a removable digital medium such as a disk, which may be read-only. According to an optional variant, the executable code of the program can be received by a communication network via the interface 702 so as to be stored in the memory of the communication device 700 before being executed.

[0155] In one embodiment, the device is a programmable device that uses software to implement an embodiment of the present invention. However, alternatively, embodiments of the present invention may be implemented in whole or in part in hardware (e.g., in the form of an application specific integrated circuit (ASIC)).

[0156] FIG. 7b is a block diagram schematically showing the architecture of a communication device 700 which is either the AP 110 or one of the stations 101 to 107 adapted to execute at least partially 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, usually the 802.11 standardized PHY layer) has the tasks of formatting, modulating on any 802.11 channel, or demodulating from an 802.11 channel, and thus transmits or receives frames via the wireless medium 100 used, such as 802.11 frames like management frames and MPDUs.

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

[0159] Preferably, an additional block 725 called the LLRS management module implements part of the embodiments of the present invention (from the perspective of the station or from the perspective of the AP). This block executes the operations of FIG. 2 or FIG. 3 according to the role of the communication device 700.

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

[0161] At the upper part of the figure, the application layer block 721 executes an application that generates and receives data packets, such as data packets like video streams, video games, etc. The application layer block 721 represents all stack layers above the MAC layer according to ISO standardization.

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

[0163] By referring to the above exemplary embodiments, those skilled in the art will naturally come up with many further changes and modifications. The above exemplary embodiments are shown only as examples and are not intended to limit the scope of the present invention, which is defined only by the appended claims. In particular, the different features of different embodiments may be exchanged as necessary.

[0164] In the claims, the term "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 used advantageously.

Claims

1. A communication method in a wireless network executed at an access point (AP) station of a basic service set (BSS), comprising: declaring information indicating a traffic setting selected from a plurality of predefined traffic setting candidates including a traffic profile and QoS parameters to one or more non-AP stations; scheduling, in the BSS, resources of the wireless network to traffic that matches the traffic profile included in the declared traffic setting based on the QoS parameters included in the declared traffic setting; A communication method including the above.

2. A communication method in a wireless network executed at a non-access point (AP) station, comprising: receiving, from an AP station of a basic service set (BSS), a frame declaring information indicating a traffic setting selected from a plurality of predefined traffic setting candidates including traffic profile information and QoS parameters; accessing, for the traffic, resources of the wireless network scheduled by the AP station in the BSS to receive or transmit traffic that matches the traffic profile included in the declared traffic setting; A communication method including the above.

3. The communication method according to claim 1 or 2, wherein the declaration is performed using a beacon frame or a probe response frame transmitted by the AP station during an association of the non-AP station with the AP station.

4. The communication method according to claim 1 or 2, wherein the declaration is performed using a beacon frame or an action frame transmitted by the AP station to the non-AP station of the BSS.

5. The declaring includes declaring an index that refers to the traffic profile and the traffic setting indicating the QoS parameters associated with the traffic profile, the communication method according to claim 1.

6. The declaring includes declaring a profile identifier that identifies the traffic profile and QoS parameters associated with the profile identifier, the communication method according to claim 1.

7. The declaring includes declaring one or more traffic characteristic values that define the traffic profile and the one or more QoS parameters associated with the traffic characteristic values, the communication method according to claim 1.

8. The one or more traffic characteristic values include a minimum value and a maximum value of the same traffic characteristic, the communication method according to claim 7.

9. The declaring includes declaring information indicating a plurality of sets of a traffic profile and QoS parameters, the communication method according to claim 1.

10. The QoS parameters included in the traffic setting newly declared for the one or more non-AP stations are defined by inheriting from the previously defined QoS parameters, the communication method according to claim 9.

11. The newly declaring the traffic setting for the one or more non-AP stations includes declaring the traffic setting including a replacement value that replaces one or more QoS parameter values, the previously defined QoS parameters, and traffic characteristic values of a traffic profile associated with the QoS parameters, the communication method according to claim 10.

12. The communication method according to claim 10, wherein the previously defined QoS parameter is a QoS parameter included in the previously declared traffic setting.

13. The communication method according to claim 1, wherein scheduling is performed in response to detecting a need for signaling an amount of data corresponding to a traffic profile included in the predefined traffic setting, which is a need declared by the non-AP station.

14. The communication method according to claim 1, wherein scheduling includes scheduling a protected Target Wake Time (TWT) service period for traffic matching the defined traffic profile, and the one or more non-AP stations stop the current transmission opportunity (TXOP) before the protected TWT service period starts.

15. The communication method according to claim 1, further including, at the AP station, monitoring whether a traffic profile of traffic transmitted during a scheduling period matches a traffic profile included in a traffic setting assigned to the scheduled resources.

16. The communication method according to claim 15, further including, at the AP station, applying a corrective measure to the detected non-AP station in response to detecting a non-AP station transmitting traffic that does not match a traffic profile included in a traffic setting assigned to the scheduled resources.

17. The communication method according to claim 2, further including, at the non-AP station, accessing the scheduled resources for transmitting the local traffic in response to determining that the local traffic matches a traffic profile included in a traffic setting indicated by the declared information.

18. The communication method according to claim 2, further comprising, in the non-AP station, declaring local traffic that matches a traffic profile included in a traffic setting indicated by the declared information to the AP station.

19. A program that causes a wireless device to execute the communication method according to claim 1 or 2 when executed by a microprocessor or a computer system in the wireless device.

20. A wireless communication device having at least one microprocessor configured to execute the steps of the communication method according to claim 1 or 2.

Images