Terminal device, base station device, and communication method

Abstract

The present invention provides a base station device having one or more APs, wherein: the one or more APs are affiliated with a first AP MLD; a first seamless mobility domain (SMD) is configured from a plurality of AP MLDs including the first AP MLD; a second SMD is configured from a plurality of AP MLDs not including the first AP MLD; the first SMD and the second SMD are part of the same mobility domain; each of the APs affiliated with the AP MLDs belonging to each of the first SMD and the second SMD includes a processing unit that uses a mobility domain element (MDE) to report that the AP is included in a group of APs constituting the mobility domain; and all of the APs affiliated with the AP MLDs belonging to each of the first SMD and the second SMD report the same MDE.

Description

Terminal device, base station device, and communication method

[0001] The present invention relates to a terminal device, a base station device, and a communication method. The present application claims priority based on Japanese Patent Application No. 2025-037331 filed in Japan on March 10, 2025, the content of which is incorporated herein by reference.

[0002] Speed enhancement and frequency utilization efficiency improvement for wireless LAN (Local Area Network) communication are being studied by IEEE (The Institute of Electrical and Electronics Engineers Inc.). Currently, as a successor standard to IEEE802.11be, standardization of IEEE802.11bn has been launched.

[0003] IEEE802.11-23 / 1996r0, Po-Kai Huang (Intel), “Improve roaming between MLDs”, November 2023.

[0004] One aspect of the present invention provides a terminal device, a base station device, and a communication method that enable efficient communication.

[0005] (1) A first aspect of the present invention is a base station device including one or more access points, wherein the one or more access points belong to a first AP MLD. A first SMD (Seamless Mobility Domain) is composed of a plurality of AP MLDs including the first AP MLD. A second SMD is composed of a plurality of AP MLDs that do not include the first AP MLD. The first SMD and the second SMD are part of the same mobility domain. Each AP belonging to an AP MLD included in each of the first SMD and the second SMD comprises: a processing unit that advertises, by using an MDE (Mobility Domain element), that the AP is included in a group of APs constituting the mobility domain. All APs belonging to AP MLDs included in each of the first SMD and the second SMD advertise the same MDE.

[0006] (2) A second aspect of the present invention is the base station device described above, wherein the terminal device communicating with the base station device has one or more non-AP STAs. The one or more non-AP STAs belong to a non-AP MLD. The non-AP MLD transitions from a first SMD to a second SMD, which is part of the same mobility domain.

[0007] (3) A third aspect of the present invention is a terminal device having one or more non-AP STAs belonging to a non-AP MLD, which communicates with a base station device having one or more APs. The one or more APs belong to a first AP MLD. The first SMD (Seamless Mobility Domain) consists of a plurality of AP MLDs, including the first AP MLD. The second SMD consists of a plurality of AP MLDs, not including the first AP MLD. The first SMD and the second SMD are part of the same mobility domain. Each AP belonging to an AP MLD belonging to the first SMD and the second SMD includes a processing unit that uses an MDE (Mobility Domain element) to announce that it is included in a group of APs constituting the mobility domain. All APs belonging to an AP MLD belonging to the first SMD and the second SMD announce the same MDE. The non-AP MLD transitions from the first SMD to the second SMD, which is part of the same mobility domain.

[0008] (4) A fourth aspect of the present invention is a communication method in a base station device having one or more APs, wherein one or more APs belong to a first AP MLD. The first SMD (Seamless Mobility Domain) consists of a plurality of AP MLDs including the first AP MLD. The second SMD consists of a plurality of AP MLDs not including the first AP MLD. The first SMD and the second SMD are part of the same mobility domain. Each AP belonging to an AP MLD belonging to the first SMD and the second SMD respectively broadcasts that it is included in the group of APs constituting the mobility domain using an MDE (Mobility Domain element). All APs belonging to an AP MLD belonging to the first SMD and the second SMD respectively broadcast the same MDE.

[0009] This enables the realization of an efficient wireless communication system.

[0010] This is a diagram showing an example of a wireless LAN system according to one embodiment of this embodiment. This is a diagram showing an example of an OBSS according to one embodiment of this embodiment. This is a diagram showing an example of an STA configuration according to one embodiment of this embodiment. This is a diagram showing an example of an AP configuration according to one embodiment of this embodiment. This is a diagram showing an example of a MAC frame format according to one embodiment of this embodiment. This is a diagram showing an example of an A-MSDU according to one embodiment of this embodiment. This is a diagram showing an example of an A-MPDU according to one embodiment of this embodiment. This is a diagram showing an example of Fragmentation according to one embodiment of this embodiment. This is a diagram showing an example of a PPDU according to one embodiment of this embodiment. This is a diagram showing an example of a MAC data plane architecture of an MLD according to one embodiment of this embodiment. This is a diagram showing an example of a backoff procedure according to one embodiment of this embodiment. This is a diagram showing an example of a NAV according to one embodiment of this embodiment. This is a diagram showing an example of an SMD according to one embodiment of this embodiment. This is a diagram showing an example of an FT initial mobility domain association procedure for an SMD-ME according to one embodiment of this embodiment. This is a diagram showing an example of an FT initial mobility domain association procedure for a non-AP MLD according to one embodiment of this embodiment.

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

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

[0013] The wireless LAN system in this embodiment comprises access points (APs) and stations (STAs). The network consisting of access points and stations is referred to as a BSS (Basic Service Set). The wireless LAN system may consist of one or more stations. If the wireless LAN system consists of two or more STAs, the wireless LAN system may also be referred to as a BSS.

[0014] An access point (AP) may also be called a base station device. A station (STA) may also be called a terminal device. A single base station device may have one or more APs. A single base station device may have one or more AP MLDs. A single base station device may have one or more Super MLDs. A single base station device may have one or more Super AP MLDs. A single base station device may have one or more APs, one or more AP MLDs, and / or one or more Super AP MLDs. A single terminal device may have one or more STAs. A single terminal device may have one or more non-AP STAs. A single terminal device may have one or more non-AP MLDs. A single terminal device may have one or more non-AP STAs, and / or one or more non-AP MLDs.

[0015] Figure 1 shows an example of a wireless LAN system according to one embodiment of this model. In Figure 1, the wireless LAN system comprises STA 103, STA 104, and AP 102. 101 may be referred to as BSS.

[0016] 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.

[0017] 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.

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

[0019] 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.

[0020] 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.

[0021] 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 simply be referred to as an STA.

[0022] 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).

[0023] 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 an SME and an MLME, between an SME and a PLME, or between an MLME and a PLME.

[0024] 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 as 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).

[0025] 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).

[0026] Figure 2 shows 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.

[0027] 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.

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

[0029] 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.

[0030] 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.

[0031] 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-General Link (non-GLK) 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.

[0032] 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.

[0033] 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 in 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 update. a) Accept MSDUs from APs, meshgates, portals, and AP MLDs (as part of MAC service tuples).b) Distribute MSDUs to APs, meshgates, portals, or AP MLDs (as part of MAC service tuples). c) Accept mapping updates between STAs and APs from APs. d) Accept mapping updates between STAs and meshgates from meshgates. e) Accept mapping updates between non-AP MLDs and AP MLDs from AP MLDs.

[0034] 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.

[0035] 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 to the LLC (within the same ESS). 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).

[0036] Figure 3 shows an example of the device configuration of an STA according to one embodiment of this model. 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] Figure 4 shows an example of the device configuration of an AP according to one aspect of this embodiment. The AP may have 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 have a higher layer packet processing function. The AP may also have 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.

