Terminal equipment, base station equipment, and communication method

Abstract

Achieve efficient communication with a wireless LAN system. [Solution] A base station device having an AP MLD belonging to an SMD (Seamless Mobility Domain) transmits a frame containing a BSS Max Idle Period element, the BSS Max Idle Period element containing a Max Idle Period field, the Max Idle Period field being an unsigned integer containing the value of BSSMaxIdlePeriod, the BSSMaxIdlePeriod representing a time period, the SMD-ME applying the time period carried by the BSS Max Idle Period element at the SMD-ME level, and the SMD-ME using the time period to determine disassociation of a non-AP MLD.

Description

Technical Field

[0001] The present invention relates to a terminal device, a base station device, and a communication method. Background Art

[0002] Higher speed and higher frequency utilization efficiency of wireless LAN (Local Area Network) communication are being studied by IEEE (The Institute of Electrical and Electronics Engineers Inc.). Currently, standardization of IEEE802.11bn has been started as a successor standard to IEEE802.11be. Prior Art Documents Non-Patent Documents

[0003] IEEE802.11-23 / 1996r0, Po-Kai Huang (Intel), “Improve roaming between MLDs”, November 2023. Summary of Invention Problem to be Solved by Invention

[0004] The present invention provides a terminal device, a base station device, and a communication method that enable efficient communication. Means for Solving the Problem

[0005] (1) A first aspect of the present invention is a base station device having an AP MLD belonging to an SMD (Seamless Mobility Domain), comprising a transmitting unit that transmits a frame including a BSS Max Idle Period element, wherein the BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer including the value of BSSMaxIdlePeriod, BSSMaxIdlePeriod represents a time period, and in the SMD-ME, the time period carried by the BSS Max Idle Period element is applied at the SMD-ME level, and the SMD-ME uses the time period to determine disassociation of a non-AP MLD.

[0006] (2) A second aspect of the present invention is a communication method comprising the steps of: a base station device having an AP MLD belonging to an SMD (Seamless Mobility Domain) transmits a frame including a BSS Max Idle Period element; the BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer including the value of BSSMaxIdlePeriod, the BSSMaxIdlePeriod represents a time period; the SMD-ME applies the time period carried by the BSS Max Idle Period element at the SMD-ME level; and the SMD-ME uses the time period to determine disassociation of a non-AP MLD.

[0007] (3) A third aspect of the present invention is a terminal device having a Non-AP MLD, comprising a receiving unit that receives a frame including a BSS Max Idle Period element, wherein the BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer including the value of BSSMaxIdlePeriod, the BSSMaxIdlePeriod indicates a time period, and the terminal device transmits a frame to an SMD-ME that is associated with the SMD-ME within the time period indicated by the Max Idle Period field in order to avoid disassociation due to the SMD-ME not receiving the frame. [Effects of the Invention]

[0008] This enables the realization of an efficient wireless communication system. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of a wireless LAN system according to one aspect of this embodiment. [Figure 2] This figure shows an example of OBSS according to one aspect of this embodiment. [Figure 3] This diagram shows an example of the configuration of STA according to one aspect of this embodiment. [Figure 4] This diagram shows an example of the configuration of an AP according to one aspect of this embodiment. [Figure 5] This figure shows an example of a MAC frame format according to one aspect of this embodiment. [Figure 6] This figure shows an example of an A-MSDU according to one aspect of this embodiment. [Figure 7] This figure shows an example of an A-MPDU according to one aspect of this embodiment. [Figure 8]This figure shows an example of Fragmentation according to one embodiment. [Figure 9] This figure shows an example of a PPDU according to one aspect of this embodiment. [Figure 10] This figure shows an example of the MAC data plane architecture of an MLD according to one aspect of this embodiment. [Figure 11] This figure shows an example of a backoff procedure according to one aspect of this embodiment. [Figure 12] This figure shows an example of a NAV according to one aspect of this embodiment. [Figure 13] This figure shows an example of a transition execution procedure according to one aspect of this embodiment. [Figure 14] This figure shows an example of a transition execution procedure according to one aspect of this embodiment. [Figure 15] This figure shows an example of an SMD according to one aspect of this embodiment. [Figure 16] This figure shows an example of BSSMaxIdlePeriod processing of SMD-ME according to one aspect of this embodiment. [Figure 17] This figure shows an example of a non-AP MLD that receives BSSMaxIdlePeriod from an SMD-ME according to one aspect of this embodiment. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described below.

[0011] "A, and / or B" may be a term that includes "A", "B", or "A and B".

[0012] The wireless LAN system in the present embodiment includes an access point (AP) and a station (STA). A network constituted by an access point and a station is referred to as a BSS (Basic Service Set). The wireless LAN system may be constituted by one or more stations. When the wireless LAN system is constituted by two or more STAs, the wireless LAN system may be referred to as a BSS.

[0013] An access point (AP) may also be referred to as a base station device. A station (STA) may also be referred to as a terminal device. One base station device may include one or more APs. One base station device may include one or more AP MLDs. One base station device may include one or more Super MLDs. One base station device may include one or more Super AP MLDs. One base station device may include one or more APs, one or more AP MLDs, and / or one or more Super AP MLDs. One terminal device may include one or more STAs. One terminal device may include one or more non-AP STAs. One terminal device may include one or more non-AP MLDs. One terminal device may include one or more non-AP STAs, and / or one or more non-AP MLDs.

[0014] Figure 1 is a diagram illustrating an example of a wireless LAN system according to one aspect of the present embodiment. In Figure 1, the wireless LAN system includes STA 103, STA 104, and AP 102. 101 may be referred to as a BSS.

[0015] An STA may be a logical entity. This logical entity may be a logical entity that is a single addressable instance of the Medium Access Control (MAC) and physical layer interface to the wireless medium (WM). An STA may be a communication device over the wireless medium. An STA may also include an Access Point (AP) with base station functionality and / or a non-AP STA with terminal functionality. In other words, an STA may be an AP. An STA may also be a non-AP STA. An STA may also be both an AP and a non-AP STA. An STA may also be referred to as a terminal device.

[0016] The wireless medium may be the medium used to implement the transfer of Protocol Data Units (PDUs) between peer physical layer entities of a Wireless LAN. The wireless medium may be referred to as the medium. The medium may be referred to as Medium.

[0017] A channel may be an instance of a radio medium used to transmit PPDUs between two or more STAs.

[0018] The link may also be a physical path consisting of a single traversal of the wireless medium used to transfer the MSDU between the two STAs.

[0019] An AP may include one STA and be an entity that provides access to distribution system services (DSS) via a wireless medium to associated STA(s). An AP may include an STA and a distribution system access function (DSAF). An AP may be referred to as an STA. In other words, an AP may be an STA.

[0020] A non-AP STA (non-access point station) may be an STA that is not included in an AP. For example, a non-AP STA may be an HT STA, a VHT STA, a HE STA, an EHT STA, or a UHR STA. A non-AP STA may be any STA other than those mentioned above. A non-AP STA may also be simply called an STA.

[0021] Distribution system services may be a set of services provided by the distribution system (DS). The distribution system access function may be a function within the AP that uses MAC services and distribution system services to provide access between the distribution system and the wireless medium. The distribution system may also be a system used to interconnect a set of BSSs and an integrated LAN to create an Extended Service Set (ESS).

[0022] A BSS may consist of a set of STAs that have successfully synchronized using JOIN service primitives and a set of STAs that uses a START primitive. For example, MLME-JOIN.confirm may be used as the JOIN service primitive. MLME-JOIN.confirm may be a primitive for confirming synchronization with the BSS. MLME-JOIN.request may be used as the JOIN service primitive. MLME-JOIN.request may be a primitive for requesting synchronization with the BSS. For example, MLME-START.request may be used as the START primitive. MLME-START.request may be a primitive for requesting a MAC entity to start a new BSS. A primitive may be an internal signal in an STA or AP. An internal signal here may be an internal signal used for information exchange between entities at different layers or different protocols, such as between SME and MLME, between SME and PLME, between MLME and PLME, or between SMD-ME and MLME.

[0023] An ESS is a set of one or more interconnected BSSs, which may appear as a single BSS in the Logical Link Control (LLC) layer of an STA associated with any of these BSSs. An ESS (Extended Service Set) may have a connection path via a WM between one of the APs that are members of the ESS and a non-AP STA. An ESS may have overlapping communication areas (coverages) composed of multiple BSSs. The distances between the multiple BSSs in an ESS may be large, and the coverage covered by multiple BSSs may be arranged to form a wider coverage. In other words, the communication area of ​​an ESS may be the same as or larger than the communication area of ​​a single BSS. The communication area composed of an ESS may be referred to as an ESA (Extended Service Area).

[0024] An OBSS (Overlapping Basic Service Set) may be a BSS that operates on the same channel as the STA's BSS, and within (partially or entirely) its BSA (Basic Service Area).

[0025] Figure 2 is a diagram showing an example of OBSS according to one aspect of this embodiment. In Figure 2, 202 may be AP#1. 203 may be STA#1. 204 may be STA#2. 201 may be BSS#1 composed of 202, 203, and 204. 203 may be synchronized with 202. 204 may be synchronized with 202. 206 may be AP#2. 207 may be STA#3. 208 may be STA#4. 205 may be BSS#2 composed of 206, 207, and 208. 207 may be synchronized with 206. 208 may be synchronized with 206. 202 may not be synchronized with 207. 202 may not be synchronized with 208. 206 may not be synchronized with 203. 206 may not be synchronized with 204. 201 and 205 may be BSS operating on the same channel. 205 may be considered an OBSS to 201. 201 may be considered an OBSS to 205. For example, 202 may receive a frame transmitted by 207. 204 may receive a frame transmitted by 207. 207 may receive a frame transmitted by 202. 207 may receive a frame transmitted by 204. For example, 202 may determine that the channel is busy while 207 is transmitting. 204 may determine that the channel is busy while 207 is transmitting. 207 may determine that the channel is busy while 202 is transmitting. 207 may determine that the channel is busy while 204 is transmitting.

[0026] A BSA may be a region that includes members of a BSS. A BSA may also include members of other BSSs. For example, in Figure 2, 201 may be a BSA that includes 203, 204, and 207, where 207 may be a member of another BSS.

[0027] IBSS (Independent Basic Service Set) is a BSS that forms a self-contained network, and access to the DS is not available.

[0028] An addressable unit may be a station (STA). Physical and operational characteristics may be defined by modifiers placed before the term STA. For example, in the case of location or mobility, an addressable unit may be a fixed STA, a mobile STA, and a mobility STA. An STA is an addressable destination, but it does not (generally) have to be a fixed location. An STA may have several different characteristics, each of which may constitute its function. For example, a single addressable unit may simultaneously have the characteristics of a portable STA, a QoS STA, a dependent STA, and a hidden STA.

[0029] The architecture may consist of several components that interact to provide a WLAN that transparently supports the movement of STAs to higher layers. The BSS may be a fundamental component of the LAN. The range over which member STAs of the BSS can communicate may be considered the coverage area. The range of all possible directional transmissions by member STAs may be referred to as the BSA.

[0030] Physical limitations may determine the direct distance between STAs. An infrastructure BSS may be part of a network composed of multiple BSSs. The architectural component for interconnecting infrastructure BSSs may be a DS for non-GLK (General Link) operations. The DS and Extended Service Set (ESS) may be mechanisms for extending connectivity for non-GLK operations. GLK operations may involve using bridges to form an extended network. The radio medium and the DSM (Distribution System Medium) may be logically separated. Each logical medium may be used for different purposes by different components of the architecture. Recognizing that multiple media are logically different is important for understanding the flexibility of the architecture. The LAN architecture is specified independently of the physical characteristics of a particular implementation. The DS may enable support for mobile devices by providing logical services necessary for address-to-destination mapping and seamless integration of multiple BSSs. An AP is an entity with STA functionality and a DSAF (Distribution System Access Function), which may enable access to the DS via the radio medium for the associated STA. Data between the BSS and DS may travel via the DSAF within the AP. An AP may include an STA, and its STA address may be addressable on the radio medium. The address that the AP uses to communicate with the radio medium and the DSM does not necessarily have to be the same. Data sent from one of the STAs associated with the AP to the AP's STA address may always be received on an uncontrolled port and processed by a port access entity. If a controlled port is authorized, the frame may conceptually pass through the DS.

[0031] A DS Service Access Point (SAP) may be an interface between multiple DS SAP service users and a DS SAP service provider. DS SAP service users may be connected APs, meshgates, portals, and AP MLDs. A DS SAP service provider may be a DS.

[0032] DS SAP may perform some or all of the following actions: MAC service tuples are collections of MPDUs that may be delivered via DS between APs, mesh gates, ESS portals, and AP MLDs. Mapping updates may include updating the APs through which MAC service tuples delivered between STAs and DS. Mapping updates may include updating the mapping between the destination STA to which DS delivers MAC service tuples and the APs to which that STA connects. Mapping updates may include updating the mesh gates through which MAC service tuples delivered between STAs and DS. Mapping updates may include updating the mapping between the destination STA to which DS delivers MAC service tuples and the mesh gates to which that STA connects. Mapping updates may include updating the AP MLDs through which MAC service tuples delivered between non-AP MLDs and DS. Mapping updates may involve updating the mapping between the non-AP MLDs to which DS delivers MAC service tuples and the AP MLDs to which those non-AP MLDs connect. The DS-STA-NOTIFY primitive may be a primitive used for mapping updates. The DS-STA-NOTIFY primitive may be generated by an AP, meshgate, or AP MLD. APs, meshgates, and AP MLDs may use the DS-STA-NOTIFY primitive to request a mapping update from DS SAP. For example, DS-STA-NOTIFY.request may be used as the DS-STA-NOTIFY primitive. Mapping updates may also be referred to as DS mapping updates. a) Accept MSDUs (as part of MAC service tuples) from APs, Meshgates, Portals, and AP MLDs. b) Distribute the MSDU (as part of MAC service tuples) to APs, mesh gates, portals, or AP MLDs. c) Accept updates to the mapping between STA and AP from AP. d) Accept updates to the mapping between STA and mesh gate from the mesh gate. e) Accept updates to the mapping between non-AP MLD and AP MLD from AP MLD.

[0033] When DS distributes MAC service tuples to AP, AP may decide when and how to distribute the MAC service tuples to AP's MAC via MAC SAP. When DS distributes MAC service tuples to mesh gate, mesh gate may decide when and how to distribute the MAC service tuples to mesh gate's MAC via MAC SAP. When DS distributes MAC service tuples to AP MLD through DSAF, AP MLD may decide when and how to distribute the MAC service tuples to AP MLD's MLD upper MAC sublayer via MAC SAP.

[0034] Wireless networks of any size and complexity may be constructed using DS and infrastructure BSS. This network may be referred to as an ESS (Extended Service Set). An ESS is a collection of infrastructure BSSs connected by the same SSID, which may be connected by DS. An ESS does not necessarily contain a DS. To the LLC layer, an ESS may look the same as an IBSS. STAs within an ESS can communicate, and mobile STA(s) may move transparently between BSSs (within the same ESS) to the LLC. In an ESS, BSSs may partially overlap. This may be commonly used to position coverage within a physical range. In an ESS, BSSs may be physically separated. In an ESS, there may be no logical limit on the distance between BSSs. In an ESS, BSSs may be located in the same physical location. This may be done to provide redundancy. In an ESS, one or more IBSS(s) or ESS(s) may physically reside in the same location as one or more ESS(s).

[0035] Figure 3 shows an example of the device configuration of an STA according to one aspect of this embodiment. The STA may include an antenna unit SU1, an RF (Radio Frequency) unit SU2, a physical layer processing unit (PHY layer processing unit) SU3, a MAC layer processing unit SU4, and an upper layer packet processing unit SU5. The STA may also include a wireless transceiver unit SU6 and a frame processing unit SU7. The wireless transceiver unit SU6 may be configured to include the antenna unit SU1 and the RF unit SU2. The frame processing unit SU7 may be configured to include the physical layer processing unit SU3 and the MAC layer processing unit SU4. The RF unit SU2 receives wireless signals via the antenna unit SU1.

[0036] The signal received by the RF unit SU2 is converted into a baseband signal and sent to the physical layer processing unit SU3. The physical layer processing unit SU3 performs processing related to the physical layer function (PHY function) on the converted baseband signal. The signal that has undergone processing at the physical layer in the physical layer processing unit SU3 is sent to the MAC layer processing unit SU4. The MAC layer processing unit SU4 performs processing related to the MAC layer function (MAC function) on the baseband signal. The signal that has undergone processing at the MAC layer in the MAC layer processing unit SU4 is sent as an upper layer packet to the upper layer packet processing unit SU5. The upper layer packet processing unit SU5 performs processing related to the upper layer function on the upper layer packet extracted from the received signal.

[0037] The upper layer packet processing unit SU5 performs processing related to the functions of the upper layer when transmitting upper layer packets. The upper layer packet to be transmitted is sent from the upper layer packet processing unit SU5 to the MAC layer processing unit SU4. The MAC layer processing unit SU4 performs processing related to the functions of the MAC layer on the upper layer packet. The frame that has undergone MAC layer processing in the MAC layer processing unit SU4 (a frame generated by processing the upper layer packet) is sent to the physical layer processing unit SU3. The physical layer processing unit SU3 performs processing related to the functions of the physical layer on the frame that has undergone MAC layer processing. The frame sent from the physical layer processing unit SU3 to the RF unit SU2 is converted into an RF signal and transmitted as a wireless signal via the antenna unit SU1.

[0038] The processing of the physical layer processing unit SU3 may be controlled by a PLME (Physical Layer Management Entity), which is an entity that controls the physical layer. The processing of the MAC processing unit SU4 may be controlled by an MLME (MAC Layer Management Entity), which is an entity that controls the MAC layer. PLME and MLME provide their respective layer management service interfaces. PLME and MLME may also be controlled by an SME (Station Management Entity), which is an entity independent of the layer. PLME, MLME, and SME may be included in the frame processing unit SU7.

[0039] Figure 4 shows an example of the device configuration of an AP according to one aspect of this embodiment. The AP may include an antenna unit AU1, an RF unit AU2, a physical layer processing unit AU3, a MAC layer processing unit AU4, and a DSAF unit AU5. The DSAF unit AU5 may also have a higher layer packet processing function. The AP may also include a wireless transceiver unit AU6 and a frame processing unit AU7. The wireless transceiver unit AU6 may be configured to include the antenna unit AU1 and the RF unit AU2. The frame processing unit AU7 may be configured to include the physical layer processing unit AU3 and the MAC layer processing unit AU4.

[0040] The signal received by the RF unit AU2 is converted into a baseband signal and sent to the physical layer processing unit AU3. The physical layer processing unit AU3 performs processing related to the physical layer functions on the converted baseband signal. The signal that has undergone processing at the physical layer in the physical layer processing unit AU3 is sent to the MAC layer processing unit AU4. The MAC layer processing unit AU4 performs processing related to the MAC layer functions on the baseband signal. The signal that has undergone processing at the MAC layer in the MAC layer processing unit AU4 is sent to the DSAF unit AU5 as an upper layer packet. The DSAF unit AU5 performs processing related to the upper layer functions on the upper layer packet extracted from the received signal. The DSAF unit AU5 may also provide the upper layer packet to the DS.

[0041] The DSAF unit AU5 may acquire upper-layer packets from the DS. When transmitting upper-layer packets, the DSAF unit AU5 performs processing related to the functions of the upper layer. The upper-layer packets to be transmitted from the DSAF unit AU5 are sent to the MAC layer processing unit AU4. The MAC layer processing unit AU4 performs processing related to the functions of the MAC layer on the upper-layer packets. The frame that has undergone processing at the MAC layer in the MAC layer processing unit AU4 (a frame generated by processing the upper-layer packets) is sent to the physical layer processing unit AU3. The physical layer processing unit AU3 performs processing related to the functions of the physical layer on the frame that has undergone processing at the MAC layer. The frame sent from the physical layer processing unit AU3 to the RF unit AU2 is converted into an RF signal and transmitted as a radio signal via the antenna unit AU1.

[0042] The processing of the physical layer processing unit AU3 may be controlled by PLME. The processing of the MAC processing unit AU4 may be controlled by MLME. Furthermore, PLME and MLME may be controlled by SME, which is an entity independent of the layer. PLME, MLME, and SME may be included in the frame processing unit AU7.

[0043] An MLD (Multi-Link Device) may also be a logical entity that supports multiple affiliated STAs (STAs) and can be operated using multiple affiliated STAs. An affiliated STA may be an STA that provides link-specific MLD lower MAC sublayers and physical layer (PHY) services within the MLD. In other words, an affiliated STA may be an STA belonging to an MLD. An MLD may have two STAs. An MLD may have three or more STAs. An affiliated STA may be either an AP or a non-AP STA. An AP MLD (Access Point Multi-Link Device) may be an MLD in which each of the STAs belonging to the MLD is an AP. APs belonging to an AP MLD may be called affiliated APs (affiliated APs). A non-AP MLD (non-Access Point Multi-Link Device) may be an MLD in which each of the STAs belonging to the MLD is a non-AP STA. An MLO (Multi-Link Operation) may be an operation between two MLDs.

[0044] In MLD, the MAC layer may be divided into an MLD upper MAC sublayer and an MLD lower MAC entity. The MLD upper MAC sublayer may perform functions common to all links. The MLD lower MAC entity may be shared between the MLD and the APs or non-AP STAs belonging to that MLD. The MLD lower MAC entity may perform functions local to each link. Some functions may require joint processing by both the MLD upper MAC sublayer and the MLD lower MAC entity.

[0045] A Seamless Mobility Domain (SMD) may be defined. An SMD may cover multiple AP MLDs, and non-AP MLDs may use the Seamless BSS Transition described below to transition between AP MLDs within that SMD. An SMD may be a set of multiple BSSs. An SMD may be a set of multiple AP MLDs. An SMD may be a logical entity. The AP MLDs covered by an SMD may be called a series of AP MLDs, etc. A series of AP MLDs may be AP MLDs that provide MLD-specific MAC sublayers and / or physical layer (PHY) services within the SMD. An SMD may cover two AP MLDs. An SMD may cover three or more AP MLDs. An SMD may be referred to in ways other than SMD. For example, SMD may be referred to as Single Mobility Domain, Super MLD (Super Multi-Link Device), Seamless Transition Mobility Domain (STMD), Single Mobility Domain (SMD) MLD, Seamless Mobility Domain (SMD) MLD, Seamless Transition Mobility Domain (STMD) MLD, non-colocated MLD, virtual MLD, transition MLD, or roaming MLD, etc. Affiliated AP MLD may be referred to by a name other than Affiliated AP MLD. The mobility domain described below may include one or more SMDs.

[0046] An SMD Management Entity (SMD-ME) may be defined. The SMD-ME may be an entity that controls the SMD; that is, the SMD may be controlled by the SMD-ME. The SMD-ME may be a logical entity. The SMD-ME may provide association, an IEEE 802.1X authenticator, and RSNA key management to one or more non-AP MLDs across all AP MLDs in the SMD. Non-AP MLDs may migrate between AP MLDs within the SMD while maintaining their association with the SMD-ME and their security association. The SMD-ME may be referred to by other names.

[0047] The MAC layer of an SMD does not necessarily have to be divided into two or more MAC sublayers or MAC entities. The MAC layer of an SMD may be referred to as an SMD MAC entity, etc. An SMD MAC entity may be referred to by a name other than an SMD MAC entity. An SMD MAC entity may perform functions common to all MLDs. An SMD MAC entity may perform functions common to all AP MLDs of an SMD. An MLD upper MAC sublayer may be shared between an SMD and the AP MLDs that the SMD covers. An MLD upper MAC sublayer may perform functions local to each MLD. An MLD upper MAC sublayer may perform functions local to each AP MLD covered by the SMD. Some functions may require joint processing by both the SMD MAC entity and the MLD upper MAC sublayer.

[0048] In SMD, the MAC layer may be divided into an SMD upper MAC sublayer and an SMD lower MAC entity. The SMD upper MAC sublayer may be referred to by a name other than the SMD upper MAC sublayer. The SMD lower MAC entity may be referred to by a name other than the SMD lower MAC entity. The SMD upper MAC sublayer may perform functions common to all MLDs. The SMD upper MAC sublayer may perform functions common to all AP MLDs covered by the SMD. The SMD lower MAC entity may be shared between the SMD and the AP MLDs covered by the SMD. The SMD lower MAC entity may perform functions local to each MLD. The SMD lower MAC entity may perform functions local to each AP MLD covered by the SMD. The SMD lower MAC entity may perform some or all of the functions performed by the MLD lower MAC entity. In addition to or instead of this, the SMD lower MAC entity may perform some or all of the functions performed by the MLD upper MAC sublayer. The SMD lower MAC entity may also be an MLD lower MAC entity. Alternatively, the SMD lower MAC entities may be split into MLD upper MAC sublayers and MLD lower MAC entities. Some functions may require joint processing of both the SMD upper MAC sublayers and the SMD lower MAC entities.

[0049] The MLD upper MAC sublayer may be common to two or more AP MLDs. The MLD upper MAC sublayer common to two or more AP MLDs may be called the MLD common MAC sublayer, or the MLD common upper MAC sublayer, etc. The MLD common MAC sublayer may be referred to by names other than MLD common MAC sublayer. The MLD common MAC sublayer may perform functions common to all MLDs. The MLD common MAC sublayer may perform functions common to all AP MLDs covered by the same SMD. Alternatively, the MAC layer of an AP MLD may be divided into the MLD common MAC sublayer, the MLD upper MAC sublayer, and the MLD lower MAC entities. Some functions may require joint processing of both the MLD common MAC sublayer and the MLD lower MAC entities. Some functions may require joint processing of both the MLD common MAC sublayer and the SMD lower MAC entities. Some functions may require joint processing of both the MLD common MAC sublayer and the MLD upper MAC sublayer. Some functions may require the collaborative processing of three or more MAC sublayers or MAC entities, such as the MLD common MAC sublayer, the MLD upper MAC sublayer, and the MLD lower MAC entities.

