Methods and station for federated learning over wireless (FLOW) in wireless local area networks (WLAN)

Abstract

A shared learning (FL) and / or distributed machine learning (ML) model program can be implemented in a wireless network. An access point (AP), station (STA), or similar entity can provide an FL publishing message indicating that an FL or ML program is in use. An STA receiving the publishing message can provide an FL / ML support frame indicating its participation in FL model sharing. The STA may contain a local FL model that can be executed on the STA. The STA can update its local FL model based on information in the FL publishing message. The STA can also update its local FL model based on information received from other STAs in the network. The FL publishing message may contain a schedule, and the STA can be configured to train its local FL model according to the schedule. The shared model program can be implemented in a wireless local area network.

Description

[Technical Field]

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 252,484, filed October 5, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0003] This invention relates to joint machine learning in wireless local area networks (WLANs). [Previous Technology]

[0004] In Basic Service Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP typically accesses or interfaces with a Distribution System (DS) or loads and unloads traffic into and out of the BSS via another type of wired / wireless network. Traffic originating outside the BSS and destined for STAs can reach and be delivered to those STAs via the AP. Traffic originating from STAs and destined for destinations outside the BSS can be sent to the AP for delivery to individual destinations. Traffic between STAs within the BSS can also be sent via the AP, where the source STA sends traffic to the AP and the AP delivers traffic to the destination STA. Such traffic between STAs within the BSS can be considered peer traffic. Such peer traffic can also be used, for example, with a direct link setup (DLS) using 802.11e DLS or 802.11z Tunneled DLS (TDLS) to send directly between source and destination STAs. WLANs using the Standalone BSS (IBSS) mode do not have access points (APs) and / or stations that communicate directly with each other. This communication mode is called "ad-hoc" communication mode.

[0005] Federation learning is a distributed machine learning mechanism involving multiple devices. The implementation of federated learning in wireless networks (e.g., WLAN) can leverage high computational processing and high-throughput communication. [Summary of the Invention]

[0006] This document describes methods and apparatuses for efficiently implementing federated learning without excessive overhead. In federated learning, models and / or model variants can be shared among distributed users and servers or similar entities. The methods and apparatuses described herein provide efficiency mechanisms for users to share their current machine learning models while maintaining reduced overhead. The description is based on an enhanced broadcast service (EBCS) framework, for example, containing mechanisms that support or enable distributed machine learning (ML) or federated learning (FL). In some federated learning scenarios, to reduce overhead and communication load, for example, several variables of a part of the model, such as gradients, or gradients of one or more weights, can be shared among different users utilizing the same learning model to facilitate fast convergence.

[0007] This document describes an efficiency mechanism that allows users to correctly share their learning model parameters (e.g., gradients of weights) while maintaining a reduced burden. In an example embodiment, to save power, the selected user terminal may not need to be constantly operational except when necessary. The AP knows that the STA operating parameters used for FL can be advantageous, such as when the STA is ready to receive an updated training model, processing power, available power for processing data, the amount of data collected for training, or similar factors, or any suitable combination thereof. Therefore, FL operating parameter settings and synchronization can be implemented between the AP and the selected STA. As described herein, an effective agreement can provide FL operating parameters between the AP and the STA.

[0008] In one example embodiment, an access point (AP) may connect to an ML or FL server. The AP may publish that FL model sharing is in progress. The publication may be in the form of a publication frame and may be broadcast, multicast, or any suitable combination thereof. A station (STA) receiving the publication may transmit an FL support message indicating its participation in FL sharing. The STA receiving the publication may update its local FL model based on the information in the publication. The publication may include a schedule, and the STA receiving the publication may follow the schedule to communicate with other STAs and / or APs. STAs may provide individual local FL model parameters, and STAs receiving parameters may use their individual local FL models updated with the received parameters. Local FL models can be executed, and the results may be provided to a centralized model via a network.

[0009] In one example method, an FL model publishing frame may be received by a STA. The FL model publishing frame may be provided by an AP. The FL model publishing frame may contain instructions for FL model sharing procedures. In response to receiving an FL publishing frame, the STA may transmit an FL support frame containing instructions for participating in the FL model sharing procedures. The FL support frame may contain a set of parameters associated with the local FL model. The FL support frame may be broadcast, multicast, unicast directly to the AP, or any suitable combination thereof. A station may receive an FL support frame transmitted by another station. A station may update its local FL model based on information contained in the received publishing frame, information contained in the received FL support frame, or any suitable combination thereof. The publishing frame may contain publishing parameters including at least one of an FL model identifier (ID), the number of FL model layers, or the number of weights per layer. The STA may be configured to update its local FL model according to the publishing parameters. The publishing frame may contain at least one of an uplink (UL) schedule or a downlink (DL) schedule, and the STA may be configured to transmit and receive according to at least one of the UL schedule or the DL schedule.

[0010] According to this method, the STA can receive a trigger frame and respond to the received trigger frame, sharing its local FL model parameters. Sharing can be accomplished via broadcast messages, multicast messages, messages sent directly to network entities, or any suitable combination thereof. The trigger frame may contain a null data packet feedback report poll (NFRP) frame. The trigger frame may contain a UL Enhanced Broadcast Service (EBCS) message. Sharing can be accomplished according to at least one of the UL schedule or the DL schedule.

[0011] According to this method, the STA can receive gradient updates for its local FL model and be configured to update its local FL model based on the received gradient updates. The STA can train its local FL model and transmit the training results. The results can be transmitted via broadcast messages, multicast messages, unicast messages sent directly to network entities, or any suitable combination thereof. The STA can receive messages containing a target wake time (TWT) schedule and can be configured to receive training parameters for its local FL model during the TWT.

[0012] An instance STA can be configured to perform the above method. For example, an STA may include a transceiver and a processor. The processor can be configured to receive an FL model publishing frame via the transceiver. The FL model publishing frame may be provided by an AP in the network. The FL model publishing frame may contain instructions for FL model sharing procedures. In response to receiving an FL publishing frame, the STA can transmit an FL support frame via the transceiver containing instructions for participating in the FL model sharing procedures. The FL support frame may contain a set of parameters associated with the local FL model. The FL support frame may be broadcast, multicast, unicast directly to the AP, or any suitable combination thereof. The processor can be configured to receive an FL support frame transmitted by another station in the network via the transceiver. The STA can update its local FL model based on information contained in the received publishing frame, information contained in the received FL support frame, or any suitable combination thereof. The publishing frame may contain parameters including at least one of an FL model identifier (ID), the number of layers, or the number of weights per layer. The STA can be configured to update its local FL model according to the published parameters. The publishing frame may contain at least one of an uplink (UL) schedule or a downlink (DL) schedule, and the STA may be configured to transmit and receive according to at least one of the UL schedule or the DL schedule.

[0013] The STA's processor can be configured to receive trigger frames via a transceiver and respond to the received trigger frames, sharing its local FL model parameters. Sharing can be accomplished via broadcast messages, multicast messages, messages sent directly to network entities, or any suitable combination thereof. The trigger frame may contain a null data packet feedback report poll (NFRP) frame. The trigger frame may contain a UL Enhanced Broadcast Service (EBCS) message. Sharing can be accomplished according to at least one of the UL schedule or DL ​​schedule.

[0014] The processor of the STA can be configured to receive gradient updates for its local FL model via a transceiver, and to update its local FL model based on the received gradient updates. The processor can train its local FL model and transmit the training results. The results can be transmitted via broadcast messages, multicast messages, messages sent directly to network entities, or any suitable combination thereof. The processor can receive messages containing the Target Wake-up Time (TWT) schedule via a transceiver, and can be configured to receive training parameters for its local FL model during the TWT.

Implementation Method

[0016] Figure 1A is a diagram illustrating one or more example communication systems 100 that may be implemented according to the disclosed embodiments. The communication system 100 may be a multi-access system that provides content (such as voice, data, video, communications, broadcasts, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), and similar methods.

[0017] As shown in FIG1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, an internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be configured to operate and / or communicate in a wireless environment of any type. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station, STA) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile radios, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRU 102a, 102b, 102c, and 102d may be referred to as UE interchangeably.

[0018] The communication system 100 may also include base stations 114a and / or 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home node Bs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs), new radio (NR) NodeBs), station controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0019] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base stations 114a and / or 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, and these base stations may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide radio service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, that is, one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0020] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0021] More specifically, as mentioned above, the communication system 100 may be a multi-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies, such as using wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) on the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0022] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) on the air interface 116.

[0023] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technology, such as using NR to establish NR radio access to space interface 116.

[0024] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0025] In other embodiments, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Global Interoperability Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), and the like.

[0026] Base station 114b in Figure 1A may be a wireless router, home node B, home eNode-B, or access point, for example, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as business premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in FIG1A, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0027] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 can provide call control, billing services, location-based services, prepaid telephone, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or different RATs. For example, in addition to connecting to RAN 104 (which can utilize NR radio technology), CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] CN 106 may also function as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU 102c shown in FIG1A may be configured to communicate with a base station 114a that may employ cellular-based radio technology and with a base station 114b that may employ IEEE 802 radio technology.

[0030] Figure 1B is a system diagram illustrating example WTRU 102. As shown in Figure 1B, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that WTRU 102 may include any combination of the above-mentioned elements while remaining consistent with one embodiment.

[0031] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although FIG. 1B depicts processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or on a chip.

[0032] The transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 can be configured as an antenna to transmit and / or receive RF signals. In one embodiment, for example, the transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0033] Although the transmit / receive element 122 is depicted as a single element in FIG. 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals through the air interface 116.

[0034] Transceiver 120 can be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, WTRU 102 may have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0035] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0036] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0037] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to (or alternatively) information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

[0038] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), universal serial bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, frequency modulated (FM) radio unit, digital music player, media player, video game console module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, and the like. Peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, and the like.

[0039] WTRU 102 may include some or all of the signals (e.g., associated with a specific subframe for both UL (e.g., for transmission) and DL (e.g., for reception)) for which transmission and reception may be parallel and / or simultaneous full-duplex radio. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via either hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include some or all of the signals (e.g., associated with a specific subframe for either UL (e.g., for transmission) or DL ​​(e.g., for reception) for which transmission and reception may be half-duplex radio.

[0040] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As mentioned above, RAN 104 may use E-UTRA radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0041] RAN 104 may include eNode-B 160a, 160b, 160c, although it should be understood that RAN 104 may include any number of eNode-Bs, while remaining consistent with one embodiment. Each of eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-B 160a, 160b, 160c may implement MIMO technology. Therefore, eNode-B 160a, for example, may use multiple antennas to transmit radio signals to WTRU 102a and / or receive radio signals from the WTRU.