[0041] 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.

[0042] 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 MAC layer processing 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 MAC layer processing. 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.

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

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

[0045] 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.

[0046] The MLD synchronization service may be a service for distributing and coordinating various parameters between the MLD and multiple MLD series STAs. The MLD may support multiple MAC functions and synchronize them via the MLD synchronization service as needed, while other MAC functions may be coordinated by the SME.

[0047] 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.

[0048] 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, IEEE 802.1X Authenticator, and RSNA Key management to one or more non-AP MLDs across all AP MLDs of the SMD. A non-AP MLD may migrate between AP MLDs within the SMD while maintaining association and security association with the SMD-ME. The SMD-ME may be referred to by other names than SMD-ME.

[0049] A non-AP MLD may migrate from one SMD to another SMD that is part of the same mobility domain using the FT protocol described later. That is, a non-AP MLD may migrate between SMDs within the same mobility domain using the FT protocol described later.

[0050] 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 (SMD MAC entity), etc. An SMD MAC entity may be referred to by something 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 covered by that SMD. 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.

[0051] 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.

[0052] 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.

[0053] The SMD-ME synchronization service may be a service for distributing and coordinating various parameters between the SMD-ME controlling the SMD and the multiple AP MLDs covered by that SMD. In addition to or instead of this, the SMD-ME synchronization service may distribute and coordinate various parameters in the multiple AP MLDs covered by each of the multiple SMDs within the same mobility domain. The SMD-ME may support multiple MAC functions and synchronize between them via the SMD-ME synchronization service as needed, while other MAC functions may be coordinated by the SMD-ME.

[0054] 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.

[0055] 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 a main PHY function of a VHT STA. 160MHz and 80+80MHz channel widths may be supported as a main PHY function of a VHT STA. VHT multi-user (MU) PPDUs may be supported as a main PHY function 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 a main MAC function of a VHT STA. S-MPDU may be supported as a main MAC function of a VHT STA. Bandwidth indication response may be supported as a 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 functionality may be used in VHT STAs associated with a VHT AP (Very High-Throughput AP). A subset of the VHT functionality may be used between two VHT STAs that are members of the same IBSS.

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

[0057] 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 HE STAs. 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 HE STAs. A HE STA may also be an HT STA. The main PHY features of an 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 an 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 supporting 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 features of HE STA that is not present in HT STA or VHT STA may be support for two NAV operation in non-AP STA.

[0058] 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. A key 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). A key 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. A key 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.

[0059] 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. That is, 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] The MAC header may consist of a Frame Control field, a Duration / ID field, an Address 1 field, an Address 2 field, an Address 3 field, a Sequence Control field, an Address 4 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.

[0068] 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 Address 1 field, an Address 2 field, an Address 3 field, a Sequence Control field, an Address 4 field, and a QoS Control field. The MAC frame format may also be an MPDU.

[0069] The MAC header's Frame Control field 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 MAC header's Frame Control field may consist of some of the aforementioned subfields. The MAC header's Frame Control field may consist of all of the aforementioned subfields. The MAC header's Frame Control field may consist of a specific combination of subfields depending on the frame type.

[0070] The frame type may be indicated in the Type subfield contained in the Frame Control field of the MAC header. Control frame, Management frame, and Data frame may be defined as frame types. The Type subfield may indicate any of these three. For example, the Type subfield may be a two-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.

[0071] 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.

[0072] 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.

[0073] 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, the Type subfield may indicate a Management frame. If the Type subfield is set to 01, the Type subfield may indicate a Control frame. If the Type subfield is set to 10, the Type subfield may indicate a Data frame.

[0074] 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.

[0075] 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 in 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.

[0076] 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, a Probe Response frame, a Link Reconfiguration Notiify frame, or a Link Reconfiguration Request frame.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] A Reconfiguration SMD element may be used by SMD-ME to announce an operation of Seamless BSS Transition. Alternatively, a Reconfiguration SMD element may be used by a non-AP MLD to initiate a procedure 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 other names. 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.

[0082] 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.

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

[0084] 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.

[0085] The Current AP Removal Timer subfield may indicate the value of the timer for SMD-ME 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-ME sends the frame containing this Current AP Removal Timer subfield. In the TBTT indicated by the Current AP Removal Timer subfield, the SMD-ME may remove the current AP MLD.

[0086] 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 in 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 in 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 at the time the SMD-ME sends the frame containing this Current AP Removal Timer subfield. The SMD-ME may remove the current AP MLD after the time period indicated in this subfield has elapsed since sending the frame containing the Current AP Removal Timer subfield.

[0087] 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.

[0088] 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-ME 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 include 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.

[0089] 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-ME 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 this 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.

[0090] A Mobility Domain element (MDE) includes a Mobility Domain Identifier (MDID) field and an FT Capability and Policy field. An AP uses the MDE to notify that it belongs to a group of APs that constitute a mobility domain, to notify support for FT capability, and to notify FT policy information.

[0091] The format for MDE includes the Element ID field, Length field, MDID field, and FT capability and Policy field.

[0092] The FT capability and policy field may include the Fast BSS Transition over DS subfield, the Resource Request Protocol Capability subfield, and the Reserved subfield.

[0093] The Fast BSS Transition over DS subfield and the Resource Request Protocol Capability subfield may be used to control the behavior of the STA performing the fast BSS transition.

[0094] The STA may use information from the MDE to determine the transition method(s) recommended by the AP and the protocols supported by the AP.

[0095] If the Resource Request Protocol Capability subfield is 1, the STA may perform the FT resource request protocol.

[0096] When transmitted by the STA to the target AP, the FT capability and Policy field matches the value reported by the target AP.

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

[0098] 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.

[0099] The element format of each element included in the Frame body may be defined in 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.

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

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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. Similarly, UHR MAC Capabilities Information may be referred to by something other than UHR MAC Capabilities Information.

[0110] 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.

[0111] 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".

[0112] 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".

[0113] 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.

[0114] 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.

[0115] 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.

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

[0117] 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 to allow 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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 the HT Operation element and the HE Operation element. When operating in the 5GHz band, the HE STA in the HE BSS may be controlled by the HT Operation element, the VHT Operation element (if present), and the HE Operation element. When operating in the 6GHz band, the HE STA in the HE BSS may be controlled by the 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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 of 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).

[0132] 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 Address 1 field, an Address 2 field, an Address 3 field, a Sequence Control field, an Address 4 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.

[0133] 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.

[0134] Figure 7 shows an example of an A-MPDU according to one embodiment of this model. 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.

[0135] 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 an MSDU or MMPDU that is carried in individually addressed MPDUs.

[0136] 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).

[0137] 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.

[0138] 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, a PHY preamble, a PHY header, a 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.

[0139] Figure 10 shows an example of a MAC data plane architecture for 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 SAPs, 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 pass through MLD subordinate MAC entities, then through merging processing, and then 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 SAPs or to the DS via DSAFs.

[0140] 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 - Security associations such as PMKSA (Pairwise Master Key Security Association) and PTKSA (Pairwise Transient Key Security Association), and distribution of GTK (Group Temporal Key) / IGTK (Integrity Group Temporal Key) / BIGTK (Beacon Integrity Group Temporal Key) - Assignment of SN (Sequence Number) / PN (Packet Number) for frames encrypted by PTK (Pairwise Transient Key) for individually addressed frames - Assignment of SN for multiple MSDUs addressed to a group - Power-saving buffering for individually addressed frames (AP MLD only) - Encryption / decryption of individually addressed frames by PTK - Selection of MLD lower MAC entities for transmission - Merging of MPDUs received from two or more links - Each Block Packet sorting for sequential delivery within each Ack session; scoreboarding of Block Acks for individually addressed frames in cooperation with MLD lower MAC entities; exchange / instruction of MLD-level management information via MLD lower MAC entities; and selection of each STA's own EDCA (Enhanced Distributed Channel Access) parameters.