[0050] An HT STA (High-Throughput STA) may provide PHY and MAC capabilities capable of supporting throughput of 100 Mb / s or more as measured at a MAC Data Services Access Point (SAP). An HT STA may also be a QoS STA. HT features may be utilized in an HT STA associated with an HT AP (High-Throughput AP). A subset of HT features may be used between two HT STAs that are members of the same IBSS. Some PHY features that distinguish an HT STA from a non-HT STA may be multiple-input multiple-output (MIMO) operation, spatial multiplexing (SM), spatial mapping (including transmit beamforming), spacetime block coding (STBC), low-density parity checking (LDPC) coding, and antenna selection (ASEL). The PPDU formats permitted in an HT STA may be non-HT format, HT-mixed format, and HT-greenfield format. In an HT STA, the PPDU may be transmitted with a 20 MHz bandwidth. In an HT STA, the PPDU may be transmitted with a 40 MHz bandwidth. The HT STA may have MAC functionality, including frame aggregation, several block ack features, low-power multipole (PSMP) operation, reverse direction (RD), and protection mechanisms to support coexistence with non-HT STAs.

[0051] A VHT STA (Very High-Throughput STA) may be an HT STA that supports VHT functions in addition to the functions supported by an HT STA. The main PHY functions of a VHT STA may support 40MHz and 80MHz channel widths. VHT single-user (SU) PPDUs may be supported as the main PHY functions of a VHT STA. 160MHz and 80+80MHz channel widths may be supported as the main PHY functions of a VHT STA. VHT multi-user (MU) PPDUs may be supported as the main PHY functions of a VHT STA. The main PHY functions of a VHT STA do not necessarily have to be present in an HT STA. A-MPDU padding of VHT PPDUs may be supported as the main MAC function of a VHT STA. S-MPDU may be supported as the main MAC function of a VHT STA. Bandwidth indication response may be supported as the main MAC function of a VHT STA. The main MAC functions of a VHT STA do not necessarily have to be present in an HT STA. The VHT function may be used in VHT STAs associated with a VHT AP (Very High-Throughput AP). A subset of the VHT function may be used between two VHT STAs that are members of the same IBSS.

[0052] The operating channel width may also be the channel width that the STA can currently receive.

[0053] A High Efficiency (HE) STA may also be a VHT STA if operating in the 5GHz band. A 20MHz-only HE STA may not support 40MHz and 80MHz channel widths. Support for a 20MHz operating channel width may be mandatory for a HE STA. A 20MHz-only non-AP HE STA may be required to support 40MHz and 80MHz operating channel widths. Support for 160MHz and 80+80MHz operating channel widths may be optional for a HE STA. A HE STA may also be an HT STA. The main PHY features of a HE STA that are not present in HT STAs or VHT STAs may include support for DL ​​and UL OFDMA (Up Link Orthogonal Frequency Division Multiple Access). The main PHY features of a HE STA that are not present in HT STAs or VHT STAs may include support for DL ​​MU-MIMO (Down Link Multi User Multiple Input Multiple Output) with an HE AP that supports four or more spatial streams when MU-MIMO (Multi User Multiple Input Multiple Output) is performed across the entire PPDU bandwidth. The main PHY function of HE STA that is not present in HT STA or VHT STA may be support for DL ​​MU-MIMO reception in non-AP HE STA. The main MAC function of HE STA that is not present in HT STA or VHT STA may be support for the AP's OMI (Operating Mode Indication) responder and OMI initiator. The main MAC function of HE STA that is not present in HT STA or VHT STA may be support for the AP's individual TWT (Target Wake Time).One of the main MAC functions of HE STA that is not present in HT STA or VHT STA may be support for two NAV operation in non-AP STA.

[0054] An EHT (Extreme High Throughput) STA may operate in a bandwidth between 1 GHz and 7.250 GHz. For example, an EHT STA may be an HE STA at 5 GHz and 6 GHz. For example, an EHT STA may be an HE STA at 2.4 GHz. An EHT STA may use an operation element for HT and / or VHT and / or HE STA. The main PHY function of an EHT STA that is not present in HT STA, VHT STA, or HE STA may be support for MRU (Multiple Resource Unit). The main PHY function of an EHT STA that is not present in HT STA, VHT STA, or HE STA may be support for any type of preamble puncturing in non-OFDMA, which is required for MRU (Multiple Resource Unit) support in non-OFDMA. The main MAC function of an EHT STA that is not present in HT STA, VHT STA, or HE STA may be support for MLO in the case of an EHT AP. The main MAC function of EHT STA that is not present in HT STA, VHT STA, or HE STA may, in the case of MLD, be support for the ML (Multi-Link) discovery procedure. The main MAC function of EHT STA that is not present in HT STA, VHT STA, or HE STA may, in the case of MLD, be support for the ML (re)setup procedure. The main MAC function of EHT STA that is not present in HT STA, VHT STA, or HE STA may, in the case of MLD, be support for the ML BlockAck procedure. The main MAC function of EHT STA that is not present in HT STA, VHT STA, or HE STA may, in the case of MLD, be support for MLD level sequence number spaces. The main MAC function of EHT STA that is not present in HT STA, VHT STA, or HE STA may, in the case of MLD, be support for MLD level packet number space.The main MAC function of EHT STA, which is not present in HT STA, VHT STA, or HE STA, may be support for ML reconfiguration procedures in the case of MLD.

[0055] A UHR (Ultra High Reliability) STA may operate in a bandwidth between 1 GHz and 7.250 GHz. For example, a UHR STA may be an EHT STA at 5 GHz and 6 GHz. For example, a UHR STA may be an HE STA at 5 GHz and 6 GHz. For example, a UHR STA may be a VHT STA at 5 GHz and 6 GHz. For example, a UHR STA may be an HE STA at 2.4 GHz. For example, a UHR STA may be an HT STA at 2.4 GHz. A UHR STA may support SMD. A UHR STA may support Seamless BSS Transition. A UHR STA may use operation elements for HT, and / or VHT, and / or HE STA, and / or UHR STA. In other words, a UHR STA may be controlled by an HT operation element, and / or a VHT operation element, and / or an HE operation element, and / or an EHT operation element, and / or a UHR operation element.

[0056] APs and STAs within a BSS may transmit based on CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance). The CSMA / CA protocol may be a protocol designed to reduce the probability of collisions at the point in time when collisions between multiple STAs accessing the medium are most likely to occur.

[0057] An HT BSS may be a BSS in which the Beacon frame transmitted by the HT STA includes an HT Capabilities element. A VHT BSS may be a BSS in which the Beacon frame transmitted by the VHT STA includes a VHT Operation element. A HE BSS may be a BSS in which the Beacon frame transmitted by the HE STA includes an HE Operation element. An EHT BSS may be a BSS in which the Beacon frame transmitted by the HE STA includes an EHT Operation element. For example, an HT BSS may consist of an STA that supports the capabilities of the HT STA. For example, a VHT BSS may consist of an STA that supports the capabilities of the VHT STA. For example, a HE BSS may consist of an STA that supports the capabilities of the HE. For example, an EHT BSS may consist of an STA that supports the capabilities of the EHT. For example, a UHR BSS may consist of an STA that supports the capabilities of the UHR.

[0058] In this embodiment, STA may be, for example, HT STA, VHT STA, HE STA, EHT STA, or UHR STA. STA may also be any STA other than those described above.

[0059] APs and STAs may transmit frames of multiple frame types that share a common frame format. Frames may be defined at the physical layer, MAC layer, and Logical Link Control (LLC) layer, respectively.

[0060] A MAC frame may be a unit of data exchanged between MAC entities. A synonym for MAC frame may be MPDU. An MPDU (MAC Protocol Data Unit) may be a unit of data exchanged between two peer MAC entities using physical layer (PHY) data services. A synonym for MPDU may be MAC frame. An MSDU (MAC Service Data Unit) may be information delivered as a single unit between MAC service access points (SAPs). In an STA, a MAC frame may be processed by the MAC layer processing unit SU4. In an STA, a MAC frame may be processed by the frame processing unit SU7. In an AP, a MAC frame may be processed by the MAC layer processing unit AU4. In an AP, a MAC frame may be processed by the frame processing unit AU7.

[0061] A PHY frame may be a unit of data exchanged between PHY entities. A synonym for PHY frame may be PPDU. A PPDU (PHY Protocol Data Unit) may be a unit of data exchanged between two peer PHY entities using physical layer (PHY) data services. A synonym for PPDU may be PHY frame. In the STA, a PHY frame may be processed by the physical layer processing unit SU4. In the STA, a PHY frame may be processed by the frame processing unit SU7. In the AP, a PHY frame may be processed by the physical layer processing unit AU4. In the AP, a PHY frame may be processed by the frame processing unit AU7.

[0062] The MAC frame format may consist of a MAC header, a frame body, and an FCS. The MAC frame format may also consist of a set of fields that occur in a fixed order in all frames.

[0063] The MAC header may consist of a Frame Control field, a Duration / ID field, an Address1 field, an Address2 field, an Address3 field, a Sequence Control field, an Address4 field, a QoS Control field, an HT Control field, etc. The MAC header may consist of all of the aforementioned fields. The MAC header may consist of some of the aforementioned fields.

[0064] Figure 5 shows an example of a MAC frame format according to one aspect of this embodiment. In Figure 5, the MAC frame format may consist of a MAC header, a Frame Body, and an FCS. In Figure 5, the MAC header may consist of a Frame Control field, a Duration field, an Address1 field, an Address2 field, an Address3 field, a Sequence Control field, an Address4 field, and a QoS Control field. The MAC frame format may also be an MPDU.

[0065] The Frame Control field of the MAC header may consist of subfields such as Protocol Version, Type, Subtype, To DS, From DS, More Fragments, Retry, Power Management, More data, Protected Frame, +HTC, Control Frame Extension, Compressed SSID Present, ANO Present, BSS BW, Security, AP PM, etc. The Frame Control field of the MAC header may consist of some of the aforementioned subfields. The Frame Control field of the MAC header may consist of all of the aforementioned subfields. The Frame Control field in the MAC header may consist of a specific combination of subfields, depending on the frame type.

[0066] The frame type may also be indicated in the Type subfield within the Frame Control field of the MAC header. The frame type may be defined as Control frame, Management frame, or Data frame. The Type subfield may indicate one of these three. For example, the Type subfield may be a 2-bit subfield. If the Type subfield is set to 00, the frame type may be a Management frame. If the Type subfield is set to 01, the frame type may be a Control frame. If the Type subfield is set to 10, the frame type may be a Data frame.

[0067] A Management frame may be a frame for managing the connection status between devices. A Control frame may be a frame for managing the communication status between devices. A Data frame may be a frame containing the actual data to be transmitted.

[0068] The Subtype subfield in the Frame Control field of the MAC header may indicate the frame's subtype. Possible subtypes of the frame include Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, ATIM, Disassociation, Authentication, Deauthentication, Action, Block Ack Request, Block Ack, PS-Poll, RTS, CTS, Ack, CF-End, Data, QoS Data, etc. Other subtypes may also be defined.

[0069] The frame subtype may be determined from the Type subfield and Subtype subfield contained in the Frame Control field of the MAC header. The Subtype subfield may be a 4-bit subfield. If the Type subfield is set to 00, it may indicate a Management frame. If the Type subfield is set to 01, it may indicate a Control frame. If the Type subfield is set to 10, it may indicate a Data frame.

[0070] For example, if the Type subfield indicates a Management frame and the Subtype subfield is set to 0000, the subtype may be an Association Request. If the Type subfield indicates a Management frame and the Subtype subfield is set to 0001, the subtype may be an Association Response. If the Type subfield indicates a Management frame and the Subtype subfield is set to 0010, the subtype may be a Reassociation Request. If the Type subfield indicates a Management frame and the Subtype subfield is set to 0011, the subtype may be a Reassociation Response. If the Type subfield indicates a Management frame and the Subtype subfield is set to 0100, the subtype may be a Probe Request. If the Type subfield indicates a Management frame and the Subtype subfield is set to 0101, the subtype may be a Probe Response. If the Type subfield indicates a Management frame and the Subtype subfield is set to 1000, the subtype may be a Beacon.

[0071] A Beacon frame may contain information such as the Beacon period and SSID. A Beacon frame may be a frame that is periodically transmitted to the STA within the BSS. The Beacon period may be the time interval between two consecutive Target Beacon Transmission Times (TBTT). An Association Request frame may contain information such as the capabilities supported by the STA, the Beacon reception interval, SSID, and MLO. An Association Response frame may contain information such as the capabilities supported by the STA, the Status code, AID (Association ID), EDCA parameters, the received Channel Power Indicator (RCPI), the received signal-to-noise indicator (RSNI), and MLO. An Association Response frame may be a frame that is transmitted as a response to a received Association Request frame. A Reassociation Request frame may contain information such as the capabilities supported by the STA, the Beacon reception interval, the MAC address of the AP to which the STA is connected, SSID, and MLO. A Reassociation Response frame may contain information such as the capabilities, status code, AID, EDCA parameters, RCPI, RSNI, and MLO supported by the STA. A Reassociation Response frame may also be a frame sent in response to a received Reassociation Request frame. A Probe Response frame may contain information such as the Beacon period and SSID. A Probe Response frame may also be a frame sent in response to a received Probe Request frame.

[0072] The Reconfiguration Multi-Link element may be used by an AP MLD to announce an ML reconfiguration operation. Alternatively, the Reconfiguration Multi-Link element may be used by a non-AP MLD to initiate an ML reconfiguration to add or remove links from an existing ML setup. The Reconfiguration Multi-Link element may be included in a Beacon frame. The Reconfiguration Multi-Link element may be included in a Probe Response frame. The Reconfiguration Multi-Link element may be included in a Link Reconfiguration Notify frame. The Reconfiguration Multi-Link element may be included in a Link Reconfiguration Request frame.

[0073] A Reconfiguration Multi-Link element may consist of an Element ID field, a Length field, an Element ID Extension field, a Multi-Link Control field, a Common Info field, and a Link Info field. The Multi-Link Control field included in the Reconfiguration Multi-Link element may consist of a Type subfield, a Presence Bitmap subfield, etc. For example, the Type subfield included in the Reconfiguration Multi-Link element may show a value of 2. The Common Info field included in the Reconfiguration Multi-Link element may consist of a Common Info Length subfield, an MLD MAC Address subfield, an EML Capabilities subfield, an MLD Capabilities And Operations subfield, and an Extended MLD Capabilities And Operations subfield. The Link Info field included in the Reconfiguration Multi-Link element may consist of one or more Per-STA Profile subelements. A Per-STA Profile subelement may contain information about one of one or more STAs belonging to a certain MLD. That is, a Per-STA Profile subelement may show information for each STA. The Per-STA Profile subelement included in the Reconfiguration Multi-Link element may consist of a Subelement ID field, a Length field, an STA Control field, an STA Info field, and an STA Profile field.The STA Control field included in the Reconfiguration Multi-Link element may consist of a Link ID subfield, a Complete Profile subfield, a STA MAC Address Present subfield, an AP Removal Timer Present subfield, a Reconfiguration Operation Type subfield, etc. The STA Info field included in the Reconfiguration Multi-Link element may consist of a STA Info Length subfield, a STA MAC Address subfield, an AP Removal Timer subfield, etc.

[0074] The AP Removal Timer Present subfield may be set to 1 to indicate that the AP Removal Timer subfield exists in the STA Info field. Otherwise, the AP Removal Timer Present subfield may be set to 0.

[0075] The Reconfiguration Operation Type subfield may be set to indicate the type of MLO update for the link indicated by the Link ID subfield. For example, to indicate AP Removal, the Reconfiguration Operation Type subfield may be set to 0.

[0076] The AP Removal Timer subfield may indicate the number of TBTTs (Through Time Totals) until an AP corresponding to a Per-STA Profile subelement is removed. That is, the AP Removal Timer subfield may indicate the number of Beacon frames transmitted by an AP corresponding to a Per-STA Profile subelement before it is removed. If the value of the AP Removal Timer subfield is 1, it may indicate that the AP will be removed at the next TBTT, i.e., when the next Beacon frame is transmitted. In the TBTT indicated by the AP Removal Timer subfield, the AP MLD may remove the sequence APs corresponding to the Per-STA Profile subelement.

[0077] A Reconfiguration SMD element may be used to announce an operation of a Seamless BSS Transition. Alternatively, a Reconfiguration SMD element may be used to initiate a procedure by a non-AP MLD to add a link to the target AP MLD or remove a link to the current AP MLD. A Reconfiguration SMD element may be referred to by a different name. A Reconfiguration SMD element may be included in a Transition Execution Request frame. A Reconfiguration SMD element may be included in a Transition Execution Response frame. A Reconfiguration SMD element may be included in a Transition Preparation Request frame. A Reconfiguration SMD element may be included in a Transition Preparation Response frame.

[0078] A Reconfiguration SMD element may include one or more Per-MLD Profile subelements. A Per-MLD Profile subelement may contain information about one of several AP MLDs covered by a given SMD. That is, a Per-MLD Profile subelement may show information for each AP MLD. A Per-MLD Profile subelement included in a Reconfiguration SMD element may consist of a Subelement ID field, a Length field, an MLD Control field, an MLD Info field, an MLD Profile field, etc. The MLD Control field included in a Reconfiguration SMD element may consist of an MLD ID subfield, a Current AP Removal Timer Present subfield, etc. The MLD Info field included in a Reconfiguration SMD element may consist of an MLD Info Length subfield, a Current AP Removal Timer subfield, etc. The names of the Per-MLD Profile subelement, each field, and subfields described above may be referred to by other names.

[0079] The MLD ID subfield may indicate an identifier value that the SMD uses to identify the AP MLD. The SMD may use the MLD ID subfield to identify the current AP MLD.

[0080] The Current AP Removal Timer Present subfield may be set to 1 to indicate that the Current AP Removal Timer subfield exists in the MLD Info field. Otherwise, the Current AP Removal Timer Present subfield may be set to 0.

[0081] The Current AP Removal Timer subfield may indicate the value of the timer for the SMD to remove the current AP MLD. For example, the Current AP Removal Timer subfield may indicate the TBTT number until the current AP MLD is removed. That is, the Current AP Removal Timer subfield may indicate the number of Beacon frames to be sent before the current AP MLD is removed. The TBTT indicated in the Current AP Removal Timer subfield may be, for example, the number of Beacon frames sent by APs belonging to the current AP MLD and sending the Transition Execution Response frame described below. Alternatively, the TBTT indicated in the Current AP Removal Timer subfield may be, for example, the number of Beacon frames sent by all APs belonging to the current AP MLD. If the value of the Current AP Removal Timer subfield is 1, it may indicate that the current AP MLD will be removed at the next TBTT, i.e., at the next time a Beacon frame is sent. If the value of the Current AP Removal Timer subfield is 0, it may indicate that the current AP MLD will be removed when the SMD sends the frame containing this Current AP Removal Timer subfield. In the TBTT indicated by the Current AP Removal Timer subfield, the SMD may remove the current AP MLD.

[0082] As another example, the Current AP Removal Timer subfield may indicate the time period until the current AP MLD is removed. The time period indicated by the Current AP Removal Timer subfield may be expressed in units of, for example, an integer multiple of a time unit (TU), i.e., an integer multiple of 1024 μs. The time period indicated by the Current AP Removal Timer subfield may be the same as, or longer than, the time it takes for the current AP MLD to send one or more individually addressed downlink data frames to the non-AP MLD. If the value of the Current AP Removal Timer subfield is 0, it may indicate that the current AP MLD will be removed when the SMD sends the frame containing this Current AP Removal Timer subfield. The SMD may remove the current AP MLD after the time period indicated by this subfield has elapsed since sending the frame containing the Current AP Removal Timer subfield.

[0083] The Reconfiguration SMD element may have a configuration other than those described above. For example, the Reconfiguration SMD element may include a Current AP Removal Timer subfield in addition to the Per-MLD Profile subelement. That is, the Reconfiguration SMD element may contain only one Current AP Removal Timer subfield.

[0084] As another example, if the Reconfiguration SMD element contains link-specific information, the Current AP Removal Timer subfield may be included for each link in the current AP MLD. In this case, the SMD may delete the corresponding current AP MLD link and all information held for that link after the period indicated by this subfield has elapsed since sending the frame containing the Current AP Removal Timer subfield. The link-specific information included in the Reconfiguration SMD element may also be indicated by an identifier for identifying the link, such as in the Link ID subfield. The link-specific information included in the Reconfiguration SMD element may also be referred to as the Per-Link Profile subelement, etc.

[0085] As another example, if the Reconfiguration SMD element contains information for each AP, the Current AP Removal Timer subfield may be included for each AP belonging to the current AP MLD. In this case, the SMD may remove the AP belonging to the corresponding current AP MLD after the period indicated by the Current AP Removal Timer subfield has elapsed since sending the frame containing the subfield. Some of the AP-specific information included in the Reconfiguration SMD element may be the same as the subfields included in the Per-STA Profile subelement. The AP-specific information included in the Reconfiguration SMD element may be referred to as the Per-AP Profile subelement, etc.

[0086] For example, if the Type subfield indicates a Data frame and the Subtype subfield is set to 0000, then subtype may be Data. If the Type subfield indicates a Data frame and the Subtype subfield is set to 1000, then subtype may be QoS Data.

[0087] The Frame body field of a MAC frame format may consist of fields and elements defined for each subtype of management frame. Fields and elements are displayed in a specified relative order, and non-existent fields or elements may be skipped. If the STA encounters an element ID that it does not recognize in the frame body of a received management frame, it ignores that element and continues to parse the rest of the management frame body (if any) in search of additional elements with recognizable element IDs. In other words, the frame body of a management frame may contain one or more elements.

[0088] The element format of each element included in the Frame body may be defined by the Element ID field, Length field, Element ID Extension field, information field, etc. The Information field may contain information specific to the element. For example, if Element ID is 61, it may indicate an element for HT Operation. For example, if Element ID is 191, it may indicate an element for VHT Capabilities. For example, if Element ID is 192, it may indicate an element for VHT Operation. For example, if Element ID is 255, it may indicate an element for HE Capabilities. For example, if Element ID is 255, it may indicate an element for HE Operation.

[0089] The Capabilities element may contain information indicating the capabilities supported by STA. The Capabilities element may consist of multiple fields.

[0090] The HT Capabilities element may be defined by the Element ID field, Length field, HT Capability Information field, A-MPDU Parameters field, Supported MCS Set field, HT Extended Capabilities field, Transmit Beamforming Capabilities field, and ASEL Capabilities field. The HT Capability Information field may consist of the LDPC Coding Capability subfield, Supported Channel Width Set subfield, SM Power Save subfield, etc. The HT Extended Capabilities field may consist of the MCS Feedback subfield, +HTC-HT Support subfield, etc. The capabilities supported by the HT STA may be indicated by the HT Capabilities element. In other words, the HT Capabilities element may be a Capabilities element that indicates the capabilities supported by the HT STA.

[0091] An HT Capabilities element may be sent in a Management frame. An HT Capabilities element may be sent in a Control frame. An HT Capabilities element may be sent in a Data frame. For example, an HT Capabilities element may be sent in a Beacon frame. For example, an HT Capabilities element may be sent in an Association Request frame. For example, an HT Capabilities element may be sent in an Association Response frame. For example, an HT Capabilities element may be sent in a Reassociation Request frame. For example, an HT Capabilities element may be sent in a Reassociation Response frame. For example, an HT Capabilities element may be sent in a Probe Request frame. For example, an HT Capabilities element may be sent in a Probe Response frame.

[0092] A VHT Capabilities element may be defined by an Element ID field, a Length field, a VHT Capabilities Information field, and a Supported VHT-MCS and NSS Set field. The VHT Capabilities Information field may consist of subfields such as Maximum MPDU Length, Supported Channel Width Set, and Rx LDPC. The capabilities supported by VHT STA may be indicated by the VHT Capabilities element. In other words, a VHT Capabilities element may be a Capabilities element that indicates the capabilities supported by VHT STA.

[0093] A VHT Capabilities element may be sent in a Management frame. A VHT Capabilities element may be sent in a Control frame. A VHT Capabilities element may be sent in a Data frame. For example, a VHT Capabilities element may be sent in a Beacon frame. For example, a VHT Capabilities element may be sent in an Association Request frame. For example, a VHT Capabilities element may be sent in an Association Response frame. For example, a VHT Capabilities element may be sent in a Reassociation Request frame. For example, a VHT Capabilities element may be sent in a Reassociation Response frame. For example, a VHT Capabilities element may be sent in a Probe Request frame. For example, a VHT Capabilities element may be sent in a Probe Response frame.

[0094] The HE Capabilities element may be defined by the Element ID field, Length field, Element ID Extension field, HE MAC Capabilities Information field, HE PHY Capabilities Information field, Supported HE-MCS and NSS Set field, and PPE Thresholds field. The HE MAC Capabilities Information field may consist of subfields such as +HTC HE, TWT Requester, and TWT Responder. The HE PHY Capabilities Information field may consist of subfields such as Supported Channel Width Set, Punctured Preamble Rx, and Device Class. Capabilities supported by HE STA may be indicated by the HE Capabilities element. In other words, the HE Capabilities element may be a Capabilities element that indicates the capabilities supported by HE STA.

[0095] The HE Capabilities element may be sent in a Management frame. The HE Capabilities element may be sent in a Control frame. The HE Capabilities element may be sent in a Data frame. For example, the HE Capabilities element may be sent in a Beacon frame. For example, the HE Capabilities element may be sent in an Association Request frame. For example, the HE Capabilities element may be sent in an Association Response frame. For example, the HE Capabilities element may be sent in a Reassociation Request frame. For example, the HE Capabilities element may be sent in a Reassociation Response frame. For example, the HE Capabilities element may be sent in a Probe Request frame. For example, the HE Capabilities element may be sent in a Probe Response frame.