[0042] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, and the like. As shown in Figure 1C, the eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0043] CN 106 shown in FIG1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the above elements are depicted as components of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0044] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, enabling / disabling bearers, and selecting specific service gateways during the initial attachment of WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0045] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to WTRUs 102a, 102b, and 102c, or route and forward user data packets from these WTRUs. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode-Bs, triggering calls when DL data is available to WTRUs 102a, 102b, and 102c, managing and storing background information for WTRUs 102a, 102b, and 102c, and similar functions.

[0046] SGW 164 can be connected to PGW 166, which can provide access to packet switching networks (such as Internet 110) to WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0047] CN 106 may facilitate communication with other networks. For example, CN 106 may provide WTRU 102a, 102b, 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP multimedia subsystem (IMS) server) or be able to communicate with such IP gateway, which acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 may provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, it is envisioned that in some representative embodiments, this terminal may be used with a communication network (e.g., temporarily or permanently) with a wired communication interface.

[0049] In a representative embodiment, the other network 112 may be a WLAN.

[0050] In an Infrastructure Basic Service Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that loads and / or loads traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for STAs can be reached and delivered to those STAs via the AP. Traffic originating from STAs and destined for destinations outside the BSS can be sent to the AP for delivery to individual destinations. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between a source STA and a destination STA (e.g., directly therebetween) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0051] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (such as the primary channel). The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can back off. A STA (e.g., only one station) can transmit at any given time within a given BSS.

[0052] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, for example, by combining a 20 MHz main channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0053] The Very High Throughput (VHT) STA supports channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, data can be transmitted through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. Streams can be mapped to two 80 MHz channels, and data can be transmitted via the transmission STA. At the receiver receiving the STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0054] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidth in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidth using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in large coverage areas. MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include battery packs with a battery pack life exceeding the critical limit (e.g., to maintain a very long battery pack life).

[0055] WLAN systems supporting multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP (and other STAs in the BSS) supports 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes, the primary channel can be 1 MHz wide for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. For example, if the main channel is busy, for example because the STA (which only supports 1 MHz operating mode) transmits to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0056] In the United States, the available frequency bands (which can be used by 802.11ah) range from 902 MHz to 928 MHz. In South Korea, the available frequency bands range from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands range from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0057] Figure 1D is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As mentioned above, RAN 104 may employ NR radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0058] RAN 104 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 104 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a, for example, may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on a license-free spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0059] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable parameter set (numerology). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., containing a varying number of OFDM symbols and / or a continuously varying absolute time length).

[0060] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as operational anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in the unlicensed frequency band to communicate with gNBs 180a, 180b, and 180c. In a non-independent configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, while also communicating with / connecting to another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-independent configuration, eNode-B 160a, 160b, and 160c can act as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or delivery capacity for servicing WTRU 102a, 102b, and 102c.

[0061] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interaction between DC, NR, and E-UTRA, routing of user plane data to User Plane Function (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Function (AMF) 182a and 182b, and similar. As shown in Figure 1D, gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.

[0062] CN 106 shown in FIG1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include Data Network (DN) 185a, 185b. Although the above elements are depicted as components of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., processing different Protocol Data Unit (PDU) conversations with different requirements), selecting specific SMF 183a and 183b, managing login zones, terminating non-access-stratum (NAS) communications, mobility management, and the like. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by the WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that use other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0064] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure the routes of traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU conversations, controlling policy enforcement and QoS, providing DL data notifications, and the like. PDU conversation types can be IP-based, non-IP-based, Ethernet-based, and the like.

[0065] UPF 184a, 184b can be connected via an N3 interface to one or more of gNB 180a, 180b, 180c in RAN 104. This interface can provide WTRU 102a, 102b, 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184, 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0066] CN 106 may facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, 102c may be connected to area DN 185a, 185b via UPF 184a, 184b through an N3 interface to UPF 184a, 184b and an N6 interface between UPF 184a, 184b and DN 185a, 185b.

[0067] In view of the corresponding descriptions in Figures 1A to 1D, one or more of the following functions described herein may be performed by one or more emulation devices (not shown): WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other device(s) described herein. An emulation device may be one or more devices configured to emulate the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0068] The simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all of the functions to test other devices within the communication network while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network. One or more simulation devices can perform one or more or all of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device and / or use over-the-air wireless communication to perform the test for the purpose of testing.

[0069] One or more simulation devices can perform one or more (including all) functions while not being implemented / deployed as a wired and / or wireless communication network. For example, the simulation device can be used in test scenarios in a test laboratory and / or in a non-deployed (e.g., test) wired and / or wireless communication network to perform tests on one or more components. One or more simulation devices can be test instruments. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., which may include one or more antennas) can be used by the simulation device to transmit and / or receive data. It should be understood that the embodiments of Figures 1A to 1D can be configured to perform the methods described in more detail below.

[0070] In Basic Service Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP typically accesses or interfaces with a Distribution System (DS) or another type of wired / wireless network that loads and unloads traffic into and out of the BSS. Traffic originating outside the BSS and destined for STAs can reach and be delivered to those STAs via the AP. Traffic originating from a STA and destined for an external BSS can be sent to the AP for delivery to the individual destination. Traffic between STAs within the BSS can also be sent via the AP, where the source STA sends traffic to the AP and the AP delivers traffic to the destination STA. Such traffic between STAs within the BSS can be considered peer traffic. Such peer traffic can also be used, for example, with a direct link setup (DLS) using 802.11e DLS or 802.11z Tunneled DLS (TDLS) to transmit directly between the source and destination STAs. WLANs using the Standalone BSS (IBSS) mode do not have access points (APs) and / or stations that communicate directly with each other. This communication mode is called "ad-hoc" communication mode.

[0071] An AP operating in 802.11ac infrastructure mode can transmit beacons on a fixed channel (usually the primary channel). This channel can be 20 MHz wide and is the operating channel of the BSS. This channel can also be used by STAs to establish connections with the AP. The basic channel access mechanism in the 802.11 system is collision-avoiding carrier sense multiple access (CSMA / CA). In this operating mode, each STA, including the AP, can sense the primary channel. If the channel is detected as busy, the STA can back off. Therefore, only one STA can transmit at any given time within a given BSS.

[0072] A high-capacity (HT) STA configured to comply with the 802.11n standard specification can communicate using a 40 MHz wide channel. This is achieved by combining the main 20 MHz channel with an adjacent 20 MHz channel to form a continuous 40 MHz wide channel.

[0073] A Very High Transmission Rate (VHT) STA configured to comply with the 802.11ac standard can operate with wide channels of 20 MHz, 40 MHz, 80 MHz, and 160 MHz. The 40 MHz and 80 MHz channels can be formed by combining consecutive 20 MHz channels, similar to the 802.11n described above. The 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels (this can also be referred to as the 80+80 configuration). For the 80+80 configuration, after channel encoding, data can be transmitted through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transmission (IFFT) and time-domain processing can be performed separately on each stream. The streams can then be mapped to the two channels, and data can be transmitted. This mechanism can be inverted at the receiver, and the combined data can be sent to the MAC.

[0074] STAs configured to comply with the 802.11af and 802.11ah standards can operate in a sub-1 GHz mode. For these configurations, the channel operating bandwidth and carrier can be reduced compared to those used in the 802.11n and 802.11ac standard configurations. STAs configured to comply with the 802.11af standard can operate with bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum. STAs configured to comply with the IEEE 802.11ah standard can operate with bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz in the non-TVWS spectrum. Embodiments of the present invention can be useful in WLAN applications including meter type control (MTC) devices in large coverage areas. MTC devices may have limited capabilities, including only supporting limited bandwidth, but also include requirements for very long battery life.

[0075] A WLAN system supporting multiple channels and channel widths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) may include a channel designated as the primary channel. The primary channel may, but does not necessarily, have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may therefore be limited by the STAs supporting the minimum bandwidth operating mode of all STAs operating in the BSS. In the 802.11ah example, even if the AP (and other STAs in the BSS) can support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes, if there is a STA that only supports the 1 MHz mode (e.g., an MTC type device), the primary channel may be 1 MHz wide. The carrier sensing and network allocation vector (NAV) settings can depend on the status of the primary channel; for example, if the primary channel is busy because a STA that only supports 1 MHz operating mode is transmitting to an AP, then even if most of the frequency band remains idle and available, the entire available frequency band can be considered busy.

[0076] In the United States, the available frequency bands utilized by 802.11ah range from 902 MHz to 928 MHz. In South Korea, it ranges from 917.5 MHz to 923.5 MHz; and in Japan, it ranges from 916.5 MHz to 927.5 MHz. The total bandwidth available for operation compliant with 802.11ah can range from 6 MHz to 26 MHz, depending on national regulations.

[0077] Enhanced Broadcast Service (EBCS) can download from the AP to non-AP STAs or upload from sensors or other non-AP STAs. EBCS can be provided to two types of STAs, one associated with a particular AP and the other not. It is anticipated that an AP can support up to 3000 non-AP STAs using EBCS. Additionally, there may be a class of low-cost non-AP STAs that consume EBCS and may not be able to transmit directly to the AP. Some practical applications of the EBCS embodiments disclosed herein may include stadium video broadcasting, car broadcasting, uplink sensor data broadcasting, museum information and multilingual broadcasting, and event producer information and content broadcasting, or similar applications.

[0078] Non-AP STAs can select a compatible network for performing authentication and association. Once a compatible network is discovered, the STA can attempt authentication. For example, the STA can send an authentication frame to the AP. The AP can receive the authentication frame and respond to the STA. After authentication, the STA can execute the association procedure to enable data transfer through the AP. The STA can send an association request to the AP. If the AP has the capability to support STAs, the AP can create an association ID for the STA and respond to the STA with an association response containing a success message indicating authorized network access. The STA then successfully associates with the AP, and data transfer can begin.

[0079] The embodiment provides Target Wake-Up Time (TWT) operation in 802.11ax and 802.11be. Target Wake-Up Time (TWT) allows the AP to manage activity in the BSS to reduce contention between STAs and reduce the amount of time required for STAs utilizing power management modes that may need to be woken up. This can be achieved by allocating STAs to operate in non-overlapping times and / or frequencies and centralizing frame switching within predefined service cycles.

[0080] High-efficiency (HE) / Extremely high throughput (EHT) STAs can negotiate individual TWT protocols. Non-AP HE / EHT STAs can establish membership in broadcast TWT schedules. HE / EHT APs can deliver broadcast TWT parameter sets to non-AP HE / EHT STAs.

[0081] Example TWT element 202 is shown in Figure 2A. TWT element 202 may include element ID field 204, length field 206, control field 208, and TWT parameter information field 210. Example format of control field 208 is shown in Figure 2B. Control field 208 may include NDP call indicator field 212, responder PM mode field 214, negotiation type field 216, TWT information box deactivation field 218, wake-up duration unit field 220, link ID bit map presence field 222, and reserved field 224. Individual TWT parameter set field formats and broadcast TWT parameter set field formats are shown in Figures 2C and 2D, respectively.