[0141] The functions of the MLD lower MAC entities 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) • MAC address filtering for power save status and mode frame reception • Block Ack scoreboarding for individually addressed frames in cooperation with the MLD upper MAC sublayer.

[0142] 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 SN for multiple MSDUs addressed to a group - Power-saving buffering for individually addressed frames - PTK encryption / decryption of individually addressed frames - 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 of MPDUs received from two or more MLDs - Packet reordering to deliver packets in order for each Block Ack session - Block Ack scoreboarding for individually addressed frames in cooperation with SMD lower MAC entities - Block Ack scoreboarding for individually addressed frames in cooperation with MLD lower MAC entities - Block Ack scoreboarding for individually addressed frames in cooperation with MLD upper MAC sublayer Ack scoreboarding; exchange / instruction of MLD-level management information via SMD lower MAC entities; exchange / instruction of MLD-level management information via MLD lower MAC entities; exchange / instruction of MLD-level management information via MLD upper MAC sublayers; selection of each series MLD's own EDCA parameters; selection of each AP MLD's own EDCA parameters.

[0143] The functions of an SMD lower MAC entity may include some or all of the following: • Authentication, association, and reassociation between AP MLDs and non-AP MLDs • Power-saving buffering of individually addressed frames (AP MLDs only) • PTK encryption / decryption of individually addressed frames • Selection of an MLD lower MAC entity for transmission • Merging of MPDUs received from two or more links • Packet reordering for sequential delivery of packets for each Block Ack session • Block Ack scoreboarding for individually addressed frames in cooperation with an MLD lower MAC entity • Exchange / instruction of MLD-level management information via an MLD lower MAC entity • Selection of its own 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 status and mode • MAC address filtering for frame reception • Block Ack scoreboarding for individually addressed frames in cooperation with an SMD upper MAC sublayer

[0144] The time interval between frames may be referred to as IFS (Inter-Frame Space). The STA may use carrier sensing functionality at a specified time interval 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.

[0145] 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).

[0146] 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.

[0147] 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.

[0148] 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.

[0149] Clear Channel Assessment (CCA) may determine the current usage status of a wireless medium. CCA may be a function at the physical layer for determining the current usage status of a wireless medium. CCA may also be referred to as the CCA function.

[0150] 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.

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

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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 Agent) ensures 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.

[0156] 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 duration (e.g., a fixed duration in microseconds).

[0157] 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.

[0158] 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 pseudo-random 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.

[0159] 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 integers 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.

[0160] 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.

[0161] 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.

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

[0163] 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 transmit 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.

[0164] 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.

[0165] 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.

[0166] An EDCAF (Enhanced Distributed Channel Access Function) is a logical function within a QoS STA that uses the EDCAF 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.

[0167] 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.

[0168] In HCF, the basic unit of assigning transmission rights to a radio medium may be a TXOP. A TXOP (Transmission Opportunity) may be 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. That is, an STA may acquire a TXOP if it performs an EDCA.

[0169] 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. That is, 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 1102. 1103 decrements the backoff counter while the channel is idle. For example, six 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.

[0170] 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.

[0171] 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.

[0172] 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. Physical and virtual carrier sense functions may be used to determine the state of the medium. If either the physical or virtual carrier sense function indicates busy, the medium may be considered busy. If both the physical and virtual carrier sense functions 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.

[0173] 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.

[0174] 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.

[0175] 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 medium is busy.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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 a CTS frame format sent in response to an RTS frame may be the Duration field of the immediately preceding 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.

[0180] 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. There may be an IFS between 1205 and 1207. AP#2 may transmit 1207 if the channel is idle during the IFS period before transmitting 1207. There may be an IFS period between 1207 and 1209. STA#1 may transmit 1209 if the channel is idle during the IFS period before transmitting 1209. There may be an IFS period between 1209 and 1210. AP#2 may transmit 1210 if the channel is idle during the IFS period before transmitting 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 a timeline of the operation of AP or STA. 1202 may be a timeline of the operation of AP or STA. 1203 may be a timeline of the operation of AP or STA. 1204 may be a timeline of the operation of AP or STA.

[0181] 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.

[0182] 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, enabling STA invocation by distribution system services (DSSs), or a service that establishes a mapping between an AP MLD and a non-AP MLD, enabling 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.

[0183] 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".

[0184] A BSS transition may be defined for an STA, MLD, or SMD-ME. 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 of a non-AP MLD may be defined from one SMD-ME in one 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 SMD-ME in 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 of a non-AP MLD may be defined from one AP MLD in one 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 BSS in 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 MLD becomes a non-AP STA.In a BSS transition, the movement of a non-AP STA that moves from a BSS within a given ESS to an AP MLD within the same ESS and becomes a non-AP MLD may be defined, where each non-AP STA belonging to a non-AP MLD is in a different BSS, different non-AP STAs belonging to a 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.

[0185] To deliver MSDUs within an ESS via a DS, the DS needs to know which AP, AP MLD, or SMD-ME within the ESS to which the MSDUs should be delivered. 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 an AP. A non-AP MLD may first be associated with an AP MLD or SMD-ME before being permitted to deliver MSDUs via an 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 or SMD-ME may invoke an association service and provide the DS with a mapping from the non-AP MLD to an AP MLD, or from the non-AP MLD to an SMD-ME.

[0186] At any given moment, a non-AP STA may connect to one AP, and a non-AP MLD may connect to one AP MLD or one SMD-ME. 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, or between a non-AP MLD and an SMD-ME, 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. Association between a non-AP MLD and an SMD-ME may be initiated by either the non-AP MLD or the SMD-ME.

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

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

[0189] 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.

[0190] The Reassociation service may be started to move the current association of an AP and a non-AP STA from one AP to another, either 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 another, either to the same AP MLD or a different AP MLD. The Reassociation service may be started to move the current association of an SMD-ME and a non-AP MLD from one SMD-ME to another, either to the same SMD-ME or a different SMD-ME. 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.

[0191] In ESS, the reassociation service may notify the DS of the current mapping between APs and non-AP STAs, between AP MLDs and non-AP MLDs, or between SMD-MEs 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, AP MLD, or SMD-ME, respectively. In the case of non-SMD, Reassociation may always be initiated by a non-AP STA or non-AP MLD. In the case of SMD, Reassociation may be initiated by a non-AP MLD or SMD-ME.

[0192] The Authentication service may be used in both ESS and IBSS for all STAs to establish their identity with the STA they are communicating 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.

[0193] 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.

[0194] 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. In the case of SMD, the state variable may represent the relationship between SMD-ME and non-AP 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.