[0096] The EHT Capabilities element may be defined by the Element ID field, Length field, Element ID Extension field, EHT MAC Capabilities Information field, EHT PHY Capabilities Information field, Supported EHT-MCS And NSS Set field, and EHT PPE Thresholds field. The EHT MAC Capabilities Information field may consist of subfields such as EPCS Priority Access Support, EHT OM Control Support, TXS Mode 1 Support, and TXS Mode 2 Support. The EHT PHY Capabilities Information field may consist of subfields such as Support For 320 MHz In 6 GHz, Support For 242-tone RU In BW Wider Than 20 MHz, and Partial Bandwidth UL MU-MIMO. Capabilities supported by the EHT STA may be indicated by the EHT Capabilities element. In other words, the EHT Capabilities element may be a Capabilities element that indicates the capabilities supported by the EHT STA.

[0097] An EHT Capabilities element may be sent in a Management frame. An EHT Capabilities element may be sent in a Control frame. An EHT Capabilities element may be sent in a Data frame. For example, an EHT Capabilities element may be sent in a Beacon frame. For example, an EHT Capabilities element may be sent in an Association Request frame. For example, an EHT Capabilities element may be sent in an Association Response frame. For example, an EHT Capabilities element may be sent in a Reassociation Request frame. For example, an EHT Capabilities element may be sent in a Reassociation Response frame. For example, an EHT Capabilities element may be sent in a Probe Request frame. For example, an EHT Capabilities element may be sent in a Probe Response frame.

[0098] The UHR Capabilities element may be defined by some or all of the Element ID field, Length field, Element ID Extension field, UHR MAC Capabilities Information field, UHR PHY Capabilities Information field, and / or other fields. The UHR MAC Capabilities Information field may consist of some or all of the DPS (Dynamic Power Save) Support subfield, NPCA (Non-Primary Channel Access) Support subfield, UHR Link Reconfiguration Support subfield, UHR Link Reconfiguration Mode 2 Support subfield, etc. Capabilities supported by UHR STA may be indicated by the UHR Capabilities element. In other words, the UHR Capabilities element may be a Capabilities element that indicates the capabilities supported by UHR STA. The UHR Capabilities element may be referred to by something other than the UHR Capabilities element. Also, UHR MAC Capabilities Information may be referred to by something other than UHR MAC Capabilities Information.

[0099] A UHR Capabilities element may be sent in a Management frame. A UHR Capabilities element may be sent in a Control frame. A UHR Capabilities element may be sent in a Data frame. For example, a UHR Capabilities element may be sent in a Beacon frame. For example, a UHR Capabilities element may be sent in an Association Request frame. For example, a UHR Capabilities element may be sent in an Association Response frame. For example, a UHR Capabilities element may be sent in a Reassociation Request frame. For example, a UHR Capabilities element may be sent in a Reassociation Response frame. For example, a UHR Capabilities element may be sent in a Probe Request frame. For example, a UHR Capabilities element may be sent in a Probe Response frame.

[0100] The UHR Link Reconfiguration Support subfield may also be a subfield indicating support for UHR Link Reconfiguration. That is, the UHR Link Reconfiguration Support subfield may be a subfield indicating whether or not the UHR STA supports UHR Link Reconfiguration. The UHR Link Reconfiguration Support subfield may be set to a first value if the UHR STA supports UHR Link Reconfiguration Mode 1, as described below. For example, the UHR Link Reconfiguration Support subfield may be set to 1 if the UHR STA supports UHR Link Reconfiguration Mode 1. The UHR Link Reconfiguration Support subfield may be set to a second value different from the first value if the UHR STA supports UHR Link Reconfiguration Mode 2, as described below. For example, the UHR Link Reconfiguration Support subfield may be set to 2 if the UHR STA supports UHR Link Reconfiguration Mode 2. The UHR Link Reconfiguration Support subfield may be set to a third value different from the first and second values ​​if the UHR STA supports both UHR Link Reconfiguration Mode 1 and UHR Link Reconfiguration Mode 2, as described below. For example, the UHR Link Reconfiguration Support subfield may be set to 3 if the UHR STA supports both UHR Link Reconfiguration Mode 1 and UHR Link Reconfiguration Mode 2.For example, the UHR Link Reconfiguration Support subfield may be set to 0 if the UHR STA does not support UHR Link Reconfiguration. The UHR Link Reconfiguration Support subfield may be named in a different way. "UHR STA" may be rephrased as "non-AP MLD" or "non-AP STA belonging to a non-AP MLD".

[0101] The UHR Link Reconfiguration Mode 2 Support subfield may also be a subfield indicating support for UHR Link Reconfiguration Mode 2, as described below. That is, the UHR Link Reconfiguration Mode 2 Support subfield may also be a subfield indicating whether or not the UHR STA supports UHR Link Reconfiguration Mode 2. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be set to 1 if the UHR STA supports UHR Link Reconfiguration Mode 2. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be set to 0 if the UHR STA does not support UHR Link Reconfiguration Mode 2. For example, both the UHR Link Reconfiguration Support subfield and the UHR Link Reconfiguration Mode 2 Support subfield may be set to 1 if the UHR STA supports both UHR Link Reconfiguration Mode 1 and UHR Link Reconfiguration Mode 2. "UHR STA" can also be rephrased as "non-AP MLD" or "non-AP STA belonging to non-AP MLD".

[0102] The UHR Link Reconfiguration Support subfield may be sent in the Management frame. The UHR Link Reconfiguration Support subfield may be sent in the Control frame. The UHR Link Reconfiguration Support subfield may be sent in the Data frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Beacon frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Association Request frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Association Response frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Reassociation Request frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Reassociation Response frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Probe Request frame. For example, the UHR Link Reconfiguration Support subfield may be sent in the Probe Response frame.

[0103] The UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Management frame. The UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Control frame. The UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Data frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Beacon frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Association Request frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Association Response frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Reassociation Request frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Reassociation Response frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Probe Request frame. For example, the UHR Link Reconfiguration Mode 2 Support subfield may be sent in the Probe Response frame.

[0104] UHR Link Reconfiguration Mode 1 may be a mode of UHR Link Reconfiguration in which a non-AP STA belonging to a non-AP MLD sends a frame (UHR Link Reconfiguration Request Frame, described below) to request the addition of a link to a target AP MLD, stops sending data frames to APs belonging to the current AP MLD until it receives a response frame (UHR Link Reconfiguration Response Frame, described below) to the request to add a link to the target AP MLD, and starts sending data frames to APs belonging to the target AP MLD when it receives the response frame to the request to add a link to the target AP MLD. In other words, if a non-AP STA belonging to a non-AP MLD supports UHR Link Reconfiguration Mode 1, it may send a UHR Link Reconfiguration Request Frame, stop sending data frames to APs belonging to the current AP MLD until it receives a UHR Link Reconfiguration Response Frame, and start sending data frames to APs belonging to the target AP MLD when it receives the UHR Link Reconfiguration Response Frame.UHR Link Reconfiguration Mode 2 may be a mode of UHR Link Reconfiguration in which a non-AP STA belonging to a non-AP MLD sends a frame (UHR Link Reconfiguration Request Frame, described below) to request the addition of a link to a target AP MLD, and does not stop sending data frames to APs belonging to the current AP MLD until it receives a response frame (UHR Link Reconfiguration Response Frame, described below) to the request to add a link to the target AP MLD, and starts sending data frames to APs belonging to the target AP MLD when it receives the response frame to the request to add a link to the target AP MLD. In other words, if a non-AP STA belonging to a non-AP MLD supports UHR Link Reconfiguration Mode 2, it may send a UHR Link Reconfiguration Request Frame, and not stop sending data frames to APs belonging to the current AP MLD until it receives a UHR Link Reconfiguration Response Frame, and start sending data frames to APs belonging to the target AP MLD when it receives the UHR Link Reconfiguration Response Frame. If a non-AP STA belonging to a non-AP MLD does not support UHR Link Reconfiguration Mode 2, it may stop sending data frames to APs belonging to the current AP MLD when sending a UHR Link Reconfiguration Request Frame until it receives a UHR Link Reconfiguration Response Frame, and then start sending data frames to APs belonging to the target AP MLD when it receives a UHR Link Reconfiguration Response Frame.AP MLDs and / or APs belonging to AP MLDs may support both UHR Link Reconfiguration Mode 1 and UHR Link Reconfiguration Mode 2. For example, AP MLDs and / or APs belonging to AP MLDs may set the UHR Link Reconfiguration Support subfield to 3. "Data frame" may be rephrased as "MSDU", "A-MSDU", or "PPDU", etc. "Without stopping the transmission of Data frames" may be rephrased as "Continue transmitting Data frames", "Persistently transmit Data frames", etc. "Non-AP STA belonging to a non-AP MLD" and "AP belonging to an AP MLD" may be rephrased as "non-AP MLD" and "AP MLD", respectively.

[0105] An Operation element may be information for controlling the operation of STA within BSS. An Operation element may consist of multiple fields.

[0106] An HT Operation element may be defined by the Element ID field, Length field, Primary Channel field, HT Operation information field, and Basic HT-MCS Set field. The Primary Channel field may indicate the channel number of the primary channel. The HT Operation information field may consist of fields such as Secondary Channel Offset field and STA Channel Width field. The Secondary Channel Offset field may indicate the offset of the secondary channel relative to the primary channel. If the Secondary Channel Offset field is set to 1, the secondary channel may be located above the primary channel. If the Secondary Channel Offset field is set to 3, the secondary channel may be located below the primary channel. If the Secondary Channel Offset field is set to 0, the secondary channel may not exist. The STA Channel Width field may define the channel width that the STA can use for transmission. The STA Channel Width field may be set to 0 for 20MHz. The STA Channel Width field may be set to 1 if it allows the use of any channel within the supported channel width set. The operation of HT STA(s) in the BSS may be controlled by the HT Operation element. In other words, the HT Operation element may be an operation element that controls the operation of the HT STA within the BSS.

[0107] An HT operation element may be sent in a Management frame. An HT operation element may be sent in a Control frame. An HT operation element may be sent in a Data frame. For example, an HT operation element may be sent in a Beacon frame. For example, an HT operation element may be sent in an Association Response frame. For example, an HT operation element may be sent in a Reassociation Response frame. For example, an HT operation element may be sent in a Probe Response frame.

[0108] A VHT Operation element may be defined by an Element ID field, a Length field, a VHT Operation information field, and a Basic VHT-MCS And NSS Set field. The VHT Operation information field may consist of a Channel Width field, a Channel Center Frequency Segment 0 field, and a Channel Center Frequency Segment 1 field. The operation of VHT STA(s) within the BSS may be controlled by an HT Operation element and a VHT Operation element. In other words, a VHT Operation element may be an operation element that controls the operation of VHT STA within the BSS.

[0109] A VHT operation element may be sent in a Management frame. A VHT operation element may be sent in a Control frame. A VHT operation element may be sent in a Data frame. For example, a VHT operation element may be sent in a Beacon frame. For example, a VHT operation element may be sent in an Association Response frame. For example, a VHT operation element may be sent in a Reassociation Response frame. For example, a VHT operation element may be sent in a Probe Response frame.

[0110] The Channel Width field in the VHT Operation information field, along with the STA channel width field of the HT operation element, may define the BSS bandwidth. The Channel Width field may be set to 0 for a 20MHz or 40MHz BSS bandwidth. The Channel Width field may be set to 1 for an 80MHz, 160MHz, or 80+80MHz BSS bandwidth. The Channel Width field may be set to 2 for a 160MHz BSS bandwidth. The Channel Width field may be set to 3 for an 80+80MHz BSS bandwidth. Values ​​in the Channel Width field ranging from 4 to 255 may be reserved.

[0111] The Channel Center Frequency Segment 0 field within the VHT Operation information field may define the channel center frequency for VHT BSS of 20MHz, 40MHz, 80MHz, 160MHz, or 80+80MHz. For BSS bandwidths of 20MHz, 40MHz, or 80MHz, the Channel Center Frequency Segment 0 field may indicate the channel center frequency index for the 20MHz, 40MHz, or 80MHz channel on which the VHT BSS operates. For a 160MHz BSS bandwidth and a Channel Width subfield of 1, the Channel Center Frequency Segment 0 field may indicate the channel center frequency index for the 80MHz channel segment containing the primary channel. For a 160MHz BSS bandwidth and a Channel Width subfield of 2, the Channel Center Frequency Segment 0 field may indicate the channel center frequency index for the 160MHz channel on which the VHT BSS operates. The Channel Center Frequency Segment 0 field may indicate the channel center frequency index of the primary 80MHz channel of the VHT BSS when the BSS bandwidth is 80 + 80MHz and the Channel Width subfield is 1 or 3.

[0112] The Channel Center Frequency Segment 1 field within the VHT Operation information field may define the channel center frequency for a 160MHz or 80+80MHz VHT BSS. The Channel Center Frequency Segment 1 field may be set to 0 for a 20MHz, 40MHz, or 80MHz BSS bandwidth. If the BSS bandwidth is 160MHz and the Channel Width subfield is 1, the Channel Center Frequency Segment 1 field may indicate the channel center frequency index of the 160MHz channel on which the VHT BSS operates. If the BSS bandwidth is 160MHz and the Channel Width subfield is 2, the Channel Center Frequency Segment 1 field may be set to 0. If the BSS bandwidth is 80+80MHz and the Channel Width subfield is 1 or 3, the Channel Center Frequency Segment 1 field may indicate the channel center frequency index of the VHT BSS's Secondary 80MHz channel.

[0113] The HE Operation element format may consist of fields such as Element ID, Length, Element ID Extension, HE Operation Parameter, BSS Color Information, Basic HE-MCS And NSS Set, VHT Operation Information, Max Co-Hosted BSSID Indicator, and 6GHz Operation Information. When operating in the 2.4GHz band, the HE STA in the HE BSS may be controlled by an HT Operation element and an HE Operation element. When operating in the 5GHz band, the HE STA in the HE BSS may be controlled by an HT Operation element, a VHT Operation element (if present), and an HE Operation element. When operating in the 6GHz band, the HE STA in the HE BSS may be controlled by an HE Operation element. In other words, the HE Operation element may be an operation element that controls the operation of the HE STA in the BSS.

[0114] HE operation elements may be sent in a Management frame. HE operation elements may be sent in a Control frame. HE operation elements may be sent in a Data frame. For example, HE operation elements may be sent in a Beacon frame. For example, HE operation elements may be sent in an Association Response frame. For example, HE operation elements may be sent in a Reassociation Response frame. For example, HE operation elements may be sent in a Probe Response frame.

[0115] The HE Operation Parameter field format of the HE Operation element format may consist of the Default PE Duration subfield, TWT Required subfield, TXOP Duration RTS Threshold subfield, VHT Operation Information Present subfield, Co-Hosted BSS subfield, ER SU Disabled subfield, 6GHz Operation Information Present subfield, Reserved subfield, etc. The VHT Operation Information Present subfield may be set to 1 to indicate that the VHT Operation Information field exists in the HE Operation element, and to 0 otherwise. The 6GHz Operation Information Present field may be set to 1 to indicate that the 6GHz Operation Information field exists, and to 0 otherwise.

[0116] The BSS Color Information field format of the HE Operation element format may consist of a BSS Color subfield, a Partial BSS Color subfield, a BSS Color Disabled subfield, and so on.

[0117] The 6GHz Operation Information field in the HE Operation element format may provide channel and bandwidth information related to 6GHz operation. The 6GHz Operation Information field format may consist of a Primary channel field, a Control field, a Channel Center Frequency Segment 0 field, a Channel Center Frequency Segment 1 field, a Minimum Rate field, etc. The Primary Channel field may indicate the channel number of the primary channel at 6GHz. The Channel Center Frequency Segment 0 field may indicate the channel center frequency index of a 20MHz, 40MHz, 80MHz, 160MHz, or 80+80MHz channel of the BSS operating at 6GHz. If the BSS channel width is 160MHz or 80+80MHz, the Channel Center Frequency Segment 0 field may indicate the channel center frequency index of the primary 80MHz channel. The Channel Center Frequency Segment 1 field may indicate the channel center frequency index of a 160MHz channel of the BSS operating at 6GHz. The Channel Center Frequency Segment 1 field may indicate the channel center frequency index of the secondary 80MHz channel when the channel width is 80+80MHz. The Control field format within the 6GHz Operation Information field format may consist of the Channel Width field, Duplicate Beacon subfield, Regulatory Info subfield, Reserved subfield, etc.The Channel Width field indicates the BSS channel width and may be set to 0 for 20MHz, 1 for 40MHz, 2 for 80MHz, or 3 for 80+80MHz or 160MHz.

[0118] The EHT Operation element format may also be an Operation element for controlling an EHT STA operating in an EHT BSS. When operating in the 2.4GHz band, an EHT STA in an EHT BSS may be controlled by an HT Operation element, an HE Operation element, and an EHT Operation element. When operating in the 5GHz band, an EHT STA in an EHT BSS may be controlled by an HT Operation element, a VHT Operation element (if present), an HE Operation element, and an EHT Operation element. When operating in the 6GHz band, an EHT STA in an EHT BSS may be controlled by an HE Operation element and an EHT Operation element.

[0119] The EHT Operation element format may consist of the Element ID, Length, Element ID Extension, EHT Operation Parameter, Basic EHT-MCS And Nss Set, and EHT Operation Information fields. The EHT Operation Information field may consist of the Control subfield, CCFS0 subfield, CCFS1 subfield, and Disabled Subchannel Bitmap subfield. The Control subfield may include a Channel Width subfield. The Channel Width subfield may be a subfield for defining the EHT BSS bandwidth. The Channel Width subfield may define 0 for a 20MHz EHT BSS bandwidth. The Channel Width subfield may define 1 for a 40MHz EHT BSS bandwidth. The Channel Width subfield may define 2 for an 80MHz EHT BSS bandwidth. The Channel Width subfield may define 3 for a 160MHz EHT BSS bandwidth. The Channel Width subfield may define 4 for a 320MHz EHT BSS bandwidth. The CCFS0 subfield may define the center frequency of the primary 80MHz channel for 20MHz EHT BSS, 40MHz EHT BSS, 80MHz EHT BSS, 160MHz EHT BSS, or the primary 160MHz channel for 320MHz EHT BSS. The CCFS0 subfield may also indicate the channel center frequency index of the 20MHz channel, 40MHz channel, or 80MHz channel on which the EHT BSS operates, for a 20MHz BSS bandwidth, 40MHz BSS bandwidth, or 80MHz BSS bandwidth.The CCFS0 subfield may indicate the channel center frequency index of the primary 80MHz channel for a 160MHz BSS bandwidth. The CCFS0 subfield may indicate the channel center frequency index of the primary 160MHz channel for a 320MHz BSS bandwidth. The CCFS1 subfield may define the center frequency of a 160MHz EHT BSS or a 320MHz EHT BSS. The CCFS1 subfield may be set to 0 for a 20MHz BSS bandwidth, a 40MHz BSS bandwidth, or an 80MHz BSS bandwidth. The CCFS1 subfield may index the center frequency of a 160MHz channel for a 160MHz BSS bandwidth. The CCFS1 subfield may index the center frequency of a 320MHz channel for a 320MHz BSS bandwidth.

[0120] An A-MSDU (Aggregate MSDU) may be a sequence of A-MSDU subframes. Each A-MSDU subframe may consist of an A-MSDU subframe header, followed by the MSDU and padding from 0 to 3. In an A-MSDU subframe, the A-MSDU subframe header may include a DA field, an SA field, and a Length field. The DA and SA fields may contain values ​​passed in MA-UNITDATA.request and MAUNITDATA.indication primitives. The Length field may contain the length of the MSDU in octets (i.e., 8 bits).

[0121] Figure 6 shows an example of an A-MSDU according to one aspect of this embodiment. In Figure 6, the MAC frame format may consist of a MAC header, a Frame Body, and an FCS. Here, the MAC header may consist of a Frame Control field, a Duration field, an Address1 field, an Address2 field, an Address3 field, a Sequence Control field, an Address4 field, and a QoS Control field. The MAC frame format may also be an MPDU. The Frame Body may consist of n A-MSDU subframes. Each A-MSDU may consist of an A-MSDU subframe header, an MSDU, and Padding. The A-MSDU subframe header may consist of a DA field, an SA field, and a Length field.

[0122] An A-MPDU (Aggregate MPDU) may consist of a sequence of one or more A-MPDU subframes and a variable amount of EOF Padding. Each A-MPDU subframe may optionally consist of an MPDU followed by an MPDU delimiter. Each nonfinal A-MPDU subframe within an A-MPDU may have additional padding octets to make the subframe length a multiple of four octets. The EOF Padding field may consist of an EOF Padding subframe field and an EOF Padding Octets field. The A-MPDU pre-EOF padding may refer to the contents of the A-MPDU without including the EOF Padding field. The MPDU delimiter may consist of an EOF field, a Reserved field, an MPDU Length field, a CRC field, and a Delimiter Signature field.

[0123] Figure 7 shows an example of an A-MPDU according to one aspect of this embodiment. In Figure 7, the A-MPDU may consist of n A-MPDU subframe fields and an EOF Padding field. The n A-MPDU subframe fields may be referred to as A-MPDU pre-EOF padding. Each A-MPDU subframe field may consist of an MPDU delimiter field, an MPDU field, and a padding field. The MPDU delimiter field may consist of an EOF field, a Reserved field, an MPDU Length field, a CRC field, and a Delimiter Signature field. The EOF Padding field may consist of an EOF Padding subframe field and an EOF Padding Octets field.

[0124] The process of dividing an MSDU or MMPDU (MAC Management Protocol Data Unit) into smaller MAC-level frames, or MPDUs, may be called fragmentation. A MAC may fragment and reassemble MSDUs or MMPDUs that are carried in individually addressed MPDUs.

[0125] Figure 8 shows an example of Fragmentation according to one aspect of this embodiment. In Figure 8, the MSDU may be fragmented into n parts. The MSDU is divided into n Frame Bodies, and each Frame Body may be assigned a MAC HDR (header) and a CRC (Cyclic Redundancy Check).

[0126] A PPDU may consist of a PHY preamble, a PHY header, a PSDU (PHY Service Data Unit), etc. A PPDU may be assigned L-STF, L-LTF, and L-SIG. A PPDU may be assigned HT-STF, HT-LTF, and HT-SIG. A PPDU may be assigned VHT-STF, VHT-LTF, VHT-SIG-A, and VHT-SIG-B. A PPDU may be assigned HE-STF, HE-LTF, HE-SIG-A, and HE-SIG-B. A PPDU may be assigned HT-STF, HT-LTF, and HT-SIG in addition to L-STF, L-LTF, and L-SIG. A PPDU may be assigned VHT-STF, VHT-LTF, VHT-SIG-A, and VHT-SIG-B in addition to L-STF, L-LTF, and L-SIG. In addition to L-STF, L-LTF, and L-SIG, PPDU may also be assigned HE-STF, HE-LTF, HE-SIG-A, and HE-SIG-B.

[0127] Figure 9 shows an example of a PPDU according to one aspect of this embodiment. In Figure 9, L-STF and L-LTF may be added to the PPDU in the PHY layer. In Figure 9, the PPDU may consist of a PSDU, PHY preamble, PHY header, tail, and padding. Here, the PSDU may be an A-MPDU in the MAC sublayer. The A-MPDU may consist of multiple MAC frame formats. Here, one MAC frame format may consist of a MAC header field, an A-MSDU field, and an FCS field.

[0128] Figure 10 shows an example of a MAC data plane architecture of an MLD according to one aspect of this embodiment. The MAC data plane architecture may refer to processing that involves the transmission of all or part of an MSDU. In the MLO, one or more links may be used for communication between AP MLDs and non-AP MLDs. During transmission, an MSDU from a MAC Service Access Point (SAP) may be forwarded to one or more MLD subordinate MAC entities and then to the corresponding PHY SAP, after going through the processing on the left side of Figure 10, and then through TID-To-Link Mapping (TTLM) processing that forwards one or more MPDUs based on a Traffic Identifier (TID). During reception, MPDUs sent from different PHY SAPs may first go through the MLD subordinate MAC entities, then through merging processing, and then go through the remaining processing on the right side of Figure 10, after which one or more MSDUs may be delivered to the LLC layer via MAC SAP or to the DS via DSAF.

[0129] The functions of the MLD upper MAC sublayer may include some or all of the following: Authentication, association, and reassociation between AP MLD and non-AP MLD. • Distribution of GTK (Group Temporal Key) / IGTK (Integrity Group Temporal Key) / BIGTK (Beacon Integrity Group Temporal Key) with security associations such as PMKSA (Pairwise Master Key Security Association) and PTKSA (Pairwise Transient Key Security Association). • Assignment of SN (Sequence Number) / PN (Packet Number) for frames encrypted by PTK (Pairwise Transient Key) for individually addressed frames. • Assignment of SNs for multiple MSDUs addressed to a group • Power-saving buffering for individually addressed frames (AP MLD only) • Encryption / decryption of individually addressed frames using PTK • Selection of MLD lower MAC entities for transmission Merging MPDUs received from two or more links • Packet reordering to ensure packets are delivered in the correct order for each Block Ack session. • Block Ack scoreboarding for individually addressed frames through collaboration with MLD lower MAC entities. • Exchange / instruction of MLD-level management information via MLD subordinate MAC entities • Selection of EDCA (Enhanced Distributed Channel Access) parameters for each STA series.

[0130] The functionality of an MLD subordinate MAC entity may include some or all of the following: • Exchange / instruction of link-specific control information such as RTS / CTS, acknowledgements, and NDP (Null Data PPDU). • Power saving state and mode • MAC address filtering for frame reception • Block Ack scoreboarding for individually addressed frames through collaboration with the MLD upper MAC sublayer.