[0082] For the purposes of this specification, the term "machine learning" means one or more computers (e.g., machines) configured according to an algorithm, such that the performance of the one or more computers on a task measured in units of T by means of P is improved by experience E, and it is said that the one or more computers learn from experience E related to a certain type of task T and performance measurement P by means of the algorithm.

[0083] There are many different kinds of machine learning, depending on the nature of the task T that the system is learning, the nature of the performance measurement P used to evaluate the system, and the nature of the training signal or experience E given to it. Machine learning implementation schemes are classified into three main categories, depending on the nature of the learning "signals" or "responses" that can be used in the learning systems described below.

[0084] Supervised learning refers to an algorithm learning from instance data and associated target responses, which can be composed of numerical or string representations (such as categories or labels), so that when encountering new instances later, it can predict situations where the correct response belongs to the category of the supervised learning. This method is similar to human learning under teacher supervision. The teacher provides good examples for the student to memorize, and the student then derives general rules from these specific examples.

[0085] Unsupervised learning refers to a scenario where an algorithm learns from ordinary instances without any associated responses, allowing the algorithm to independently determine data patterns. This type of algorithm often restructures data into something else, such as new features that can represent a class of unrelated values ​​or a new set of unrelated values. These are quite useful in providing insights into the meaning of data from human perspectives and in providing new, useful inputs to supervised machine learning algorithms.

[0086] Reinforcement learning refers to a category of problems in which a system or agent must learn how to interact with its environment. This can be encoded by a policy a = π(x), which specifies which action to take in response to each possible input x (derived from the state of the environment). The difference from supervised learning is that the system is not told which action is the best action to take (e.g., which output to produce for a given input). Instead, the system only receives non-recurring reward (or punishment) signals as a response to the action it takes. This is similar to learning from a critic who gives non-recurring approval or disapproval, rather than from a teacher who tells you what to do at each step.

[0087] The goal of federated learning is a machine learning setup that trains a high-quality centralized model while maintaining training data distributed across several user terminals. One or more user terminals may have unreliable or relatively slow network connections. In each round, each user terminal can independently compute an update to the current model based on its location data and transmit this update to a central server, where the user-side updates are aggregated to compute a new global update. A typical user terminal in this setup may include a mobile phone. Therefore, efficient communication is advantageous. Federated learning enables mobile phones to collaboratively learn and share a predictive model while keeping training data on the mobile phone, decoupling the ability to perform machine learning from the need to store data in the cloud. Training data can be held locally on the user's mobile device, and the device can be used as a node to perform computations on its local data to update the global model.

[0088] According to a simple implementation of joint learning, each user terminal can send the complete model (or a complete model update) back to the server in each round. For large models, this step can become a bottleneck in joint learning due to several factors. One factor is the asymmetric nature of internet connection speed: uplink is slower than downlink. One way to reduce the cost of uplink communication (from user terminal to server) in joint learning is to implement structured updates, where updates from finite progress can be learned and can be parameterized using a smaller number of variables. Another is to update a summary of the complete model. This is then compressed before being sent to the server.

[0089] Learning performance is measured using gradient descent. Gradient descent is a first-order iterative optimization algorithm used to find local minima of differentiable functions. The idea is to take repeated steps in the opposite direction of the gradient (or approximate gradient) of the function at the current point, because this is the steepest descent direction. This function is often defined as a loss or error function used to measure learning performance.

[0090] Gradient descent is a technique commonly used to minimize the loss function, as shown in Figure 3. Initially, the model outputting y assigns random weights to the features. Therefore, its initial weights are called a. This produces a loss far from the minimum point L-min. If the weights are moved towards the positive x-axis, the loss function J(w) can be optimized and minimized. To optimize the weights and minimize the error, we can examine how the error changes with the weights. We can find the derivative of the error with respect to the weights. This derivative is called the gradient, or , or

[0091] If the loss increases with increasing weights, the gradient will be positive, for example, at point c in Figure 3. If the loss decreases with increasing weights, the gradient will be negative, corresponding to point a in Figure 3. Moving from point a towards the positive x-axis to Lmin indicates a negative gradient. Moving from point c towards the negative x-axis to Lmin indicates a positive gradient. Therefore, a negative gradient indicates that the weights should move in the direction that optimizes the loss function. It is the gradient that guides the model to increase or decrease weights to optimize the loss function.

[0092] The procedure for training a neural network determines a set of parameters that minimizes the difference between the expected value and the model output (e.g., minimizes the loss function). This is accomplished using gradient descent, which involves two steps: calculating the gradient of the loss / error function and then updating the existing parameters in response to the gradient. This cycle is repeated until the minimum value of the loss function is reached. This learning procedure can be described by a simple equation:

[0093] Gradient descent also operates in N dimensions. The gradient indicates which components need to be changed more and which components need to be changed less to reduce the loss function, J(w1, w2, w3, ..., wN), that is:

[0094] Backpropagation will now be described. When based on a set of input-adapted neural networks, backpropagation computes the gradient of the loss function with respect to the network weights for a single input-output instance, and this is efficient, unlike the simple, direct computation where the gradient is independently related to each weight. This efficiency makes it feasible to use gradient methods to train multi-layer networks and update weights to minimize the loss; typically gradient descent or its variants, such as stochastic gradient descent, are used. The backpropagation algorithm operates by computed the gradient of the loss function with respect to each weight using chaining, computed the gradient layer by layer, and iterates backward from the last layer to avoid redundant computation of intermediate terms in the chaining; this is an example of dynamic programming.

[0095] Although the term backpropagation refers to the algorithm used to compute gradients rather than how gradients are used, the term is often used loosely to refer to the entire learning algorithm, including how gradients are used, such as through stochastic gradient descent.

[0096] Federated learning enables cross-organizational data use and model building while complying with appropriate privacy, security, and / or regulatory requirements. Architectural frameworks and application guidelines for federated machine learning can be defined.

[0097] This disclosure addresses the sharing of federated learning models. Federated learning has been increasingly deployed in wireless networks. In federated learning, models and / or model variants can be shared among distributed users and servers. A model addresses how to provide an efficiency mechanism that allows users to share their current machine learning models while considering and / or reducing their burden. Based on the EBCS framework, mechanisms that support or enable distributed ML or federated learning can be advantageous.

[0098] This disclosure also addresses the state of gradient sharing in joint learning models. Joint learning has been increasingly deployed in wireless networks. In some joint learning scenarios, to reduce burden and communication load, for example, the gradients of some variables (e.g., gradients) or one or more weights of a part of the model can be shared among different users utilizing the same learning model to facilitate faster convergence. Therefore, the state of gradient sharing in joint learning models refers to how to provide an efficient mechanism for users to correctly share their learning model parameters (e.g., gradients of weights) while considering and / or reducing burden.

[0099] This disclosure also addresses the state of operation synchronization in federated learning. In federated learning, to save power, selected user terminals may not need to be constantly active except when required. The AP may need to know multiple STA operation parameters for FL, such as when the STA is ready to receive the updated trained model, processing power, available power for processing data, and the amount of data collected for training. Therefore, the setting and synchronization of FL operation parameters between the AP and the selected STA can be advantageous. Thus, the state of operation synchronization in federated learning is how to define an effective agreement for providing FL operation parameters between the AP and STA.

[0100] The example embodiments discussed below handle the sharing of joint learning or machine learning models. Enhanced Broadcast Service (EBCS) (e.g., 802.11bc) programs provide both uplink (UL) and downlink (DL) broadcast protocols. Such UL and DL broadcast programs can be applied to APs and STAs to share their machine learning and joint learning models, weights, gradients, and / or other parameters.

[0101] Figure 4A depicts an example design of an ML / FL model shared publishing frame 402In. The ML / FL model shared publishing frame 402In may be referred to herein as an FL publishing frame, publishing frame, shared publishing frame, ML publishing frame, FL shared publishing frame, ML shared publishing frame, or ML / FL shared publishing frame. In one example application, a shared broadcaster for machine learning and federated learning models can be implemented in a scenario where an EBCS STA (such as an EBCS AP or EBCS non-AP STA) is connected to a machine learning (ML) or federated learning server (LS) and the LS is configured to cooperate with one or more STAs within a region or network to initiate or execute machine learning or federated learning algorithms.

[0102] An EBCS AP or EBCS STA can broadcast one or more FL release frames to release machine learning models or joint learning models currently in progress. Release frame 402 may contain one or more fields for conveying parameters related to the ML / FL model. For example, the ML / FL support indicator frame may include one or more of the following fields: MAC header field 404, Learning Server (LS) server address field 406, ML / FL model ID field 408, number of layers field 410, weight list field 412, gradient list field 414, update schedule field 416, model update 418, and frame check sequence (FCS) field 420. The FCS field 420 can be used to check the integrity of the frame.

[0103] MAC header field 404 may contain a receiver address (RA). RA may be set to a broadcast address, or an address such as a multicast address shared with one or more ML / FL models, or another address agreed upon in advance. MAC header field 404 may contain a transmitter address (TA). TA may be set to the MAC address of a transmitter, such as the MAC address of an EBCS AP or STA, or a multicast address shared with one or more ML / FL models.

[0104] Learning Server (LS) Address Field 406 is a subfield that can identify the LS server address, which can be an IP address, or a MAC address, or a multicast address, or any other suitable address of any other type.

[0105] ML / FL Model Identification (ID) field 408 can be a subfield indicating the ID of one or more ML / FL models.

[0106] The number of layers field 410 is a subfield that indicates the number of layers that should be shared or will be shared for an ML / FL model that can be identified by the ML / FL ID.

[0107] The weight list field 412 is a subfield that indicates the number of weights that should be shared or aligned when using a shared ML / FL model. This subfield may contain a list of numbers, where each number is associated with the number of weights belonging to one of the layers. The number of weights for each layer may be the same or different. In one instance, the number of subfields in the weight list field 412 may be the same as the value in the layer number field 410, where the nth subfield contains the value of the number of weights for the nth or (n-1)th layer. If the number of weights is the same for all layers, the weight list body may contain only one number applied to each layer of the ML / FL model.

[0108] The gradient list field 414 is a sub-field that indicates the number of gradients shared or aligned when using a shared ML / FL model. This sub-field may contain a list of numbers, where each number is associated with the number of gradients belonging to one of the layers. The number of gradients for each layer may be the same or different. In one instance, the number of sub-fields in the gradient list is the same as the value in the layer number field 410, where the nth sub-field contains the value of the number of gradients for the nth or (n-1)th layer. If the number of gradients is the same for all layers, then the gradient list field 414 may contain a number of all layers applied to the ML / FL layers.