[0195] When an MLME-REASSOCIATE.request primitive is received, non-AP STAs, non-AP MLDs, and non-PCPs (PBSS control point) STAs may perform reassociation with APs, AP MLDs, or PCPs respectively using the following procedure. In SMDs, when an MLME-REASSOCIATE.request primitive is received, a non-AP MLD may perform reassociation with an SMD-ME using the following procedure. If an STA or non-AP MLD is not connected within the same ESS, or if the status of a new AP, AP MLD, PCP, or SMD-ME is State 1, an 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, or a Reassociation Request frame containing a Basic SMD element to an AP belonging to an AP MLD within a new SMD. 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.- When a Reassociation Response frame with a status code of SUCCESS is received, the state variable of the new AP, AP MLD, PCP, or SMD-ME is 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, PCP, or SMD-ME. Alternatively, the state variable of the old AP, AP MLD, PCP, or SMD-ME may be set to State 2 unless the old AP, AP MLD, PCP, or SMD-ME is identical to the new AP, AP MLD, PCP, or SMD-ME. 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, PCP, or SMD-ME in the CurrentAPAddress parameter (reassociation to the same AP, AP MLD PCP, or SMD-ME), 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 reassociation to a different AP, AP MLD, PCP, or SMD-ME, or in the case of reassociation to an AP when the new AP address is the same as the value of the CurrentAPAddress parameter and the existing association is between MLDs, or when the new AP MLD address is CurrentAPAddress If the parameter value is the same and the existing association is not between MLDs, and it is a reassociation to AP MLD, then all of the above states, agreements, and allocations may be deleted or reset to their initial values.

[0196] 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, or if an AP belonging to an AP MLD in an SMD receives a Reassociation Request frame containing a Basic SMD 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 the 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 reassociation failure in the ResultCode parameter. When MLME receives the MLME-REASSOCIATE.response primitive, it may send a Reassociation Response frame. If a Reassociation Response frame with a status code of 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 initial value any items (states, agreements, and allocations described above) that the non-AP MLD has requested to be deleted or reset to their initial value. The AP MLD does not have to change states, agreements, and allocations that are listed as not being affected by the reassociation procedure.- If the ResultCode of 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, 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 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, 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.

[0197] 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, AP MLD, or SMD-ME 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.

[0198] The FT protocol may require the exchange of information during the initial association (or subsequent reassociation) between STA and AP, between non-AP MLD and AP MLD, or between non-AP MLD and SMD-ME. STA and non-AP MLD may be referred to as FT Originators (FTOs). AP, AP MLD, and SMD-ME may be referred to as FT Responders (FTRs). The initial exchange may be referred to as an FT initial mobility domain association. Subsequent reassociations to FTRs within the same mobility domain may use FT protocols.

[0199] 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.

[0200] 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 convert between the two encapsulations.

[0201] FT capability may be advertised in the Beacon frame and Probe Response frame by including the MDE. The MDE may be advertised in the Beacon frame and Probe Response frame to indicate the MDID, FT capability, and FT policy. The MDID may be indicated in the MDID field included in the MDE. The FT capability and FT policy may be indicated in the FT capability and Policy field included in the MDE.

[0202] All APs belonging to AP MLD may communicate the same MDE and at least one common AKM (authentication and key management) with the Authentication type column indicating FT authentication via the MLD synchronization service. For example, an AKM with the Authentication type column indicating FT authentication may be an AKM suite selector with Suite type 3, 4, 9, 13, 16, 17, or 19. An AKM suite may be a set of algorithms for providing authentication and key management.

[0203] Reporting the same MDE may mean reporting the same values ​​in all fields and subfields of the MDE. For example, AP1 and AP2 may indicate that they belong to the same mobility domain by reporting the same MDE that shows the same MDID.

[0204] All APs belonging to each of the multiple AP MLDs within the SMD may communicate the same MDE and / or at least one common AKM whose Authentication type column indicates FT authentication via the SMD-ME synchronization service. For example, an AKM whose Authentication type column indicates FT authentication may be an AKM suite selector whose Suite type is one of 0, 3, 4, 9, 13, 16, 17, 18, 19, 21 through 255.

[0205] In addition to or instead of the above, all APs belonging to an AP MLD belonging to each of the multiple SMDs may communicate the same MDE and / or at least one common AKM whose Authentication type column indicates FT authentication via the SMD-ME synchronization service. For example, an AKM whose Authentication type column indicates FT authentication may be an AKM suite selector whose Suite type is one of 0, 3, 4, 9, 13, 16, 17, 18, 19, 21 through 255.

[0206] A non-AP MLD may transition from the current AP MLD to the target AP MLD using the FT (Fast BSS Transition) procedure if the MDE reported by an AP belonging to the current AP MLD within a given SMD is the same as the MDE reported by an AP belonging to the target AP MLD within a different SMD. For example, the FT procedure may include an FT initial mobility domain association.

[0207] The FT initial mobility domain association is the first (re)association (initial (re)association) in the mobility domain, and the use of the FT procedure may be enabled by an SME of STA or non-AP MLD. The FT initial mobility domain association may also be the first association in an ESS. In addition to the Association Request frame and Association Response frame, the Reassociation Request frame and Reassociation Response frame are supported in the initial mobility domain association, and both FT AP(s) and non-FT AP(s) or AP MLD(s) or SMD-ME(s) may exist in a single ESS. FT AP(s) and / or non-FT AP(s) and / or AP MLD(s) and / or non-FT AP MLD(s) may exist in a single ESS. In the case of non-SMD MLO, non-AP MLDs and AP MLDs may include a Basic Multi-Link element in all Authentication frames and (Re)Association Request / Response frames. The Basic Multi-Link element contains the MLD MAC address of each MLD and may be used to establish a security association. In the case of SMD, non-AP MLDs and SMD-MEs may include the Basic SMD element in all Authentication frames, (Re)Association Request / Response frames, Transition Preparation Request / Response frames, and Transition Execution Request / Response frames.The Basic SMD element contains the MLD MAC address of each MLD, or the MAC address of the SMD-ME, and may be used to establish a security association.

[0208] The Basic Multi-Link element may transmit information related to the MLD and its sequence STA(s). For example, the Basic Multi-Link element may broadcast during ML discovery and ML setup.

[0209] The Basic SMD element may transmit information related to the SMD-ME that controls the SMD and the multiple AP MLDs covered by that SMD. For example, the Basic SMD element may broadcast during a Seamless BSS Transition and / or during transitions between SMDs.

[0210] An example of the FT initial mobility domain association procedure is described below. The STA or non-AP MLD may indicate support for the FT procedure by including the MDE in the (Re)Association Request frame and support for security by including the RSNE. The AP, AP MLD, or SMD-ME may respond by including the FTE (fast BSS transition element), MDE, and RSNE in the (Re)Association Response frame. After successful IEEE 802.1X authentication (if required) or SAE authentication, the STA and AP, non-AP MLD and APMLD, or non-AP MLD and SMD-ME may perform an FT 4-way handshake. After successful IEEE 802.1X authentication (if required) or SAE (simultaneous authentication of equals) authentication, the STA and / or AP and / or non-AP MLD and / or AP MLD and / or SMD-ME may perform an FT 4-way handshake. SAE authentication may also be an authentication method that uses finite field cryptography to prove that one knows the shared password.

[0211] An STA or non-AP MLD may initiate the FT initial mobility domain association procedure(s) by performing IEEE 802.11 authentication using the Open System authentication algorithm. The Open System authentication may also be an authentication method that allows any STA to access the DS. STA → AP: Authentication-Request (Open System authentication algorithm) AP → STA: Authentication-Response (Open System authentication algorithm, Status) non-AP MLD → AP MLD: Authentication-Request (Open System authentication algorithm, Basic Multi-Link element) AP MLD → non-AP MLD: Authentication-Response (Open System authentication algorithm, Status, Basic Multi-Link element) non-AP MLD → SMD-ME: Authentication-Request (Open System authentication algorithm, Basic SMD element) SMD-ME → non-AP MLD: Authentication-Response (Open System authentication algorithm, Status, Basic SMD element)