[0131] The functionality of the SMD MAC entity may include some or all of the following. The functionality of the SMD upper MAC sublayer may include some or all of the following. The functionality of the MLD common MAC sublayer may include some or all of the following. • Operations performed by two MLDs covered by the same SMD Seamless BSS Transition between AP MLD and non-AP MLD Other operations between AP MLD and non-AP MLD • Security associations such as PMKSA and PTKSA, and distribution of GTK / IGTK / BIGTK. • Assignment of SN / PN for frames encrypted by PTK for individually addressed frames • Assignment of SNs for multiple MSDUs addressed to a group • Power-saving buffering of individually addressed frames • Encryption / decryption of individually addressed frames using PTK • Selection of SMD lower MAC entities for transmission • Selection of MLD lower MAC entities for transmission • Selection of MLD upper MAC sublayer for transmission Merging MPDUs received from two or more MLDs • Packet reordering to ensure packets are delivered in the correct order for each Block Ack session. • Block Ack scoreboarding for individually addressed frames through collaboration with SMD lower MAC entities. • Block Ack scoreboarding for individually addressed frames through collaboration with MLD lower MAC entities. • Block Ack scoreboarding for individually addressed frames through collaboration with the MLD upper MAC sublayer. • Exchange / instruction of MLD-level management information via SMD subordinate MAC entities • Exchange / instruction of MLD-level management information via MLD subordinate MAC entities • Exchange / instruction of MLD-level management information via the MLD upper MAC sublayer • Selection of the EDCA parameters for each MLD series • Selection of each AP MLD's own EDCA parameters

[0132] The functionality of an SMD subordinate MAC entity may include some or all of the following: Authentication, association, and reassociation between AP MLD and non-AP MLD • Power-saving buffering for individually addressed frames (AP MLD only) • Encryption / decryption of individually addressed frames using PTK • Selection of MLD lower MAC entities for transmission Merging MPDUs received from two or more links • Packet reordering to ensure packets are delivered in the correct order for each Block Ack session. • Block Ack scoreboarding for individually addressed frames through collaboration with MLD lower MAC entities. • Exchange / instruction of MLD-level management information via MLD subordinate MAC entities • Selection of EDCA parameters for each series STA • Exchange / instruction of link-specific control information such as RTS / CTS, acknowledgements, and NDP (Null Data PPDU). • Power saving state and mode • MAC address filtering for frame reception • Block Ack scoreboarding for individually addressed frames through collaboration with the SMD upper MAC sublayer.

[0133] The time interval between frames may be referred to as IFS (Inter-Frame Space). The STA may use carrier sensing functionality at specified time intervals to determine if the medium is idle. In other words, the STA may perform carrier sensing over the IFS period to determine whether the medium is idle or not.

[0134] Multiple types of IFS may be defined. For example, IFS may include RIFS (Reduced Inter Frame Space), SIFS (Short Inter Frame Space), PIFS (Priority Inter Frame Space), DIFS (DCF Inter Frame Space), AIFS (Arbitration Inter Frame Space), EIFS (Extended Inter Frame Space), SBIFS (Short Beamforming Inter Frame Space), BRPIFS (Beam Refinement Inter Frame Space), MBIFS (Medium Beamforming Inter Frame Space), and LBIFS (Long Beamforming Inter Frame Space).

[0135] The time interval may differ depending on the type of IFS. For example, PIFS may have a longer time interval than SIFS. DIFS may also have a longer time interval than PIFS. The type of IFS may provide a priority level for access to the wireless medium. In other words, an IFS with a shorter time interval may be an IFS with a higher priority level for access to the wireless medium.

[0136] SIFS (Short Inter Frame Space) may be the time from the end of the last symbol or signal extension (if any) of the previous frame until the first symbol of the preamble of the next frame is seen on the radio medium.

[0137] Priority Inter Frame Space (PIFS) may be used to control access to media in order to obtain priority access. PIFS may also be used to perform Clear Channel Assessment (CCA) on secondary 20MHz, secondary 40MHz, and secondary 80MHz channels before transmission at 40MHz, 80MHz, and 160MHz.

[0138] CCA (Clear Channel Assessment) may be a function that determines the current usage status of a wireless medium. CCA may be a function at the physical layer that determines the current usage status of a wireless medium. CCA may also be referred to as the CCA function.

[0139] DIFS (DCF Inter Frame Space) may be used by an STA operating with DCF to transmit data frames (MPDUs) and management frames (MMPDUs). An STA using DCF may transmit after successfully receiving a frame, if the CS (Carrier Sense) mechanism determines that the medium is idle at a TxDIFS slot boundary, and the value of the STA's backoff counter is zero.

[0140] AIFS (Arbitration Inter Frame Space) may be used for QoS STAs that access media using EDCAF.

[0141] EIFS (Extended Inter Frame Space) may be used in DCF when the medium is immediately determined to be idle after receiving a frame with an incorrect FCS value.

[0142] The basic method of accessing MACs used by STAs may be DFC (Distributed Coordination Function). DCF may be a class of coordination function where the same coordination logic is always active in each STA within the BSS when the network is operational. DCF may be a type of CSMA / CA. DCF may be a function that needs to be implemented in all STAs.

[0143] To initiate a transmission, the STA detects the medium and determines whether another STA is currently transmitting. If the medium is not busy, the STA may proceed with the transmission. If the medium is determined to be busy, the STA postpones the transmission until the current transmission is complete.

[0144] In the CSMA / CA distributed algorithm, there is a specified time gap between frame exchange sequences. This specified time gap between frame exchange sequences may be referred to as the IFS (Interval Free Time). Before attempting to transmit, the transmitting STA (Signal Attached) verifies that the medium is idle for a required period. This required period may be the specified time gap between frame exchange sequences. This required period may be referred to as the IFS.

[0145] The STA may initialize the backoff counter to a random backoff counter before attempting to transmit again after a delay or immediately after a successful transmission. The STA may decrement the backoff counter once per aSlotTime period while the medium is idle. aSlotTime may be the duration of the slot. The duration of the slot may be the duration of the slot that the MAC uses to define the IFS. Alternatively, aSlotTime may be a predetermined length of time (e.g., a fixed duration in microseconds).

[0146] The basic media access protocol may be DCF. DCF enables automatic sharing of media between compatible PHYs through the use of CSMA / CA and a random backoff counter after the media becomes busy. All individually addressed traffic uses an immediate positive acknowledgment (Ack frame), and if an Ack frame is not received, the sender schedules a retransmission. Multiple STAs may be waiting for the media to become available, and collisions are most likely when the media goes from busy to idle. Therefore, a random backoff procedure is necessary to resolve media contention. An STA transmission may interfere with (collision with) another STA transmission even if the carrier sense function (CS function) indicates that the media is not busy. Interference may be identified when the expected response frame is not received.

[0147] An STA that wants to initiate the transfer of data frames or management frames using DCF may use a carrier sense mechanism to determine the busy / idle state of the medium. If the medium is busy, the STA waits without interruption for an IFS until the medium is determined to be idle. Here, the type of IFS may be EIFS if the transition to the last idle state was due to the detection of a frame that was not properly received on the medium. Otherwise, the type of IFS may be DIFS. After the medium is idle in DIFS or EIFS, the STA may generate a random backoff count for additional delay time before transmission. However, if the backoff counter already contains a non-zero value, the selection of a random number is not required. The backoff counter may be a pseudorandom integer obtained by subtracting a uniform variance between [0, CW]. CW may be an integer within the range of aCWmin and aCWmax values, which are characteristics of the PHY. CW may be greater than or equal to aCWmin and less than or equal to aCWmax. CW may be referred to as the Contention Window.

[0148] The contention window parameter may take the initial value of aCWmin. The contention window takes a series of values ​​each time an MPDU transmission attempt fails and any STA retry increases until the contention window reaches the value of aCWmax. Once the contention window reaches aCWmax, it maintains the value of aCWmax until the contention window is reset. If a data frame or management frame is successfully transmitted, the contention window may be reset to aCWmin. If the SSRC reaches dot11ShortRetryLimit, the contention window may be reset to aCWmin. The set of contention window values ​​may be in ascending order as integer values ​​obtained by powers of 2 minus 1, starting from the PHY-specific aCWmin value and continuing up to the PHY-specific aCWmax. For example, if aCWmin is 7 and aCWmax is 255, the set of contention window values ​​may be a set containing 7, 15, 31, 63, 127, and 255.

[0149] For example, in OFDM PHY characteristics, with a 20MHz channel spacing, aSlotTime may be 9μs. In OFDM PHY characteristics, with a 20MHz channel spacing, aCWmin may be 15. In OFDM PHY characteristics, with a 20MHz channel spacing, aCWmax may be 1023.

[0150] A QoS facility may include an additional coordinating function called HCF (Hybrid Coordination Function), which is only available in a QoS network configuration. HCF may be implemented in all QoS STAs. HCF is a coordinating function that combines aspects of competition-based and competition-free access methods to provide prioritized, parameterized QoS access to the radio medium for QoS STAs, and may continue to support non-QoS STAs for best-effort forwarding. HCF may include functionality provided by both EDCA (Enhanced Distributed Channel Access) and HCCA (HCF controlled channel access). HCF may use a competition-based channel access method called the EDCA mechanism for competition-based forwarding. HCF may use a controlled channel access method called the HCCA mechanism for competition-free forwarding.

[0151] HCCA (HCF Controlled Channel Access) may be a channel access mechanism used by an HC (Hybrid Coordinator) to coordinate the use of a non-contourable medium by a QoS STA for individually addressed downlink, uplink, and direct link transmissions.

[0152] The EDCA mechanism may use eight different User Priorities (UPs) to provide STAs with differentiated, distributed access to the wireless medium. UPs are values ​​associated with MAC Service Data Units (MSDUs) and may indicate how the MSDU should be handled. UPs may be assigned to MSDUs at higher layers of the MAC. UPs may take any value from 0 to 7. The EDCA mechanism may define four Access Categories (ACs) to support the delivery of traffic using STAs' UPs. ACs may be labels for a common set of EDCA parameters that QoS STAs use to compete for channels and send MSDUs with specific priorities. ACs may take any value from AC_BE, AC_BK, AC_VI, and AC_VO. AC_BE, AC_BK, AC_VI, and AC_VO may indicate access categories corresponding to best-effort, background, video, and voice, respectively.

[0153] A Quality of Service (QoS) facility may include extensions, channel access rules, frame formats, frame exchange sequences, and managed objects used to provide parameterized and prioritized QoS. A QoS STA may be an STA that implements the QoS function. A QoS AP may be an AP that supports the QoS function. A QoS BSS may be a BSS that provides the QoS function. An Infrastructure QoS BSS may include a QoS AP.

[0154] A QMF (QoS Management Frame) policy may be a policy that defines the AC of Management frames. A QMF service may be a service that determines the AC of the EDCA that sends Management frames according to the configured policy. A QMF STA may be an STA that implements the QMF service. A QMF AP may be an AP that implements the QMF service. A QMF MLD may be an MLD that implements the QMF service. A Non-QMF STA may be an STA that does not implement the QMF service. A Non-QMF AP may be an AP that does not implement the QMF service. A Non-QMF MLD may be an MLD that does not implement the QMF service. An IQMF (Individually addressed QoS Management Frame) may be an individually addressed Management Frame that is sent using the QMF service.

[0155] An EDCAF (Enhanced Distributed Channel Access Function) is a logical function within a QoS STA that uses the EDCA to determine when a frame in a transmit queue with an associated AC is permitted to be transmitted over the radio medium. There may be one EDCAF per AC. DCFs and HCFs may be defined to operate within the same BSS.

[0156] Each EDCAF may maintain a backoff counter measured in the backoff slot. When the backoff procedure is called, the backoff counter may be set to a randomly selected integer value in a uniform distribution from 0 to CW. AIFS may be defined as AIFSN × aSlotTime + aSIFSTime. For example, in OFDM PHY characteristics, for a 20MHz channel spacing, aSlotTime may be 9μs and aSIFTTime may be 16μs. AIFSN may differ for each AC. For example, if AC is AC_BK, AIFSN may be 7. If AC is AC_BE, AIFSN may be 3. If AC is AC_VI, AIFSN may be 2. If AC is AC_VO, AIFSN may be 2. CW may be in ascending order as a power of 2 minus 1 integer, starting from a PHY-specific CWmin value and continuing to a PHY-specific CWmax. CWmin and CWmax may differ for each AC. For example, if AC is AC_BK, CWmin may be aCWmin and CWmax may be aCWmax. If AC is AC_BE, CWmin may be aCWmin and CWmax may be aCWmax. If AC is AC_VI, CWmin may be {(aCWmin+1) / 2}-1 and CWmax may be aCWmin. If AC is AC_VO, CWmin may be {(aCWmin+1) / 4}-1 and CWmax may be {(aCWmin+1) / 2}-1. In OFDM PHY characteristics, with a 20MHz channel spacing, aCWmin may be 15. In OFDM PHY characteristics, with a 20MHz channel spacing, aCWmax may be 1023. The STA may decrement its backoff counter once per aSlotTime period while the medium is idle. Each time an MPDU transmission attempt fails and any STA retry increases, it takes a series of the following values.

[0157] In HCF, the basic unit of assigning transmission rights to a radio medium may be a TXOP (Transmission Opportunity). A TXOP is a time interval in which a particular QoS STA has the right to initiate a frame exchange sequence on the radio medium. A TXOP may be defined by its start time and maximum duration. A TXOP may be acquired through EDCA (Early Cycle Exchange). That is, an STA may acquire a TXOP if it performs an EDCA.

[0158] Figure 11 is a diagram showing an example of a backoff procedure according to one aspect of this embodiment. In Figure 11, the horizontal axis may represent time. 1101 may be a transmission by STA#1. 1102 may be an IFS. 1103 may be a backoff counter. 1103 may also be called a contention window. 1104 may be a transmission by STA#2. In Figure 11, STA#2 may detect 1101 on the channel. While STA#2 is detecting 1101, it may determine that the channel is busy. In other words, 1101 may be the period during which the channel is determined to be busy. STA#2 may perform carrier sense and determine whether the channel is busy or not. When the period of 1101 has ended and STA#2 determines that the channel is idle, it may perform carrier sense during the period of 1102. For example, 1102 may be a DIFS. 1102 may also be an AIFS. STA#2 may start 1103 if it is idle during the period of 1102. 1103 decrements the backoff counter while the channel is idle. For example, 6 backoff counters may be generated in 1103. The backoff counter is decremented while the channel is idle, and when the backoff counter reaches 0, STA#2 may transmit (1104). Here, the backoff counter may be determined between 0 and CW. CW may be a value selected from a range of values ​​between aCWmin and aCWmax. The channel may be referred to as the radio medium.

[0159] The carrier sense mechanism may be a mechanism that combines the Network Allocation Vector (NAV) status with the physical carrier sense of the STA transmitter to determine whether the medium is busy or idle. The NAV may be maintained by each STA and may be an indicator of the period during which transmission to the wireless medium is not initiated by the STA, regardless of whether the STA's Clear Channel Assessment (CCA) function senses that the medium is busy.

[0160] The carrier sense mechanism in STA may be performed in the physical layer processing unit SU3 and / or the MAC layer processing unit SU3. The carrier sense mechanism in AP may be performed in the physical layer processing unit AU3 and / or the MAC layer processing unit AU3.

[0161] The NAV may be a counter that counts down to zero at a constant rate. The STA may indicate that the virtual carrier sense is idle if the NAV counter is zero. The STA may indicate that the virtual carrier sense is busy if the NAV counter is not zero. The physical carrier sense function and the virtual carrier sense function may be used to determine the state of the medium. If either the physical carrier sense function or the virtual carrier sense function indicates busy, the medium may be considered busy. If both the physical carrier sense function and the virtual carrier sense function indicate idle, the medium may be considered idle. The virtual carrier sense may be referred to as the NAV. The NAV may be provided by all MACs. The NAV counter may be referred to as the NAV timer.

[0162] The physical carrier sense function in the STA may be controlled by the physical layer processing unit SU3. The virtual carrier sense function in the STA may be controlled by the MAC layer processing unit SU4. The physical carrier sense function in the AP may be controlled by the physical layer processing unit AU3. The virtual carrier sense function in the AP may be controlled by the MAC layer processing unit AU4. The NAV in the STA may be controlled by the MAC layer processing unit SU4. The NAV in the AP may be controlled by the MAC layer processing unit AU4.

[0163] The STA may set the NAV if the address field of a received frame is not its own address. The STA may update the NAV using the information from any valid Duration field in the PSDU when it receives at least one valid frame in the PSDU. The STA may update the NAV if the value indicated by the Duration field of a received frame is greater than the current NAV value. The STA does not update the NAV if the RA (address) of a received frame is equal to the STA's own MAC address.

[0164] An STA may maintain two NAVs. An AP may maintain two NAVs. The two NAVs may be an intra-BSS NAV and a basic NAV. The intra-BSS NAV may be updated by an intra-BSS PPDU. The basic NAV may be updated by an inter-BSS PPDU. The basic NAV may be updated by a PPDU that cannot be classified as either an intra-BSS PPDU or an inter-BSS PPDU. An STA maintaining two NAVs may indicate that the medium is idle if the timers for both NAVs are 0. In other words, an STA maintaining two NAVs may indicate that the medium is idle if the timers for both the intra-BSS NAV and the basic NAV are 0. If at least one of the two NAV timers is not 0, the virtual CS indication may indicate that the medium is busy. In other words, if an STA or AP maintaining two NAVs has a timer that is not zero for at least one Intra-BSS NAV or basic NAV, the virtual CS indication may indicate that the media is busy.

[0165] NAV may also be basic NAV. NAV may also be intra-BSS NAV. Basic NAV may also be NAV. Intra-BSS NAV may also be NAV. NAV may be called basic NAV. NAV may also be called intra-BSS NAV. Basic NAV may also be called NAV. Intra-BSS NAV may also be called NAV.

[0166] Carrier sense (CS) may be performed through both physical and virtual mechanisms. Carrier sense may also be referred to as a carrier sense function. Carrier sense may also be referred to as a carrier sense mechanism. A virtual carrier sense mechanism is implemented by distributing reservation information that notifies of the advance use of a medium. Exchanging RTS and CTS frames before the actual data frame may be one means of distributing medium reservation information. RTS and CTS frames may include a Duration field that defines the period during which the medium is reserved for transmitting the actual data frame and Ack frame. An STA that receives an RTS frame (sent by an originating STA) or a CTS frame (sent by a destination STA) processes the medium reservation. An STA can know that it is planning to transmit a data frame using the medium even if it does not receive from the originating STA. Medium reservation information may be distributed in the Duration / ID field of an individually addressed frame. The Duration / ID field may indicate the time (period) during which the medium is reserved. The Duration / ID field may indicate the time during which the medium is reserved, ending in the following Ack frame. In the case of fragment sequences, the Duration / ID field may indicate the time the medium is reserved until the end of the Ack frame following the next fragment. The RTS / CTS mechanism may also function when multiple BSSs using the same channel overlap. The medium reservation mechanism may also function across BSS boundaries.

[0167] The RTS (Request To Send) frame format may include a Frame Control field, a Duration field, an RA field, a TA field, and an FCS field. The Duration field of the RTS frame format may indicate the time (in microseconds) required to send the pending data or management frame, one CTS frame, one Ack frame, and three SIFS frames. The RA field of the RTS frame may be the address of the STA that is the intended direct recipient of the pending individually addressed frame. The TA field may be the address of the STA sending the RTS frame or the bandwidth signal TA of the STA sending the RTS frame.

[0168] The CTS (Clear To Send) frame format may include a Frame Control field, a Duration field, an RA field, and an FCS field. The Duration field of the CTS frame format sent in response to an RTS frame may be the Duration field of the previous RTS frame minus the time required to send the CTS frame and its corresponding SIFS. In other words, it may be the time required to send the pending data or management frame, one Ack frame, and two SIFS. If the CTS frame is the first frame in the exchange and the pending data or management frame requires an acknowledgment, the Duration field may be the time (in microseconds) required to send the pending data or management frame, two SIFS, and one Ack frame. If the CTS frame is the first frame in the exchange and the pending data or management frame does not require an immediate acknowledgment, the Duration field may be the time required to send the pending data or management frame and one SIFS. If the CTS frame is a response to an RTS frame, the RA field of the CTS frame may contain the address from the TA field of the RTS frame, and the individual / group bits may be set to 0. If the CTS frame is the first frame in a frame exchange, the RA field may contain the source MAC address.

[0169] Figure 12 shows an example of NAV according to one aspect of this embodiment. In Figure 12, the horizontal axis may represent time. For example, 1201 may be the timeline of AP#1's operation. 1202 may be the timeline of STA#1's operation. 1203 may be the timeline of AP#2's operation. 1204 may be the timeline of STA#2's operation. 1201, 1202, 1203, and 1204 may be timelines on the same channel. 1205 may be an RTS frame. 1206 may be the NAV period of AP#1. 1207 may be a CTS frame. 1208 may be the NAV period of STA#2. 1209 may be a Data frame. 1210 may be an AcK frame. 1211 may be an IFS. 1212 may be a contention window (backoff counter, backoff procedure). STA#1 may send 1205 to AP#2. Upon receiving 1205, AP#1 may set 1206 for the period indicated in the RTS Duration field. Upon receiving 1205, AP#2 may send 1207 to STA#1. Upon receiving 1207, STA#2 may set 1208 for the period indicated in the CTS Duration field. Upon receiving 1207, STA#1 may send 1209. Upon receiving 1209, AP#2 may send 1210 to STA#1. After 1206 is completed, AP#1 may start 1212 with 1211 if the channel is idle. After 1208 is completed, STA#2 may start 1212 with 1211 if the channel is idle. The period between 1205 and 1207 may be IFS. AP#2 may send 1207 if the channel is idle during the IFS period before sending 1207. There may be an IFS period between 1207 and 1209. STA#1 may send 1209 if the channel is idle during the IFS period before sending 1209. There may be an IFS period between 1209 and 1210. AP#2 may send 1210 if the channel is idle during the IFS period before sending 1210.Here, for example, AP#1 may be 202 in Figure 2. For example, STA#1 may be 207 in Figure 2. For example, AP#2 may be 206 in Figure 2. For example, STA#2 may be 208 in Figure 2. 1201 may be the timeline of the operation of AP or STA. 1202 may be the timeline of the operation of AP or STA. 1203 may be the timeline of the operation of AP or STA. 1204 may be the timeline of the operation of AP or STA.

[0170] An STA or AP may perform a frame exchange. For example, a frame exchange may occur when an STA or AP sends an RTS and the STA or AP sends a CTS to the RTS. For example, a frame exchange may occur when an STA or AP sends a Trigger frame and the STA or AP sends a CTS to the Trigger frame. For example, a frame exchange may occur when an STA or AP sends an MU-RTS and the STA or AP sends a CTS to the MU-RTS. For example, a Trigger frame may be used by an AP to allocate a Resource Unit (RU) to an STA. A Trigger frame may be a frame containing at least a Common Info field and / or a User Info List field. The Common Info field may be a field for notifying multiple STAs of information common to them. The User Info List field may contain zero or more User Info fields. The User Info field may be a field for allocating RUs to each STA. For example, the User Info field may contain an RU allocation subfield.

[0171] A BSS transition may refer to a change in the association between two BSSs within the same ESS, performed by an STA. An association may refer to a service that establishes a mapping between an AP and an STA and enables STA invocation by distribution system services (DSSs), or a service that establishes a mapping between an AP MLD and a non-AP MLD and enables non-AP MLD invocation by a DSS. A disassociation service may refer to a service that removes an existing association. A reassociation service may refer to a service that transfers an association established between an AP and an STA from one AP to another (or the same AP). Authentication may refer to a service used to establish the identity of one STA as a member of a set of STAs authorized to connect to another STA, or to establish the identity of one MLD as a member of a set of MLDs authorized to connect to another MLD. A Robust Security Network Association (RSNA) may refer to the type of association used by a pair of STAs when the procedure for establishing authentication or association between them involves a 4-way handshake or the Fast BSS Transition (FT) protocol.A 4-way handshake may be defined as a pairwise key management protocol in which two parties verify that they mutually possess a Pairwise Master Key (PMK) and distribute a Group Temporal Key (GTK). The PMK may be a key derived from a key generated using the Extensible Authentication Protocol (EAP) method, or a key obtained directly from a pre-shared key (PSK). The GTK may be a temporary key used to protect information exchanged in a group-addressed Data Frame.

[0172] The primary purpose of a MAC sublayer may be to transfer MSDUs between MAC sublayer entities. The information necessary for the distribution system service to operate is provided by association services. Before the MSDU is processed by the distribution system service, the STA or MLD may be "associated".

[0173] A BSS transition may be defined for an STA or MLD. In a BSS transition, the movement of an STA from one BSS within a given ESS to another BSS within the same ESS may be defined. In a BSS transition, the movement of a non-AP MLD may be defined from one AP MLD within a given ESS, where each non-AP STA belonging to a non-AP MLD is in one BSS, and different non-AP STAs belonging to a non-AP MLD are in different BSSs, to another AP MLD within the same ESS, where each non-AP STA belonging to a non-AP MLD is in another BSS, and different non-AP STAs belonging to a non-AP MLD are in different BSSs. In a BSS transition, a movement may be defined for a non-AP MLD to move from one AP MLD within one ESS to another BSS within the same ESS, where the MLD MAC address of the non-AP MLD is the same as the MAC address of the non-AP STA, and the non-AP STA belonging to the non-AP MLD is in one BSS, and different non-AP STAs belonging to the non-AP MLD are in different BSSs. In a BSS transition, a movement may be defined for a non-AP STA to move from one BSS within a certain ESS to an AP MLD within the same ESS, where the MLD MAC address of the non-AP STA is the same as the MLD MAC address of the non-AP MLD, and the non-AP STA belonging to the non-AP MLD is in another BSS, and different non-AP STAs belonging to the non-AP MLD are in different BSSs, and the MAC address of the non-AP STA is the same as the MLD MAC address of the non-AP MLD, and the non-AP STA becomes a non-AP MLD.