[0109] The update scheduling field 416 may contain subfields for UL and / or DL ​​scheduling. DL scheduling may indicate how frequently the LS is expected to share its updates to the ML / FL model (e.g., related layers, weights, and / or gradients), for example, the expected transmission schedule of the L / FL via the transmission STA. Additionally, DL scheduling may also indicate the allocation of resource units (RUs) or time for each update, for one or more weights and / or gradients of one or more layers.

[0110] The UL schedule may indicate to other users / STAs that they share the scheduled ML / FL updates and may include the IDs (such as time-varying STA IDs, MAC addresses, group IDs, etc.) of one or more STAs that are expected to share updates for one or more weights and / or gradients of one or more layers of the ML / FL model. The IDs may include all STAs or users or none at all. The UL schedule may include an update method indication that indicates whether sharing of the ML / FL model is expected to be triggered by, for example, a trigger box or EDCU UL transmission. Another method is for STAs to share updates via UL EBCS broadcast.

[0111] UL scheduling may include a frequency indication that indicates the frequency at which one or more STAs are expected to share their updates on one or more gradients of one or more layers in the ML / FL model.

[0112] UL scheduling may include weight / gradient quantization indications that can indicate the quantization of weights / gradients shared for its updates. For example, a transfer STA may indicate only the expected direction of gradient updates, such as increase, decrease, or no change. Or it may indicate that the actual weights or gradients with a certain quantization level should be transferred within the [Min, Max] values.

[0113] The model update field 418 may contain instructions on the current LS ML / FL model layers and weights and / or gradient values, as well as information on appropriate updates.

[0114] One or more of the fields described herein may be contained within a High-Level Protocol (HLP) container. An ML / FL publishing frame may be implemented as a frame that can have an HLP container containing HLP information necessary for transmitting ML / FL-related information. An ML / FL publishing frame may be implemented as a common action frame that can have an HLP container containing HLP information necessary for transmitting ML / FL-related information.

[0115] ML / FL publish boxes / information may also be elements, child elements, fields, or contained in other boxes, such as beacons, SMS beacons, probe requests, probe response boxes, association request / response boxes, EBCS information boxes, FILS discovery boxes, or similar. In the case of ensemble or multicast, the group ID or a set of group IDs or multicast addresses may be included in the model shared box.

[0116] Figure 4B shows an example design of the ML / FL support indicator box 422. If the EBCS STA receives an ML / FL release box and it supports ML / FL model updates via EBCS or other types of transmission, it may transmit an ML / FL support indicator box that may include one or more fields (e.g., for conveying parameters related to the ML / FL model). For example, the ML / FL support indicator box may include one or more of the following fields: MAC header field 424, LS server address field 426, ML / FL model ID field 428, layer number field 430, weight list field 432, gradient list field 434, update schedule field 436, and FCS field 438. The MAC header field 424 may contain the RA address and / or TA address. The RA address can be set to a broadcast address, or an address such as a multicast address shared with one or more ML / FL models, the MAC address of an EBCS AP from which an ML / FL publishing frame has been received, or another address pre-agreed upon. The TA address can be set to the MAC address of a transmitter, such as the MAC address of an EBCS STA, or a multicast address shared with one or more ML / FL models that can be included in the received ML / FL publishing frame. The LS server address field 426 identifies the LS server address, which can be an IP address, a MAC address, or a multicast address.

[0117] The ML / FL support indicator box 422 may further include an ML / FL model ID field 428. This subfield may indicate the ID of one or more ML / FL models. The layer number field 430 may indicate the number of layers that will be shared for the ML / FL model that can be identified by the ML / FL ID. The weight list field 432 may indicate the number of weights that will be shared when updating the shared ML / FL model. This subfield may contain a list of numbers, where each number is associated with the number of weights belonging to one of the layers. The number of weights for each layer may be the same or different. In one instance, the number of subfields in the weight list field 432 may be the same as the value in the layer number field 430, where the nth subfield may contain a value for the number of weights for the nth layer or the (n-1)th layer. If the number of weights is the same for all layers, then the weight list field 432 may contain a number of all layers applied to the ML / FL layers.

[0118] The gradient list field 434 may indicate the number of gradients that will be shared when updating a shared ML / FL model. This subfield may contain a list of numbers, where each number is associated with the number of gradients belonging to one of the layers. The number of gradients for each layer may be the same or different. In one instance, the number of subfields in the gradient list field 434 may be the same as the value in the layer number field 430, where the nth subfield contains the value of the number of gradients for the nth or (n-1)th layer. If the number of gradients is the same for all layers, the gradient list body may contain a number applied to all layers in the ML / FL.

[0119] The ML / FL support indicator box 422 may further include an update scheduling field 436 that may contain UL and / or DL ​​schedules. The UL schedule may indicate the expected schedule of updates to the indicated ML / FL model shared by the STA and may include an update method. The update method may indicate whether the sharing of the ML / FL model is expected to be triggered, for example, by a trigger box. Another method is for the STA to broadcast shared updates via the UL EBCS. The UL schedule may include a frequency indicator that indicates the frequency at which the STA is expected to share updates of the same type on one or more gradients of one or more layers of the ML / FL model. The UL schedule may include a weight / gradient quantization indicator that indicates the quantization of the weights and / or gradients being shared for its updates. For example, the STA may indicate only the expected direction of weight / gradient updates, such as increase, decrease, or no change. Or it may indicate that the actual weights / gradients with a certain quantization level should be transmitted within [Min, Max] values.

[0120] The ML / FL support indicator box 422 may include model updates. For example, the ML / FL support indicator box 422 may also contain the ML / FL model layer and weight / gradient values ​​currently being transmitted to the STA, such as the current layer, weights, or gradients of the FL model identified by the ML / FL model ID. One or more of the fields described above may be contained in a High-Level Protocol (HLP) container. The ML / FL support indicator box 422 may be implemented as a common action box that may have an HLP container containing HLP information required for transmitting ML / FL-related information. If the EBCS issues a model update, the receiving EBCS STA may record the indicated current ML / FL layer and / or weights and / or gradient values.

[0121] When the EBCS AP or EBCS STA transmitting the ML / FL release frame receives an ML / FL support indicator frame corresponding to the same ML / FL model and having acceptable update settings (e.g., number of layers, number of gradients per layer, gradient quantization level, etc.), it can record the EBCS STA and monitor the media for any future updates to the ML / FL model. It can also respond with an answer frame. It can also follow the UL schedule to transmit a trigger frame to trigger a UL ML / FL model update from the EBCS STA, for example, as included in ML / FL support indicator frame 422.

[0122] For an EBCS STA that has received an ML / FL release box and / or an ML / FL support indicator box and can use acceptable update settings to support the ML / FL model of the indicated ML / FL mode, it can record the current LS or STA layers and gradients for the indicated ML / FL model. It can then transmit the ML / FL support indicator box. The EBCS AP or STA can then follow the DL update schedule to transmit an ML / FL release box that may contain updates to ML / FL settings (such as the number of layers, the number of gradients per layer) and ML / FL parameters (gradient update direction or gradient value).

[0123] The EBCS STA may then follow the UL update schedule to transmit ML / FL support indicator boxes, which may include updates based on the updated ML / FL parameters (gradient update direction or gradient value) as included in the most recently received ML / FL release box for the appropriate ML / FL model. The EBCS AP / STA may update its ML / FL model after receiving one or more ML / FL release boxes or ML / FL indicator boxes.

[0124] In one instance method, an ML / FL publish box can be transmitted as a broadcast box. For example, an AP can transmit an ML / FL publish box to its associated and unassociated ISTAs, and a STA with the capability to do so can respond to the FL-supported indicator box. In one method, an ML / FL publish box can be transmitted as a standalone addressable box. For example, an AP can transmit an ML / FL publish box to a STA, and the STA can respond to the FL-supported indicator box.

[0125] Figure 4C depicts an example flowchart 440 for implementing a joint / machine learning procedure in a wireless network. This procedure can be applied, for example, to the shared broadcasting and triggering of gradients in machine learning and joint learning models.

[0126] In step 442, an AP or STA capable of supporting wireless FL (FLOW) can indicate its capabilities in its beacon, short beacon, FILS discovery box, probe request, (re)association request, association response box, or similar, and can include one or more FLOW elements in any of the boxes it transmits. These boxes can be communicated in any of the APs, STAs, or LSs in a federated ML environment. And therefore, the transmission of these boxes can be from any device in the environment to another device or group of devices. An AP or non-AP STA can connect to a machine learning (ML) or federated learning server (LS), and the LS can be planning to use one or more STAs in the area to perform machine learning or federated learning. In step 444, the AP / STA can broadcast one or more FL release boxes to announce that a machine learning model or federated learning model sharing is currently in progress. The ML / FL release box may include an FL model identifier (ID), model layers, the number of weights in each layer, downlink (DL) scheduling, uplink (UL) scheduling, or similar. The ML / FL release box may include an ML / FL model and / or parameters. The example ML / FL publishing frame described above is depicted in Figure 4A. In step 446, the STA may transmit one or more ML / FL support indicator frames to indicate its participation in FL model sharing. For example, if the STA receives an ML / FL frame from its associated AP and it supports ML / FL model updates, the STA may transmit one or more ML / FL support indicator frames to indicate its participation in FL model sharing. The ML / FL support indicator frame may include the FL model ID, model layer, number of weights per layer, downlink (DL) schedule, uplink (UL) schedule, or similar. The ML / FL support indicator frame may include the ML / FL model and / or parameters. Refer to Figure 4B for the example ML / FL support indicator frame described above.

[0127] In step 448, the AP may provide one or more FLOW Empty Data Packet Feedback Report Polling (NFRP) frames. The AP may transmit a FLOW NFRP frame to trigger one or more STAs to transmit FL parameters, such as, for example, model / weight / gradient sharing. The FLOW NFRP frame may contain at least a portion of the FL information to be transmitted by the STA. The AP may use the NFRP / NFR frames to collect ML / FL model updates. The AP may, for example, follow a UL schedule indicated by the STA or by the AP (e.g., in an ML / FL release frame or in an ML / FL support instruction frame) to transmit NFRP frames for ML / FL updates. The NFRP frame may contain an indication of the type of ML / FL update polling currently being performed by the NFRP frame (referred to as type information).

[0128] The NFRP frame may include an ML / FL model ID that indicates the ID of the ML / FL model. The NFRP frame may include one or more STA IDs that indicate one or more STA IDs that can provide updates to the ML / FL model. The NFRP frame may include an LTF number that indicates the number of LTFs that the responding STA should transmit in the UL NDP in response to the NFRP.

[0129] The NFRP frame may contain layer indications for one or more layers in the ML / FL mode of the NFR frame that can be provided in response to gradient updates therefor. The NFRP frame may contain gradient indications for one or more gradients in the NFR frame that can be provided in response to gradient updates therefor.