[0212] In the case of non-SMD, an STA SME or a non-AP MLD SME may initiate an authentication exchange using the MLME-AUTHENTICATE.request primitive, and an AP SME or an AP MLD SME may respond using the MLME-AUTHENTICATE.response primitive, respectively.

[0213] In the case of SMD, a non-AP MLD SME may initiate an authentication exchange using the MLME-AUTHENTICATE.request primitive, and an SMD-ME SME may respond with the MLME-AUTHENTICATE.response primitive.

[0214] If IEEE 802.11 Open System or SAE authentication is successful, the STA may send a (Re)Association Request frame containing the MDE to the AP, or a non-AP MLD may send a (Re)Association Request frame containing the MDE via an affiliated non-AP STA to the AP MLD via an affiliated AP, or to the SMD-ME via an AP MLD in the SMD. If IEEE 802.11 Open System or SAE authentication is successful, and the Authentication type column indicates FT authentication (suite type), the STA may send a (Re)Association Request frame containing the MDE to the AP, or a non-AP MLD may send a (Re)Association Request frame containing the MDE via an affiliated non-AP STA to the AP MLD via an affiliated AP, or to the SMD-ME via an AP MLD in the SMD. If IEEE 802.11 Open System or SAE authentication is successful, and the Authentication type column of the predefined Table (AKM suite selector) is set to a type (suite type) that indicates FT authentication, the STA may send a (Re)Association Request frame containing the MDE to the AP, or a non-AP MLD may send a (Re)Association Request frame containing the MDE via an affiliated non-AP STA to the AP MLD via an affiliated AP, or to the SMD-ME via an AP MLD in the SMD.The contents of the MDE may be values ​​notified in Beacon frames or Probe Response frames by an AP, any AP belonging to an AP MLD, or any AP belonging to any AP MLD within an SMD. STAs or non-AP MLDs may incorporate security functions into the RSNE. STA→AP: (Re)Association Request (MDE, RSNE, RSNXE) AP→STA: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID], RSNXE) non-AP MLD→AP MLD: (Re)Association Request (MDE, RSNE, RSNXE, Basic Multi-Link element) AP MLD→non-AP MLD: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID], RSNE, RSNXE, Basic Multi-Link element) non-AP MLD→SMD-ME: (Re)Association Request (MDE, RSNE, RSNXE, Basic SMD element) SMD-ME→non-AP MLD: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID], RSNE, RSNXE, Basic SMD element).

[0215] STA SMEs or non-AP MLD SMEs may initiate a (re)association using the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive. AP SMEs, AP MLD SMEs, or SMD-ME SMEs may respond to the indication using the MLMEASSOCIATE.response or MLME-REASSOCIATE.response primitive.

[0216] If the content of the MDE received by the AP does not match what was notified in the Beacon frame and Probe Response frame, the AP may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. If the MDE is present in the (Re)Association Request frame and the content of the RSNE does not indicate a negotiated AKM where the Authentication type column indicates FT authentication, the AP may reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP. If the MDE is present in the (Re)Association Request frame and / or the content of the RSNE does not indicate a negotiated AKM where the Authentication type column indicates FT authentication, the AP may reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP.

[0217] In the case of a non-SMD MLO, if the content of the MDE received by the AP MLD does not match what was advertised in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD, the AP MLD may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. If the MDE is present in the (Re)Association Request frame and the content of the RSNE does not indicate a negotiated AKM where the Authentication type column indicates FT authentication, the AP MLD may reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP.

[0218] In the case of SMD, if the content of the MDE received by SMD-ME does not match the content advertised in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD within SMD, SMD-ME may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. If the MDE is present in the (Re)Association Request frame and the content of the RSNE does not indicate a negotiated AKM where the Authentication type column indicates FT authentication, SMD-ME may reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP. If the MDE is present in the (Re)Association Request frame and / or the content of the RSNE does not indicate a negotiated AKM where the Authentication type column indicates FT authentication, SMD-ME may reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP.

[0219] The (Re)Association Response frame from the AP may include an MDE containing the content presented in the Beacon frame and Probe Response frame. The (Re)Association Response frame from the AP MLD may include an MDE containing the content presented in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD. The (Re)Association Response frame from the SMD-ME may include an MDE containing the content presented in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD within the SMD. The FTE includes R0KH-ID and R1KH-ID as key holder IDs (identities) of the AP, AP MLD, or SMD-ME, and may be set to the values ​​of predetermined parameters of R0KH (e.g., dot11FTR0KeyHolderID) and R1KH (e.g., dot11FTR1KeyHolderID), respectively. The MIC element count of the FTE may be 0 (no MIC exists), and the ANOnce, SNonce, and MIC field of the FTE may also be set to 0. The RSNXE Used subfield of the MIC Control field may also be set to 0.

[0220] If (re)association is successful, the S0KH of the STA or non-AP MLD and the R0KH of the AP or AP MLD may, respectively, continue with IEEE 802.1X authentication using the EAPOL PDU transmitted in an IEEE 802.11 Data frame if SAE authentication is not performed (for example, if the suite type is not a predetermined value (e.g., 00-0F-AC:9)). For SMDs, if (re)association is successful, the S0KH of the non-AP MLD and the R0KH of the SMD-ME may, respectively, continue with IEEE 802.1X authentication using the EAPOL PDU transmitted in an IEEE 802.11 Data frame if SAE authentication is not performed (for example, if the suite type is not a predetermined value (e.g., 00-0F-AC:9)). S0KH may use the value of R0KH-ID as the endpoint identifier (NAS-Identifier if RADIUS is used) for the NAS client during exchange, as defined in IETF RFC 3748.

[0221] If IEEE 802.1X authentication is performed, and the authentication completes successfully, R0KH may receive the MSK and authorization attributes. If SAE authentication is performed, R0KH may receive the PMK and the SAE may complete successfully. If a key hierarchy already exists for STAs or non-AP MLDs belonging to the same mobility domain (i.e., having the same MDID), R0KH may delete the existing PMK-R0 security association and PMK-R1 security association. Then, PMK-R0, PMKR0Name, and PMK-R1 may be calculated and made available for R1KH of APs associated with STAs, AP MLDs associated with non-AP MLDs, or SMD-MEs associated with non-AP MLDs to use PMK-R1.

[0222] If an STA SME or a non-AP MLD SME cannot authenticate the AS, they may disassociate using the MLMEDISASSOCIATE.request primitive. If the AS notifies the Authenticator that it cannot authenticate the STA or non-AP MLD, the AP SME or AP MLD SME may disassociate using the MLME-DISASSOCIATE.request primitive, respectively. In the case of SMD, if the AS notifies the Authenticator that it cannot authenticate the non-AP MLD, the SMD-ME SME may disassociate using the MLME-DISASSOCIATE.request primitive.

[0223] If the MSK lifetime attribute is provided by the AS, the lifetime of PMK-R0 shall not exceed the lifetime of the MSK. If the MSK lifetime attribute is not provided, the lifetime of PMK-R0 may be dot11FTR0KeyLifetime. In the case of PSK, the lifetime of PMK-R0 may be dot11FTR0KeyLifetime. The lifetimes of PMK-R1 and PTK may be the same as the lifetime of PMK-R0. When the key lifetime expires, each key holder may delete their respective PMK-R0, PMK-R1, and PTK SA.