[0174] To deliver MSDUs within an ESS via a DS, the DS needs to know which AP or AP MLD within the ESS to deliver the MSDUs to. This information may be provided to the DS through the concept of association. Association is necessary, but not sufficient, to support BSS-transition mobility. Association may be one of the services of the DSS. A non-AP STA may first be associated with an AP before being permitted to deliver MSDUs via the AP. A non-AP MLD may first be associated with an AP MLD before being permitted to deliver MSDUs via the AP MLD. In the case of a non-GLK STA that does not belong to an MLD, the act of connecting with an AP may invoke an association service and provide the DS with a mapping from the STA to the AP. In the case of a non-AP MLD, the act of connecting with an AP MLD may invoke an association service and provide the DS with a mapping from the non-AP MLD to the AP MLD.

[0175] At any given moment, a non-AP STA may connect to one AP, and a non-AP MLD may connect to one AP MLD. Once association is complete between a non-AP STA and an AP, the non-AP STA may communicate by making full use of the DS. Similarly, once association is complete between a non-AP MLD and an AP MLD, the non-AP MLD may communicate by making full use of the DS. Association between a non-AP STA and an AP may always be initiated by the non-AP STA, not by the AP. Association between a non-AP MLD and an AP MLD may always be initiated by the non-AP MLD, not by the AP MLD.

[0176] An AP may connect to multiple non-AP STAs simultaneously. Similarly, an AP MLD may connect to multiple non-AP MLDs simultaneously.

[0177] A non-AP STA may learn which APs exist and what operational capabilities are available from each of those APs, and then initiate an association service to establish an association. Similarly, a non-AP MLD may learn which MLDs exist and what operational capabilities are available from each of those AP MLDs and the APs belonging to each AP MLD, and then initiate an association service to establish an association with the AP MLDs.

[0178] To support BSS-transition mobility, additional functionality is required, which may be provided by a reassociation service. Reassociation may also be one of the DSS services.

[0179] The Reassociation service may be started to move the current association of an AP and a non-AP STA from one AP to the same AP or a different AP. The Reassociation service may be started to move the current association of an AP MLD and a non-AP MLD from one AP MLD to the same AP MLD or a different AP MLD. The Reassociation service may be started to move the current association of an AP and a non-AP STA to an association of an AP MLD and a non-AP MLD where the MLD MAC address of the non-AP MLD is the same as the MAC address of the non-AP STA. The Reassociation service may be started to move the current association of an AP MLD and a non-AP MLD to an association of an AP and a non-AP STA where the MAC address of the non-AP STA is the same as the MLD MAC address of the non-AP MLD.

[0180] In ESS, the reassociation service may notify the DS of the current mapping between APs and non-AP STAs, or between AP MLDs and non-AP MLDs. Reassociation may also allow non-AP STAs or non-AP MLDs to modify the association attributes of an established association while remaining connected to the same AP or AP MLD, respectively. Reassociation may always be initiated by a non-AP STA or non-AP MLD.

[0181] The Authentication service may be used in both ESS and IBSS for all STAs to establish their identity with the STAs they communicate with. If a mutually acceptable level of authentication is not established between two STAs, association may not be established. An STA may authenticate with many other STAs simultaneously. If authentication continues until reassociation, it may affect the speed at which STAs reassociate between APs, potentially limiting the performance of BSS-transition mobility. By using preauthentication, the overhead of the authentication service may be removed from the time-critical reassociation process.

[0182] An STA (local STA) for which dot11OCBActivated is false may keep an enumerated state variable for each STA (remote STA) that requires direct communication via WM. An MLD (local MLD) may keep an enumerated state variable for each MLD (remote MLD) that requires direct communication between two MLDs via WM, from one STA belonging to the local MLD to another STA belonging to the remote MLD.

[0183] This state variable may represent the relationship between local STA and remote STA. This state variable may also represent the relationship between local MLD and remote MLD. The state variable may take any of the following values. • State 1: Initial startup state of non-DMG STA performing authentication. Initial startup state of MLD performing authentication. Unauthenticated and unassociated. State 2: Authenticated but unassociated. State 3: Authenticated and associated. Pending RSNA Authentication. State 4: Authenticated and associated. RSNA established or not required.

[0184] Upon receiving the MLME-REASSOCIATE.request primitive, non-AP STAs, non-AP MLDs, and non-PCP (PBSS control point) STAs may perform reassociation with APs, AP MLDs, or PCPs, respectively, using the following procedures. If the STA or non-AP MLD is not connected within the same ESS, or if the status of the new AP, AP MLD, or PCP is State 1, the MLME-REASSOCIATE.confirm primitive may be issued to notify the SME that reassociation failed, and this process may be terminated. A non-AP STA may send a Reassociation Request frame to a new AP or PCP, or a non-AP STA belonging to a non-AP MLD may send a Reassociation Request frame containing a Basic Multi-Link element to an AP belonging to a new AP MLD. Unless otherwise specified, a non-AP STA belonging to a Non-AP MLD may initiate sending a Reassociation Request frame on a recommended link included in the MLME-REASSOCIATE.request primitive. The Reassociation Request frame may include an RSNE (Robust Security Network Element) included in the MLME-ASSOCIATE.request primitive. If a Reassociation Response frame with a status code of SUCCESS is received, the state variable of the new AP, AP MLD, or PCP may be set to State 4, or to State 3 if dot11RSNAActivated is true and the FT protocol is not used for the new AP, AP MLD, or PCP. Alternatively, the state variable of the old AP, AP MLD, or PCP may be set to State 2 unless the old AP, AP MLD, or PCP and the new AP, AP MLD, or PCP are identical. The MLME may also issue the MLME-REASSOCIATE.confirm primitive to notify the SME that the reassociation was successful. If the MLME-REASSOCIATION.request primitive stores the MAC address of a new AP, AP MLD, or PCP in the CurrentAPAddress parameter (reassociation to the same AP, AP MLD, or PCP), the following states, agreements, and allocations may be deleted or reset to their initial values. 1) All EDCAF(Enhanced Distributed Channel Access Function) state 2) Any block ack agreements that are not GCR(GroupCast with Retries) agreements 3) Sequence number 4) Duplicate detection caches 5) Anything queued for transmission 6) Fragmentation and reassembly buffers 7) Power management mode 8) WNM(Wireless Network Management) sleep mode 9) TDLS(Tunneled Direct-Link Setup) agreements 10) TPKSAs (TDLS PeerKey Security Associations) established with any peers 11) TSPECs (Traffic SPECification) 12) DMG(Directional Multi-Gigabit) TSPECs 13) GLK-GCR agreement 14) MSCS(Mirrored Stream Classification Service) 15) SCS (Stream Classification Service) 16) TWT (Target Wake Time) • If the reassociation destination is the same AP and the existing association is not between MLDs, the following states, agreements, and allocations may not be affected by the reassociation procedure. 1) Enablement / Deenablement 2) GDD (Geolocation Database Dependent) enablement 3) MMSLs (Multiple MAC Sublayers Links) 4) GCR agreements that are not GLK-GCR agreements 5) DMS (Directed Multicast Service) agreements 6) TFS (Traffic Filtering Service) agreements 7) FMS (Flexible Multicast Service) agreements 8) Triggered autonomous reporting agreements 9) FTM (Fine Timing Measurement) sessions 10) DMG SP(Service Period) and CBAP(Contention Based Access Period) allocations 11) PTP (Peer-to-Peer) TSPECs. In the case of a reassociation to a different AP, AP MLD, or PCP, or in the case of a reassociation to an AP where the new AP address is the same as the value of the CurrentAPAddress parameter and the existing association is between MLDs, or in the case of a reassociation to an AP MLD where the new AP MLD address is the same as the value of the CurrentAPAddress parameter and the existing association is not between MLDs, all of the above states, agreements, and allocations may be deleted or reset to their initial values.

[0185] If an AP or PCP receives a Reassociation Request frame from an STA, or if an AP belonging to an AP MLD receives a Reassociation Request frame containing a Basic Multi-Link element from a non-AP STA belonging to a non-AP MLD, the following procedure may be used. The MLME may issue an MLME-REASSOCIATE.indication primitive to notify the SME of a reassociation request. The SME may issue an MLME-REASSOCIATE.response primitive to the STA or non-AP MLD identified by the PeerSTAAddress parameter of the MLME-REASSOCIATE.indication primitive. If the reassociation fails, the SME may indicate the specific reason for the failure in the ResultCode parameter. Upon receiving the MLME-REASSOCIATE.response primitive, the MLME may send a Reassociation Response frame. If a Reassociation Response frame with a status code indicating SUCCESS is acknowledged by a non-AP STA belonging to an STA or non-AP MLD, the state of the STA or non-AP MLD may be set to State 4, or to State 3 if dot11RSNAActivated is true and the reassociation is not part of a fast BSS transition. If the ResultCode of the MLME-REASSOCIATE.response primitive is SUCCESS and the CurrentAPAddress parameter of the MLME-REASSOCIATION.indication primitive is the MAC address of the AP or PCP (reassociation to the same AP or PCP), the AP or PCP will treat the agreements and allocations of the non-AP STA as described above. The AP or PCP may delete or reset to its default values ​​any items (states, agreements, and allocations described above) that the non-AP STA has requested to be deleted or reset to their default values. The AP or PCP does not have to change states, agreements, and allocations that are listed as unaffected by the reassociation procedure. If the ResultCode of the MLME-REASSOCIATE.response primitive is SUCCESS and the CurrentAPAddress parameter of the MLME-REASSOCIATION.indication primitive is the MLD MAC address of the AP MLD (reassociation to the same AP MLD), the AP MLD will treat the agreements and allocations of the non-AP MLD as described above. The AP MLD may delete or reset to its default values ​​any items (states, agreements, and allocations described above) that the non-AP MLD has requested to be deleted or reset to their default values. The AP MLD does not need to change states, agreements, and allocations that are listed as unaffected by the reassociation procedure. If the ResultCode of the MLME-REASSOCIATE.response primitive is SUCCESS, and the CurrentAPAddress parameter of MLME-REASSOCIATION.indication is not the MAC address of its own AP or PCP, then all states, agreements, and allocations of the connected STA (associating STA) described above may be deleted or reset to their initial values. If the ResultCode of the MLME-REASSOCIATE.response primitive is SUCCESS, and the CurrentAPAddress parameter of MLME-REASSOCIATION.indication is not the MLD MAC address of its own AP MLD, then all states, agreements, and allocations of the connected non-AP MLD (associating non-AP MLD) described above may be deleted or reset to their initial values.

[0186] Fast BSS transition may aim to reduce the time during which connectivity is lost between STA and DS, or between non-AP MLD and DS, during BSS transition. FT (Fast BSS Transition) protocols are part of a relations service and may only apply when an STA or MLD moves to an AP or AP MLD within the same mobility domain in the same ESS. A mobility domain is a set of BSSs within the same ESS and may support Fast BSS transitions between BSSs.

[0187] The FT protocol may require the exchange of information between an STA and an AP, or between a non-AP MLD and an AP MLD, during the initial association (or subsequent reassociation). The STA and non-AP MLD may be referred to as the FT Originator (FTO). The AP and AP MLD may be referred to as the FT Responder (FTR). The initial exchange may be referred to as the FT initial mobility domain association. Successive reassociations to FTRs within the same mobility domain may use the FT protocol.

[0188] Two FT protocols may be defined: the FT protocol and the FT resource request protocol. The FT protocol may be executed when an FTO moves to a target FTR and may not require a resource request before the move. The FT resource request protocol may be executed when an FTO requires a resource request before the move.

[0189] When an FTO travels to a target FTR using FT protocols, message exchange may be performed using one of two methods: Over-the-Air or Over-the-DS. Over-the-Air, the FTO may communicate directly with the target FTR using authentication by the FT authentication algorithm. Over-the-DS, the FTO may communicate with the target FTR via the current FTR. Over-the-DS, communication between the FTO and the target FTR may take place using FT Action frames between the FTO and the current FTR. Over-the-DS, communication between the current FTR and the target FTR may take place using an encapsulation method. Over-the-DS, the current FTR may switch between the two encapsulations.

[0190] The ML (re)setup procedure may be a procedure for setting up a link between a non-AP MLD and an AP MLD. The ML (re)setup procedure may be a procedure completed through the exchange of Association Request frames and Association Response frames. The ML (re)setup procedure may be a procedure completed through the exchange of Reassociation Request frames and Reassociation Response frames. In the ML (re)setup procedure, the non-AP MLD and AP MLD may follow the association or reassociation procedure. The ML (re)setup procedure may be rephrased as ML (re)setup, etc.

[0191] A setup link is a link between an AP MLD and an associated non-AP MLD (associated non-AP MLD) that is requested by the non-AP MLD in a (Re)Association Request frame and accepted by the AP MLD in a (Re)Association Response frame, and that is not later deleted due to the deletion of a related AP or the deletion of the link.

[0192] A non-AP MLD may initiate an ML (re)setup with an AP MLD to (re)set up one or more links with the AP MLD. When a non-AP MLD initiates an ML (re)setup with an AP MLD, it may send a (Re)Association Request frame via a non-AP STA that belongs to the non-AP MLD and is operating on a link that the non-AP MLD expects to be part of the ML (re)setup. The “link expected to be part of the ML (re)setup” may be any single link that the ML (re)setup expects to be (re)set up.

[0193] The exchange of (Re)Association Request / Response frames may be for ML (re)setup only if both the (Re)Association Request frame and the (Re)Association Response frame contain a Basic Multi-Link element. If the (Re)Association Request frame contains a Basic Multi-Link element, the (Re)Association Response frame sent in response to the (Re)Association Request frame will also contain a Basic Multi-Link element.

[0194] In the (Re)Association Request frame, a non-AP MLD may indicate one or more links that have been requested to be (re)set up (re)set up, and the capabilities and operational parameters of the non-AP STAs belonging to the non-AP MLD corresponding to one or more requested links. A non-AP MLD may also request the (re)setup of one or more links with one or more subsets of APs belonging to an AP MLD.

[0195] In the (Re)Association Response frame, the AP MLD may indicate one or more request links whose (re)setup was accepted and / or rejected, and the capabilities and operational parameters of one or more request links. The AP MLD does one of the following: • Accept all links that request (re)setup. • Accept a subset of links that have been requested to be (re)set up, and that subset of links includes links that have received a (Re)Association Request frame. • Reject all links that request (re)setup.

[0196] The (Re)Association Response frame may be sent via AP MLD through the affiliated AP that received the (Re)Association Request frame.

[0197] When an MLD requests or accepts an ML (re)setup, it ensures that for two links that are part of a set of multiple links requested or accepted by the ML (re)setup, each link is located on a different non-overlapping operating channel.

[0198] If the link that received the (Re)Association Request frame is not accepted by AP MLD, AP MLD may treat ML (re)setup as a failure and may not accept any requested links. If the link that received the (Re)Association Request frame is accepted by AP MLD, ML (re)setup may succeed.

[0199] The AP MLD may assign a single AID to the non-AP MLD once the ML setup is successful.

[0200] If the ML setup is successful, for each setup link accepted as an ML setup, the single AID assigned by the AP MLD to the non-AP MLD must not be an AID already used by an AP belonging to the AP MLD corresponding to that setup link, or by another AP in the same multiple BSSID set as an AP belonging to the AP MLD corresponding to that setup link, to identify another non-MLD non-AP STA or non-AP MLD.

[0201] All non-AP STAs belonging to a non-AP MLD may have the same AID as the AID assigned to the non-AP MLD within the ML setup.

[0202] After a successful ML (re)setup between a non-AP MLD and an AP MLD, the non-AP MLD may be associated with the AP MLD according to the association or reassociation procedure between MLDs. Alternatively, after a successful ML (re)setup between a non-AP MLD and an AP MLD, the non-AP MLD and the AP MLD may have one or more setup links for the MLO.

[0203] ML reconfiguration may refer to a series of steps in which an AP MLD adds one or more related APs to itself, or removes one or more related APs from itself. Alternatively, ML reconfiguration may refer to a procedure that dynamically adds / removes links to a non-AP MLD's setup link without requiring a (re)association between two peer MLDs. ML reconfiguration may also be referred to as link reconfiguration, etc.

[0204] The AP MLD's SME may remove one or more affiliated APs by issuing an MLME-BSS-AP-REMOVAL.request primitive for each affiliated AP to be removed. The AP MLD may remove the affiliated APs indicated by the parameters of the BSSID of the primitive when it receives an MLME-BSS-AP-REMOVAL.request primitive. The AP MLD may announce the removal of an affiliated AP through all Beacon and Probe Response frames transmitted by the affiliated AP through the Reconfiguration Multi-Link element before the affiliated AP is removed.

[0205] For each series AP that AP MLD intends to remove, the Reconfiguration Multi-Link element may include a Per-STA Profile subelement with the AP Removal Timer Present subfield set to 1. For each series AP that AP MLD intends to remove, the Reconfiguration Multi-Link element may include a Per-STA Profile subelement with the AP Removal Timer subfield in the STA Info field set to the TBTT number of the series AP before that series AP was removed. The initial value of the AP Removal Timer subfield may be set to the value of the parameter in MLME-BSS-AP-REMOVAL.request primitive. The value of AP Removal Timer may be decremented by 1 for each subsequent Beacon frame.

[0206] AP MLD may remove the sequential AP indicated by the Link ID subfield in the STA Control field of the Per-STA Profile subelement containing the AP Removal Timer subfield, in the TBTT indicated by the value of the AP Removal Timer subfield in the Reconfiguration Multi-Link element included in the Beacon or Probe Response frame sent by the sequential AP. After removing the sequential AP, AP MLD may remove the Per-STA Profile subelement corresponding to the removed AP from the Reconfiguration Multi-Link element. If at least one Per-STA Profile subelement remains in the Reconfiguration Multi-Link element, AP MLD may continue to include the Reconfiguration Multi-Link element in subsequent Beacon and Probe Response frames of the remaining sequential APs. Otherwise, i.e., if no Per-STA Profile subelements remain in the Reconfiguration Multi-Link element, AP MLD may stop including the Reconfiguration Multi-Link element in subsequent Beacon and Probe Response frames of the remaining sequential APs.

[0207] In the TBTT indicated by the value of the AP Removal Timer subfield in the Reconfiguration Multi-Link element included in the Beacon or Probe Response frame sent by the affiliated AP, if the link corresponding to the AP to be removed is the only setup link between the AP MLD and the non-AP MLD, the AP MLD's MLME may issue the MLME-DISASSOCIATE.indication primitive to inform the SME of the non-AP MLD's disassociation.

[0208] A non-AP MLD may identify one or more affiliated APs to be removed from an associated AP MLD from a Reconfiguration Multi-Link element received in a Beacon or Probe Response frame transmitted by an AP belonging to the connected AP MLD (associated AP MLD). The connected non-AP MLD (associated non-AP MLD) may consider that there is no link corresponding to the AP to be removed in the TBTT indicated by the value of the AP Removal Timer subfield of the received Reconfiguration Multi-Link element, and may delete all information maintained for that link. If, after the non-AP MLD has deleted all information maintained for the link corresponding to the AP to be removed, there are no other setup links with that AP MLD, the MLME of the non-AP MLD may issue the MLME-DISASSOCIATE.indication primitive to notify the SME of the disassociation of the non-AP MLD.

[0209] A setup link is a link that was added after association via multilink reconfiguration (ML reconfiguration) and is not subsequently deleted by the deletion of a related AP or the deletion of a link.

[0210] A non-AP MLD in an associated state, i.e., one that holds a state variable that takes a State 3 or State 4 value, may request link reconfiguration for its setup link by sending a Link Reconfiguration Request frame from its non-AP STA to the corresponding AP belonging to the connected AP MLD (associated AP MLD). The Link Reconfiguration Request frame may also be a frame used by the non-AP MLD to request the addition and / or removal of links from the links set up during ML setup.

[0211] A Link Reconfiguration Response frame may be a frame sent by an AP MLD in response to a Link Reconfiguration Request frame received from a non-AP MLD, to accept or reject a request to add and / or remove links from links set up during the non-AP MLD's ML setup.

[0212] In the Reconfiguration Multi-Link element included in the Link Reconfiguration Request frame, the AP Removal Timer Present subfield within the Per-STA Profile subelement may be set to 0. In other words, the Per-STA Profile subelement within the Link Reconfiguration Request frame does not need to have the AP Removal Timer subfield in the STA Info field.

[0213] The AP MLD may send a Link Reconfiguration Response frame indicating a SUCCESS status to the non-AP MLD in response to a delete link operation, and after receiving an acknowledgment from the non-AP MLD for that response frame, it may delete the link and all information held for that link from the non-AP MLD's multiple setup links.

[0214] Non-AP MLD may receive a Link Reconfiguration Response frame indicating a SUCCESS status for the link deletion operation, send an acknowledgment for that response frame, and then delete the link and all information held for that link from its multiple setup links.

[0215] Seamless BSS Transition may be a process in which a terminal device transitions from one base station device to another without interrupting communication. A terminal device may support multiple different frequency bands. A terminal device may communicate with another base station device using a frequency band different from the frequency band used to communicate with a certain base station device. A terminal device may transition to another base station device using a different frequency band while still communicating with a certain base station device using a certain frequency band. A terminal device may be an STA. A terminal device may have a non-AP MLD built in. A terminal device may be a set of multiple STAs. A terminal device may have multiple non-AP MLDs built in. A base station device may be an AP. A base station device may have an AP MLD built in. A base station device may be a set of multiple APs. A base station device may have multiple AP MLDs built in. The AP MLD built into the base station device may belong to SMD. A base station device may have a program that has SMD-ME functionality built in. Both of the above two base station devices may have a program that realizes SMD-ME functionality by communicating between programs. Another communication device connected to the two base station devices mentioned above may incorporate a program with SMD-ME functionality. A communication device incorporating a program with SMD-ME functionality may maintain multiple base station devices, including the two base station devices mentioned above. For example, a communication device incorporating a program with SMD-ME functionality and connected to the two base station devices may perform maintenance by sending a signaling signal from the SMD-ME functionality program to the two base station devices to delete some or all of the information relating to one of the two base station devices. If both of the two base station devices incorporate a program with SMD-ME functionality, the two base station devices may implement SMD-ME functionality by communicating between their programs. For example, the two base station devices may perform maintenance by sending a signaling signal between the programs embedded in the base station devices to delete some or all of the information relating to one of the base station devices.A Seamless BSS Transition may be a set of procedures for a non-AP MLD to migrate from one AP MLD to another within the SMD. A Seamless BSS Transition may also be a set of procedures to minimize the time of connectivity loss between the non-AP MLD and the DS. In a Seamless BSS Transition, the non-AP MLD may remain in State 4 during the transition. That is, in a Seamless BSS Transition, the non-AP MLD may keep a state variable that takes the value of State 4 during the transition. Also, in a Seamless BSS Transition, the non-AP MLD may preserve the context of data transmission for a seamless experience. A Seamless BSS Transition may be referred to by a name other than Seamless BSS Transition. For example, Seamless BSS Transition may also be referred to as Seamless Transition, Seamless Roaming, MLD Transition, SMD Transition, UHR BSS Transition, UHR Link Reconfiguration, UHR Seamless Roaming, MLD-based mobility, SMD-based mobility, Super MLD-based mobility, MLD-based BSS transition, SMD-based BSS transition, Super MLD-based BSS transition, MLD-based fast BSS transition, etc. The term "transition" may be replaced with "roaming," "movement," etc. The transition may include BSS transition. The transition may include reassociation. The transition may include reassociation service.The transition may include a Fast BSS transition. The transition may include an MLO. A Super MLD may be used in the transition. Two or more AP MLDs belonging to a Super MLD may be used in the transition. "A certain AP MLD" may be referred to as "current AP MLD," "serving AP MLD," etc. "Another AP MLD" may be referred to as "target AP MLD," etc. "A series of steps" may be rephrased as "mechanism," etc.

[0216] A Seamless BSS Transition includes at least a transition execution procedure. For example, the transition execution procedure may be a procedure for a non-AP MLD to migrate from the current AP MLD to the target AP MLD. A Seamless BSS Transition may also include a transition preparation procedure. For example, the transition preparation procedure may be a procedure performed by a non-AP MLD as preparation for the migration. If a non-AP MLD uses Seamless BSS Transition to migrate from the current AP MLD to the target AP MLD, the transition preparation procedure may be executed before the transition execution procedure. While the transition preparation procedure is being executed, the current AP MLD may remain connected to the non-AP MLD. While the transition preparation procedure is being executed, the target AP MLD may not remain connected to the non-AP MLD. While the transition preparation procedure is being executed, the non-AP MLD may stop sending Data frames to the current AP MLD. While the transition preparation procedure is being executed, the non-AP MLD may not stop sending Data frames to the current AP MLD. A Non-AP MLD may determine whether to stop sending a Data Frame to the current AP MLD during the execution of the transition preparation procedure, based on the values ​​of some or all of the subfields contained in the received UHR Capabilities element.For example, a non-AP MLD may determine whether to stop sending Data frames to the current AP MLD during the execution of the transition preparation procedure based on the values ​​of the UHR Link Reconfiguration Support subfield and / or the UHR Link Reconfiguration Mode 2 Support subfield contained in the received UHR Capabilities element. The transition execution procedure may be referred to by names other than the transition execution procedure. For example, the transition execution procedure may be referred to as the transition procedure, roaming procedure, roaming execution procedure, etc. The transition preparation procedure may be referred to by names other than the transition preparation procedure. For example, the transition preparation procedure may be referred to as the roaming preparation procedure, etc. The transition preparation procedure may include some or all of the following: Transfer of context related to non-AP MLD from the current AP MLD to the target AP MLD. • Renegotiation of the context with target AP MLD • Setting up one or more links with target AP MLD

[0217] In a Seamless BSS Transition, a non-AP MLD may initiate the transition preparation procedure by sending a Transition Preparation Request frame to the current AP MLD. The Transition Preparation Request frame may indicate one or more sets of links to be set up in the target AP MLD. The Transition Preparation Request frame may also indicate context to be forwarded or renegotiated to the target AP MLD. The current AP MLD may send a Transition Preparation Response frame to the non-AP MLD to indicate acceptance or rejection of the link setting. If the link setting is accepted, the forwardable context may be forwarded to the target AP MLD. The Transition Preparation Request frame may be referred to in ways other than the Transition Preparation Request frame. For example, the Transition Preparation Request frame may be referred to in ways other than the Transition Preparation Response frame. For example, the Transition Preparation Response frame may be referred to in ways other than the Transition Preparation Response frame.