[0130] In step 450, the STA can provide FL information. For example, if the STA receives an NFRP from its associated STA and it is scheduled to respond, for example, since its ID is indicated in the NFRP, the STA can follow the indicated settings in the NFRP box and transmit the number of LTF fields. In one instance, each LTF can be associated with a gradient in a specific layer as indicated in the NFRP.

[0131] Each LTF can be modulated to indicate whether the gradient update direction should increase or decrease. For example, if the first half of the subcarriers assigned to the RU of the STA are modulated while the second half of the subcarriers assigned to the RU of the STA are not modulated, it means that the gradient update direction increases in the local replica system of the ML / FL model; otherwise, the gradient update direction decreases. In another instance, if the first half of the subcarriers assigned to the RU of the STA are not modulated while the second half of the subcarriers assigned to the RU of the STA are modulated, it means that the gradient update direction increases in the local replica system of the ML / FL model; otherwise, the gradient update direction decreases.

[0132] One example embodiment provides NFRP (NDP Feedback Reporting Polling) and NDP procedures for machine learning. In one example embodiment, the NFRP trigger box and NDP box swap in IEEE 802.11 can be modified to poll and report AI / machine learning related information, such as gradients or gradient descent. An exemplary procedure using gradient updates is shown as an example in Figure 5.

[0133] The AP can contend for and acquire the media and transmit a modified NFRP trigger box to request gradient updates from one or more STAs. The AP can carry gradient update configurations in the trigger box. The AP can transmit gradient update configurations or configuration options / candidates for use in the modified NFRP trigger in BBS level communication, such as information elements / fields carried in management boxes, for example, beacon boxes, probe response boxes, (re)association response boxes, etc. Gradient update configurations may include the type of gradient, the group / subset of gradients to be updated, gradient quantization / resolution, etc. NFRP trigger boxes are discussed below.

[0134] A STA with an updated gradient transmitted via an FNRP trigger frame and / or polled via an NFRP trigger frame can respond. The STA can transmit an NDP PPDU in response. An exemplary NDP PPDU is shown in Figure 5. The NDP PPDU may include a conventional preamble (L-preamble) portion 502 and an enhanced portion 504. The conventional preamble (L-preamble) portion 502 can be transmitted using a conventional parameter set and over a 20 MHz bandwidth. The transmission of the L-preamble portion 502 may be repeated on every 20 MHz sub-channel of the overall bandwidth, or on a 20 MHz sub-channel of the gradient that the STA can transmit. The L-preamble portion 502 may include an L-STF field, an L-LTF field, an L-SIG field, and an enhanced SIG field (e.g., U-SIG for an EHT STA). The enhanced SIG field may indicate the version or type of the NDP PPDU. For example, a value in the PHY version field and / or type field can indicate that this system carries an NDP PPDU containing AI / machine learning information. L-prequence portions transmitted from multiple STAs can overlap in frequency and / or time, and therefore their equivalents can be identical, allowing the AP to correctly detect them.

[0135] The enhancement portion 504 may contain AI / machine learning related information, such as gradients. In one method, the enhancement portion 504 may include an enhanced short training field (STF) and an enhanced long training field (LTF). The enhanced STF can be used for automatic gain control (AGC) purposes. The enhanced LTF field can be used to carry AI / machine learning related information. The enhanced LTF field may include symbols in the time domain. The enhanced LTF field can carry a total of K resource units in the time / frequency / spatial domain, wherein the size of the resource units can be determined and communicated in an NFRP trigger frame or is predefined.

[0136] In one instance, the STA can report (or can be requested to report) updates to N gradients, and each gradient can have M quantized possible values. Then at least one resource unit is available to carry them (and thus). The resource unit can be a localized (with contiguous subcarriers) or distributed (with non-contiguous subcarriers) time-frequency-spatial resource block. In one approach, each resource unit can correspond to a gradient with a value. Transmission on resource unit k can indicate that the STA can update gradient x with a gradient value or gradient value index y. There can be a predefined / predetermined one-to-one mapping between k and (x,y) pairs; for example, resource unit k can correspond to a gradient with a value / value index. STAs that can update gradients with value / value indexes can transmit a predefined / predetermined sequence on resource unit k. STAs that can update gradients with other value / value indexes may not transmit on resource unit k.

[0137] Each resource unit can correspond to a gradient. STAs can transmit different sequences on resource units to indicate that the STA can update the corresponding gradient with a certain value. The enhancement part can use a different parameter set than the L-prequence part for transmission. The enhancement part can also use CSI pre-coding to support computation-in-the-air operations in FL. The sequence transmitted on each RU can be an LTF sequence or a part of an LTF sequence, or an LTF sequence with phase rotation or a modification of an LTF sequence.

[0138] A UL trigger with random access for machine learning can be provided. IEEE 802.11ax allows STAs to participate in UL OFDMA via a random access (RA) procedure. In this procedure, any STA that does not use the RU associated with its ID to receive the trigger box can access a random access resource unit. In one embodiment, the trigger box can use AID = 0 or another / other special AID to indicate the availability of resources for random access machine learning (RAML), which, if certain conditions are met, allows some STAs or edge devices to transmit ML parameters through the same resource without considering collisions. Resources for RAML can be partitioned into several subsets, one for each ML parameter, such as gradient level and / or model type. The setting of this resource partitioning and its relevance to meaning in ML can be indicated / messaged in the trigger box.

[0139] For each STA (Single Targeting Device) that functions like an edge or local device to perform local model updates via local training using local data and believes that updating the global model is necessary, updates to the ML model or model gradients can be provided via the RAML protocol. Based on the interpretation of the resources provided for model updates or gradient levels in the trigger box, the edge or local device can thus transmit the updated model. When the transmission from the edge device is a quantized gradient, the edge devices transmitting the same gradient value can implement RAML on the same resources assigned to that value without concern for collisions. Pre-coded transmission based on CSI may be necessary (RAML).

[0140] A modified NFRP trigger box can be used to trigger NDP for ML / FL or other types of transmissions from multiple non-AP STAs simultaneously. The NFRP trigger box for ML / FL design is described below. In one example embodiment, the feedback type subfield in the user information field of the NFRP trigger box may have 4 bits capable of signaling up to 16 different feedback types. One value can be used and the remaining values ​​can be reserved. Reserved values ​​can be used to indicate that the NFRP trigger request AI and / or machine learning and / or joint learning is related to the feedback. Once the feedback subfield in the user information field of the NFRP trigger box is set to this value, the user information field can be considered as an AI variant of the NFRP user information field.

[0141] Example NFRP User Information Field AI Variant 602 is depicted in Figure 6A. As depicted in Figure 6A, NFRP User Information Field AI Variant 602 may include RU size field 604, maximum number of values ​​per gradient field 606, feedback type field 608, total number of gradients field 610, loss function type or index field 611, start gradient index field 612, UL target RSSI field 614, and / or multiplexing flag field 616.

[0142] The RU size field 604 indicates the smallest resource unit available to represent a possible value of the gradient. In one instance, the N possible sizes of the RU can be predefined / reserved and sorted using indices 0 to N-1. In this instance, the RU resolution subfield can have log 2 N bits and indicate the index of the selected RU size. For example, a [13, 26, 104, 242] tuned RU can be predefined / reserved using indices [0,1,2,3]. When the RU resolution subfield is set to 0, it indicates that a 13 tuned RU is used in the following NPD PPDU. Each 13 tuned RU can be used to indicate a possible value of the gradient.

[0143] Regarding the maximum number of values ​​per gradient field 606, each gradient may have multiple possible values ​​or multiple quantization levels. This subfield can indicate the maximum allowed number of values ​​per gradient, which may be called N_maxValuesPerGradient.

[0144] Feedback type field 608 can indicate the AI ​​variant of the NFRP user information field.

[0145] The total number of gradients field 610 can indicate the total number of gradients to be included in the subsequent NDP PDPU transmission, which can be referred to as N_Gradient.

[0146] Loss Function Type or Index Field 611: There may be different ways to measure the learning performance based on different loss functions. This loss function may be selected in pairs that are the same or related (i.e., have some dependencies) on different local devices. The list of possible loss functions may be predefined and indexed, and may be communicated to the local device.

[0147] The Start Gradient Index field 612 can be sorted using gradient indices. The gradients and their corresponding indices can both be known on the transmitter and receiver sides. This subfield indicates the start gradient index. With the presence of this subfield, along with the Total Gradients subfield 610, the range of gradients can be identified. Using this feature, the transmitter can collect partial gradient updates each time.

[0148] UL target RSSI field 614 can be used for UL power control, enabling transmissions from multiple STAs to reach the AP at similar power levels.

[0149] Multitasking flag field 616 can indicate the number of data streams allowed for an upcoming NDP PPDU. It can be represented as N SS.

[0150] A non-AP STA receiving an NFRP AI trigger box can use the following equation to calculate the number of LTF symbols in the NDP PDPU:

[0151] wherein N SC refers to the total number of subcarriers and N RU refers to the number of subcarriers in the RU indicated by the RU size sub-field.

[0152] The design shown in Figure 6A can be used by the AP to request gradient updates from any STA. In another instance, a set of selected STAs can be requested to send updated gradients. The following subfields (not shown in Figure 6A) can be added to the user information fields of the NFRP trigger box AI variant of Figure 6A. The Start AID subfield can indicate the start AID or minimum AID of the selected subset of STAs. The AID Number subfield can respond to the NFRP AI trigger box by providing STAs with an AID range in the range of [Start AID, Start AID + Number of AIDs – 1].

[0153] The NFRP trigger frame for the second ML / FL design is described below. This document describes at least two different formats for user information fields in the NFRP trigger frame. These formats can be used individually or in any combination. An example user information field of the NFRP trigger frame 618 is depicted in Figure 6B. As shown in Figure 6B, the NFRP user information field AI variant design II 618 may include a gradient quantization level field 620, a loss function type or index field 621, an LTF number field 622, an NDP number field 624, a feedback type field 626, and a UL target RSSI field 628.

[0154] The gradient quantization level field 620 specifies the number of quantization levels for the gradient of a given FL model parameter. Two or more bits can be used to encode the number of quantization levels. For example, gradient quantization level = 1 indicates that the gradient can have 3 values ​​(-1, 0, 1). In another instance, gradient quantization level = 2 indicates that the gradient can have 5 values ​​(-2, -1, 0, 1, +2). Therefore, the number of subcarriers required to transmit the gradient of a parameter can be derived from the same number of quantization levels. For example, gradient quantization level = 1 indicates that 3 subcarriers are needed to transmit the gradient value. Furthermore, the number of parameters that can be carried in one LTF symbol can be derived by considering the bandwidth used to transmit the NDP.