[0224] R1KH and S1KH may perform an FT 4-way handshake. EAPOL-Key frame notation may be defined. The FT 4-way handshake between STA and AP may be as follows: R1KH→S1KH:EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {}) S1KH→R1KH:EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE[PMKR1Name], MDE, FTE, RSNXE}) R1KH→S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {RSNE[PMKR1Name], MDE, GTK[N], IGTK[M], BIGTK[Q], FTE, TIE[ReassociationDeadline], TIE[KeyLifetime], RSNXE}) S1KH→R1KH:EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {}) The FT 4-way handshake between the non-AP MLD and the AP MLD may be as follows:R1KH→S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {MAC Address}) S1KH→R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE(PMKR1Name), MDE, FTE, [RSNXE] [, OCI], MAC Address, MLO Linkn}) R1KH→S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {MAC Address, MLO Linkm(RSNE(PMKR1Name)), MLO GTKn [, MLO IGTKn] [, MLO BIGTKn], MDE, FTE, TIE(ReassociationDeadline), TIE(KeyLifetime) [, WIGTK(R, WIPN)]}) S1KH→R1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {[MAC Address]}) The FT 4-way handshake between non-AP MLD and SMD-ME may be, for example, as follows:R1KH→S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {MAC Address}) S1KH→R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE(PMKR1Name), MDE, FTE, [RSNXE] [, OCI], MAC Address, MLD MAC Address, SMD Linkn}) R1KH→S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {MAC Address, SMD Linkm(RSNE(PMKR1Name)), SMD GTKn [, SMD IGTKn] [, SMD BIGTKn], MDE, FTE, TIE(ReassociationDeadline), TIE(KeyLifetime) [, WIGTK(R, WIPN)]}) S1KH→R1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {[MAC Address], [MLD MAC Address]}).

[0225] The MAC address KDE may be the MLD MAC address of the MLD to which the transmitting STA belongs. If RSNA is not established between a non-AP MLD and an AP MLD, or between a non-AP MLD and an SMD-ME, each FT 4-way handshake message may be sent over the same link used in the most recent exchange of successful (Re)Association Request / Response frames.

[0226] The reassociation deadline may be managed consistently across the entire mobility domain.

[0227] PTK may be calculated using R1KH and S1KH. PTK may also be calculated using R1KH and S1KH according to a predetermined procedure.

[0228] If the FT 4-way handshake completes successfully, the IEEE 802.1X Controlled Port may be opened on both the non-AP STA and AP, the non-AP MLD and AP MLD, or the non-AP MLD and SMD-ME. The (subsequent) EAPOL key frame may use the key replay counter to detect replayed messages.

[0229] If the FT 4-way handshake completes successfully, the PTK lifetime timer may be started. The operation of the PTK lifetime timer may prevent the PTKSA from being used for longer than the value specified in the TIE[KeyLifetime] sent in message 3.

[0230] If the lifetime of the PTKSA key expires as indicated by TIE[KeyLifetime], the STA or non-AP MLD may perform FT initial mobility domain association procedures to continue the association in the mobility domain. In the case of non-SMD, if an AP or AP MLD sends a Deauthentication frame or Disassociation frame to the STA or non-AP MLD, respectively, with reason code INVALID_AUTHENTICATION, the STA or non-AP MLD may perform FT initial mobility domain association procedures with any AP or any AP MLD within the mobility domain, respectively, to continue the association in the mobility domain. In the case of SMD, if an SMD-ME sends a Deauthentication frame or Disassociation frame to a non-AP MLD, respectively, with reason code INVALID_AUTHENTICATION, the non-AP MLD may perform FT initial mobility domain association procedures with any SMD-ME within the mobility domain to continue the association in the mobility domain. If, after the initial mobility domain association is successful, the Supplicant EAPOL state machines are triggered to send an EAPOL-Start frame, the STA or non-AP MLD may perform the FT initial mobility domain association procedures.

[0231] Another example of the FT initial mobility domain association procedure is described below. An STA or non-AP MLD may use the FT procedure by including the MDE in the (Re)Association Request frame. An AP, AP MLD, or SMD-ME may respond by including the MDE in the (Re)Association Response frame.

[0232] An STA or non-AP MLD may initiate the FT initial mobility domain association procedure(s) by performing IEEE 802.11 authentication using the Open System authentication algorithm. STA→AP: Authentication-Request (Open System authentication algorithm) AP→STA: Authentication-Response (Open System authentication algorithm, Status) non-AP MLD→AP MLD: Authentication-Request (Open System authentication algorithm, Basic Multi-Link element) AP MLD→non-AP MLD: Authentication-Response (Open System authentication algorithm, Status, Basic Multi-Link element) non-AP MLD→SMD-ME: Authentication-Request (Open System authentication algorithm, Basic SMD element) SMD-ME→non-AP MLD: Authentication-Response (Open System authentication algorithm, Status, Basic SMD element)

[0233] In the case of non-SMD, an STA SME or a non-AP MLD SME may initiate an authentication exchange using the MLME-AUTHENTICATE.request primitive, and an AP SME or an AP MLD SME may respond using the MLME-AUTHENTICATE.response primitive, respectively.

[0234] In the case of SMD, a non-AP MLD SME may initiate an authentication exchange using the MLME-AUTHENTICATE.request primitive, and an SMD-ME SME may respond with the MLME-AUTHENTICATE.response primitive.

[0235] Upon successful IEEE 802.11 Open System authentication, the STA may send a (Re)Association Request frame containing the MDE to the AP, or a non-AP MLD may send a (Re)Association Request frame containing the MDE via an affiliated non-AP STA to the AP MLD via an affiliated AP, or to the SMD-ME via an AP MLD within the SMD. The contents of the MDE may be values ​​notified in a Beacon frame or Probe Response frames by the AP, or any AP belonging to an AP MLD, or any AP belonging to any AP MLD within the SMD. STA→AP: (Re)Association Request (MDE) AP→STA: (Re)Association Response (MDE) non-AP MLD→AP MLD: (Re)Association Request (MDE, Basic Multi-Link element) AP MLD→non-AP MLD: (Re)Association Response (MDE, Basic Multi-Link element) non-AP MLD→SMD-ME: (Re)Association Request (MDE, Basic SMD element) SMD-ME→non-AP MLD: (Re)Association Response (MDE, Basic SMD element)

[0236] STA SMEs or non-AP MLD SMEs may initiate a (re)association using the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive. AP SMEs, AP MLD SMEs, or SMD-ME SMEs may respond to the indication using the MLMEASSOCIATE.response or MLME-REASSOCIATE.response primitive.

[0237] In the case of non-SMD non-MLO, if the content of the MDE received by the AP does not match what was notified in the Beacon frame and Probe Response frame, the AP may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. The (Re)Association Response frame from the AP may contain an MDE that includes the content presented in the Beacon frame and Probe Response frame.

[0238] In the case of a non-SMD MLO, if the content of the MDE received by the AP MLD does not match the content notified in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD, the AP MLD may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. The (Re)Association Response frame from the AP MLD may contain an MDE that includes the content presented in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD.

[0239] In the case of SMD, if the content of the MDE received by SMD-ME does not match the content notified in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD within SMD, SMD-ME may reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. The (Re)Association Response frame from SMD-ME may contain an MDE that includes the content presented in the Beacon frame and Probe Response frame of the AP belonging to the AP MLD within SMD.