[0218] The aforementioned "context related to non-AP MLD" may include PTK (Pairwise Transient Key). The aforementioned "context related to non-AP MLD" may include PMK (Pairwise Master Key). The aforementioned "context related to non-AP MLD" may include information about SCS (Stream Classification Service). The aforementioned "context related to non-AP MLD" may include information about TWT (Target Wake Time). The aforementioned "context related to non-AP MLD" may include BA (Block Ack) agreements. The aforementioned "context related to non-AP MLD" may include other information related to non-AP MLD.

[0219] In the transition execution procedure, if a non-AP MLD uses Seamless BSS Transition to transition from the current AP MLD to the target AP MLD within the SMD, the non-AP MLD may send a Transition Execution Request frame to the current AP MLD. The current AP MLD may send one or more individually addressed downlink Data frames to the non-AP MLD over a certain period. The aforementioned period may begin from the time the Transition Execution Request frame is received. If the non-AP MLD chooses to receive one or more individually addressed buffered downlink Data frames from the current AP MLD, it may receive them over the aforementioned period. The Transition Execution Request frame may be referred to by something other than Transition Execution Request frame. For example, the Transition Execution Request frame may be referred to as Transition Request frame, Roaming Execution Request frame, Roaming Request frame, etc. The Transition Execution Request Frame may also be a UHR Link Reconfiguration Request Frame. A UHR Link Reconfiguration Request Frame may be used by a non-AP MLD to request the current AP MLD to add a link to the target AP MLD. A Transition Execution Request Frame may contain some or all of the fields included in the Reassociation Request Frame.A Transition Execution Request frame may contain some or all of the fields included in an FT Request frame, which is one of the FT Action frames. A Transition Execution Request frame may also contain some or all of the fields included in a Link Reconfiguration Request frame used in ML reconfiguration procedures. In a transition execution procedure, the current AP MLD may send a Transition Execution Response frame to a non-AP MLD after receiving a Transition Execution Request frame and after the context transfer or renegotiation is complete. A non-AP MLD does not need to send one or more Class 3 frames to the target AP MLD until it receives a Transition Execution Response frame from the current AP MLD. For example, a non-AP MLD does not need to send one or more uplink Data frames to the target AP MLD until it receives a Transition Execution Response frame from the current AP MLD. For example, a non-AP MLD does not need to send one or more Action frames to the target AP MLD until it receives a Transition Execution Response frame from the current AP MLD. A Transition Execution Response frame may be referred to by something other than a Transition Execution Response frame. For example, a Transition Execution Response frame may be referred to as a Transition Response frame, Roaming Execution Response frame, Roaming Response frame, etc.A Transition Execution Response frame may also be a UHR Link Reconfiguration Response Frame. A UHR Link Reconfiguration Response Frame is sent by the current AP MLD in response to a UHR Link Reconfiguration Request Frame received from a non-AP MLD, and may accept or reject a request to add a link to the target AP MLD. A Transition Execution Response frame may contain some or all of the fields included in a Reassociation Response frame. A Transition Execution Response frame may contain some or all of the fields included in an FT Response frame, which is one of the FT Action frames. A Transition Execution Response frame may contain some or all of the fields included in a Link Reconfiguration Response frame used in ML reconfiguration procedures. "non-AP MLD" and "current AP MLD" may be rephrased as "non-AP STA belonging to a non-AP MLD" and "AP belonging to a current AP MLD," respectively. Also, "current AP MLD" may be rephrased as "target AP MLD."

[0220] Seamless BSS Transition may include a series of steps in which the SMD removes the current AP MLD from itself, or the SMD removes some or all of the links of the current AP MLD to non-AP MLDs.

[0221] An example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove the current AP MLD by issuing a primitive for each AP MLD to be removed. When SMD receives this primitive, it may remove the current AP MLD indicated by the parameters contained in the primitive.

[0222] For the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-MLD Profile subelement with the Current AP Removal Timer Present subfield set to 1. For the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-MLD Profile subelement with the Current AP Removal Timer subfield in the MLD Info field set to the TBTT number of the current AP MLD before it was removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter of the primitive issued by SMD-ME. The value of Current AP Removal Timer may be decremented by 1 for each subsequent Beacon frame after the transmission of the Transition Execution Response frame. For AP MLDs other than the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may set the Current AP Removal Timer Present subfield in the corresponding Per-MLD Profile subelement to 0.

[0223] The SMD may remove the current AP MLD in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent with the current AP MLD. The SMD may also identify the current AP MLD from the identifier indicated by the MLD ID subfield in the MLD Control field of the Per-MLD Profile subelement in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent with the current AP MLD, and remove that current AP MLD. After removing the current AP MLD, the SMD may remove the Per-MLD Profile subelement corresponding to the removed AP MLD from the Reconfiguration SMD element.

[0224] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove the current AP MLD by issuing a primitive for each AP MLD to be removed. When SMD receives this primitive, it may remove the current AP MLD indicated by the parameters contained in the primitive.

[0225] For the current AP MLD that the SMD intends to remove, the Reconfiguration SMD element may include a Per-MLD Profile subelement with the Current AP Removal Timer Present subfield set to 1. For the current AP MLD that the SMD intends to remove, the Reconfiguration SMD element may include a Per-MLD Profile subelement with the Current AP Removal Timer subfield in the MLD Info field set to the time period until the current AP MLD is removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter of the primitive issued by the SMD-ME. When the SMD sends a Transition Execution Response frame with the current AP MLD, it may set the value of the Current AP Removal Timer subfield in the Per-MLD Profile subelement corresponding to the current AP MLD within the Reconfiguration SMD element included in this Transition Execution Response frame to its initial value and start the timer. Furthermore, for AP MLDs other than the current AP MLD that the SMD intends to remove, the Reconfiguration SMD element may set the Current AP Removal Timer Present subfield in the corresponding Per-MLD Profile subelement to 0.

[0226] The SMD may remove the current AP MLD at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in the Transition Execution Response frame sent with the current AP MLD. The SMD may also identify the current AP MLD from the identifier indicated by the MLD ID subfield in the MLD Control field of the Per-MLD Profile subelement at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in the Transition Execution Response frame sent with the current AP MLD, and remove that current AP MLD. After removing the current AP MLD, the SMD may remove the Per-MLD Profile subelement corresponding to the removed AP MLD from the Reconfiguration SMD element.

[0227] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove the current AP MLD by issuing a primitive for each AP MLD to be removed. When SMD receives this primitive, it may remove the current AP MLD indicated by the parameters contained in the primitive.

[0228] The Reconfiguration SMD element may include a Current AP Removal Timer subfield outside the Per-MLD Profile subelement, which is set to the TBTT number of the current AP MLD before it is removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter issued by the SMD-ME. The value of Current AP Removal Timer may be decremented by 1 for each subsequent Beacon frame after the transmission of the Transition Execution Response frame.

[0229] The SMD may remove the current AP MLD in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent with the current AP MLD. The SMD may also identify the current AP MLD from the identifier indicated by the MLD ID subfield in the MLD Control field of the Per-MLD Profile subelement in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent with the current AP MLD, and remove that current AP MLD. After removing the current AP MLD, the SMD may remove the Per-MLD Profile subelement corresponding to the removed AP MLD from the Reconfiguration SMD element.

[0230] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove the current AP MLD by issuing a primitive for each AP MLD to be removed. When SMD receives this primitive, it may remove the current AP MLD indicated by the parameters contained in the primitive.

[0231] The Reconfiguration SMD element may include a Current AP Removal Timer subfield outside the Per-MLD Profile subelement, which is set for the time period until the current AP MLD is removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter issued by the SMD-ME primitive. When the SMD sends a Transition Execution Response frame with the current AP MLD, it may set the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in this Transition Execution Response frame to its initial value and start the timer.

[0232] The SMD may remove the current AP MLD at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in the Transition Execution Response frame sent with the current AP MLD. The SMD may also identify the current AP MLD from the identifier indicated by the MLD ID subfield in the MLD Control field of the Per-MLD Profile subelement at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in the Transition Execution Response frame sent with the current AP MLD, and remove that current AP MLD. After removing the current AP MLD, the SMD may remove the Per-MLD Profile subelement corresponding to the removed AP MLD from the Reconfiguration SMD element.

[0233] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may delete some or all of the links in the current AP MLD by issuing a primitive for each link to be deleted. When SMD receives this primitive, it may delete the links in the current AP MLD indicated by the parameters contained in the primitive.

[0234] For each link in the current AP MLD that the SMD intends to delete, the Reconfiguration SMD element may include a Per-Link Profile subelement with the Current AP Removal Timer Present subfield set to 1. For each link in the current AP MLD that the SMD intends to delete, the Reconfiguration SMD element may include a Per-Link Profile subelement with the Current AP Removal Timer subfield set to the TBTT of the link before it was deleted. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter of the primitive issued by the SMD-ME. The value of Current AP Removal Timer may be decremented by 1 for each subsequent Beacon frame after the transmission of the Transition Execution Response frame.

[0235] The SMD may delete the link indicated by the Link ID subfield in the Per-Link Profile subelement containing the Current AP Removal Timer subfield, and all information held for that link, in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent in the current AP MLD.

[0236] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may delete some or all of the links in the current AP MLD by issuing a primitive for each link to be deleted. When SMD receives this primitive, it may delete the links in the current AP MLD indicated by the parameters contained in the primitive.

[0237] For each link in the current AP MLD that the SMD intends to delete, the Reconfiguration SMD element may include a Per-Link Profile subelement with the Current AP Removal Timer Present subfield set to 1. For each link in the current AP MLD that the SMD intends to delete, the Reconfiguration SMD element may include a Per-Link Profile subelement with the Current AP Removal Timer subfield set to the time period until the link is deleted. The initial value of the Current AP Removal Timer subfield may be set to the value of the primitive parameter issued by the SMD-ME. When the SMD sends a Transition Execution Response frame in the current AP MLD, it may set the value of the Current AP Removal Timer subfield in the Per-Link Profile subelement corresponding to each link within the Reconfiguration SMD element included in this Transition Execution Response frame to its initial value and start a timer for each link.

[0238] The SMD may delete the link indicated by the Link ID subfield in the Per-Link Profile subelement containing the Current AP Removal Timer subfield, and all information held for that link, at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame sent in the current AP MLD.

[0239] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove some or all of the APs belonging to the current AP MLD by issuing a primitive for each AP to be removed. When SMD receives this primitive, it may remove the APs belonging to the current AP MLD indicated by the parameters contained in the primitive.

[0240] For each AP in the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-AP Profile subelement with the Current AP Removal Timer Present subfield set to 1. For each AP in the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-AP Profile subelement with the Current AP Removal Timer subfield set to the TBTT number of the AP in the series before that AP was removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter of the primitive issued by SMD-ME. The value of Current AP Removal Timer may be decremented by 1 for each subsequent Beacon frame after the transmission of the Transition Execution Response frame.

[0241] The SMD may remove the series AP indicated by the Link ID subfield in the Per-AP Profile subelement containing the Current AP Removal Timer subfield in the TBTT indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element contained in the Transition Execution Response frame or Transition Preparation Response frame sent in the current AP MLD. After removing the series AP, the SMD may remove the Per-AP Profile subelement corresponding to the removed AP from the Reconfiguration SMD element.

[0242] Another example of the procedure included in Seamless BSS Transition is described below. SMD-ME may remove some or all of the APs belonging to the current AP MLD by issuing a primitive for each AP to be removed. When SMD receives this primitive, it may remove the APs belonging to the current AP MLD indicated by the parameters contained in the primitive.

[0243] For each AP in the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-AP Profile subelement with the Current AP Removal Timer Present subfield set to 1. For each AP in the current AP MLD that SMD intends to remove, the Reconfiguration SMD element may include a Per-AP Profile subelement with the Current AP Removal Timer subfield set to the time period until that AP is removed. The initial value of the Current AP Removal Timer subfield may be set to the value of the parameter in the primitive issued by SMD-ME. When SMD sends a Transition Execution Response frame in the current AP MLD, it may set the value of the Current AP Removal Timer subfield in the Per-AP Profile subelement corresponding to each AP in the Reconfiguration SMD element included in this Transition Execution Response frame to its initial value and start a timer for each AP in the series.

[0244] The SMD may remove the series AP indicated by the Link ID subfield in the Per-AP Profile subelement containing the Current AP Removal Timer subfield at the end of the period indicated by the value of the Current AP Removal Timer subfield in the Reconfiguration SMD element included in the Transition Execution Response frame sent by the current AP MLD. After removing the series AP, the SMD may remove the Per-AP Profile subelement corresponding to the removed AP from the Reconfiguration SMD element.

[0245] Another example of the procedure included in Seamless BSS Transition is described below. SMD may remove the current AP MLD based on the success of the Seamless BSS Transition. For example, SMD may remove the current AP MLD when it sends a Transition Execution Response frame indicating SUCCESS status to the non-AP MLD in response to a request for a transition execution procedure from the non-AP MLD, and receives an acknowledgment for that response frame from the non-AP MLD. Alternatively, for example, SMD may remove the current AP MLD when it sends an acknowledgment for the Class 3 frame from the target AP MLD to the non-AP MLD, based on the fact that it has received the first Class 3 frame from the non-AP MLD in the target AP MLD it covers. In this case, the timing of SMD's removal of the current AP MLD does not have to be based on the value of the Current AP Removal Timer subfield.

[0246] The statement "the SMD removes the current AP MLD" may also be rephrased as "the SMD deletes all links of the current AP MLD", "the SMD deletes all information retained for the links of the current AP MLD", and the like. In addition, when the SMD removes the current AP MLD, part or all of the context related to the non-AP MLD may be deleted or reset to an initial value.

[0247] In the transition execution procedure, after receiving the Transition Execution Request frame, the current AP MLD may forward any pending, individually addressed downlink Data frames intended for the non-AP MLD that initiated the Seamless BSS Transition to the target AP MLD. For example, if an AP belonging to the current AP MLD decides to forward a Data frame to an AP belonging to the target AP MLD, it may forward a Data frame received from a non-AP STA belonging to a non-AP MLD to the AP belonging to the target AP MLD. For example, if an AP belonging to the current AP MLD receives a Data frame from a non-AP STA belonging to a non-AP MLD after a DS mapping update, it may forward that Data frame to the AP belonging to the target AP MLD until it sends a Transition Execution Response frame. The AP belonging to the target AP MLD may deliver the Data frame forwarded from the AP belonging to the current AP MLD to the DS as MAC service tuples. If an AP belonging to the current AP MLD receives a Data frame from a non-AP STA belonging to a non-AP MLD after a DS mapping update, it does not need to forward that Data frame to the AP belonging to the target AP MLD after sending a Transition Execution Response frame. If an AP belonging to the current AP MLD receives a Data frame from a non-AP STA belonging to a non-AP MLD before a DS mapping update, it does not need to forward that Data frame to the AP belonging to the target AP MLD.If an AP belonging to the Current AP MLD receives a Data Frame from a non-AP STA belonging to a non-AP MLD before a DS mapping update, it may distribute that Data Frame to the DS as a MAC service tuples.

[0248] In the transition execution procedure, the current AP MLD, after receiving a Transition Execution Request frame, transfers the context necessary to enable operations with the target AP MLD. For example, in the transition execution procedure, the current AP MLD may begin transferring the context necessary to enable operations with the target AP MLD to the target AP MLD when an AP belonging to the current AP MLD receives a Transition Execution Request frame from an STA belonging to a non-AP MLD. The "context necessary to enable operations with the target AP MLD" may include the SN (Sequence Number). The "context necessary to enable operations with the target AP MLD" may include the PN (Packet Number). The "context necessary to enable operations with the target AP MLD" may include the PTK (Pairwise Transient Key). The "context necessary to enable operations with the target AP MLD" may include the PMK (Pairwise Master Key). The "context necessary to enable operations with the target AP MLD" may include information about the SCS (Stream Classification Service). The "context necessary to enable operation with target AP MLD" may include information about TWT (Target Wake Time). The "context necessary to enable operation with target AP MLD" may include BA (Block Ack) agreements. The "context necessary to enable operation with target AP MLD" may include other information about non-AP MLDs.Part of the context required to enable operations with a target AP MLD may be transferred in the transition preparation procedure.

[0249] In the transition execution procedure, while a non-AP MLD transitions from a current AP MLD to a target AP MLD, the current AP MLD may forward one or more frames to the target AP MLD. In the transition execution procedure, the frames transferred from the current AP MLD to the target AP MLD may include Data frames transmitted from an AP belonging to the current AP MLD and / or the target AP MLD to a STA belonging to the non-AP MLD. In the transition execution procedure, the frames transferred from the current AP MLD to the target AP MLD may include individually addressed QoS Data frames. In the transition execution procedure, the frames transferred from the current AP MLD to the target AP MLD may include individually addressed Management frames. In the transition execution procedure, the frames transferred from the current AP MLD to the target AP MLD may include IQMF. In the transition execution procedure, the frames transferred from the current AP MLD to the target AP MLD may include other types of frames.

[0250] Figure 13 shows an example of the steps of a transition execution procedure according to one aspect of this embodiment. 1301 may be a non-AP MLD. 1302 and 1303 may be non-AP STAs belonging to a non-AP MLD. 1302 and 1303 may use different frequency bands. 1301 may belong to non-AP STAs other than 1302 and 1303. 1304 may be a current AP MLD. 1305 and 1306 may be APs belonging to a current AP MLD. 1305 and 1306 may use different frequency bands. 1304 may belong to APs other than 1305 and 1306. 1307 may be a target AP MLD. 1308 and 1309 may be APs belonging to a target AP MLD. 1308 and 1309 may use different frequency bands. 1307 may include APs other than 1308 and 1309. 1302, 1305, and 1308 may use the same frequency band. 1303, 1306, and 1309 may use the same frequency band. 1310 may be an SMD. 1310 may be an SMD-ME. 1304 and 1307 may be AP MLDs covered by 1310. 1310 may cover AP MLDs other than 1304 and 1307. In Figure 13, the vertical axis may represent time. 1311 may be the timeline of operation for 1302. 1312 may be the timeline of operation for 1303. 1313 may be the timeline of operation for 1305. 1314 may be the timeline of operation for 1306. 1315 may be the timeline of operation for 1308. 1316 may be part of the timeline for the operation of 1309. 1313, 1314, 1315, and 1316 may be part of the timeline for the operation of 1310. 1317 may be a frame sent from 1302 to 1305. For example, 1317 may be a Transition Execution Request frame. 1318 may be a frame sent from 1305 to 1302.For example, 1318 may be a Transition Execution Response frame. 1318 may include a first parameter. For example, the first parameter may be the Current AP Removal Timer subfield. For example, the first parameter may be the Current AP Removal Timer subfield set to the number of TBTTs of the current AP MLD before the current AP MLD is removed. For example, the first parameter may be the Current AP Removal Timer subfield set to the time period until the current AP MLD is removed. 1305 may send 1318 based on having received 1317. 1310 may set 1319 with the value indicated by the first parameter when 1305 sends 1318. 1310 may start 1319 when 1305 sends 1318. Alternatively, 1310 may start 1319 when 1307 receives the first Class 3 frame from 1301. For example, if the first parameter is the Current AP Removal Timer subfield set to the number of TBTTs in the current AP MLD, 1310 may decrement the value of the first parameter by 1 each time 1305 sends a subsequent Beacon frame after sending 1318. If the first parameter is the Current AP Removal Timer subfield set to the number of TBTTs in the current AP MLD, 1310 may consider 1319 to have expired in the TBTT indicated by the value of the first parameter. For example, if the first parameter is the Current AP Removal Timer subfield set to the number of TBTTs in the current AP MLD, and the value of the first parameter is 1, 1310 may consider 1319 to have expired at the time when 1305 sends a Beacon frame after sending 1318.If the first parameter is the Current AP Removal Timer subfield, which is set to the time period until the current AP MLD is removed, then 1310 may consider that 1319 expires at the end of the period indicated by the value of the first parameter. When 1319 expires, 1310 may remove 1304. For example, after removing 1304, 1310 may remove the Per-MLD Profile subelement corresponding to 1304 from the Reconfiguration SMD element. For example, if the value of the first parameter is 0, 1310 may remove 1304 when 1305 sends 1318. "Removing 1304" can be rephrased as "removing all links for 1304", "removing all information held for all links for 1304", etc. Also, the value of the first parameter may differ for each AP belonging to 1304. In this case, 1310 may set 1319 for each AP belonging to 1304. Furthermore, when 1310 expires, it may remove the AP belonging to the corresponding 1304. "Remove the AP" can be rephrased as "delete the link," "delete all information held for the link," etc.

[0251] In Figure 13, the first parameter may be included in a frame sent before 1318 by 1304, 1305, or 1310. For example, the first parameter may be sent in a Transition Preparation Response frame. When 1310 sends 1318 containing the first parameter, if it has already sent a frame containing the first parameter before 1318, it may update the value indicated by the first parameter with the value included in 1318 and set 1319 with the updated value.

[0252] Figure 14 shows an example of the steps of a transition execution procedure according to one aspect of this embodiment. 1401 may be a non-AP MLD. 1402 and 1403 may be non-AP STAs belonging to a non-AP MLD. 1402 and 1403 may use different frequency bands. 1401 may belong to non-AP STAs other than 1402 and 1403. 1404 may be a current AP MLD. 1405 and 1406 may be APs belonging to a current AP MLD. 1405 and 1406 may use different frequency bands. 1404 may belong to APs other than 1405 and 1406. 1407 may be a target AP MLD. 1408 and 1409 may be APs belonging to a target AP MLD. 1408 and 1409 may use different frequency bands. 1407 may include APs other than 1408 and 1409. 1402, 1405, and 1408 may use the same frequency band. 1403, 1406, and 1409 may use the same frequency band. 1410 may be an SMD. 1410 may be an SMD-ME. 1404 and 1407 may be AP MLDs covered by 1410. 1410 may cover AP MLDs other than 1404 and 1407. In Figure 14, the vertical axis may represent time. 1411 may be the timeline of operation for 1402. 1412 may be the timeline of operation for 1403. 1413 may be the timeline of operation for 1405. 1414 may be the timeline of operation for 1406. 1415 may be the timeline of operation for 1408. 1416 may be part of the timeline for the operation of 1409. 1413, 1414, 1415, and 1416 may be part of the timeline for the operation of 1410. 1417 may be a frame sent from 1402 to 1405. For example, 1417 may be a Transition Execution Request frame. 1418 may be a frame sent from 1405 to 1402.For example, 1418 may be a Transition Execution Response frame. 1419 may be a frame sent from 1402 to 1405. For example, 1419 may be a frame indicating an acknowledgment for 1418. 1420 may be a frame sent from 1403 to 1409. For example, 1420 may be the first Class 3 frame sent by 1402 after receiving 1418. 1421 may be a frame sent from 1409 to 1403. For example, 1421 may be a frame indicating an acknowledgment for 1420. If 1418 indicates a SUCCESS status, 1410 may consider the Seamless BSS Transition to have been successful upon receiving 1419 and remove 1404. Alternatively, 1410 may, upon receiving 1420, consider the Seamless BSS Transition to have been successful and, when sending 1421, remove 1404. "Remove 1404" may be rephrased as "remove all links for 1404," "remove all information held for all links for 1404," etc.

[0253] The term "frame" may also be referred to as a "MAC frame." The term "frame" may be rephrased as "MAC frame." The term "frame" may include MSDU, A-MSDU, and / or MMPDU.

[0254] "SMD removes current AP MLD" can also be rephrased as "SMD deletes all links in current AP MLD," or "SMD deletes all information held for the links in current AP MLD." Additionally, when SMD removes current AP MLD, it may delete or reset some or all of the context associated with non-AP MLDs.

[0255] As described above, when the timer that the SMD started when it sent a Transition Execution Response frame from the current AP MLD belonging to it expires, the current AP MLD is removed. This invention makes it possible to perform Seamless BSS Transition more efficiently.

[0256] A BSS max idle period may be defined. The BSS max idle period may be the period during which the AP does not disassociate the STA because it has not received a frame from that STA.

[0257] The WNM service may include BSS max idle period management. Through WNM (Wireless Network Management), STAs may exchange information to improve the overall performance of the wireless network. STAs may exchange operational data using the WNM protocol, and each STA may be aware of the network state, including the network topology and status. The WNM protocol provides a means for STAs to recognize the presence of coexisting interference, and STAs may manage RF (Radio Frequency) parameters based on the network state. In addition to providing information about the network state, WNM may also provide means for exchanging location information, supporting multiple BSSID capability on the same wireless infrastructure, supporting efficient distribution of group-addressed frames, and enabling a WNM sleep mode that allows STAs to sleep for extended periods without receiving frames from APs.The WNM service may include BSS max idle period management and / or BSS transition management and / or Channel usage and / or Collocated interference reporting and / or Diagnostic reporting and / or Directed multicast service (DMS) and / or Event reporting and / or Flexible multicast service (FMS) and / or Location services and / or Multicast diagnostic reporting and / or Multiple BSSID capability and / or Proxy Address Resolution Protocol (ARP) and / or QoS traffic capability and / or SSID list and / or Triggered STA statistics and / or TIM broadcast and / or Timing measurement and / or Traffic filtering service and / or U-APSD coexistence and / or WNM notification and / or WNM sleep mode. Other services may also be included.

[0258] BSS max idle period management may indicate a period during which the AP does not disassociate from the STA because it has not received any frames from that STA. This may improve STA power saving and AP resource management.

[0259] The MLME-ASSOCIATE.request primitive may include a BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate a recommended BSS Max Idle Period parameter. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is not true.