[0155] Regarding the loss function type or index field 621, there may be different ways to measure the learning performance based on different loss functions. This loss function may be selected in pairs that are the same or related (i.e., have some dependencies) on different local devices. The list of possible loss functions may be predefined and indexed, and may be communicated to the local device.

[0156] The LTF Count field 622 specifies how many LTFs are expected to come from each participating STA in this FL model update round. In some FL models, the number of parameters can be enormous, and this can utilize a large number of LTFs to transmit more FL model parameters than the participating STAs can handle.

[0157] The NDP Number field 624 specifies how many NDPs are expected to come from each STA in this triggering dialog. Since the number of LTFs in an NDP can be finite, multiple NDPs can be used to transmit subsequent parts of the FL model, where each NDP can carry a subset of the gradients of the FL model parameters. In response to the same NFRP triggering box depicted in Figure 7, a short interframe spacing (SIFS) (or any other interframe spacing) between them can be sent to subsequent NDPs.

[0158] The feedback type field 626 can specify the expected type of NFRP feedback as described above.

[0159] UL target RSSI field 628 can be used for UL power control, so that transmissions from multiple STAs can arrive at the AP at similar power levels.

[0160] The state of operation synchronization in federated learning is described below. A trigger box can be provided for FL Operational Parameter Report (FLOPR). Individual STAs can send their desired wake-up time, i.e., target wake-up time, and processing capacity, etc., to the AP. These parameter reports can be initiated or requested by the AP, sent by unrequested STAs, or sent without initiation or request. After receiving parameter reports from different STAs, the AP can make the following determinations (but are not limited to): the number of STAs that can be used in the same TWT period; STAs scheduled in the same TWT period; model runtime in STAs; requested updates from STAs, or similar, or any suitable combination thereof. The TWT service period (SP) after the sleep time can be used for FL updates, which include the latest training model update or training plan from the AP, or model updates from local devices (e.g., non-AP STAs).

[0161] An AP can use a trigger box to request one or more STAs to report operating parameters. The value of the trigger type subfield in the common information field of the EHT variant can be any value from 8 to 15. Figure 6C shows an exemplary trigger type subfield code for FL operating parameter reporting. In this example, it shows that when the trigger type subfield 630 value is 8, the corresponding trigger box type 632 is FL operating parameter reporting. The RA field of the FL operating parameter reporting trigger box can be set to a broadcast address or to the MAC address of the group requesting the operating parameters for it.

[0162] If requested operation parameters are shared across all STAs, they may be included in the trigger-dependent common information subfield 800 of the FL operation parameter report trigger box. Figure 8A depicts an exemplary trigger-dependent common information subfield of the FL operation parameter report trigger box. The parameters of the trigger-dependent common information subfield of the FL operation parameter report trigger box may include some or all of the information described herein. For example, the parameters may include TWT 802, which may request STA(s) to send TWT-related parameters (e.g., TWT elements). For example, if the value of the TWT subfield is 1, it may indicate that the AP requests the STA to send TWT-related parameters; if the value of the TWT subfield is 0, it may indicate that the AP does not request the STA to send TWT-related parameters. The parameters of the trigger-dependent common information subfield 800 may include available electronic power 804, which may request STA(s) to indicate whether they are operating with charge or battery pack. For example, if the value of the available electronic power subfield is 1, it may indicate that the AP requests the STA to indicate whether it is operating with battery pack. If the value of the available battery power subfield is 0, it indicates that the AP does not request the STA to indicate whether it is operating on battery power. If the STA is operating on battery power, the STA can indicate the remaining battery power level, such as high, medium, or low. Parameters triggering the dependent common information subfield 800 may include the ability to request the STA(s) to indicate, for example, whether there is an available dataset 806 for any new training data collected in the device during a certain period. Parameters triggering the dependent common information subfield 800 may include the ability to request the STA(s) to indicate processing power (e.g., how many GPUs are available in the STA) 808. For example, if the value of the processing power subfield is 1, it indicates that the AP may request the STA to indicate processing power (e.g., the number of available GPUs in the STA). If the value of the available processing power field is 0, it indicates that the AP does not request the STA to indicate processing power. Parameters triggering the dependent common information subfield 800 may include the ability to request the STA(s) to provide feedback on an updated training model or an updated training model with updated parameters 810. For example, if the value of the "Updated Training Model" subfield is 1, it instructs the AP to request the STA to send the updated training model (or training model parameters). If the value of the "Updated Training Model" subfield is 0, it instructs the AP not to request the STA to send any updated training model (or training model parameters).

[0163] If the parameter value of the triggering dependent common information subfield 800 is indicated as 1, for example, it means that the corresponding parameter is requested; if the parameter value is indicated as 0, it means that the corresponding parameter is not requested. For example, if the triggering dependent common information subfield is 11010, it means that TWT, available electronic power, and processing power are requested from all STAs; if the triggering dependent common information subfield is 00001, it means that the updated training model (or updated training model parameters) is requested from all STAs.

[0164] Requested parameters may also be included in the trigger-dependent user information subfield, such as the HE variant user information field, the EHT variant user information field, and the special usage information field. Additionally, this type of trigger box can also be used as an indication to transmit the training model in the next incoming PPDU (e.g., EHT MU PPDU). For example, if all parameter values ​​are equal to 0, it may mean that an STA report is not required and the latest updated training model is delivered. The trigger box can also be used as an indication of a training plan from the AP.

[0165] More types of operational information may be requested from the AP. Therefore, the length or content of the trigger dependent common information subfield or the trigger dependent user information subfield may differ from that depicted in Figure 8A.

[0166] Processing capabilities may be included in non-AP STA capability elements. For example, an exemplary EBCS parameter element format for FL is depicted in Figure 8B. The FL / ML parameter sub-column 820 depicted in Figure 8B may indicate the machine learning (ML) capabilities of a non-AP STA. Processing capabilities may be reported from a non-AP to an AP in any appropriate manner. For example, processing capabilities may be included in a response to a trigger box sent from an AP. Processing capabilities may be included in capability elements that may be reported to an AP when a non-AP STA is associated with an AP.

[0167] An exemplary format of the machine learning parameter field 820 for a non-AP STA is depicted in FIG8C. The machine learning parameter field 820 may include a machine learning support field 822. The machine learning support field 822 may include one or more bits to indicate whether the STA supports machine learning. For example, the machine learning support field 822 may include 1 bit, where 1 indicates that machine learning is supported and 0 indicates that machine learning is not supported. The machine learning parameter field 820 may include a processing power field 824. The processing power field 824 may include one or more bits to indicate the processing power of the STA. For example, the processing power field 824 (e.g., 2 bits) may indicate the number of GPUs or other relevant processing power of the STA. The number of bits used for processing power is not limited to 2. Other ML-related parameters 826 may be provided in the machine learning parameter field 820.

[0168] Machine learning parameters can be negotiated between AP and non-AP STAs during TWT setup or negotiation phase using enhanced TWT elements. For example, one or more fields / subfields described herein can be carried in enhanced TWT elements(s). In another instance, one or more fields / subfields described herein can be carried in ML / FL model shared publishing box 402 and / or ML / FL support indicator box 422.

[0169] Some embodiments may provide enhanced TWT operations, such as group TWT operations for FL. In one embodiment, one or more STAs may request training model exchange or training model parameter exchange via a TWT procedure. The TWT time for requesting an STA and the number of STAs scheduled for the next TWT period may be determined by the AP. An example of a group TWT operation is depicted in FIG9, where AP 902 is a TWT response to an STA, and STA1 904, STA2 906, STA3 908, and STA4 910 are TWT requests to STAs. Although group TWT operations are described as being used for FL training model updates, they are not limited thereto and are applicable to other use cases.

[0170] Figure 9 illustrates an example of a group TWT operation for training model updates. In this example, STA1 904 may send an enhanced TWT request 912 to TWT response STA 902 to set a trigger-enabled TWT protocol for training model updates. TWT response STA 902 may receive the TWT protocol with STA1 904 and may acknowledge receipt in TWT response 914 sent to STA1 904. Prior to the next TWT for STA1 904, TWT response STA 902 may receive another TWT request 916 from STA2 906 to set a trigger-enabled TWT protocol for training model updates. TWT response STA 902 may receive the TWT protocol with STA2 906 and may acknowledge receipt in TWT response 918 sent to STA2 906. Subsequently, the TWT responds to STA 902 by sending an unrequested TWT as a published TWT 919, which can be received by multiple STAs, such as STA3 908 and STA4 910.

[0171] During the trigger activation of the TWT service cycle (SP) 930, STA 902 may send a federated learning operational parameter report (FLOPR) trigger box or a basic trigger box 928 to a TWT request STA that may instruct it to wake up during the TWT SP. For example, in response to FLOPR or basic trigger box 928, STA1 904 and STA2 906 may instruct them to wake up by sending respective PS-polling boxes 920 and 922, and STA3 908 and STA4 910 may instruct them to wake up by sending respective QoS empty boxes 924 and 926 (depicted as message unit (MU) physical layer protocol data unit (PPDU) in FIG9). In another example, AP 902 may request FL-related information from STA3 908 and STA4 910, such as available electronic power, available dataset, processing power, or desired TWT, and STA3 908 and STA4 910 may send the requested information to AP 902. STA1 to STA4 904, 906, 908, and 910 may receive individual DL bufferable units (BUs) (e.g., updated channel models or training plans) in subsequent exchanges with TWT response STA 902, and go to a sleep state outside this TWT SP.

[0172] During the first triggered TWT service cycle (SP) 930 for training model updates, a response STA 902 (e.g., AP) may indicate to STAs 904, 906, 908, and 910 that another triggered TWT SP will be activated subsequently. This indication may be carried in a training model update or training plan sent by the AP. If the indication is sent to the STA, another TWT SP 932 may be facilitated via an unrequested TWT setting as a published TWT, which may be sent to STAs 1 through 4 904, 906, 908, and 910. During the "doze" time 929 of this cycle, the STAs may perform local training and receive training updates. When the second TWT SP 932 arrives, it may be designed so that these STAs 904, 906, 908, and 910 report their updated training models as requested by the AP. The TWT SP 932 may be referred to as a training model update from the STA.

[0173] Some embodiments provide enhanced broadcast TWT operation for FL. Broadcast TWT operation for FL can be enabled if the TWT scheduling AP indicates its support for ML / FL in its capability element, and the TWT via scheduling STA sets ML or FL support in its capability element. An example of broadcast TWT operation is shown in Figure 10. In this example, the AP is a TWT scheduling AP that supports ML / FL, and STA1 and STA2 are TWT via scheduling STAs that support ML / FL.