[0240] If the (re)association is successful, the AP and non-AP STA, AP MLD and non-AP MLD, or SMD-ME and non-AP MLD may transition to State 4 to enable the transmission of data frames.

[0241] 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.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] In the (Re)Association Request frame, a non-AP MLD may indicate one or more links that are requested to be (re)set up (requested link(s)) 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.

[0246] In the (Re)Association Response frame, the AP MLD may indicate one or more requested links whose (re)setup has been accepted and / or rejected, as well as the capabilities and operational parameters of one or more requested links. The AP MLD may do one of the following: • Accept all links for which (re)setup has been requested. • Accept a subset of several links for which (re)setup has been requested, including the links that received the (Re)Association Request frame. • Reject all links for which (re)setup has been requested.

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

[0248] An MLD requesting or accepting an ML (re)setup 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.

[0249] 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.

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

[0251] 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.

[0252] 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.

[0253] 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.

[0254] ML reconfiguration may also 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.

[0255] 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.

[0256] 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.

[0257] 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.

[0258] 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.

[0259] 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 an MLME-DISASSOCIATE.indication primitive to notify the SME of the disassociation of the non-AP MLD.

[0260] 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.

[0261] 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 a 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.

[0262] 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.

[0263] 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.

[0264] 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.

[0265] 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.

[0266] 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.

[0267] 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 the 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 decide 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 the non-AP MLD from the current AP MLD to the target AP MLD - Renegotiation of context with the target AP MLD - Setup of one or more links with the target AP MLD.

[0268] 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.

[0269] 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.

[0270] 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."

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

[0272] 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.

[0273] 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 this 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 Sequence Number (SN). The "context necessary to enable operations with the target AP MLD" may include the Packet Number (PN). The "context necessary to enable operations with the target AP MLD" may include the Pairwise Transient Key (PTK). The "context necessary to enable operations with the target AP MLD" may include the Pairwise Master Key (PMK). The "context necessary to enable operations with the target AP MLD" may include information about the Stream Classification Service (SCS). The "context necessary to enable operation with the target AP MLD" may include information about the Target Wake Time (TWT). The "context necessary to enable operation with the target AP MLD" may include Block Ack (BA) agreements. The "context necessary to enable operation with the target AP MLD" may include other information about non-AP MLDs.Some of the context necessary to enable operation with the target AP MLD may be transferred in the transition preparation procedure.

[0274] In the transition execution procedure, while a non-AP MLD is transitioning from the current AP MLD to the 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 forwarded from the current AP MLD to the target AP MLD may include Data frames sent from APs belonging to the current AP MLD and / or the target AP MLD to STAs belonging to the non-AP MLD. In the transition execution procedure, the frames forwarded from the current AP MLD to the target AP MLD may include individually addressed QoS Data frames. In the transition execution procedure, the frames forwarded from the current AP MLD to the target AP MLD may include individually addressed Management frames. In the transition execution procedure, the frames forwarded from the current AP MLD to the target AP MLD may include IQMFs. In the transition execution procedure, the frames forwarded from the current AP MLD to the target AP MLD may include other types of frames.

[0275] Figure 13 shows an example of an SMD according to one aspect of this embodiment. 1301 may be a non-AP MLD. 1302 and 1303 may be non-AP STAs belonging to 1301. 1304 may be an AP MLD. 1305 and 1306 may be APs belonging to 1304. 1307 may be an AP MLD. 1308 and 1309 may be APs belonging to 1307. 1310 may be an SMD-ME. 1311 may be an SMD. 1304 and 1307 may be AP MLDs covered by 1311. 1312 may be an AP MLD. 1313 and 1314 may be APs belonging to 1312. 1315 may be an AP MLD. 1316 and 1317 may be APs belonging to 1315. 1318 may be SMD-ME. 1319 may be SMD. 1312 and 1315 may be AP MLDs covered by 1319. 1311 may not cover 1312 and 1315. 1319 may not cover 1304 and 1307. 1320 may be a mobility domain. 1320 may be an ESS. 1311 and 1319 may be parts of 1320.

[0276] In Figure 13, for example, 1305, 1306, 1308, 1309, 1313, 1314, 1316, and 1317 may broadcast the MDE in the Beacon frame and Probe Response frame. For example, in the case of non-MLO, 1305, 1306, 1308, 1309, 1313, 1314, 1316, and 1317 do not each have to broadcast the same MDE. For example, in the case of non-SMD MLO, 1305 and 1306, 1308 and 1309, 1313 and 1314, and 1316 and 1317 may each broadcast the same MDE. For example, in the case of SMD, 1305, 1306, 1308, 1309, and 1313, 1314, 1316, and 1317 may all broadcast the same MDE.

[0277] In Figure 13, for example, when 1301 transitions from 1311 to 1319, 1301 may transition from 1311 to 1319 using the FT (Fast BSS Transition) procedure if the MDE reported by 1305, 1306, 1308, or 1309 is the same as the MDE reported by 1313, 1314, 1316, or 1317. In Figure 13, for example, when using the FT procedure, 1301 may send an Association Request frame or a Reassociation Request frame containing an MDE to 1318. In Figure 13, for example, when 1301 transitions from 1311 to 1319, 1301 may send an Association Request frame or a Reassociation Request frame containing an MDE and a Basic SMD element to 1318. For example, the content of the MDE included in the Association Request frame or Reassociation Request frame that 1301 sends to 1318 may be the MDE value reported by 1313, 1314, 1316, or 1317. For example, 1318 may decide whether or not to respond with an Association Response frame or Reassociation Response frame, respectively, based on the content of the MDE included in the Association Request frame or Reassociation Request frame received from 1301.For example, if the content of the MDE (some or all of the values ​​in the Element ID field, Length field, MDID field, and FT capability and Policy field) contained in the Association Request frame or Reassociation Request frame received from 1301 matches the content of the MDE reported by 1313, 1314, 1316, or 1317, 1318 may respond with an Association Response frame or Reassociation Response frame, respectively. For example, if the content of the MDE contained in the Association Request frame or Reassociation Request frame received from 1301 does not match the content of the MDE reported by 1313, 1314, 1316, or 1317, 1318 may not respond with an Association Response frame or Reassociation Response frame, respectively. For example, 1318 may include some or all of the content of the Basic SMD element contained in the MDE reported by 1313, 1314, 1316, or 1317, and / or the Association Request frame or Reassociation Request frame received from 1301, in an Association Response frame or Reassociation Response frame, respectively, and transmit it. For example, if 1301 receives an Association Response frame or Reassociation Response frame from 1318 with a status code indicating SUCCESS, it may consider the (re)association to have been successful and proceed with IEEE 802.1X authentication or transition to State 4.

[0278] For example, in Figure 13, 1301 and / or 1302 and / or 1303 may associate with 1310 in the first association procedure. For example, if 1301 has the capability for Seamless BSS Transition, it may associate with 1301. For example, if 1301 has the capability for UHR, it may associate with 1301. Under conditions other than those stated above, 1301 and / or 1302 and / or 1303 may associate with 1310 in the first association procedure. 1304 and / or 1305 and / or 1306 and / or 1307 and / or 1308 and / or 1309 and / or 1310 may include SMD (1310 and / or 1311) information in the frame they transmit.