[0260] The MLME-ASSOCIATE.request primitive requests association with a specified peer MAC entity within the AP. The MLME-ASSOCIATE.request primitive may be generated by the SME when the STA attempts to establish an association with the AP or PCP. The MLME-ASSOCIATE.request primitive may initiate the association procedure. Upon receiving a response from the responder STA, the MLME may issue an MLME-ASSOCIATE.confirm primitive reflecting the result.

[0261] The MLME-ASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate the BSS Max Idle Period parameter of AP or PCP. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented is not true.

[0262] The MLME-ASSOCIATE.confirm primitive may report the result of an association attempt by the AP or PCP with a specified peer MAC entity. The MLME-ASSOCIATE.confirm primitive may be generated by the MLME as a result of receiving the MLME-ASSOCIATE.request primitive or an Association Response frame from the peer MAC entity in order to associate with the specified peer MAC entity in the AP or PCP. The SME may be notified of the result of the association procedure.

[0263] The MLME-ASSOCIATE.indication primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate a recommended BSS Max Idle Period parameter. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is not true.

[0264] The MLME-ASSOCIATE.indication primitive may indicate that a particular peer MAC entity is requesting association with a local MAC entity within the AP or PCP. The MLME-ASSOCIATE.indication primitive may be generated by the MLME as a result of receiving an association request from a particular peer MAC entity. The SME may be notified of the result of the association procedure.

[0265] The MLME-ASSOCIATE.response primitive may include a BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate the BSS Max Idle Period parameter of AP or PCP. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented is not true.

[0266] The MLME-ASSOCIATE.response primitive may be used to send a response to a specific peer MAC entity in the AP or PCP that requested association with the STA that issued this primitive. The MLME-ASSOCIATE.response primitive may be generated by the SME of the STA in the AP or PCP as a response to the MLME-ASSOCIATE.indication primitive. The MLME-ASSOCIATE.response primitive may initiate the sending of an AssociationResponse to the specific peer MAC entity that requested association.

[0267] The MLME-REASSOCIATE.request primitive may request a change of association to a specified new peer MAC entity in the AP or PCP. The MLME-REASSOCIATE.request primitive may be generated by the SME for the STA to change the association to a specified new peer MAC entity in the AP or PCP. The MLME-REASSOCIATE.request primitive may initiate the Reassociation procedure. If a response is received from the responding STA, the MLME may then issue an MLME-REASSOCIATE.confirm primitive reflecting the result.

[0268] The MLME-REASSOCIATE.request primitive may include a BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate a recommended BSS Max Idle Period parameter. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is not true.

[0269] The MLME-REASSOCIATE.confirm primitive may report the result of a reassociation attempt with a specified peer MAC entity in an AP or PCP. The MLME-REASSOCIATE.confirm primitive may be generated by the MLME as a result of an MLME-REASSOCIATE.request primitive for reassociation with a specified peer MAC entity located in an AP or PCP. The result of the reassociation procedure may be notified to the SME.

[0270] The MLME-REASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be the BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate the BSS Max Idle Period parameter of an AP or PCP. For example, the BSSMaxIdlePeriod parameter may be present when dot11WirelessManagementImplemented is true. The BSSMaxIdlePeriod parameter may be absent when dot11WirelessManagementImplemented is not true.

[0271] The MLME-REASSOCIATE.indication primitive may indicate that a particular peer MAC entity is requesting reassociation with a local MAC entity within the AP or PCP. The MLME-REASSOCIATE.indication primitive may be generated by the MLME as a result of a reassociation procedure initiated by the particular peer MAC entity, or as a result of a reassociation being established with the particular peer MAC entity. The SME may be notified of the establishment of the reassociation.

[0272] The MLME-REASSOCIATE.indication primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate a recommended BSS Max Idle Period parameter. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is not true.

[0273] The MLME-REASSOCIATE.response primitive may be used to send a response to a specific peer MAC entity in the AP or PCP that requested reassociation with the STA that issued this primitive. The MLME-REASSOCIATE.response primitive may be generated by the SME of the STA in the AP or PCP as a response to the MLME-ASSOCIATE.indication primitive. The MLME-ASSOCIATE.response primitive may initiate sending a Response to the specific peer MAC entity that requested reassociation.

[0274] The MLME-REASSOCIATE.response primitive may include a BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. The BSSMaxIdlePeriod parameter may indicate an AP or PCP BSS Max Idle Period parameter. For example, the BSSMaxIdlePeriod parameter may exist when dot11WirelessManagementImplemented is true. The BSSMaxIdlePeriod parameter may not exist when dot11WirelessManagementImplemented is not true.

[0275] The BSSMaxIdlePeriod parameter may also be referred to as BSSMaxIdlePeriod. The BSSMaxIdlePeriod parameter may also be referred to as parameter BSSMaxIdlePeriod.

[0276] The BSS Max Idle Period element may be included in the Association Request frame. The BSS Max Idle Period element may be included in the Association Response frame. The BSS Max Idle Period element may be included in the Reassociation Request frame. The BSS Max Idle Period element may be included in the Reassociation Response frame. For example, the BSS Max Idle Period element may exist if dot11WirelessManagementImplemented is true. For example, the BSS Max Idle Period element may exist if dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. Otherwise, it may not exist.

[0277] The Element ID of the BSS Max Idle Period element may be 90. The BSS Max Idle Period element (format) may include an Element ID field and / or a Length field and / or a Max Idle Period field and / or an Idle Options field.

[0278] The BSS Max Idle Period element may include a period during which an STA may refrain from sending frames to an AP before the AP disassociates the STA due to inactivity. For example, even if an STA does not send frames to the AP during the period included in the BSS Max Idle Period element, the AP may not disassociate the STA during the BSS Max Idle Period.

[0279] The BSSMaxIdlePeriod parameter may indicate the idle timeout limit. The time period (idle timeout limit) may be specified in units of 1000 TU. For example, 1000 TU may be 1024 microseconds (μs). For example, if the BSSMaxIdlePeriod parameter is 1, the time period of BSS Max Idle Period may be 1024 microseconds. If the BSSMaxIdlePeriod parameter is 2, the time period of BSS Max Idle Period may be 2048 microseconds. A value of 0 may indicate reserved. The Max Idle Period field may be an unsigned integer containing the value of the parameter BSSMaxIdlePeriod.

[0280] The Idle Options field may indicate options associated with the BSS idle capability. The Idle Options field may include the Protected Keep-Alive Required subfield. The Idle Options field may include "reserved". The Protected Keep-Alive Required subfield may be set to 1 to indicate that only protected frames are showing activity. The Protected Keep-Alive Required subfield may be set to 0 to indicate that either unprotected frames or protected frames are showing activity. The upper two bits of the Max Idle Period field may include the Unified Scaling Factor subfield, and the remaining 14 bits may include the Unscaled Interval subfield.

[0281] AP may include the BSS Max Idle Period element in the Association response frame and / or Reassociation Response frame. If dot11BssMaxIdlePeriod is non-zero, AP may include the BSS Max Idle Period element in the Association response frame and / or Reassociation Response frame. Otherwise, AP does not need to include the BSS Max Idle Period element in the Association response frame and / or Reassociation Response frame. STA can send protected keepalive frames or unprotected keepalive frames, as indicated in the Idle Options field.

[0282] The STA may include the BSS Max Idle Period element in the Association Request frame and / or Reassociation Request frame. Depending on the parameter conditions, the STA may include the BSS Max Idle Period element in the Association Request frame and / or Reassociation Request frame. For example, if dot11WirelessManagementImplemented is true, dot11BSSMaxIdlePeriod is non-zero, and dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true, the STA may include the BSS Max Idle Period element in the Association Request frame and / or Reassociation Request frame. If the BSS Max Idle Period element is present in the Association Request frame and / or Reassociation Request frame received by an AP with dot11BSSMaxIdlePeriodIndicationByNonAPSTA set to true, the AP can select the STA's recommended maximum idle period. The AP may indicate the selected value to the STA in the Association Request frame and / or Reassociation Request frame. The value selected by the AP may be the value used by the AP when making a disassociation decision, based on a timeout value equal to the BSSMaxIdlePeriod of the STA that is the recipient of the Association Request frame and / or Reassociation Request frame. The AP may provide different BSSMaxIdlePeriod values ​​for different STAs.The STA may send at least one protected or unprotected keepalive frame for each BSSMaxIdlePeriod, as indicated in the Idle Options field. If the STA sends an unprotected keepalive frame, it may use a frame with 48-bit TA and RA fields.

[0283] The Max Idle Period field of the BSS Max Idle Period element may indicate a period during which an STA may not send frames to the AP it is associating with without being disassociated. In other words, an STA will not be disassociated even if it does not send frames to the AP it is associating with during the period indicated by the Max Idle Period field of the BSS Max Idle Period element. An STA may be considered inactive if the AP has not received a Data frame, PS-Poll frame, or Management frame (protected or unprotected) from a frame exchange sequence initiated by the STA for a period longer than the time specified by the Max Idle Period field. If a protected keepalive frame is requested in the Idle Options field, the AP may disassociate the STA if it does not receive a protected frame from the STA during the BSSMaxIdlePeriod period. If the Idle Options field allows unprotected keepalive frames or protected keepalive frames, the AP may disassociate the STA if it does not receive a protected frame or an unprotected frame with 48-bit TA and RA fields from the STA during the BSSMaxIdlePeriod period. The AP may also disassociate and / or deauthenticate the STA even if the STA meets the requirements for sending keep-alive frames.

[0284] A Multi-link Device (MLD) max idle period may be defined. The MLD max idle period may be the period during which an AP MLD does not disassociate a non-AP MLD because it has not received a frame from any of the STAs belonging to that non-AP MLD.

[0285] In the case of non-MLO, BSS max idle period management may indicate a period during which the AP does not disassociate an STA because it has not received a frame from that STA. This may improve STA power saving and AP resource management.

[0286] In the case of MLO, the MLD max idle period management service may indicate a period during which an AP MLD does not disassociate a non-AP MLD because it has not received frames from that non-AP MLD on at least one setup link. This may improve power saving on non-AP MLDs and resource management on AP MLDs.

[0287] The MLME-ASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. In the case of non-MLO, the BSSMaxIdlePeriod parameter may indicate the BSS Max Idle Period parameter of AP or PCP. In the case of MLO, the BSSMaxIdlePeriod parameter may indicate the MLD max idle period parameter specified to the non-AP MLD by the AP MLD. For example, the BSSMaxIdlePeriod parameter may be present if dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true, and / or if a BSS Max Idle Period element is present in the Association Response frame.

[0288] The MLME-REASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. In the case of non-MLO, the BSSMaxIdlePeriod parameter may indicate the BSS Max Idle Period parameter of AP or PCP. In the case of MLO, the BSSMaxIdlePeriod parameter may indicate the MLD max idle period parameter specified to the non-AP MLD by the AP MLD. For example, the BSSMaxIdlePeriod parameter may exist if dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true.

[0289] In the case of non-MLO, the BSS Max Idle Period element may include a period during which the STA may refrain from sending frames to the AP before the AP disassociates the STA due to inactivity. For example, even if the STA does not send frames to the AP during the period included in the BSS Max Idle Period element, the AP may not disassociate it during that period.

[0290] In the case of MLO, the BSS Max Idle Period element may include a period during which a non-AP MLD may refrain from sending frames to an AP MLD on any enabled link before the AP MLD disassociates the non-AP MLD due to its inactivity. For example, even if a non-AP MLD does not send frames to an AP MLD on any enabled link during the period included in the BSS Max Idle Period element, it does not need to be disassociated from the AP MLD during that period.

[0291] The Max Idle Period field may indicate the BSS max idle period for BSS max idle period management and / or MLD max idle period management. A value of 0 may indicate reserved. The BSS max idle period may be in units of 1000 TU. The BSS max idle period may be in units of 1024 microseconds.

[0292] AP may include the BSS Max Idle Period element in the Association Response frame and / or Reassociation Response frame. For example, AP may include the BSS Max Idle Period element in the Association Response frame and / or Reassociation Response frame if a given parameter (e.g., dot11BssMaxIdlePeriod) is not 0. AP does not have to include the BSS Max Idle Period element in the Association Response frame and / or Reassociation Response frame if a given parameter (e.g., dot11BssMaxIdlePeriod) is 0.

[0293] In the case of MLO, the value carried in the BSS Max Idle Period element may be applied at the MLD level (unit). In the case of MLO, the value carried in the BSS Max Idle Period element is applied at the MLD level, and associated MLDs may follow the MLD max idle period (procedure). For example, associated MLDs may be the associated non-AP MLD and AP MLD. STA may send a protected keepalive frame or an unprotected keepalive frame as indicated in the Idle Options field.

[0294] If an AP belonging to an AP MLD includes a BSS Max Idle Period element in an Association Response frame and / or Reassociation Response frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field is applied at the MLD level and may be referred to as the MLD max idle period. During ML setup, if an AP belonging to an AP MLD includes a BSS Max Idle Period element in an Association Response frame and / or Reassociation Response frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field is applied at the MLD level and may be referred to as the MLD max idle period. An AP MLD may use a timeout value to determine whether to disassociate a non-AP MLD that is the target of the Association Response frame and / or Reassociation Response frame. An AP MLD may provide different max idle period values ​​for different non-AP MLDs.

[0295] A non-AP MLD may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated AP MLD via one of its affiliated non-AP STAs. A non-AP MLD may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated AP MLD via one of its affiliated non-AP STAs within the period indicated by the Max Idle Period field. If a non-AP MLD wants to avoid being disassociated by an AP MLD due to nonreceipt of a frame, it may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated AP MLD via one of its affiliated non-AP STAs (affiliated non-AP STAs) within the period specified in the Max Idle Period field. The keepalive frame may be protected or unprotected, as indicated in the Idle Options subfield.

[0296] A non-AP MLD may be considered inactive by an associated AP MLD if it has not received any Data frames, PS-Poll frames, or Management frames (protected or unprotected) from a frame exchange sequence initiated by any enabled link of any STA belonging to that non-AP MLD for a period longer than the time specified in the Max Idle Period subfield of the BSS Max Idle Period element sent to that non-AP MLD.

[0297] AP MLD may disassociate non-AP MLD in the following cases: - When a protected keepalive frame is requested in the Idle Options subfield of the BSS Max Idle Period element, and no protected frames are received from any non-AP STA belonging to the non-AP MLD during the max idle period. The Idle Options subfield allows unprotected or protected keepalive frames, and during the max idle period, it does not receive protected or unprotected frames from any non-AP STA belonging to a non-AP MLD.

[0298] Even if a non-AP MLD meets the keepalive frame transmission requirements, an AP MLD may disassociate or deeauthenticate the non-AP MLD.

[0299] A maximum idle period may be defined for SMD. For example, the maximum idle period for SMD may be called the SMD-ME maximum idle period. Other names are also acceptable.

[0300] APs that have (belong to) an AP MLD belonging to an SMD may send a frame. APs that have an AP MLD belonging to an SMD may send a frame that includes a BSS Max Idle Period element. In SMD, the period notified by the BSS Max Idle Period element may be applied at the SMD-ME level. SMD-ME may use the period notified by the BSS Max Idle Period element to determine (decide) the disassociation of a non-AP MLD.

[0301] A non-AP STA that has (belongs to) a non-AP MLD may receive a frame from an SMD-ME. A non-AP STA that has (belongs to) a non-AP MLD may receive a frame containing a BSS Max Idle Period element from an AP belonging to an AP MLD belonging to an SMD. A non-AP MLD may receive a frame containing a BSS Max Idle Period element from an SMD-ME. A non-AP MLD may receive a frame containing a BSS Max Idle Period element from an AP MLD belonging to an SMD. When a non-AP STA that has (belongs to) a non-AP MLD receives a frame containing a BSS Max Idle Period element from an AP belonging to an AP MLD belonging to an SMD, it may apply BSSMaxIdlePeriod at the SMD level. When a non-AP STA that has (belongs to) a non-AP MLD receives a frame containing a BSS Max Idle Period element from an AP belonging to an AP MLD belonging to an SMD, it may apply MaxIdlePeriod at the SMD level. A non-AP MLD may send a frame to an SMD-ME that it has associated with within the time period indicated by the Max Idle Period field, in order to avoid disassociation due to the SMD-ME not receiving the frame. A non-AP MLD may send a frame to an SMD-ME that it has associated with within the time period indicated by the Max Idle Period field, in order to avoid disassociation due to the SMD-ME not receiving the frame. A non-AP MLD may send a frame to any AP MLD belonging to an SMD-ME that it has associated with within the time period indicated by the Max Idle Period field, in order to avoid disassociation due to the SMD-ME not receiving the frame.A non-AP STA belonging to a non-AP MLD may send a frame to any AP of any AP MLD belonging to an SMD-ME that it is associated with within the time period indicated by the Max Idle Period field, in order to avoid disassociation due to the SMD-ME not receiving the frame.

[0302] The SMD-ME max idle period may be the period during which SMD-ME does not disassociate a non-AP MLD because it has not received a frame from any STA belonging to a non-AP MLD. The SMD-ME max idle period may also be the period during which any AP MLD belonging to SMD does not disassociate a non-AP MLD because it has not received a frame from any STA belonging to a non-AP MLD. In other words, even if SMD-ME does not receive a frame from a non-AP MLD it is associated with during the SMD-ME max idle period, it does not have to disassociate that non-AP MLD.

[0303] In the case of non-MLO, BSS max idle period management may indicate a period during which the AP does not disassociate an STA because it has not received a frame from that STA. This may improve STA power saving and AP resource management.

[0304] In the case of MLO, the MLD max idle period management service may indicate a period during which an AP MLD does not disassociate a non-AP MLD because it has not received frames from that non-AP MLD on at least one setup link. This may improve power saving on non-AP MLDs and resource management on AP MLDs.

[0305] In the case of SMD, the SMD-ME max idle period management service may indicate a period during which SMD-ME does not disassociate any AP MLD belonging to the SMD because it has not received frames from a non-AP MLD on at least one setup link. This may improve power saving on non-AP MLDs and resource management on SMD-ME.

[0306] The MLME-ASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. For non-MLO (non-SMD), the BSSMaxIdlePeriod parameter may indicate the AP or PCP BSS Max Idle Period parameter. For MLO (non-SMD), the BSSMaxIdlePeriod parameter may indicate the MLD max idle period parameter specified to the non-AP MLD by the AP MLD. For SMD, the BSSMaxIdlePeriod parameter may indicate the SMD-ME max idle period parameter specified to the non-AP MLD by the SMD-ME.

[0307] For example, the BSSMaxIdlePeriod parameter may exist if dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA are true, and / or if a BSS Max Idle Period element exists in the Association Response frame. It may also exist under other conditions.

[0308] The MLME-REASSOCIATE.confirm primitive may include the BSSMaxIdlePeriod parameter. The Type of the BSSMaxIdlePeriod parameter may be a BSS Max Idle Period element. For non-MLO (non-SMD), the BSSMaxIdlePeriod parameter may indicate the AP or PCP BSS Max Idle Period parameter. For MLO (non-SMD), the BSSMaxIdlePeriod parameter may indicate the MLD max idle period parameter specified to the non-AP MLD by the AP MLD. For SMD, the BSSMaxIdlePeriod parameter may indicate the SMD-ME max idle period parameter specified to the non-AP MLD by the SMD-ME.

[0309] For example, the BSSMaxIdlePeriod parameter may exist if dot11WirelessManagementImplemented and / or dot11BSSMaxIdlePeriodIndicationByNonAPSTA is true. It may also exist under other conditions.

[0310] In the case of non-SMD non-MLO, the BSS Max Idle Period element may include a period during which the STA may refrain from sending frames to the AP before the AP disassociates the STA due to inactivity. For example, even if the STA does not send frames to the AP during the period included in the BSS Max Idle Period element, the AP may not disassociate it during that period.

[0311] In the case of a non-SMD MLO, the BSS Max Idle Period element may include a period during which a non-AP MLD may refrain from sending frames to an AP MLD on any enabled link before the AP MLD disassociates the non-AP MLD due to its inactivity. For example, even if a non-AP MLD does not send frames to an AP MLD on any enabled link during the period included in the BSS Max Idle Period element, it does not need to be disassociated from the AP MLD during that period.

[0312] In the case of SMD, the BSS Max Idle Period element may include a period during which a non-AP MLD may refrain from sending frames to the SMD-ME on any enabled link before the SMD-ME disassociates the non-AP MLD due to its inactivity. For example, even if a non-AP MLD does not send frames to the SMD-ME on any enabled link during the period included in the BSS Max Idle Period element, it does not need to be disassociated from the SMD-ME during that period.

[0313] The Max Idle Period field may indicate the BSS max idle period (parameter) for BSS max idle period management and / or MLD max idle period management and / or SMD-ME max idle period management. A value of 0 may indicate reserved. The BSS max idle period may be in units of 1000 TU. The BSS max idle period may be in units of 1024 microseconds. Other units may be used. The BSS max idle period may indicate the timeout limit. The Max Idle Period field may be an unsigned integer containing the value of BSSMaxIdlePeriod.

[0314] AP and / or AP MLD and / or SMD-ME may include a BSS Max Idle Period element in its frame. The BSS Max Idle Period element may be included in the Management frame and / or Control frame and / or Data frame. AP and / or AP MLD and / or SMD-ME may include a BSS max idle period element in the frame used for roaming. For example, AP and / or AP MLD and / or SMD-ME may include a BSS Max Idle Period element in the Association Response frame and / or Reassociation Response frame and / or Roaming preparation request frame and / or Roaming preparation Response frame and / or Roaming execution Request frame and / or Roaming execution Response frame. The BSS Max Idle Period element may be included in frames other than those mentioned above. For example, AP and / or AP MLD and / or SMD-ME may include a BSS Max Idle Period element in its frame if a given parameter (e.g., dot11BssMaxIdlePeriod) is non-zero. AP does not need to include the BSS Max Idle Period element in the frame if a predetermined parameter (e.g., dot11BssMaxIdlePeriod) is 0. Other conditions may also exist.

[0315] In the case of non-SMD MLO, the value carried in the BSS Max Idle Period element may be applied at the MLD level. In the case of MLO, the value carried in the BSS Max Idle Period element is applied at the MLD level, and associated MLDs may follow the MLD max idle period (procedure). For example, associated MLDs may be the associated non-AP MLD and AP MLD. The STA may send a protected keepalive frame or an unprotected keepalive frame as indicated in the Idle Options field.

[0316] In the case of SMD, the value carried by the BSS Max Idle Period element may be applied at the SMD level. In the case of SMD, the value carried by the BSS Max Idle Period element is applied at the SMD level, and associated SMD-ME and non-AP MLDs may follow the SMD-ME max idle period (procedure).

[0317] During ML setup, if an AP belonging to an AP MLD includes a BSS Max Idle Period element in the Association Response frame and / or Reassociation Response frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field is applied at the MLD level and may be referred to as the MLD max idle period. The AP MLD may use a timeout value to determine whether to disassociate the non-AP MLD that is the target of the Association Response frame and / or Reassociation Response frame. The AP MLD may provide different max idle period values ​​for different non-AP MLDs. During ML setup, it may be an ML setup for a non-SMD. During ML setup, it may be an ML setup for an SMD.

[0318] If an AP belonging to an AP MLD belonging to SMD includes a BSS Max Idle Period element in a frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field may be applied at the SMD level. If an AP belonging to an AP MLD belonging to SMD includes a BSS Max Idle Period element in a frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field may be applied at the SMD level and may be referred to as the SMD-ME max idle period. During ML setup, if an AP belonging to an AP MLD belonging to SMD includes a BSS Max Idle Period element in a frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field may be applied at the SMD level and may be referred to as the SMD-ME max idle period. During SMD setup, if an AP belonging to an AP MLD belonging to an SMD includes a BSS Max Idle Period element in a frame sent to a non-AP STA belonging to a non-AP MLD, the value transmitted in the Max Idle Period field is applied at the SMD level and may be referred to as the SMD-ME max idle period. The SMD-ME may use a timeout value to determine whether the non-AP MLD targeted by the frame is disassociated. The SMD-ME may provide different max idle period values ​​for different non-AP MLDs.

[0319] A non-AP MLD may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated SMD-ME via one of its affiliated non-AP STAs. A non-AP MLD may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated SMD-ME via one of its affiliated non-AP STAs within the period indicated by the Max Idle Period field. If a non-AP MLD wants to avoid being disassociated by an SMD-ME due to nonreceipt of a frame, it may send at least one keepalive frame (e.g., a Data frame, PS-Poll frame, or Management frame) to an associated SMD-ME via one of its affiliated non-AP STAs within the period indicated in the Max Idle Period field. The keepalive frame may be protected or unprotected, as indicated in the Idle Options subfield.

[0320] A non-AP MLD may be considered inactive by an associated SMD-ME if it has not received any Data frames, PS-Poll frames, or Management frames (protected or unprotected) from a frame exchange sequence initiated by any enabled link of any STA belonging to that non-AP MLD for a period longer than the time specified in the Max Idle Period subfield of the BSS Max Idle Period element sent to that non-AP MLD.

[0321] SMD-ME may disassociate non-AP MLD in the following cases: - When a protected keepalive frame is requested in the Idle Options subfield of the BSS Max Idle Period element, and no protected frames are received from any non-AP STA belonging to the non-AP MLD during the max idle period. The Idle Options subfield allows unprotected or protected keepalive frames, and during the max idle period, it does not receive protected or unprotected frames from any non-AP STA belonging to a non-AP MLD.

[0322] Even if a non-AP MLD meets the keepalive frame transmission requirements, the SMD-ME may disassociate or deauthenticate the non-AP MLD.

[0323] The ML (re)setup procedure may be a procedure for setting up the link and / or association between the non-AP MLD and the SMD-ME. The ML (re)setup procedure may be a procedure completed through the exchange of Association Request frames and Association Response frames. The ML (re)setup procedure may be a procedure completed through the exchange of Reassociation Request frames and Reassociation Response frames. The ML (re)setup procedure may be a procedure completed through the exchange of Reassociation Request frames and Reassociation Response frames. The ML (re)setup procedure may be a procedure completed through the exchange of Roaming preparation Request frames and Roaming preparation Response frames. The ML (re)setup procedure may be a procedure completed through the exchange of Roaming execution Request frames and Roaming execution Response frames. It may also be completed through frame exchanges other than those described above. In the ML (re)setup procedure, the non-AP MLD and AP MLD may follow the association or reassociation procedure. The ML (re)setup procedure can also be referred to as ML (re)setup, etc.