[0174] Figure 10 illustrates an example of a broadcast TWT operation for FL. In Figure 10, STA1 can negotiate a "sleep" time with AP. During this negotiation, STA1 can send an enhanced TWT request 1002 to the Target Beacon Target Time (TBTT) scheduling AP via an enhanced TWT request. This enhanced TWT request may include, but is not limited to, the following ML / FL related parameters: available electronic power, such as how much battery power remains in the system or whether it is charging; available dataset, such as how much data is available to train the model; available processing power, such as how many GPUs are available to process the current dataset; evaluation training time (e.g., how long to obtain training results) or similar or any suitable combination thereof.

[0175] The TBTT scheduling AP that receives a TWT request from the STA may send an enhanced TWT response (e.g., response 1004 depicted in Figure 10) to STA1. This enhanced TWT response may include, but is not limited to, sending a TWT time for updating the trained model or training plan. The TWT scheduling AP may include an enhanced broadcast TWT element in the beacon box, which indicates that the AP may intend to send a trigger box or DL ​​BU to the broadcast TWT SP of the TWT scheduling STA during its period.

[0176] During the Trigger Activation Service Cycle (SP) 1006, the AP may send a basic trigger box in which STA1 and STA2 indicate that they should be woken up during the TWT SP. The AP may also send a FLOPR trigger box 1010 to request STA1 and STA2 to send FL / ML operation parameters. Because STA1 sends an enhanced TWT request before SP 1006, it can send the FL / ML operation parameters to the AP via the enhanced TWT request. STA1 may indicate that it should be woken up by sending a PS-polling. STA may send a MU PPDU carrying the FL / ML operation parameters requested by the AP. STA1 and STA2 may receive the latest training model and / or training plan from the AP via DL MU PPDU 1012 after the AP sends ACK 1014 to STA1 and STA2. In a next beacon, the AP may indicate another TWT for triggering SP 1008, which can be used to collect model updates from STA1 and STA2. STA1 and STA2 can enter a "sleep" state outside of TWT SPs 1006 and 1008. During the "sleep" state between these two SPs, STA1 and STA2 can perform local machine learning training.

[0177] Example embodiments may provide enhanced broadcast TWT operations. Another example of using broadcast TWT to update model parameters is shown in Figure 11. The ML / FL parameter negotiation phase 1102 can be performed using enhanced TWT request / response boxes (1104, 1106). In one example embodiment, the enhanced TWT element may carry information related to ML / FL parameters.

[0178] Beacon frame 1108 may carry a TWT element including one or more TWT parameter sets. The TWT parameter sets may indicate TWT SPs used to carry ML / FL model update / gradient update parameters. For example, as shown in Figure 11, two TWT parameter sets (1110, 1112) may be included in the TWT element transmitted in the beacon frame. Each TWT parameter set may correspond to a TWT that can be used to carry a group or subset of ML / FL model parameters.

[0179] A TWT SP can be published such that a non-AP STA may need to transmit a PS-polling or other type of frame to indicate that it may be in a wake-up state, or transmit an unpublished TWT, in which a non-AP STA may not indicate that it may be in a wake-up state. Different frame exchanges are allowed in different TWT SPs.

[0180] The enhanced TWT element for FL is described below with reference to FIG11. In one example embodiment, a variant of the TWT element can be used for FL communication. As shown in FIG11, during TWT SP 1 1110 (posted TWT), the AP may transmit a basic trigger frame 1114 and the STA may respond with a PS-polling frame or a QoS empty frame or other types of frames (1116, 1118) to indicate that it is in a wake-up state. The AP may transmit another trigger frame 1120 to request an ML / FL update. The trigger frame and response frame may be the NFRP and NDP frames disclosed above, or the FLOPR-related frame exchanges discussed below.

[0181] During TWT SP 2 1112 (unreleased TWT), the AP may transmit a trigger box 1122 to request an ML / FL update. The trigger box and response box may be connected to the NFRP and NDP boxes disclosed above, or exchanged with the FLOPR-related boxes discussed above.

[0182] In one example embodiment, variations of the TWT element can be used in FL communication. FIG12A depicts an exemplary control field format 1202 for variations of the TWT element. B0 to B7 represent identifiers of bits included in the respective subfields. As depicted in control field 1202, an enhanced TWT subfield 1204 may be included to indicate whether it is used for FL TWT operation. For example, enhanced TWT subfield 1204 may include one or more bits (e.g., 1) identified as B7 indicating its use for FL TWT operation. Enhanced TWT subfield 1204 may include one or more bits (e.g., 0) identified as B7 indicating its non-use for FL TWT operation. When enhanced TWT subfield 1204 is 1, for example, it may indicate its use for FL TWT operation. TWT parameter information subfields in a TWT element may follow the FL TWT parameter set field format.

[0183] In one example embodiment, the format of the enhanced group TWT parameter set field can be as depicted in Figure 12B. Machine learning parameters can be added. If the enhanced TWT subfield in the control field of the TWT element is 1, then the machine learning parameter field in the enhanced group TWT parameter set can have values ​​in the machine learning parameter subfield, which can include ML-related parameters, such as available dataset, available power, available processing power, etc.

[0184] Figure 12C depicts an exemplary enhanced group TWT parameter set field format for FL. If the enhanced TWT subfield in the control field of a TWT element is 1, then the machine learning parameter field in the enhanced broadcast TWT parameter set may have values ​​in the machine learning parameter subfield, which may include ML-related parameters, such as available dataset, available power, available processing power, etc.

[0185] The Broadcast TWT Suggestion field may be included in the Request Type subfield of the Enhanced Broadcast TWT Parameter Set field. A variant of the Broadcast TWT Suggestion field for the Broadcast TWT element is depicted as an example in Figure 13A.

[0186] An example of a variant of the broadcast TWT information subfield format is depicted in Figure 13B. When the ML / FL traffic information subfield is included in the broadcast TWT information subfield, it can be set to 1 to indicate that the machine learning parameter field is present; otherwise, it is set to 0.

[0187] Example embodiments may utilize the FL device report control field. In one example embodiment, the STA reporting operating parameters, etc., to the AP may indicate the type of operating parameters included in the report, etc. The FL device report control field is described below. Figure 14 depicts an exemplary FL device report control field format. In one example embodiment, if the TWT suggested parameter is included, the TWT value may be 1; otherwise, the TWT value may be 0.

[0188] Instance codes for available electronic power values ​​are depicted in Figure 15A. Instance codes for available dataset values ​​are depicted in Figure 15B. In Figure 15B, extremely low, low, and high values ​​may be related to the implementation scheme. Instance codes for processing capacity values ​​are depicted in Figure 15C. In one example embodiment, if updating the training model is included, the updated training model value may be 1; otherwise, the updated training model value may be 0.

[0189] Please note that all numbers shown in the description in the table above are illustrative. They may vary depending on the implementation. Although the features and elements of the invention are described in preferred embodiments in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiments, or in various combinations with or without other features and elements of the invention.

[0190] While the solutions described herein take into account the 802.11-specific protocol, it should be understood that the solutions described herein are not limited to this scenario and can also be applied to other wireless systems. Although SIFS is used to indicate various inter-frame spacings in examples of design and procedures, all other inter-frame spacings (such as RIFS, AIFS, DIFS) or other agreed time intervals can be applied in the same solution. Although the four RBs that trigger TXOP are shown as examples in some diagrams, the actual number of RBs / channels / bandwidths utilized can vary.

[0191] While features and elements in specific combinations are provided above, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not intended to be limited to specific embodiments of various forms described in this application. Many modifications and variations can be made without departing from its spirit and scope, which will be apparent to those skilled in the art. Thus, unless expressly provided, elements, actions, or instructions used in the description of this application should not be construed as critical or necessary to the invention. In addition to those enumerated herein, functionally equivalent methods, apparatus, and articles of manufacture within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the language of the appended claims, together with the full scope of their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0192] Although the foregoing embodiments may be discussed in connection with specific terms and structures (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.) for the sake of simplicity, the embodiments discussed are not limited thereto and can be applied to other systems that use, for example, other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0193] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or "imagery" may mean any snapshot, single image, and / or multiple images displayed on a time-based, or similar, or any suitable combination thereof. As another example, when referenced herein, the term "user equipment" and its abbreviation "UE", the term "remote", and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device having wireless and / or wired (e.g., wired) capabilities, particularly configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless and / or wired capabilities, configured with less than all the structure and functionality of a WTRU; or (iv) the like. Examples of any WTRU described herein may be represented by Figures 1A through 1D provided herein. As another example, the various disclosed embodiments described herein utilize a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and accordingly, some or all of the disclosed embodiments can be modified without excessive experimentation. Examples of such other devices may include drones or other devices that configure streaming information for providing adapted reality experiences.

[0194] Additionally, the methods provided herein can be incorporated into computer-readable media for implementation in computer programs, software, or firmware executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media other than signals include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-RAM discs and digital versatile disks, DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0195] Variations of the methods, apparatus, articles of manufacture, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery pack or the like) providing any suitable voltage.

[0196] Furthermore, in the embodiments provided herein, references are made to processing platforms, computing systems, controllers, and other devices containing processors. These devices may contain at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memory. Such actions and operations or instructions may be referred to as “executed,” “computer executed,” or “CPU executed.”

[0197] Those skilled in the art will understand that actions and symbolically represented operations or instructions include manipulating electrical signals by the CPU. An electrical system represents the result of which can cause changes or degradation of electrical signals and the maintenance of data bits at memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0198] Data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by the CPU. Computer-readable media may include cooperative or interconnected computer-readable media that exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local to or remote from the processing system. It should be understood that the embodiments are not limited to the memory mentioned above, and other platforms and memories may support the provided methods.

[0199] In one illustrative embodiment, any of the operations, programs, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of an action unit, network element, and / or any other computing device.

[0200] The foregoing embodiments have been described using block diagrams, flowcharts, and / or examples to illustrate various embodiments of the apparatus and / or program. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that the functions and / or operations within such block diagrams, flowcharts, or examples can be implemented individually or collectively by various hardware, software, firmware, or virtually any combination thereof. In exemplary embodiments, several parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated circuit forms. Those skilled in the art will recognize that some of the embodiments disclosed herein can be implemented, either wholly or partially, in an integrated circuit equivalent as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and will recognize that designing circuit systems and / or writing software and / or firmware code according to this disclosure will be entirely within the scope of the art of those skilled in the art. Those skilled in the art will understand that the mechanisms of the subject matter disclosed herein can be distributed in various forms of program products, and will understand that the illustrative embodiments of the subject matter disclosed herein are applied independently of any particular type of signal-bearing medium used for actual implementation. Examples of signal-carrying media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.) and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0201] Those skilled in the art will recognize that the devices and / or programs described herein are common in the art, and engineering practices are used below to integrate such devices and / or programs into data processing systems. That is, at least a portion of the devices and / or programs described herein can be integrated into a data processing system through reasonable experimentation. Those skilled in the art will recognize that a typical data processing system generally includes a system unit housing, a video display device, memory (such as volatile and non-volatile memory), a processor (such as a microprocessor and a digital signal processor), computing entities (such as an operating system, driver, graphical user interface, and application), one or more interactive devices (such as a touchpad or screen), and / or a control system including one or more feedback loops and control motors (e.g., feedback sensing of position and / or speed, movement and / or adjustment components, and / or quantity control motors). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or networking / communication systems.