[0279] For example, if 1301 performs a Seamless BSS Transition from 1304 to 1307, 1301 may also be associated with 1310. For example, if 1301 performs a Seamless BSS Transition from 1304 to 1307, 1301's association may change from 1301 and 1304 to 1301 and 1310, and then to 1301 and 1307. For example, when performing a Seamless BSS Transition, the association of 1301 may change based on the Transition Preparation Request frame and / or the Transition Preparation Response frame and / or the Transition Execution Request frame and / or the Transition Execution Response frame. For example, 1301, which is associated with 1304, may associate with 1310 after sending a Transition Preparation Request frame or Transition Execution Request frame, and then associate with 1307 after receiving a Transition Preparation Response frame or Transition Execution Response frame.For example, 1301, which is associated with 1304, may associate with 1310 after sending a Transition Preparation Request frame and / or a Transition Preparation Response frame and / or a Transition Execution Request frame and / or a Transition Execution Response frame, or after receiving a Transition Preparation Request frame and / or a Transition Preparation Response frame and / or a Transition Execution Request frame and / or a Transition Execution Response frame.

[0280] For example, when 1301 moves from 1311 to 1319, 1301 may disassociate with 1310. For example, when 1301 moves from 1311 to 1319, 1301 may reassociate with 1318. For example, when 1301 moves from 1311 to 1319, the association of 1301 may change from 1301 and 1310 to 1301 and 1318. For example, when 1301 moves from 1311 to 1319, 1301 may use the FT procedure. For example, when using the FT procedure, the association of 1301 may change based on the Association Request frame and / or the Association Response frame and / or the Reassociation Request frame and / or the Reassociation Response frame that include the MDE. For example, 1301, which is associated with 1310, may associate with 1318 after sending an Association Request frame and / or a Reassociation Request frame containing an MDE, and / or after receiving an Association Response frame and / or a Reassociation Response frame containing an MDE.

[0281] Figure 14 shows an example of the procedure for FT initial mobility domain association of an SMD-ME according to one aspect of this embodiment. The SMD-ME may broadcast the MDE using a Beacon frame or a Probe Response frame (S1401). When the SMD-ME receives the MDE from a non-AP MLD in a (Re)Association Request frame, it may determine whether the content of the received MDE (some or all of the values ​​of the Element ID field, Length field, MDID field, and FT capability and Policy field) matches the content of the MDE broadcast in the Beacon frame or Probe Response frame (S1402). If the SMD-ME determines in S1402 that the content of the MDE received from the non-AP MLD matches the content of the MDE broadcast in the Beacon frame or Probe Response frame, it may send a (Re)Association Response frame containing the MDE broadcast in the Beacon frame or Probe Response frame (S1403). If the SMD-ME determines in S1402 that the content of the MDE received from the non-AP MLD does not match the content of the MDE reported in the Beacon frame or Probe Response frame, it may reject the (Re)Association Request frame from the non-AP MLD (S1403).

[0282] Figure 15 shows an example of the procedure for FT initial mobility domain association of a non-AP MLD according to one aspect of this embodiment. The non-AP MLD may receive MDE from a Beacon frame or Probe Response frame broadcast by the SMD-ME (S1501). The non-AP MLD may send a (Re)Association Request frame including the value of MDE received in S1501 to the SMD-ME (S1502). The non-AP MLD may receive a (Re)Association Response frame from the SMD-ME, which is a response frame to the (Re)Association Request frame sent in S1502 (S1503).

[0283] SMD-ME may always be established by AP MLDs belonging to the SMD. SMD-ME may be established when a non-AP MLD performs a Seamless BSS Transition. SMD-ME may be deactivated if no non-AP MLDs within the SMD perform a Seamless BSS Transition.

[0284] 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.

[0285] "SMD" may be replaced with "SMD-ME". "Notify", "Notify", and "Advertise" may be replaced with each other. "SMD-ME removes current AP MLD" may be replaced with "SMD-ME removes all links in current AP MLD", "SMD-ME removes all information held for the links in current AP MLD", etc. Also, when SMD-ME removes current AP MLD, it may delete or reset some or all of the context associated with non-AP MLDs.

[0286] 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.

[0287] As described above, embodiments of the present invention enable non-AP MLDs to migrate between SMDs within the same mobility domain using the FT protocol. One aspect of this invention allows for more efficient management of associations by SMD-MEs.

[0288] 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.

[0289] 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.

[0290] 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.

[0291] 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.

[0292] 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.

[0293] Furthermore, the base station equipment 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 equipment 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 equipment. In addition, the terminal equipment related to the above-described embodiment can also communicate with the base station equipment as an assembly.

[0294] 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.

[0295] 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 AV equipment, kitchen equipment, cleaning and washing machines, air conditioning equipment, office equipment, vending machines, and other household appliances, as well as terminal devices or communication devices.

[0296] 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, various modifications are possible within the scope of the claims for one aspect of the present invention, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present 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.

[0297] One aspect of the present invention can be used, for example, in communication systems, communication equipment (e.g., mobile phone devices, base station devices, wireless LAN devices, or sensor devices), integrated circuits (e.g., communication chips), or programs.

[0298] 101, 201, 205 BSS 102, 202, 206 AP 103, 104, 203, 204, 207, 208 STA SU1, AU1 Antenna section SU2, AU2 RF section SU3, AU3 Physical layer processing section SU4, AU4 MAC layer processing section SU5 Upper layer packet processing section SU6, AU6 Wireless transceiver section SU7, AU7 Frame processing section AU5 DSAF section 1101, 1104 STA transmission 1102, 1211 IFS 1103, 1212 Backoff counter (concentration 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 one or more APs, wherein the one or more APs belong to a first AP MLD, the first SMD (Seamless Mobility Domain) is composed of a plurality of AP MLDs including the first AP MLD, the second SMD is composed of a plurality of AP MLDs not including the first AP MLD, the first SMD and the second SMD are part of the same mobility domain, and each AP belonging to an AP MLD belonging to the first SMD and the second SMD has a processing unit that uses an MDE (Mobility Domain element) to notify that it is included in a group of APs constituting the mobility domain, and all APs belonging to an AP MLD belonging to the first SMD and the second SMD notify the same MDE.

2. The base station device according to claim 1, wherein the terminal device communicating with the base station device has one or more non-AP STAs, the one or more non-AP STAs belong to a non-AP MLD, and the non-AP MLD transitions from the first SMD to the second SMD, which is part of the same mobility domain.

3. A terminal device having one or more non-AP STAs belonging to a non-AP MLD, which communicates with a base station device having one or more APs, wherein the one or more APs belong to a first AP MLD, the first SMD (Seamless Mobility Domain) is composed of a plurality of AP MLDs including the first AP MLD, the second SMD is composed of a plurality of AP MLDs not including the first AP MLD, the first SMD and the second SMD are part of the same mobility domain, each AP belonging to an AP MLD belonging to the first SMD and the second SMD includes a processing unit that uses an MDE (Mobility Domain element) to notify that it is included in a group of APs constituting the mobility domain, all APs belonging to an AP MLD belonging to the first SMD and the second SMD notify the same MDE, and the non-AP MLD transitions from the first SMD to the second SMD, which are part of the same mobility domain.

4. A communication method in a base station device having one or more APs, wherein the one or more APs belong to a first AP MLD, the first SMD (Seamless Mobility Domain) is composed of a plurality of AP MLDs including the first AP MLD, the second SMD is composed of a plurality of AP MLDs not including the first AP MLD, the first SMD and the second SMD are part of the same mobility domain, each AP belonging to an AP MLD belonging to the first SMD and the second SMD uses an MDE (Mobility Domain element) to announce that it is included in a group of APs constituting the mobility domain, and all APs belonging to an AP MLD belonging to the first SMD and the second SMD announce the same MDE.

Images