[0324] MLO may be non-SMD MLO. MLO may be non-SMD MLO. Non-MLO may be non-SMD non-MLO. Non-MLO may be non-SMD non-MLO.

[0325] The SMD setup procedure may be a procedure for setting up a link and / or association between a non-AP MLD and an SMD-ME. The SMD setup procedure may be a procedure for setting up a link and / or association between a non-AP MLD and / or an AP MLD and / or an SMD-ME. The SMD setup procedure may be a procedure completed through the exchange of an Association Request frame and an Association Response frame. The SMD setup procedure may be a procedure completed through the exchange of a Reassociation Request frame and a Reassociation Response frame. The SMD setup procedure may be a procedure completed through the exchange of a Reassociation Request frame and a Reassociation Response frame. The SMD setup procedure may be a procedure completed through the exchange of a Roaming preparation Request frame and a Roaming preparation Response frame. The SMD setup procedure may be a procedure completed through the exchange of a Roaming execution Request frame and a Roaming execution Response frame. It may also be completed through frame exchanges other than those described above. In the SMD setup procedure, non-AP MLDs and / or AP MLDs and / or SMD-MEs may follow the association or reassociation procedure. The SMD setup procedure may also be referred to as SMD setup, etc.

[0326] SMD-ME may be SMD. SMD may be SMD-ME. SMD-ME may be an AP MLD belonging to SMD. SMD-ME may be any AP MLD belonging to SMD. SMD may be any AP MLD belonging to SMD. An AP MLD belonging to SMD may be referred to as AP MLD affiliated with the SMD, etc. An AP MLD may be an AP MLD belonging to SMD.

[0327] The Disassociation Timer may indicate the time until an AP sends a Disassociation frame to an STA, or the time until an AP belonging to an AP MLD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation Timer field may contain the number of Target Beacon Transmission Time (TBTT) until an AP sends a Disassociation frame to an STA, or until an AP belonging to an AP MLD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. Setting the Disassociation Timer field to 0 may indicate that the AP has not decided when to send a Disassociation frame to an STA, or that an AP belonging to an AP MLD has not decided when to send a Disassociation frame to a non-AP STA belonging to a non-AP MLD.

[0328] The Disassociation Timer may indicate the time until an SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation Timer may indicate the time until an AP belonging to an AP MLD belonging to an SMD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation Timer may indicate the time until an AP sends a Disassociation frame to an STA, or the time until an AP belonging to an AP MLD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD, or the time until an SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation Timer may indicate the time until an AP sends a Disassociation frame to an STA, or the time until an AP belonging to an AP MLD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD, or the time until an AP belonging to an AP MLD belonging to an SMD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. For example, the Disassociation Timer may indicate the time from when an SMD-ME is established until an SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. It may also be indicated at a timing other than those described above.

[0329] The Disassociation timer field may include the number of Target Beacon Transmission Time (TBTT) until the SMD-ME sends a Disassociation frame to the STA, or until the SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation timer field may include the number of Target Beacon Transmission Time (TBTT) until an AP belonging to an AP MLD (any) belonging to an SMD sends a Disassociation frame to the STA, or until an AP belonging to an AP MLD (any) belonging to an SMD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. The Disassociation timer field may include the number of Target Beacon Transmission Time (TBTT) until an AP sends a Disassociation frame to the STA, or until an AP belonging to an AP MLD sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD, or until the SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD. Setting the Disassociation timer field to 0 may indicate that the AP has not decided when to send a Disassociation frame to the STA, or that the AP belonging to the AP MLD has not decided when to send a Disassociation frame to a non-AP STA belonging to a non-AP MLD, or that the SMD-ME has not decided when to send a Disassociation frame to a non-AP STA belonging to a non-AP MLD.

[0330] The SMD Disassociation timer field may include the number of Target Beacon Transmission Time (TBTT) values ​​until the SMD-ME sends a Disassociation frame to the STA, or until the SMD-ME sends a Disassociation frame to a non-AP STA belonging to a non-AP MLD.

[0331] The Disassociation timer field may be contained within a frame. The Disassociation timer field may be contained within a Management frame and / or a Control frame and / or a Data frame. For example, the Disassociation timer field may be a 16-bit field. If the Disassociation Imminent field is 0, the Disassociation timer field may be reserved.

[0332] The Disassociation Imminent field may indicate whether the STA or non-AP MLD is disassociated from the current AP or the current AP MLD. A value of 1 in the Disassociation Imminent field may indicate that the STA or non-AP MLD is disassociated from the current AP or the current AP MLD AP. A value of 0 in the Disassociation Imminent field may indicate that the STA or non-AP MLD is not imminent to be disassociated from the current AP or the current AP MLD.

[0333] The ESS Disassociation Imminent field may indicate that STA is to be disassociated from ESS. If the value of the ESS Disassociation Imminent field is 0, it may indicate that STA is to be disassociated from ESS. If the value of the ESS Disassociation Imminent field is 1, it may indicate that STA is not in imminent disassociation from ESS.

[0334] The Disassociation Imminent field and / or ESS Disassociation Imminent field may be included in a frame. The Disassociation Imminent field and / or ESS Disassociation Imminent field may be included in a Management frame and / or a Control frame and / or a Data frame.

[0335] The Disassociation Imminent field may indicate whether the STA or non-AP MLD is disassociated from the current SMD-ME. A value of 1 in the Disassociation Imminent field may indicate that the STA or non-AP MLD is disassociated from the current SMD-ME. A value of 0 in the Disassociation Imminent field may indicate that the STA or non-AP MLD is not imminent to be disassociated from the current SMD-ME. The Disassociation Imminent field may also indicate whether the STA or non-AP MLD is disassociated from the current AP or current AP MLD or current SMD-ME. A value of 1 in the Disassociation Imminent field may indicate that the STA or non-AP MLD is disassociated from the current AP or current AP MLD AP or current SMD-ME. If the value of the Disassociation Imminent field is 0, it may indicate that the STA or non-AP MLD is not in imminent disassociation from the current AP, current AP MLD, or current SMD-ME.

[0336] The SMD Disassociation Imminent field may indicate that an STA or non-AP MLD is disassociated from an SMD-ME. A value of 0 in the SMD Disassociation Imminent field may indicate that an STA or non-AP MLD is disassociated from an SMD-ME. A value of 1 in the ESS Disassociation Imminent field may indicate that an STA or non-AP MLD is not imminent to be disassociated from an SMD-ME. The SMD Disassociation Imminent field may be included in a frame. The SMD Disassociation Imminent field may be included in a Management frame and / or a Control frame and / or a Data frame.

[0337] The Preferred Candidate List Included field may indicate whether the BSS transition candidate list included in the frame is a preferred candidate list or a list of known BSS transition candidates. The Preferred Candidate List Included field may indicate whether the BSS transition candidate list included in the frame is a preferred candidate list or a list of known BSS transition candidates that is also a Target AP candidate list. The Target AP candidate list may be a list of Target AP MLDs that non-AP MLDs can seamlessly roam. The Target AP candidate list may be a list of Target AP MLDs that non-AP MLDs recommend for seamless roaming. For example, a BSS Transition Management Query frame or a BSS Transition Management Request frame may include a list of Target AP MLDs that non-AP MLDs can seamlessly roam or that are recommended for seamless roaming. A list of Target AP MLDs may also be included in frames other than those mentioned above.

[0338] For example, the Disassociation timer field and / or the SMD Disassociation timer field and / or the Disassociation Imminent field and / or the ESS Disassociation Imminent field and / or the SMD Disassociation Imminent field and / or the Preferred Candidate List Included field may be included in the same frame. For example, the Disassociation timer field and / or the SMD Disassociation timer field and / or the Disassociation Imminent field and / or the ESS Disassociation Imminent field and / or the SMD Disassociation Imminent field and / or the Preferred Candidate List Included field may be included in the same Management frame and / or Control frame and / or Data frame. For example, the Disassociation timer field and / or the SMD Disassociation timer field and / or the Disassociation Imminent field and / or the ESS Disassociation Imminent field and / or the SMD Disassociation Imminent field and / or the Preferred Candidate List Included field may be included in the BSS Transition Management Request frame. A BSS Transition Management Query frame may be sent by the AP, AP MLD, or SMD in response to a BSS Transition Management Query frame, or autonomously.A BSS Transition Management Query frame may be sent to request or provide information about BSS transition candidate APs. A BSS Transition Management Request frame may include a Request Mode field. The Request Mode field may include a Disassociation timer field and / or an SMD Disassociation timer field and / or a Disassociation Imminent field and / or an ESS Disassociation Imminent field and / or an SMD Disassociation Imminent field and / or a Preferred Candidate List Included field.

[0339] The Disassociation timer may behave and / or apply at the same level as BSSMaxIdlePeriod. The Disassociation timer may be subject to the same rules as BSSMaxIdlePeriod. The descriptions for BSSMaxIdlePeriod may also apply to the Disassociation timer. The descriptions for the Disassociation timer may also apply to BSSMaxIdlePeriod. BSSMaxIdlePeriod may be replaced by the Disassociation timer. The Disassociation timer may be replaced by BSSMaxIdlePeriod.

[0340] BSSMaxIdlePeriod may also be called MaxIdlePeriod. MLDMaxIdlePeriod may also be called MaxIdlePeriod. SMDMaxIdlePeriod may also be called MaxIdlePeriod. MaxIdlePeriod may also be called BSSMaxIdlePeriod. MaxIdlePeriod may also be called MLDMaxIdlePeriod. MaxIdlePeriod may also be called SMDMaxIdlePeriod.

[0341] An SMDMaxIdlePeriod element may be defined. The SMDMaxIdlePeriod element may contain information about the MaxIdlePeriod applied at the SMD level. The SMDMaxIdlePeriod element may be included in the Association Response frame and / or Reassociation Response frame and / or Roaming preparation Response frame and / or Roaming execution Response frame, etc. It may also be included in frames other than those mentioned above.

[0342] For example, the operation of AP MLD and / or AP and / or non-AP MLD and / or non-AP STA in SMD may be referred to as SMD operation. SMD may be referred to as SMD Operation, etc. Other names are also acceptable. SMD-ME may be referred to as SMD-ME Operation (SMO), etc. Other names are also acceptable.

[0343] Information related to MLO and information related to SMD may be sent in the same frame. Information related to MLO and information related to MaxIdlePeriod may be sent in the same frame. Information related to SMD and information related to MaxIdlePeriod may be sent in the same frame. Information related to MLO, and / or information related to SMD, and / or information related to MaxIdlePeriod may be sent in the same frame.

[0344] In SMD, the SMD-ME max idle period and / or MLD max idle period and / or BSS max idle period may be applied. In this case, one of the max idle periods may be applied preferentially. For example, in this case, the SMD-ME max idle period may be applied. In SMD MLO, the SMD-ME max idle period and / or MLD max idle period and / or BSS max idle period may be applied. In this case, one of the max idle periods may be applied preferentially. For example, in this case, the SMD-ME max idle period or the MLD max idle period may be applied. In SMD non-MLO, the SMD-ME max idle period and / or MLD max idle period and / or BSS max idle period may be applied. In this case, one of the max idle periods may be applied preferentially. For example, in this case, the SMD-ME max idle period or the MLD max idle period or the BSS max idle period may be applied. In non-SMD MLO, the SMD-ME max idle period and / or MLD max idle period and / or BSS max idle period may be applied. In this case, one of the max idle periods may be applied preferentially. For example, in this case, the MLD max idle period or the BSS max idle period may be applied. In non-MLO systems that are not SMD, the SMD-ME max idle period and / or the MLD max idle period and / or the BSS max idle period may be applied. In this case, one of the max idle periods may be applied preferentially. For example, in this case, the BSS max idle period may be applied.

[0345] If an SMD-ME associated with a non-AP MLD falls back to an AP MLD, the SMD-ME Max Idle Period may become the MLD Max Idle Period. If an SMD-ME associated with a non-AP MLD falls back to an AP MLD, the application of MaxIdlePeriod may change from the SMD level to the MLD level. For example, if an SMD-ME falls back to an AP MLD, this may also mean that the (Current) AP MLD is removed from the SMD. If an AP MLD associated with a non-AP MLD falls back to an AP, the MLD Max Idle Period may become the BSS Max Idle Period. If an AP MLD associated with a non-AP MLD falls back to an AP, the application of MaxIdlePeriod may change from the MLD level to the link (peer STA and AP) level.

[0346] Figure 15 shows an example of an SMD according to one aspect of this embodiment. 1501 may be a non-AP MLD. 1502 and 1503 may be non-AP STAs belonging to a non-AP MLD. 1504 may be an AP MLD. 1505 and 1506 may be APs belonging to an AP MLD. 1507 may be an AP MLD. 1508 and 1509 may be APs belonging to a target AP MLD. 1510 may be an SMD-ME. 1511 may be an SMD. 1504 and 1507 may be AP MLDs covered by 1510. 1501 may be 1301 in Figure 13 and / or 1401 in Figure 14. 1502 may be 1302 in Figure 13 and / or 1402 in Figure 14. 1503 may be 1303 in Figure 13 and / or 1403 in Figure 14. 1504 may be 1304 in Figure 13 and / or 1404 in Figure 14. 1505 may be 1305 in Figure 13 and / or 1405 in Figure 14. 1506 may be 1306 in Figure 13 and / or 1406 in Figure 14. 1507 may be 1307 in Figure 13 and / or 1407 in Figure 14. 1508 may be 1308 in Figure 13 and / or 1408 in Figure 14. 1509 may be 1309 in Figure 13 and / or 1409 in Figure 14. 1510 may be 1310 in Figure 13 and / or 1410 in Figure 14. 1511 may be 1310 in Figure 13 and / or 1410 in Figure 14.

[0347] In Figure 15, for example, in a non-MLD that is not SMD-ME, if 1502 and 1505 are associated, the BSSMaxIdlePeriod period may be applied between 1502 and 1505. If 1505 does not receive a frame from 1502 during the BSSMaxIdlePeriod period, 1502 may be reconsidered as inactive and a decision of disassociation may be made. To avoid being disassociated by 1505, 1502 may send a frame to 1505 during the BSSMaxIdlePeriod period. For example, in a non-MLD that is not SMD-ME, if 1501 and 1504 are associated, the BSSMaxIdlePeriod period may be applied between 1501 and 1504. If 1504 does not receive a frame from 1501 during the BSSMaxIdlePeriod period, 1501 may be reconsidered as inactive and a decision of disassociation may be made. If 1505 and / or 1506 do not receive frames from 1502 and / or 1503 during the BSSMaxIdlePeriod period, 1504 may reconsider 1501 as inactive and determine disassociation. 1501 may send a frame to 1504 during the BSSMaxIdlePeriod period to avoid being disassociated by 1504. 1501 may also send frames from 1502 and / or 1503 to 1505 and / or 1506 during the BSSMaxIdlePeriod period to avoid being disassociated by 1504. For example, in an SMD, if 1501 and 1510 are associated, the BSSMaxIdlePeriod period may apply between 1501 and 1510. If 1510 does not receive a frame from 1501 during the BSSMaxIdlePeriod period, 1501 may be reconsidered as inactive, and a disassociation decision may be made.If 1504 and / or 1505 and / or 1506 and / or 1507 and / or 1508 and / or 1509 do not receive frames from 1501 and / or 1502 and / or 1503 during the BSSMaxIdlePeriod period, 1510 may reconsider 1501 as inactive and make a decision to disassociate. 1501 may send frames to 1510 during the BSSMaxIdlePeriod period to avoid being disassociated by 1510. 1501 may also send frames from 1501 and / or 1502 and / or 1503 to 1504 and / or 1505 and / or 1506 and / or 1507 and / or 1508 and / or 1509 during the BSSMaxIdlePeriod period to avoid being disassociated by 1510.

[0348] For example, in Figure 15, 1501 and / or 1502 and / or 1503 may associate with 1510 in the first association procedure. For example, if 1501 has the capability for Seamless Roaming, it may associate with 1501. For example, if 1501 has the capability for UHR, it may associate with 1501. Under conditions other than those stated above, 1501 and / or 1502 and / or 1503 may associate with 1510 in the first association procedure. 1504 and / or 1505 and / or 1506 and / or 1507 and / or 1508 and / or 1509 and / or 1510 may include SMD (1510 and / or 1511) information in the frame they transmit.

[0349] For example, if 1501 performs a Seamless Transition from 1504 to 1507, 1501 may also be associated with 1510. For example, if 1501 performs a Seamless Transition from 1504 to 1507, 1501's association may change from 1501 and 1504 to 1501 and 1510, and then to 1501 and 1507. For example, when performing a Seamless Transition, 1501's associations may change based on the Roaming preparation Request frame and / or Roaming preparation Response frame and / or Roaming execution Request frame and / or Roaming execution Response frame. For example, 1501, which is associated with 1504, may associate with 1510 after sending a Roaming preparation Request frame or a Roaming execution Request frame, and then associate with 1507 after receiving a Roaming preparation Response frame or a Roaming execution Response frame. For example, 1501, which is associated with 1504, may associate with 1510 after sending a Roaming preparation Request frame and / or a Roaming preparation Response frame and / or a Roaming execution Request frame and / or a Roaming execution Response frame.

[0350] SMD-ME may always be established by AP MLDs belonging to the SMD. SMD-ME may be established when a non-AP MLD performs seamless roaming. SMD-ME may be deactivated if a non-AP MLD within the SMD does not perform seamless roaming.

[0351] Figure 16 shows an example of the BSSMaxIdlePeriod processing of the SMD-ME according to one aspect of this embodiment. The SMD-ME may notify BSSMaxIdlePeriod (S1601). If the SMD-ME does not receive a frame from the non-AP MLD that notified the period during the notified BSSMaxIdlePeriod, it may decide to disassociate that non-AP MLD (S1602).

[0352] Figure 17 shows an example of a non-AP MLD that has received BSSMaxIdlePeriod from an SMD-ME according to one aspect of this embodiment. The non-AP MLD may receive BSSMaxIdlePeriod from the SMD-ME (S1701). The non-AP MLD may send a frame to the SMD-ME within the duration of BSSMaxIdlePeriod in order to avoid being disassociated by the SMD-ME (S1702).

[0353] The term "frame" may also be referred to as a "MAC frame." The term "frame" may be rephrased as "MAC frame." The term "frame" may include MSDU, A-MSDU, and / or MMPDU.

[0354] "SMD" may be rephrased as "SMD-ME". "SMD-ME removes the current AP MLD" may be rephrased as "SMD-ME removes all links in the current AP MLD", "SMD-ME removes all information held for the links in the current AP MLD", etc. Also, when SMD-ME removes the current AP MLD, it may delete or reset some or all of the context associated with the non-AP MLD.

[0355] As described above, SMD-ME can transmit frames, parameters, elements, fields, etc. related to disassociation to the associated non-AP MLD, and apply Max Idle Period, Disassociation timer, etc. at the SMD-ME level. This invention enables SMD-ME to efficiently manage disassociations at the SMD level.

[0356] The programs that operate in the base station device and terminal device according to embodiments of the present invention may be programs that control the CPU (Central Processing Unit) and the like (programs that make the computer function) in order to realize the functions of the above embodiments according to embodiments of the present invention. The information handled by these devices is temporarily stored in RAM (Random Access Memory) during processing, and then stored in various ROMs such as Flash ROM (Read Only Memory) or HDD (Hard Disk Drive), and read, modified, and written by the CPU as needed.

[0357] Furthermore, the terminal device and some of the base station devices in the above-described embodiment may be implemented using a computer. In that case, the program for implementing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be loaded into a computer system and executed.

[0358] Furthermore, the term "computer system" as used herein refers to a computer system built into a terminal device or base station device, and includes hardware such as the operating system and peripheral devices. Also, "computer-readable recording media" refers to portable media such as flexible disks, magneto-optical disks, ROMs, and CD-ROMs, as well as storage devices such as hard disks built into computer systems.

[0359] Furthermore, "computer-readable recording media" may include those that dynamically hold programs for a short period of time, such as communication lines used when transmitting programs via networks such as the Internet or communication lines such as telephone lines, as well as those that hold programs for a certain period of time, such as volatile memory within a computer system that acts as a server or client in such cases. In addition, the above-mentioned program may be for the purpose of realizing some of the functions described above, and may also be a program that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0360] The terminal device may consist of at least one processor and at least one memory containing computer program instructions (computer program). The memory and computer program instructions (computer program) may be configured to cause the terminal device to perform the operations and processing described in the above embodiment using the processor. The base station device may consist of at least one processor and at least one memory containing computer program instructions (computer program). The memory and computer program instructions (computer program) may be configured to cause the base station device to perform the operations and processing described in the above embodiment using the processor.

[0361] Furthermore, the base station device in the above-described embodiment can also be implemented as an assembly (device group) composed of multiple devices. Each device constituting the device group may have some or all of the functions or functional blocks of the base station device related to the above-described embodiment. The device group only needs to have a complete set of functions or functional blocks of the base station device. In addition, the terminal device related to the above-described embodiment can also communicate with the base station device as an assembly.

[0362] Furthermore, some or all of the terminal device and base station device in the above-described embodiments may be implemented as LSIs, which are typically integrated circuits, or as chipsets. Each functional block of the terminal device and base station device may be individually chipped, or some or all of them may be integrated into a single chip. In addition, the method of implementing the integrated circuit is not limited to LSIs; it may also be implemented using dedicated circuits or general-purpose processors. Moreover, if advances in semiconductor technology lead to the emergence of integrated circuit technologies that can replace LSIs, it is also possible to use integrated circuits based on those technologies.

[0363] Furthermore, although the above-described embodiment mentions a terminal device as an example of a communication device, the present invention is not limited to this and can also be applied to stationary or non-movable electronic devices installed indoors or outdoors, such as terminal devices or communication devices for AV equipment, kitchen equipment, cleaning and washing machines, air conditioning equipment, office equipment, vending machines, and other household appliances.

[0364] While embodiments of this invention have been described in detail above with reference to the drawings, the specific configuration is not limited to these embodiments, and design modifications and the like that do not depart from the gist of this invention are also included. Furthermore, the present invention can be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of this invention. In addition, configurations in which elements described in each of the above embodiments that produce similar effects are substituted for each other are also included. [Explanation of Symbols]

[0365] 101, 201, 205 BSS 102, 202, 206 AP 103, 104, 203, 204, 207, 208 STAs SU1, AU1 Antenna Section SU2, AU2 RF section SU3, AU3 Physical Layer Processing Unit SU4, AU4 MAC layer processing unit SU5 Upper Layer Packet Processing Unit SU6, AU6 Wireless Transceiver Unit SU7, AU7 Frame Processing Unit AU5 DSAF section 1101, 1104 STA transmission 1102, 1211 IFS 1103, 1212 Backoff counter (contention window) 1201, 1202, 1203, 1204 Timeline 1205 RTS frame 1206, 1208 NAV period 1207 CTS frame 1209 Data frame 1210 AcK frame

Claims

1. A base station device having an AP MLD belonging to the SMD (Seamless Mobility Domain), It includes a transmission unit that transmits a frame containing a BSS Max Idle Period element, The BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer containing the value of BSSMaxIdlePeriod, and BSSMaxIdlePeriod represents the time period. In SMD-ME, the time period carried by the BSS Max Idle Period element is applied at the SMD-ME level, and the SMD-ME uses the time period to determine the disassociation of non-AP MLD. Base station equipment.

2. In MLO, the time period carried by the BSS Max Idle Period element is applied at the MLD level, and AP MLD uses the time period to determine disassociation in non-AP MLD. The base station device according to claim 1.

3. The aforementioned SMD covers multiple AP MLDs, and non-AP MLDs can use the UHR seamless roaming procedure to roam between the AP MLDs of the aforementioned SMD. The base station device according to claim 1.

4. The aforementioned SMD-ME provides an association of non-AP MLDs across all AP MLDs of the SMD. The base station device according to claim 1.

5. Non-AP MLDs transition between AP MLDs within the SMD while maintaining their association with SMD-MEs. The base station device according to claim 1.

6. In non-SMD non-MLO, the BSS Max Idle Period element includes a time period during which the AP may refrain from sending a frame to the AP before the Non-AP STA terminates the association due to inactivity. The base station device according to claim 1.

7. The aforementioned BSS Max Idle Period element is included in the Association Response frame, or the ReAssociation Response frame, or the Roaming preparation Response frame, or the Roaming execution Response frame. The base station device according to claim 1.

8. The BSSMaxIdlePeriod included in MLME-ASSOCIATE.confirm indicates the BSS max idle period parameter for AP in non-SMD non-MLO configurations, the MLD max idle period for AP MLD configurations in non-SMD MLO configurations, and the SMD-ME max idle period for SMD-ME configurations in SMD configurations. The base station device according to claim 1.

9. Base station equipment with AP MLD belonging to SMD (Seamless Mobility Domain) Steps to send a frame containing a BSS Max Idle Period element, The BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer containing the value of BSSMaxIdlePeriod, and BSSMaxIdlePeriod represents the time period. In SMD-ME, the time period carried by the BSS Max Idle Period element is applied at the SMD-ME level, and the SMD-ME uses the time period to determine the disassociation of non-AP MLD. Communication method.

10. A terminal device having Non-AP MLD, The system includes a receiving unit that receives a frame containing a BSS Max Idle Period element. The BSS Max Idle Period element includes a Max Idle Period field, the Max Idle Period field is an unsigned integer containing the value of BSSMaxIdlePeriod, and BSSMaxIdlePeriod represents the time period. The terminal device transmits a frame to the SMD-ME that is associated with it within the time period indicated by the Max Idle Period field, in order to avoid disassociation due to the SMD-ME not receiving the frame. Terminal device.

Images