[0202] The subject matter described herein sometimes refers to different components contained within or connected to such other components. It should be understood that the architectures thus depicted are merely examples, and in fact, many other architectures can be implemented to achieve the same functionality. Conceptually, any configuration of components that achieve the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components of this document combined to achieve a particular functionality can be considered as "associated with" each other, so that the desired functionality can be achieved regardless of the architecture or intermediate components. Similarly, any two such associated components can be considered as "operably connected" or "operably coupled" each other to achieve the desired functionality, and any two components that can be suchly associated can be considered as "operably coupled" each other to achieve the desired functionality. Specific examples of operatively coupled components include, but are not limited to, components that can be physically paired and / or physically interact and / or wirelessly interact and / or logically interact and / or logically interact.

[0203] Regarding the use of any substantial plural and / or singular terms in this document, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural forms depending on the context and / or application. For clarity, various singular / plural arrangements are explicitly described herein.

[0204] Those skilled in the art will understand that the terms used herein and particularly in the appended claims (e.g., the subject of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "include" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number described in the introduced claim is intended, such intention will be explicitly stated in the claim, and the absence of such a statement indicates the absence of such intention. For example, the term "single" or similar language may be used where only one item is intended. As a supplementary understanding, the appended claims and / or the description herein may contain the use of the leading phrases "at least one" and "one or more" to introduce the claim description. However, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles (such as "a" or "an" (e.g., "a" or "an" should be interpreted as meaning "at least one" or "one or more")), the use of such phrases should not be interpreted as meaning that the claim statement introduced by the indefinite article "a" or "an" limits any particular claim containing such an introductory claim statement to an embodiment containing only one such statement. This usage of the definite article used to introduce the claim statement is also true. Furthermore, even if a specific number of the introduced claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least that number of statements (e.g., a bare recitation of "two statements" without other modifiers means at least two statements, or two or more statements).Furthermore, in cases where a convention similar to "at least one of A, B, and C, etc." is used, this construction is generally intended to make the convention understandable to those with ordinary knowledge in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). In cases where conventions such as "at least one of A, B, or C" are used, this construction is generally intended to make the convention understandable to those skilled in the art (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). Those skilled in the art will further understand that any transitional word or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B". Furthermore, as used herein, the term "any of" following a list of multiple items and / or multiple categories of items is intended to individually or in combination with other items or categories of items to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of" of such items and / or categories of items. Additionally, as used herein, the term "set" is intended to include any number (including zero) of items. Furthermore, as used herein, the term "number" is intended to include any number (including zero). And as used herein, the term "multiple" is intended to be synonymous with "a plurality."

[0205] Furthermore, since the features or characteristics of this disclosure are described in accordance with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush group.

[0206] As will be understood by one of ordinary skill in the art, for any and all purposes, such as for providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope may be readily considered sufficient to describe and enable the decomposition of the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, the scopes discussed herein may be readily decomposed into the lower third, middle third, and upper third, etc. Also, as will be understood by one of ordinary skill in the art, all language such as "up to," "at least," "greater than," "less than," and the like includes the stated numbers and may refer to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as will be understood by one of ordinary skill in the art, a scope includes individual members. Thus, for example, a group having 1 to 3 cells refers to multiple groups having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to multiple groups having 1, 2, 3, 4, or 5 cells, and so on. [Simplified Explanation of the Diagram]

[0015] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein similar element symbols in the drawings indicate similar elements, and wherein: [Figure 1A] is a system diagram illustrating one or more example communication systems that may be implemented according to the disclosed embodiments; [Figure 1B] is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 1C] is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 1D] is a system diagram illustrating a further example RAN and a further example CN that may be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 2A] illustrates an example target wake-up time (TWT) element format according to an embodiment; [Figure 2B] illustrates an example control field format according to an embodiment; [Figure 2C] illustrates an example TWT parameter set field format according to an embodiment; [Figure 2D] illustrates the TWT parameter set field format according to an example of an embodiment; [Figure 3] is an example diagram illustrating how gradient descent acts on a parameter w according to an embodiment; [Figure 4A] illustrates an example design of a shared publishing box for ML / FL models according to an embodiment; [Figure 4B] illustrates an example design of an ML / FL support indicator box according to an embodiment; [Figure 4C] depicts an example flowchart of a procedure for implementing federated / machine learning in a wireless network.[Figure 5] Illustrate an exemplary procedure for triggering Null Data Packet Feedback Report Polling (NFRP) and feeding back null data packets (NDPs) for machine learning gradient reporting according to an embodiment; [Figure 6A] Illustrate an AI variant design of an example NFRP user information field according to an embodiment; [Figure 6B] Illustrate an example NFRP user information field variant for joint learning according to an embodiment; [Figure 6C] Illustrate an exemplary trigger type subfield encoding for FL operation parameter reporting according to an embodiment; [Figure 7] Illustrate an example procedure for updating an FL model using several NDPs in the same trigger dialog according to an embodiment; [Figure 8A] Illustrate an exemplary trigger dependent common information subfield of an FL operation parameter reporting trigger box according to an embodiment; [Figure 8B] Illustrate an exemplary EBCS parameter element format for FL according to an embodiment; [Figure 8C] Illustrate an exemplary format for machine learning parameter fields for non-AP STA according to an embodiment; [Figure 9] Illustrate an example of a group TWT operation for training model updates according to an embodiment; [Figure 10] Illustrate an example of a broadcast TWT operation for FL according to an embodiment; [Figure 11] Illustrate an alternative example of a broadcast TWT operation for FL / ML according to an embodiment; [Figure 12A] Illustrate an exemplary control field format for a variant of a TWT element according to an embodiment; [Figure 12B] Illustrate an exemplary enhanced group TWT parameter set field format for FL according to an embodiment; [Figure 12C] Illustrate an exemplary enhanced broadcast TWT parameter set field for FL according to an embodiment; [Figure 13A] Illustrate an example variant of a broadcast TWT suggestion field for broadcast TWT elements according to an embodiment; [Figure 13B] Illustrate an example variant of a broadcast TWT information subfield format according to an embodiment; [Figure 14] Illustrate an exemplary FL device control field format according to an embodiment; [Figure 15A] Illustrate an exemplary encoding of available electronic power values ​​according to an embodiment; [Figure 15B] illustrates an exemplary encoding of the available dataset values ​​according to an embodiment; and [Figure 15C] illustrates an exemplary encoding of the processing capability values ​​according to an embodiment.

Claims

1. A method performed by a first station, the method comprising: receiving a learning model publishing frame via an access point (AP) associated with a basic service set (BSS) in a wireless local area network (WLAN), the learning model publishing frame including an instruction for a model sharing procedure; transmitting a support frame in response to the learning model publishing frame, the support frame including an instruction for participating in the model sharing procedure, the support frame including a set of parameters associated with a first model; and updating the first model at least based on the learning model publishing frame after transmitting the support frame.

2. The method of claim 1, wherein the first model comprises at least one of a joint learning (FL) model or a machine learning (ML) model.

3. The method of request item 1, further comprising: receiving a second support box from a second station, the second support box containing a second set of parameters associated with a second model; and updating the first model based at least on either the model publishing box or the second set of parameters.

4. The method of request item 1, wherein the model publishing box includes publishing parameters, the publishing parameters including at least one of a model identifier (ID), a number of model layers, or a number of weights for each layer, the method further comprising: configuring the first station to update the first model according to the publishing parameters.

5. The method of request item 1, wherein the learning model publishing frame includes at least one of an uplink (UL) schedule or a downlink (DL) schedule, the method further comprising: configuring the first station to transmit and receive according to at least one of the UL schedule or the DL schedule.

6. The method of request item 5 further includes: receiving a trigger box; and responding to receiving the trigger box, sharing the same set of parameters.

7. The method of request item 6 further includes responding to receiving the trigger box by sharing the set of parameters according to at least one of the UL schedule or the DL schedule.

8. The method of request item 1, further comprising: receiving a gradient update for the first model; and configuring the first station to update the first model according to the received gradient update.

9. The method of claim 1, further comprising: training the first model; and transmitting the training result of the first model.

10. The method of claim 1, further comprising: receiving a message containing a target wake-up time (TWT); and configuring the first station to receive training parameters for the first model during the TWT.

11. A first station comprising a transceiver and a processor configured to: receive, via the transceiver and via an access point (AP) associated with a basic service set (BSS) in a wireless local area network (WLAN), a learning model publishing frame including an instruction for a model sharing procedure; transmit, via the transceiver and in response to the learning model publishing frame, a support frame including an instruction for participating in the model sharing procedure, the support frame including a set of parameters associated with a first model; and, after transmitting the support frame, update the first model at least based on the learning model publishing frame.

12. The first platform of request item 11, wherein the first model comprises at least one of a joint learning (FL) model or a machine learning (ML) model.

13. As in the first station of request item 11, the processor is further configured to: receive a second support frame from a second station via the transceiver, the second support frame containing a second set of parameters associated with a second model; and update the first model based at least on either the model release frame or the second set of parameters.

14. As in the first station of request item 11, wherein the model publishing box includes publishing parameters, the publishing parameters including at least one of a model identifier (ID), a number of model layers, or a number of weights for each layer, the processor is further configured to: configure the first station to update the first model according to the publishing parameters.

15. As in the first station of request item 11, wherein the learning model publishing frame includes at least one of an uplink (UL) schedule or a downlink (DL) schedule, the processor is further configured to: configure the first station to transmit and receive according to at least one of the UL schedule or the DL schedule.

16. As in the first station of request item 15, the processor is further configured to: receive a trigger frame via the transceiver; and respond to receiving the trigger frame by sharing the same set of parameters.

17. As in the first station of request item 16, the processor is further configured to respond to receiving the trigger box and share the set of parameters via the transceiver according to at least one of the UL schedule or the DL schedule.

18. As in the first station of request item 11, the processor is further configured to: receive a gradient update for the first model via the transceiver; and configure the first station to update the first model based on the received gradient update.

19. As in the first station of request item 11, the processor is further configured to: train the first model; and transmit the training results of the first model via the transceiver.

20. As in the first station of request item 11, the processor is further configured to: receive a message containing a target wake-up time (TWT) via the transceiver; and configure the first station to receive training parameters for the first model during the TWT.

Images