Methods and apparatuses directed to blockchain-enabled model storage, sharing and deployment for supporting distributed learning

Abstract

This invention provides programs, methods, architectures, devices, systems, apparatuses, and computer programs for storing, sharing, and deploying blockchain-enabled models to support federated learning. One of these methods relates to a method for blockchain-enabled storage of decentralized learning data, which may include: receiving information instructing a blockchain storage request, including information associated with a decentralized learning task; obtaining information identifying one or more blockchains based on a blockchain storage solution, wherein the blockchain storage solution is based on the information instructing the blockchain storage request; determining blockchain-related instructions based on the blockchain storage solution, wherein the blockchain-related instructions include at least some of the information identifying one or more blockchains; and transmitting the blockchain-related instructions to a plurality of decentralized participant nodes.

Description

[Technical Field]

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 161,194, filed March 15, 2021, which is incorporated herein by reference. This application relates to (i) International Application No. PCT / US2021 / 039967, filed June 30, 2021, which claims priority to U.S. Provisional Patent Application No. 63 / 045,835, filed June 30, 2020; and International Application No. PCT / US2021 / 039971, filed June 30, 2021, which claims priority to U.S. Provisional Patent Application No. 63 / 045,857, filed June 30, 2020; all of which are incorporated herein by reference.

[0003] This application relates to wired and / or wireless communications, including, for example, methods, architectures, devices, and systems for storing, sharing, and deploying blockchain-enabled models to support federated learning. [Previous Technology]

[0004] None [Summary of the Invention]

[0005] None

Implementation Method

[0007] In the following embodiments, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without using some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may replace or be incorporated into embodiments and other example practices described, disclosed, or otherwise expressly, implicitly, and / or inherently provided herein (collectively, the "provided"). While various embodiments in which devices, systems, apparatuses, etc., and / or any of their elements perform operations, programs, algorithms, functions, etc., and / or any of their parts are described and / or claimed herein, it should be understood that any embodiments described and / or claimed herein assume that any device, system, apparatus, etc., and / or any of its elements are configured to perform any operations, programs, algorithms, functions, etc., and / or any of their parts. Example Communication System

[0008] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Figures 1A to 1D provide an overview of various types of wireless devices and infrastructures, in which various network elements can utilize, perform, configure, and / or adapt and / or configure for use with the methods, apparatus, and systems provided herein.

[0009] Figure 1A is a diagram of an example communication system 100 that may be implemented in one or more of the disclosed embodiments. The example communication system 100 is provided for illustrative purposes only and is not intended to limit 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 (ZT) unique-word (UW) discrete Fourier transform (DFT) extended OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and similar methods.

[0010] As shown in FIG1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the 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 any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include (or be) user equipment (UE), mobile radio, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, laptop computer, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., remote surgery), industrial device and application (e.g., robot and / or other wireless device operating in the context of industrial and / or automated processing chains), consumer electronics device, device operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be referred to as WTRUs interchangeably.

[0011] 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, for example, to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), Home Node-B (HNB), Home eNode-B (HeNB), gNode-B (gNB), NR Node-B (NR NB), station controller, access point (AP), wireless router, 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.

[0012] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which 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. A cell may provide coverage for a specific geographic area that may be relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0014] More specifically, as mentioned above, the communication system 100 may be a multi-access system and may employ one or more 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 / 113 may implement radio technologies, such as using wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) on air interfaces 115 / 116 / 117. 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).

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

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

[0017] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technology, such as using New Radio (NR) to establish NR radio access to the air interface 116.

[0018] 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., eNB and gNB).

[0019] In other embodiments, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity, Wi-Fi), 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.

[0020] 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 one embodiment, base station 114b and WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: small cell, picocell, or femtocell. 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 / 115.

[0021] RAN 104 / 113 can communicate with CN 106 / 115 and can be configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to any type of network of one or more WTRU 102a, 102b, 102c, 102d. Data may 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 / 115 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 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 (which may utilize NR radio technology), CN 106 / 115 can also communicate with another RAN (not shown) that uses any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi.

[0022] CN 106 / 115 may also function as a gateway for WTRU 102a, 102b, 102c, 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 Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired 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 / 114 or a different RAT.

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

[0024] Figure 1B is a system diagram of example WTRU 102. Example WTRU 102 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. As shown in Figure 1B, WTRU 102 may include, in particular, 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 other peripheral devices 138. It will be understood that WTRU 102 may include any combination of the above elements while remaining consistent with one embodiment.

[0025] Processor 118 may be a general-purpose processor, special-purpose processor, conventional processor, digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, controller, microcontroller, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), 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, for example, in an electronic package or on a chip.

[0026] 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 an antenna configured 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 one 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.

[0027] Additionally, 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. For example, 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.

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

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

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

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

[0032] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photographs or videos), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulated (FM) radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral device 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0033] 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 downlink (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 downlink (e.g., for reception) for which transmission and reception may be half-duplex radio.

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

[0035] 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 receive radio signals from the WTRU.

[0036] 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 the uplink (UL) and / or downlink (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.

[0037] The core network 106 shown in FIG1C may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part 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.

[0038] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c 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, 102c, and similar devices, enabling / disabling bearers, and selecting specific service gateways during the initial attachment of WTRUs 102a, 102b, 102c, and similar devices. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0039] 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 / from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-eNode-B handover, triggering calls and / or mobile terminals when DL data is available to WTRUs 102a, 102b, and 102c, managing and storing the background of WTRUs 102a, 102b, and 102c, and the like.

[0040] SGW 164 can also be connected to PDN gateway 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.

[0041] CN 106 may facilitate communication with other networks. For example, CN 106 may provide access to circuit-switched networks (such as PSTN 108) to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 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 access to other networks 112 to WTRUs 102a, 102b, and 102c, such other networks may include other wired or wireless networks owned and / or operated by other service providers.

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

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

[0044] In an infrastructure basic service set mode, a WLAN may have an access point (AP) for the basic service set 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 basic service set. Traffic originating outside the basic service set and destined for STAs can be delivered to those STAs via the AP. Traffic originating from STAs and destined for destinations outside the basic service set can be sent to the AP for delivery to individual destinations. Traffic between STAs within the basic service set 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 a destination STA. Traffic between STAs within the basic service set 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 may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using the Independent Basic Service Set (IBS) mode may not have an access point (AP), and STAs within the IBS or using the IBS (e.g., all STAs) can communicate directly with each other. The IBS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0045] 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 via communication. The primary channel can be the operating channel of the basic service set and can be used by STAs to establish connections 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 go offline. A STA (e.g., only one station) can transmit at any given time within a given basic service set.

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

[0047] The Very High Throughput (VHT) STA supports channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. 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 passed 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 transport 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).

[0048] The 1 GHz operating sub-mode is supported by 802.11af and 802.11ah. The 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 bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths 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).

[0049] 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 may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the basic service set. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the basic service set. In the 802.11ah example, even if the AP and other STAs in the basic service set support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes, the primary channel may 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 may 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, even if most of the frequency band remains idle and available, the entire available frequency band can be considered busy.

[0050] In the United States, the available frequency band (which can be used by 802.11ah) ranges from 902 MHz to 928 MHz. In South Korea, the available frequency band ranges from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band ranges 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.

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

[0052] RAN 113 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 113 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 unlicensed spectrum, while the remaining component carriers may be on 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).

[0053] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable parameter set (numerology). For example, the 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).

[0054] 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 unlicensed frequency bands 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 mobile anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for servicing WTRU 102a, 102b, and 102c.

[0055] GNBs 180a, 180b, and 180c can each 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, dual connectivity, interoperability between 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.

[0056] CN 115 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 at least one Data Network (DN) 185a, 185b. Although each of the above elements is depicted as part of CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 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 packet 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, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by 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 / or similar. AMF 162 can provide control plane functions for switching between RAN 113 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 Wi-Fi).

[0058] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure the routes of traffic passing 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 downlink data notifications, and the like. PDU conversation types can be IP-based, non-IP-based, Ethernet-based, and the like.

[0059] UPF 184a, 184b can be connected via an N3 interface to one or more gNB 180a, 180b, 180c in RAN 113. This interface can provide access to packet-switched networks (such as Internet 110) to WTRU 102a, 102b, 102c, for example, 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 downlink packets, providing mobility anchoring, and the like.

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

[0061] In view of the corresponding descriptions in Figures 1A to 1D, one or more or all of the functions described herein related to any of the following can be performed by one or more emulation elements / 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 element(s) / device(s) described herein. Emulation devices can be configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0062] The emulation device may 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 emulation devices may 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 emulation devices may 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 emulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform the test.

[0063] One or more emulation devices can perform one or more (including all) functions while not being implemented / deployed as a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios in test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform tests on one or more components. One or more emulation devices may 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 emulation device to transmit and / or receive data. (Introduction to Blockchain Technology)

[0064] Blockchain technology collectively utilizes and builds upon various existing technologies, such as cryptography, hashing, Merkle trees, decentralized ledgers, peer-to-peer (P2P) networks, and consensus protocols. Blockchain technology innovatively combines these existing technologies to achieve systems that provide advanced features such as decentralization, immutability, transparency, and security.

[0065] A blockchain system is a system that utilizes blockchain technology. Applications supported by a blockchain system are called blockchain applications. A blockchain system is supported by one or more basic blockchain networks. Each blockchain network may include a plurality of (e.g., many) participating blockchain nodes (BCNs). Each BCN can host one or more decentralized blockchains (in the form of a decentralized ledger), broadcast blocks using a P2P network, and execute consensus protocols with other BCNs in the blockchain network to achieve decentralized trust and data consistency without relying on a centralized party.

[0066] A blockchain transaction can be any digital representation of a real-world transaction, a digital record of physical assets, a digital record of physical events, a digital record of any action in an information system, a digital payment, or any digital smart contract. A block groups multiple blockchain transactions together. A blockchain is a data structure and is an ordered, growing number of cryptographically linked blocks. Blockchain and blockchain data structure are interchangeable terms.

[0067] Figure 2 illustrates an example workflow of a blockchain system. The workflow may include initiating a transaction (1), broadcasting and verifying the transaction (2), creating a new block (3), verifying the new block based on the consensus protocol (4), and updating the blockchain (5).

[0068] Initiating a Transaction: Each participating user can independently generate a new transaction. Each user can have a user identifier and / or an account identifier. The user identifier and / or account identifier can be a hash of the user's public key. Each new transaction is signed using the user's private key. After a new transaction is generated, the user can send it to the blockchain network.

[0069] Broadcasting and Verifying Transactions: New transactions may be received by some BCNs. BCNs use the public keys of users included in the transaction to verify its integrity. After verification and if the new transaction is valid, it can be relayed and / or broadcast within the blockchain network. Ultimately, all BCNs receive and possess a copy of any newly generated and valid transactions.

[0070] Creating a New Block: Some BCNs (called mining nodes and / or all nodes) group together many newly generated and pending transactions to produce a new block. The new block may include a block header and a block body. The block header may include the hash of the current block, the hash of previously confirmed blocks, and the hash of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol, the block header may include other and / or additional information. The block body may include the content of all included transactions. Each mining node may independently attempt to build a new block.

[0071] Verifying new blocks based on consensus protocols. In the task of creating a new block, mining nodes can independently attempt to build a new block. They can all run the same consensus protocol (e.g., Proof-of-Work in the Bitcoin system) and agree on who (i.e., the winner) is allowed to insert the block into the existing blockchain. The winner of the consensus protocol can send its newly generated block to the blockchain network. This new block can be broadcast; allowing all mining nodes to receive and / or verify it.

[0072] Update the blockchain. After the newly generated block is verified, it can be successfully attached to the existing blockchain because it contains a hash of the previous block (i.e., the last block of the existing blockchain).

[0073] Figure 3 illustrates an instance architecture of the blockchain system 300. The blockchain system 300 may include several types of logical entities, such as, for example, any of the following: a management node, one or more BCNs, one or more BCCs, and blockchain middleware (BCM).

[0074] Blockchain Middleware (BCM): The BCM bridges the BCC and BCN. The BCM can interact with the BCN on behalf of one or more BCCs (notably, the BCC can directly interface with the BCN in some cases). The BCM can manage and / or coordinate some or all of the BCNs. For example, the BCC can send blockchain transactions to the BCM without designating any BCN as the destination node. The BCM can select BCNs and / or forward blockchain transactions to selected (e.g., appropriate) BCNs. The BCM can be viewed as an agent of the BCC for interacting with the BCNs. The BCM can maintain the same blockchain / ledger that can be managed by one or more BCNs. Public blockchain systems may not have this BCM. Private and / or permissioned blockchain systems typically have a BCM for blockchain governance, access control, and other administrative purposes.

[0075] BCN (BCN): A BCN can participate in the blockchain workflow and perform actions, such as those illustrated in Figure 2. As shown in conjunction with Figure 3, BCNs can be connected via P2P links and / or form a mesh P2P network through which transactions and blocks can be broadcast via some or all of the BCNs and ultimately received by all the BCNs (assuming such BCNs maintain connectivity). A BCN can connect to multiple other BCNs, such as adjacent BCNs. For example, as shown in Figure 3, BCN A, BCN B, and BCN C (as adjacent) can be connected to each other, and BCN C, BCN D, and BCN E (as adjacent) can be connected to each other. Because the BCNs form a mesh network, the blockchain system can continue to operate after the loss of connectivity of one or more BCNs (e.g., such BCNs go offline) if connectivity is maintained among the remaining BCNs. For example, if BCN A goes offline, the blockchain system can continue to operate because the remaining BCNs B through BCN E maintain connectivity in the form of a mesh network. However, if the loss of a BCN leads to the removal of the mesh network, that BCN is called a critical BCN (e.g., BCN C is a critical BCN). A well-designed P2P routing protocol will prevent the existence of any critical BCN. A BCN can serve multiple BCCs. When a BCN can receive new transactions from its users, it can broadcast those transactions throughout the P2P network, making them available to all other BCNs. Similarly, when a BCN wins a consensus protocol, the new blockchain blocks it generates can be broadcast to all other BCNs. Each BCN hosts one or more ongoing blockchains. The way multiple BCNs are connected to each other may depend on the P2P routing protocol of the P2P network (e.g., rumor-based routing). BCNs that include P2P routing protocols can be managed and / or coordinated by a BCM. Standardization of blockchain operation when BCNs are offline has recently begun. There may be two types of BCNs: 1) BCNs that can manage blockchains, including sending / receiving transactions and receiving new blocks (but they do not participate in the consensus protocol), and 2) BCNs that can manage blockchains and / or participate in consensus protocols, including generating new blocks, such as endorsers, validators, and / or miners.

[0076] BCC: A BCC can generate new transactions and can directly send them to the corresponding BCN and / or BCM for forwarding to one or more BCNs. A BCC can interface with one BCN when interacting directly with it; however, that BCN can be changed. Multiple BCCs can connect to the same BCN. A BCC can lose its connection to a BCN or BCM. Losing its connection to a BCN or BCM results in the BCC going offline to the entire blockchain system. A BCC can be connected to a blockchain application on a device ("local BCC") or a blockchain application in the cloud ("remote BCC"). 5G System Architecture

[0077] Figure 4 is a block diagram illustrating a communication system 100 (Figure 1) configured as (e.g., as defined by 3GPP) a 5G system (5GS). 5GS 100 may include RAN 113 and CN 115. One of the design principles of the 5G system architecture is service-centric or service-based.

[0078] 5G CN 115 may include various network functions. These network functions may work together to provide and / or deliver services to RAN 113, WTRU 102, and / or application servers and / or application service providers. Network functions may include network repository function (NRF), access and mobility management function (AMF), conversation management function (SMF), authentication server function (AUSF), policy control function (PCF), user plane function (UPF), network exposure function (NEF), unified data management (UDM), unified data repository (UDDR), unstructured data storage function (UDSF), network data analytics function (NWDAF), and network slice selection function (NSSF).

[0079] A network function can access another network function. Network functions can access and / or interact with each other in either request / response mode or subscription / notification mode. A network function can be NRF logged in. NRF logging in makes the network function discoverable by other network functions.

[0080] The AMF manages access to WTRU 102 in the 5GS 100 and manages the mobility of that WTRU. The SMF is responsible for establishing a dialogue between WTRU 102 and the 5G CN 115. The AUSF is responsible for authenticating users (e.g., WTRUs). The PCF can build and / or provide one or more policy rules for and / or for other control plane network functions and WTRU 102. The PCF can assign identifiers to the built policy rules, and other control plane network functions and WTRU 102 can use these identifiers to reference (e.g., look up or otherwise obtain) the corresponding policy rules.

[0081] UPF can be used for user plane functions. UPF can monitor, manage, control, and redirect user plane traffic flows, such as between WTRU and application servers. NEF can expose control plane functions to entities outside the 5G system and / or not in the same trusted domain (e.g., network applications).

[0082] The 5G CN 115 can provide data storage and analysis services through various functions (such as UDM, UDR, UDSF, and any of NWDAF). The 5GS 100 supports network slicing. Network slicing can be facilitated by NSSF.

[0083] While network functions can be defined as separate logical entities, some or all of the network functions can be combined. One or more network functions may be associated with a specific procedure or operation and / or use. For example, AMF, AUSF, and SMF may relate to WTRU mobility. One or more instances of network functions may be instantiated. NRF can maintain information about each network function instance. Although appearing within a single cloud, one or more network functions may be deployed in edge networks, such as edge networks supporting edge computing and / or edge networks located near RAN 113 and / or co-located with that RAN. Deploying UPF and / or NEF in edge networks supporting edge computing may be advantageous because policy controls can be applied directly to events and / or data at the edge (e.g., where data and / or events are generated), which can save certain communication costs.

[0084] Figure 5 illustrates the various programs in 5GS. For convenience, the various programs are described with reference to the 5GS in Figure 4. The various programs can also be implemented using other architectures.

[0085] As indicated in (1), the WTRU may discover and / or select networks (e.g., PLMN, RAN, cell, etc.) based on received system information blocks (SIBs) broadcast by one or more RAN nodes. As indicated in (2), the WTRU may establish a radio resource control (RRC) connection with the selected RAN (e.g., RAN1). The WTRU may communicate with the 5G CN via the selected RAN. As indicated in (3), the WTRU may initiate a login to the AMF. The selected RAN may determine and / or select the serving AMF for the WTRU from one or more AMFs. As also indicated in (3), the serving AMF may use the ASF to check primary access authentication and authorization, request subscription data from the UDM, use the PCF to check access and mobility policies, and / or contact the SMF to initiate any existing PDU conversation (e.g., if instructed by the WTRU).

[0086] A login area (RA) may be defined within 5GS. An RA may be formed from one or more tracking areas (TAs); each of them may cover one or more cells. One advantage of an RA is that, when in an RA, communication overhead is reduced by not needing to update the login in the serving AMF unless the periodic login timer expires. If a WTRU moves from one RA (e.g., RA1) to another RA (e.g., RA2), the WTRU may perform a new login, such as, for example, using a login type configured for mobility login updates (as described herein and indicated in (7)). A larger RA may reduce login overhead, but may increase call communication overhead because the serving AMF must call the WTRU from a larger number of TAs (or cells).

[0087] Upon successful login, the WTRU may enter the RM-REGISTERED state and / or may access and / or interact with other control planes (NFs) via the Serving AMF. In various embodiments, the Serving AMF may be the sole entry point for the WTRU to access and interact with the CN control plane. The procedures indicated in (3), (5), and (7) may, for example, relate to connection management.

[0088] As indicated in (4), the WTRU may use the SMF to establish a PDU session for the DN. The serving AMF may determine / select the serving SMF for the PDU session. As also indicated in (4), the SMF may use the PCF to check the PDU session policy and / or may select the UPF as the anchor for the PDU session ("PDU session anchor"). The WTRU may access the DN and / or exchange packets with the DN via the PDU session anchor (PSA). The PCF may retrieve the WTRU's subscription information from the UDR related to the SMF's use of the PCF to check the session policy. The PCF may provide the WTRU's subscription information to the SMF. The SMF may perform primary session authentication using the WTRU's subscription information, such as that retrieved from the UDM, and may perform secondary authentication between the WTRU and the DN-AAA server, for example, using an extensible authentication protocol (EAP) such as those defined in IETF RFC3748 and IETF RFC5247. The program in (4) and the program in (5) can be executed together.

[0089] As indicated in (5), the WTRU may be in a CM-IDLE state (e.g., after the connection with the serving AMF has been terminated). As indicated in (5), the WTRU may initiate a service request procedure to re-establish the connection with the serving AMF and may enter a CM-CONNECTED state. When the WTRU initiates a service request procedure to re-establish the connection with the serving AMF, it may be in a mobile initiated connections only (MICO) mode. If the WTRU is not in MICO mode, the serving AMF may call and / or trigger the WTRU to initiate a service request procedure, for example, to receive any downlink packets. A NAS connection may be established between the WTRU and the serving AMF in relation to the service request.

[0090] Service requests can be made concurrently with WTRU login, in which case the WTRU can enter the CM-CONNECTED state. The WTRU does not need to provide the Mobility Notification Service (AMF) regarding its presence within the RA. If the WTRU remains within the RA but moves out of the RAN notification area (RNA), the WTRU can perform a RAN update to trigger a RAN update of the WTRU's background information and corresponding RRC connections maintained by that RAN. The RNA can be smaller than the RA. For example, the RNA can include a subset of the TAs forming the RA (e.g., TA1, TA2, and TA3 as shown in the figure).

[0091] As indicated in (6), the WTRU may use a DN for data transmission (data plane) via RAN 113 and the UPF as a PSA. The DN may have a data network name (DNN). Although not illustrated, the 5GS may include and / or be communicatively coupled to more than one DN, and each DN may have a separate DNN.

[0092] As indicated in (7), the WTRU can detect when it moves from RA1 to RA2. For example, the WTRU can detect this event by checking the list of TAs for each RA configured by the serving AMF. As indicated in (7), the WTRU can perform a mobile sign-on update using the new serving AMF. As indicated in (7), an inter-RAN handover from the current RAN to the new RAN (e.g., an inter-RAN handover based on Xn or N2) can be performed as the serving AMF changes. The new serving AMF can access the old serving AMF to transfer the WTRU's background information. As also indicated in (7), the SMF can access the PCF and / or UPF to update existing PDU conversations using the UE.

[0093] As shown in Figure 5, multiple TAs can be grouped together as a local area data network (LADN) service area to support LADN services. As an example, TA4, TA5, and TA6 can form an LADN service area. If (for example, if and only if) the WTRU remains within TA4, TA5, or TA6, that WTRU may be allowed to access LADN1.

[0094] A group of TAs can be grouped into a service area. The 5GS can specify and / or enforce service area restrictions on the UE. For example, the 5GS can configure WTRUs for service area restrictions used to form service areas from TA7, TA8, and TA9, wherein if (e.g., if and only if) the WTRU remains in TA7, TA8, or TA9, the WTRU can access the 5GS.

[0095] The various procedures disclosed herein and represented in Figure 4 do not need to be executed in the order shown or described, and not all procedures need to be executed. For example, the procedure represented in (7) may be executed before the procedure represented in (6), and the procedure represented in (5) does not need to be executed. (Joint Learning)

[0096] Traditional machine learning (ML) techniques are typically centralized, meaning data is stored in a centralized location, such as the cloud or a centralized data platform. Training data is used to obtain ML models. This process carries the potential risk of data leakage. Federation learning (FL) is essentially a distributed ML technique. The goal of FL is to implement distributed ML model training procedures through multiple FL participants (or FL users) while still ensuring data privacy, security, and legal compliance.

[0097] The FL program can be executed as follows:

[0098] Step 1: Mobile phones participating in the FL task can download or otherwise obtain the model to be trained (e.g., initial global model, temporary global model, intermediate global model, etc.) from the FL server.

[0099] Step 2: Each mobile phone can use its data to locally train the obtained model to form a local trained model ("local model")

[0100] Step 3: After training the local model, the mobile phone can encrypt the local model updates (e.g., gradients) and / or upload the encrypted local model updates (e.g., gradients) to the FL server.

[0101] Step 4: The FL server can perform model aggregation on local model updates collected from multiple phones to obtain a new and / or updated global model. Phones participating in the FL task can return to step 1, thus obtaining an updated global model for the next round of training. Steps 1 through 4 can be performed for multiple rounds, for example, to continuously improve the global model.

[0102] It is clear from the above procedure that FL can fully utilize the data and computing power of FL participants. Furthermore, multiple parties can collaborate to build more robust ML models without sharing and / or moving (e.g., exposing) their data. This feature can be crucial for ML tasks in environments with stringent data laws and / or oversight. For example, the European General Data Protection Regulation (GDPR) imposes strict requirements on the storage, use, and transfer of users' private data. Federated learning can be used to address issues such as data ownership, data privacy, and data access rights in this environment. From an implementation perspective, next-generation artificial intelligence (AI) systems can be driven not only from the AI ​​and ML fields but also from other fields such as distributed / networked computer systems, software, security and privacy, and algorithm design. For example, given that blockchain technology and FL share many similar system characteristics, such as large scale, decentralization, and data security sensitivity, there is growing attention and consensus on the applicability of blockchain technology to distributed ML (including FL). Representative use case – FL model and training program management in intelligent transportation.

[0103] Figure 6 illustrates an example of blockchain-enabled FL for smart transportation applications. As shown, multiple vehicles may be traveling along a city road network. Driving performance and / or behavioral data may be generated and / or stored locally in each vehicle for privacy purposes. Depending on the specific needs, various FL tasks may be initiated by a task initiator (e.g., by a specific vehicle and / or person, or by a transportation consulting organization and / or a private company or organization) to analyze driving performance data to train a global model via FL. For example, a specific FL task may be established with the objective of predicting on which road segments a driver is likely to have poor driving performance. Vehicles may join FL tasks and become FL participants. In each training round, FL participants may use their local driving performance data to perform local model training and / or generate new local model updates (e.g., gradients). FL participants may upload local model updates to the FL server. The FL server may use (e.g., aggregate) the local model updates to update the global model. The updated global model may be distributed to all FL participants. FL participants can use the updated global model for the next round of training, and this can be done for multiple rounds, for example, until the quality of the updated global model meets certain expected qualities, such as model accuracy. It should be noted that, for simplicity, the model update exchange procedure between FL participants and the FL server is depicted only between the FL server and the Vehicle-W in Figure 6.

[0104] In this FL application, blockchain can be utilized. For example, the FL server and FL participants can exchange their local model updates and global model in each round. During each round, they can record local and / or global model updates, performance data, and / or logs to the blockchain system, for example, for traceability and / or accountability purposes. Performance data and / or logs can indicate how much time FL participants spend on average completing a single round of local training. Examples of the potential benefits of applying blockchain to FL applications are provided below:

[0105] FL participants (e.g., vehicles) may not know each other, and therefore how to enable them to participate in FL tasks and collaborate with each other can be a problem. By using blockchain technology, multiple untrusted FL participants can work together on FL tasks. For example, smart contracts can be used to establish trusted working and / or collaborative relationships among multiple FL participants. Additionally, certain reward mechanisms in smart contracts can encourage FL participants to actively cooperate and contribute during FL training.

[0106] FL is essentially a decentralized framework, which is very well suited to the nature of blockchain systems. During each round of FL training, the work behavior data of each FL participant (e.g., the average amount of time spent completing a single local training session) can be stored in the blockchain for traceability and / or accountability purposes. In this way, the QoS of FL training can be monitored and / or adjusted. Various unforeseen events can occur in large-scale decentralized systems (e.g., node failure, connection loss, malicious attacks). Data loss caused by unforeseen events can be reduced by using a blockchain system (e.g., a decentralized ledger) to record / store FL training progress and store log data of FL training progress.

[0107] Additionally, different FL tasks can generate various trained models. These models can be stored in a blockchain system. For example, a trained model can be generated based on the efforts of multiple FL participants. Storing trained models in private locations (e.g., hosted by specific FL participants, or in a private repository or private cloud) may be inappropriate. For ease of access, models can be stored in more open and / or public locations. Storing models (or model summaries thereof) in a blockchain allows for more widespread model distribution and greater visibility, which in turn enables more users to discover and access the models. First representative sample

[0108] Large amounts of data can be generated by FL participants and the FL server in each round of the FL training process. For example, FL participants generate local model updates in each round. Similarly, different FL tasks can deliver the final and / or trained model after FL training is completed. Data (e.g., local model updates, intermediate trained models, final trained models, etc.) can be recorded in a blockchain system for accountability and traceability purposes (e.g., supporting reversal operations if the FL training process needs to restart from a specific point). At least some of the first representative examples of the various solutions disclosed herein can be how to efficiently organize and implement or otherwise implement the storage of data in a blockchain system. For example, such various solutions can be applied in a scenario where an FL participant may have different versions of a given local model update generated by that FL participant, such as a scenario where, for a given model update, the FL participant may have a full-size version and a cropped version (but the solution can also be applied to other situations). The full version may have all gradient updates (resulting in higher accuracy), but this local model update may have a larger data size. In contrast, some existing research solutions propose reducing the size of model updates by implementing certain pruning operations, such as storing only the most important updates or performing model distillation. However, implementing certain pruning operations can degrade model accuracy.

[0109] Each model (either an intermediate model update or the final trained model) may have different versions. Different versions may be useful for different situations, contexts, etc. For example, some situations may require the use of a full model for high-accuracy predictions, even if this full model is large in size. For storage efficiency, due to its smaller size, the blockchain system can store pruned model updates more frequently. In contrast, to support the traceability of FL tasks, full model updates without any pruning operations can be recorded by the blockchain system at larger intervals; for example, only one full model update for an FL participant can be recorded every five training rounds.

[0110] Based on the above, a data storage service that supports efficient FL (Flash Filter) is needed in blockchain systems; however, no such service exists to date. Using this service (as disclosed herein), FL participants do not need to care how their models are stored and organized in the blockchain, for example, whether different versions of the model are stored on the same chain or on different chains, or whether full model updates are stored at less frequent intervals than pruned model updates. In more advanced scenarios, FL participants do not even need to care about model pruning operations, and all pruning operations can be automatically completed by the blockchain system based on the instructions of the FL participants. Second representative sample

[0111] At least some of the second representative examples of the various solutions disclosed herein may relate to how to efficiently organize and implement, or otherwise implement, access to data stored in a blockchain system. In current blockchain systems, the BCC can identify the target chain and understand the basic data structure of the data and / or transactions stored in that chain, enabling the BCC to access the required information. In the context of FL applications, the BCC (e.g., a BCC wishing to utilize a blockchain system) may need to access trained models or interim data generated by FL tasks (e.g., local model updates by FL participants in each round). The way these models are organized and stored in the blockchain system can significantly impact the performance of subsequent model access. For example, the blockchain system may choose to store only the full version of the model update in each round. If the BCC needs a trimmed model, the blockchain system can trim the full version of the model, generate a trimmed model update from it, and send the trimmed model update to the BCC. In an alternative approach, the blockchain system may pre-build different versions of the model update (such as BCN E in Figure 6) and store all different types of versions in the blockchain system. This approach may require more storage space. The advantage of this method is that subsequent model access requests can have minimal processing time because all types of model versions are immediately available for access in the blockchain. It can be seen that due to different implementation choices of data and / or model storage organization in the blockchain system, if the user needs to understand the model storage details in the underlying blockchain system, it makes efficient model access very difficult for the user. It would be advantageous if a model access service could be made available in the blockchain system to facilitate model access. Using this service, the user only needs to specify the type of model they want to access (e.g., full model or trimmed model, accuracy requirements, etc.). The model access service can handle all details and retrieve the required model by interacting with the underlying blockchain. Throughout the process, the user may not need to know any storage details or data structure in the underlying blockchain. To date, no such model access service exists. (Third representative sample)

[0112] Different FL tasks can deliver various trained models that can be recorded by a blockchain system. These models can be shared or reused for other purposes. At least some of the third representative examples of the various solutions disclosed herein can be how to support (e.g., facilitate) the sharing of data and / or models (e.g., trained models delivered by different FL tasks) in a blockchain system. It may be advantageous if model sharing and trading markets are available in the blockchain system. One reason for doing so may be to facilitate convenient transactions between model makers (e.g., various FL participants) and model consumers (e.g., consumers who may wish to download models to use in their own applications). The various solutions disclosed herein can solve the establishment of transaction relationships as simply and / or efficiently as possible. For example, models can be stored on different chains and consumers need to check multiple chains for discovery (it may be advantageous if model repositories or model catalogs are available due to high-level conveniences on top of the base chain). When a consumer identifies a model of interest, it may be necessary to contact the model owner to negotiate a model transaction. It may be advantageous if the blockchain system can automatically generate smart contracts between consumers and model owners. This could be useful in a FL (Flash Logic) context because a trained model can (e.g., often) be owned by multiple FL participants. It would be advantageous if model consumers only needed to sign a smart contract prepared by the service provided by the blockchain system and didn't need to worry about any details (e.g., negotiating with multiple FL participants who own the model). To date, no such functionality and / or service exists in blockchain systems to support a model trading market. Fourth Representative State

[0113] At least some of the fourth representative examples of the various solutions disclosed herein may relate to how FL model deployment and scoring can be supported in a blockchain system. In traditional solutions, ML models can be deployed in the cloud and expose a model scoring API so that clients can call the API to perform model scoring (i.e., send their inputs to the model to obtain model outputs, such as predictions). To successfully implement this AI or ML application, the AI ​​or ML application may need to find the accurate ML model based on the application's needs and may need to consider many other system-related aspects, such as, for example, where to deploy the ML model for client access. In traditional AI or ML applications, ML models can (e.g., often) be deployed and hosted in the cloud by the owner for other clients to access. However, in a fully decentralized scenario, more or other deployment options may be available.

[0114] For example, assuming blockchain technology is used in contexts where different FL tasks can be performed, the resulting ML models, or at least their summaries (or hashes), can be made available in the blockchain system for traceability and accountability purposes. In other words, the trained model can be generated in a completely decentralized manner in the sense that the model can be built based on the efforts of all FL participants. However, if the role of the blockchain system in the model training process is so limited, it means that it will not support other services, such as model deployment (i.e., running the model) and model scoring, and these processes may all have to be implemented outside the blockchain system.

[0115] Trained models can be large in size (e.g., billions of bits), and therefore, downloading models from a blockchain system and deploying them to user-owned platforms or the cloud can be significantly time-consuming. Running models can consume significant computational resources, especially when running very complex AI models (e.g., neural network-based models). Because ML models can be stored in a blockchain system (e.g., managed by each BCN) and no model download procedure is required, this motivates ideas on how to leverage blockchain systems to assist in model deployment and model scoring. Each BCN can have good computational capabilities (e.g., for running blockchain consensus protocols, especially for PoW-type consensus protocols) and / or, if needed, can allocate some excess computational resources for implementing model scoring.

[0116] As described above, it can be seen that when blockchain technology is integrated with FL applications, the assistance of the blockchain system to the application can extend beyond the training process and / or the model deployment and model scoring process. The embodiments disclosed herein address how to use a blockchain system for model deployment and model scoring. The motivation may lie in the fact that the blockchain system can have a large BCN network, and each BCN can have some computing power (such as BCN D in Figure 6) to act as a model scoring node. Such a large BCN network can have great flexibility in serving model scoring requests in a fully decentralized manner; for example, a model scoring request from geographic region A can be served by a BCN that can be located in region A, that is, any BCN (as long as it has available computing resources for running ML models) can act as a model scoring station. Overview

[0117] As will be understood by those skilled in the art based on the teachings herein, the procedures, methods, architectures, devices, systems, apparatuses, and computer programs relating to the storage, sharing, and deployment of blockchain-enabled models for supporting distributed learning are not limited to the embodiments described herein.

[0118] Various / new services (e.g., middleware services) may be provided, for example, in accordance with the manner disclosed above (as a convenience). Middleware services may be implemented on the same entity and / or node or on different entities and / or nodes.

[0119] A blockchain storage service (BSS) may, for example, be provided in a first-representational manner. A BSS may be a common service used to assist its clients (referred to herein as "BSS clients") in storing data (e.g., models) in the blockchain system. The BSS may not necessarily transmit information about the underlying blockchain storage organization and structure to FL participants. Instead, the BSS may only transmit the most important information to FL participants (the chain that can be used to store specific types of information), but may hide all other storage details of the blockchain system. In this way, FL participants (as BSS clients) require only minimal effort to rely on the BSS used to store their data (such as model updates in each round) to the underlying blockchain system.

[0120] A blockchain access service (BAS) may, for example, be provided in a second representative state. The BSS may be responsible for efficiently storing data in the blockchain; however, the BAS (possessing knowledge of the data organization and chain structure in a basic blockchain system) can provide efficient data access services. The BAS client (e.g., an FL task initiator) may specify high-level requirements (e.g., what it might want to retrieve) without specifying details related to the basic data organization and chain structure in the blockchain system (e.g., which chain or chains need to be accessed to retrieve the desired data and / or model). The BAS can handle most of the details; for example, the BAS can interact with the blockchain system, identify the correct chain for access, retrieve the required information, perform other (e.g., necessary) processing if needed, and return the retrieved data to the client.

[0121] A model repository (MR) may be provided, for example, in the presence of a third representative sample. Until now, if the client does not have any knowledge about where the model is stored in the blockchain system, such as which chains it is stored on, the client is very likely unable to find the desired chain(s). MR enables the client to identify and / or discover the desired model to be retrieved. For example, a BAS can assist in accessing stored models. Before performing a model access operation, MR enables the BAS (client) to identify and / or discover the desired model to be retrieved.

[0122] MR can be on top of the basic blockchain. The functionality of MR may include enabling users (e.g., BAS users) to discover models and providing model transaction assistance between BAS users and FL participants (model producers), so that users do not have to interact directly with the model owner (e.g., FL participants) in order to pay specific fees to such FL participants.

[0123] A model deployment and scoring service (MDSS) can, for example, be provided using a fourth representative sample. Trained models can be large in size (e.g., billions of bits), and therefore, downloading models from a blockchain system and deploying them to a user's own platform or cloud can be significantly time-consuming. Running models can consume significant computing resources, especially when running very complex AI models (e.g., neural network-based models). A BCN within the blockchain system can potentially host and run such models. MDSS can directly assist with model deployment and scoring within the blockchain system (e.g., hosted and / or run by a selected BCN) without requiring a model download procedure. For example, a model scoring API can be exposed by MDSS, and MDSS clients can call this API to perform model scoring using ML models deployed in the system. MDSS can select the appropriate BCN that is running a specific model for performing model scoring. In this way, fully decentralized AI / ML model deployment can be achieved by utilizing a blockchain system.

[0124] In view of the states disclosed above, this document discloses several solutions. Individual and / or new services can be provided for each of these states. New services can be deployed or implemented by the same entities and / or nodes and / or different entities and / or nodes.

[0125] The following terms may be mentioned in conjunction with the content disclosed in this article.

[0126] Joint Learning (FL): A distributed machine learning approach involving individual FL participants and a model aggregator, wherein: 1) training data can be distributed and held at an FL reference; 2) for each of multiple epochs of FL training, the FL participants can perform local training, generate local and temporary model updates, and / or send local model updates to the model aggregator; 3) the model aggregator (e.g., an FL server) can receive local model updates from the FL participants and / or aggregate them together to generate a global model update; 4) the global model update can be sent to the FL participants for performing local training in the next epoch; and 5) this procedure can be repeated until the global model converges to one that matches the expected accuracy.

[0127] FL Task: A task defined or initiated by an FL task initiator to train an AI / ML model using FL. FL tasks can be implemented by an FL training program.

[0128] FL Training Procedure: A procedure that may include multiple steps for FL participants to work collaboratively to complete FL tasks and / or generate AI / ML models. A complete FL training procedure may include multiple rounds of training.

[0129] FL Task Initiator: An entity may have an application requirement to pursue an AI / ML model via an FL task implemented among a group of FL participants, and each of one or more FL participants may maintain local data for training the AI / ML model. This entity may initiate an FL task by specifying details of the model training (e.g., what kind of data may be needed for training, what type of model may be trained, etc.).

[0130] FL Participant: An entity that participates in an FL training procedure to complete an FL task (such as generating a final global AI / ML model). A specific FL task may correspond to an FL training procedure. An FL training procedure can be implemented by multiple FL participants, and FL participants can use their local data for training, and all FL participants need to work collaboratively to generate a global model. In the presence of a centralized FL server for model aggregation, the FL server can be regarded as a special type of FL participant used to build global model updates.

[0131] AI / ML: An AI and / or ML model that can make specific predictions or evaluations for a given input (e.g., given a future time and location, the model can predict traffic conditions in that area). AI / ML models may be referred to as "models" in this document.

[0132] Training mode: An AI / ML model resulting from the completion of a training procedure that can (e.g., often) begin with an initial and / or untrained model. After a training procedure using training data, a trained model that meets the expected accuracy can be produced.

[0133] Local Model Update: An interim trained model generated by a single FL participant during each training epoch. During each epoch of FL training, each FL participant can generate a local model update based on their local data. The local model update can be uploaded to a model aggregator used for model aggregation.

[0134] Model Aggregator: A logical entity that aggregates local model updates from each training round. In a traditional FL scenario, the model aggregator may be an FL server. In more advanced scenarios where no FL server exists, for example, model aggregation may be accomplished by voting by selected FL participants.

[0135] Global Model Update: This may not be the final trained model, but rather an intermediate trained model generated by the model aggregator during one or more training epochs. During each epoch of FL training, the model aggregator can aggregate local model updates collected from any (e.g., all) FL participants and generate a new global model update from these local updates. The new global model can be distributed to FL participants for use in the next training epoch.

[0136] Blockchain System: A blockchain system refers to a block infrastructure that provides blockchain-related functions. A blockchain system can provide basic blockchain functionality and / or various value-added services, frameworks, etc. For example, a blockchain infrastructure can provide a blockchain framework that supports various middleware and / or management services, and when interacting with a blockchain system, it can reduce the development complexity of upper-layer applications.

[0137] BCN: The basic blockchain infrastructure can be implemented through a blockchain network that includes multiple BCNs. BCNs can manage various chains and / or participate in various blockchain operations, such as implementing consensus protocols.

[0138] Blockchain Storage Service (BSS): A new service operable as a shared service for assisting BSS users in storing data and / or models within a blockchain system.

[0139] BSS Client: A logical entity that uses BSS to store FL-related models and / or data. For example, an FL participant may use BSS to update their local model and store it in the blockchain system.

[0140] Blockchain Access Service (BAS): A new service operable as a shared service to assist BAS users in accessing data and / or models (i.e., facilitating efficient access and / or download of models and / or data already stored in the blockchain system by the BSS). For a given (trained) model, it can be accessed or downloaded by certain interested parties via BAS. For example, a BAS user might wish to download a weather forecasting model from the blockchain system to their local computer via BAS.

[0141] BAS Client: A logical entity that uses BAS to access FL-related models and / or data. For example, if you want to use BAS to access local model updates recorded by the blockchain system, the FL task initiator can be a BAS client.

[0142] Model Repository (MR): A new repository that can operate as a market for model discovery and trading. MR can be seen as a convenient measure built on top of the underlying blockchain, in that users may not need to examine individual chains to discover models. Instead, they can utilize MR to implement model discovery.

[0143] Model Deployment and Scoring Service (MDSS): A new service operable as a common service to assist FL models in being deployed and scored directly within a blockchain system. Unlike accessing or retrieving models, another type of user intends to use the model, i.e., to implement model scoring (note that the process of using a model generated by an FL task to produce predictions is called scoring). For example, an MDSS client can send some inputs (e.g., future time and location pairs) to a model, expecting to predict traffic conditions for those time and location pairs. According to the embodiments disclosed herein, the trained model does not need to be downloaded for use, and it can be deployed directly within the blockchain system. In other words, the trained AI / ML model can be directly deployed (e.g., via BCN) to accept model scoring requests (i.e., applying the trained model to inputs to provide, for example, predictions, evaluations, classifications, etc.).

[0144] MDSS Client: A logical entity that uses MDSS for the deployment and scoring of FL models. For example, if you want to use MDSS to deploy an AI / ML model in a blockchain system, a given entity or application can be an MDSS Client.

[0145] The following text may be mentioned in conjunction with the content disclosed in this article.

[0146] Blockchain technology may be used as a general term to refer to the broader decentralized ledger technology; in other words, blockchain technology and decentralized ledger technology may be used synonymously or interchangeably. Therefore, the disclosures herein can be applied to any specific blockchain technology and / or decentralized ledger technology.

[0147] Although the embodiments disclosed herein are described in conjunction with the FL paradigm, they may only be one distributed ML approach. The embodiments and / or solutions disclosed herein can be applied to other scenarios where another type of ML learning approach (i.e., other than federated learning) can be employed. For example, for a given trained model generated via federated learning, the embodiments disclosed herein provide different solutions to address several technical aspects, such as how to facilitate model storage, model access, model sharing, model deployment, and scoring. The embodiments and / or solutions can be used in other scenarios, such as trained models generated via other types of existing and / or future AI and / or ML methods, such as, for example, generative adversarial networks, transfer learning, reinforcement learning, etc.

[0148] In describing the embodiments and / or solutions disclosed herein, this disclosure may use conventional FL as an example (i.e., an FL in which a centralized FL server exists for model aggregation). The embodiments and / or solutions disclosed herein can be applied to any advanced or future FL setup, for example, where a centralized FL server does not exist and model aggregation can be performed in a completely decentralized manner (e.g., in each round, a particular FL participant may choose to be the model aggregator based on selection).

[0149] In describing the embodiments and / or solutions disclosed herein, this disclosure may use mobile vehicles and mobile phones as examples of FL participants. The embodiments and / or solutions disclosed herein can be applied to any terminal or entity, such as, but not limited to, laptops, IoT devices, equipment, future mobile phones, drones, roadside units, laptops, set-top boxes, gateways, access points, satellites, sensor nodes, robots, machines, routers, base stations, radio access network central units, radio access network distribution units, radio access network radio units, network functions in 5GS and / or 6GS, intelligence reflective surfaces, etc.

[0150] In describing the embodiments and / or solutions disclosed herein, this disclosure may use AI / ML models as a special type of data. The embodiments and / or solutions disclosed herein may also be applied to, or in alternatives to, other types of data.

[0151] In describing the embodiments and / or solutions disclosed herein, this disclosure may use "local model update" and / or "global model update" as examples. The embodiments and / or solutions may also be applied to the final trained model. The final trained model may be considered as the final round of global model update or the final global model update.

[0152] Any of the following methods, architectures, devices, systems, apparatuses, and computer program products may include: receiving information instructing a blockchain storage request, including information associated with a distributed learning task; obtaining information identifying one or more blockchains based on a blockchain storage solution, wherein the blockchain storage solution is based on the information instructing the blockchain storage request; determining blockchain-related instructions based on (and / or from) the blockchain storage solution, wherein such blockchain-related instructions include at least some of the information identifying one or more blockchains; and transmitting the blockchain-related instructions to a plurality of participant nodes. In various embodiments, the method may be implemented in a device that may be, may include, and / or may be configured with a circuit system (including transmitters, receivers, processors, and memory).

[0153] In various embodiments, the method may include determining a blockchain storage solution based on information indicating a blockchain storage request. In various embodiments, obtaining information identifying one or more blockchains may include obtaining information identifying one or more blockchains at one or more blockchain nodes based on the blockchain storage solution. In various embodiments, obtaining information identifying one or more blockchains may include: identifying the availability of one or more blockchains in the blockchain system based on the blockchain storage solution. In various embodiments, obtaining information identifying one or more blockchains may include: establishing one or more new blockchains based on the availability of one or more blockchains in the blockchain system.

[0154] Any of the following: a program, method, architecture, device, system, apparatus, and computer program product is a device configurable to perform: receiving information instructing a blockchain storage request, including information associated with a distributed learning task; obtaining information identifying one or more blockchains based on a blockchain storage solution, wherein the blockchain storage solution is based on the information instructing the blockchain storage request; determining blockchain-related instructions based on (and / or from) the blockchain storage solution, wherein such blockchain-related instructions include at least some of the information identifying one or more blockchains; and / or transmitting the blockchain-related instructions to a plurality of participant nodes. In various embodiments, the device may be, may include, and / or may be configured with a circuit system (including a transmitter, receiver, processor, and memory).

[0155] In various embodiments, the device can be configured to determine a blockchain storage solution based on information indicating a blockchain storage request. In various embodiments, the device can be configured to obtain information identifying one or more blockchains at one or more blockchain nodes based on the blockchain storage solution. In various embodiments, the device can be configured to identify the availability of one or more blockchains in the blockchain system based on the block storage solution. In various embodiments, the device can be configured to establish one or more new blockchains based on the availability of one or more blockchains in the blockchain system.

[0156] In various embodiments of the method and apparatus, a blockchain may be set up on one or more blockchain nodes. In various embodiments of the method and apparatus, information identifying one or more blockchains may include information identifying one or more blockchain nodes. In various embodiments of the method and apparatus, blockchain-related instructions may be configured to implement or result in an implementation of a blockchain storage solution.

[0157] In various embodiments of the method and apparatus, the information indicating a blockchain storage request may indicate that the blockchain storage request is for a distributed learning task. In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include information associated with a distributed learning task. In various embodiments of the method and apparatus, the information indicating a blockchain storage request may be and / or include messages configured according to a protocol.

[0158] In various embodiments of the method and apparatus, the apparatus may be a transmission / reception unit and / or may be, may include, and / or may be configured as any of a user equipment, a station, a base station, and an access point. In various embodiments of the method and apparatus, the apparatus may be, may include, and / or may be configured to have or be at least one participant node of a plurality of participant nodes. In various embodiments of the method and apparatus, each of the plurality of participant nodes may be, may include, and / or may be configured to have or be any of a user equipment, a station, a base station, and an access point.

[0159] In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include an identifier of the distributed learning task. In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include information identifying the distributed learning task. In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include an identifier associated with a federated learning task.

[0160] In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include information identifying a plurality of participant nodes. In various embodiments of the method and apparatus, the information identifying a plurality of participant nodes may include a list of information identifying a plurality of participant nodes. In various embodiments of the method and apparatus, the information indicating a blockchain storage request may include any of the following: information associated with storing local model updates corresponding to each of the plurality of participant nodes; and information associated with storing global model updates based on the aggregation of local model update information.

[0161] In various embodiments of the method and apparatus, the blockchain storage solution may include a first blockchain for storing full versions of local model updates corresponding to one or more of a plurality of participant nodes. In various embodiments of the method and apparatus, the blockchain storage solution may include a second blockchain for storing trimmed versions of local model updates corresponding to one or more of a plurality of participant nodes. In various embodiments of the method and apparatus, the blockchain storage solution may include a blockchain for storing (i) full versions of local model updates corresponding to at least one of a plurality of participant nodes, and (ii) trimmed versions of local model updates corresponding to at least one of a plurality of participant nodes.

[0162] In various embodiments of the method and apparatus, the blockchain storage request may originate from an application running on the device. In various embodiments of the method and apparatus, the information instructing the blockchain storage request is received from an application running on the device. In various embodiments of the method and apparatus, the blockchain storage request may be received from another device including a transmitter.

[0163] A program, method, architecture, device, system, apparatus, and computer program product may include a method that: receives information from either a participant node or a blockchain node indicating that a first blockchain transaction for storing a full version of a local model update generated by a participant node during round i has been recorded in the blockchain; generates a trimmed version of the local model update included in the blockchain transaction; establishes a second blockchain transaction for storing the trimmed version; and sends the second blockchain transaction to the blockchain node for recording in the blockchain. In various embodiments, the method may be implemented in a device that may be equipped with, may include, and / or may be configured with, a circuit system (including a transmitter, a receiver, a processor, and memory).

[0164] One of the programs, methods, architectures, devices, systems, apparatuses, and computer program products is a device configured to perform at least the aforementioned methods. In various embodiments, the device may be, may include, and / or may be configured with a circuit system (including a transmitter, a receiver, a processor, and memory).

[0165] In various embodiments of any of the methods and apparatus, the apparatus may be a transmission / reception unit and / or may be, may include, and / or may be configured as any of a user equipment, a station, a base station, and an access point.

[0166] A program, method, architecture, device, system, apparatus, and computer program product may include a method that: receives from a first entity a request to access first information relating to a distributed learning task; identifies where the first information is located in a blockchain system based on second information including and / or indicating the request; retrieves the first information from the blockchain system via a blockchain node; and sends the first information to the first entity. In various embodiments, the method may be implemented in a device that may be equipped with, may include, and / or may be configured with, a circuit system (including a transmitter, receiver, processor, and memory).

[0167] One of the programs, methods, architectures, devices, systems, apparatuses, and computer program products is a device configured to perform at least the aforementioned methods. In various embodiments, the device may be, may include, and / or may be configured with a circuit system (including a transmitter, a receiver, a processor, and memory).

[0168] In various embodiments of any of the methods and apparatus, the apparatus may be a transmission / reception unit and / or may be, may include, and / or may be configured as any of a user equipment, a station, a base station, and an access point.

[0169] A program, method, architecture, device, system, apparatus, and computer program product may include a method that: receives from a first entity a request to obtain a trained model that meets one or more criteria, including a first fee amount for using the trained model; determines, based on first information collected from a blockchain system, that a trained model or alternative trained model that meets at least some criteria is available from the blockchain system; collects from the blockchain system second information associated with the trained model or alternative trained model, including a smart contract defining at least a second fee amount for using the trained model or alternative trained model; accepts payment of the first fee amount; triggers the smart contract, including payment of the second fee amount; and provides the information for obtaining the trained model or alternative trained model to the first entity. In various embodiments, the method may be implemented in a device that may be equipped with, may include, and / or may be configurable with, a circuit system (including a transmitter, receiver, processor, and memory).

[0170] One of the programs, methods, architectures, devices, systems, apparatuses, and computer program products is a device configured to perform at least the aforementioned methods. In various embodiments, the device may be, may include, and / or may be configured with a circuit system (including a transmitter, a receiver, a processor, and memory).

[0171] In various embodiments of the method and apparatus, the smart contract specifies how transaction revenue is distributed. In various embodiments of the method and apparatus, it is possible to notify the first entity that the second fee for the blockchain access service has been paid.

[0172] In various embodiments of any of the methods and apparatus, the apparatus may be a transmission / reception unit and / or may be, may include, and / or may be configured as any of a user equipment, a station, a base station, and an access point.

[0173] A representative solution is provided regarding the disclosure of this document, including a first representative sample. In an FL task, multiple FL participants may be involved. In various embodiments, it is assumed that at least some FL participants may not come from the same organization and can join the FL task arbitrarily; FL participants may be untrusted (lacking mutual trust). The application of blockchain technology can facilitate traceability and accountability of the FL training process among FL participants, for example, allowing corrective action if an FL participant (e.g., a malicious node) uploads a bad local model update (e.g., intentionally uploading many bad local model updates). When multiple FL participants can work on a particular FL task, the following technical requirements are considered:

[0174] Requirement 1: From the perspective of the FL task initiator, the first requirement to consider is the (multiple) types of information it wants to store in the blockchain. For example, the FL task initiator may want to store local model updates of all FL participants to facilitate attribution. The FL task initiator may want to store global model updates in each round, as well as the final delivered and / or trained model.

[0175] Requirement 2: After the FL task initiator specifies the (multiple) types of information to be stored in the blockchain, the second requirement considers how this message can be delivered to FL participants so that they can know and follow it. The FL task initiator may be completely unaware of the FL participants, and FL participants may dynamically change or reselect. Therefore, if the FL task initiator must contact each of the involved FL participants to deliver information that may need to be recorded in the blockchain system, additional overhead may be placed on the FL task initiator.

[0176] Requirement 3: The third requirement considers how and / or which entity / node will prepare the information to be written to the blockchain. For example, FL participants may have different versions of a given local model update generated by FL participants. The full version may have all gradient updates (resulting in higher accuracy), but this local model update may be large (in terms of storage). Some existing research solutions propose reducing the size of the model update by implementing certain pruning operations, such as storing only the most important updates, performing model distillation, etc.; however, implementing such pruning operations can degrade model accuracy. If both the full version and the pruned version of a given model need to be written to the blockchain, part of the third requirement may consider which entity / node will prepare the pruned version of the model. A simple approach could be to rely on FL participants to do all the work, but this increases the additional workload of FL participants.

[0177] Requirement 4: Assume that the full version model and its corresponding trimmed version have both been generated and are ready to be written to the blockchain. Requirement 4 considers how the data (the full version model and its corresponding trimmed version) should be stored in the blockchain. For example, part of Requirement 4 could consider storing the full version model and its corresponding trimmed version on the same chain or on different chains. If FL participants and / or FL task initiators must handle such details requiring deep interaction and understanding with the underlying blockchain system, this will place an additional burden on FL participants and / or FL task initiators.

[0178] In general, it can be seen that each model (either the intermediate local and / or global model update or the final trained model) can have different versions, and these different versions may be useful for different situations or contexts. For example, some situations may require a high-accuracy model, even if such a model is very large. However, for storage efficiency, complete model updates without any pruning operations can be recorded by the blockchain system at larger intervals; for example, only one complete model update for FL participants can be recorded every five rounds of training.

[0179] Blockchain Storage Service (BSS) may be provided. The BSS may provide other value-added services to FL applications. The BSS may be unique in that it addresses the above technical requirements and / or may include any of the following:

[0180] Property 1: BSS clients (e.g., FL task starters) can specify their requirements regarding the types of information they want to store in the blockchain (e.g., local and global model updates in each round). Specifically, various requirements can be specified, such as whether the full version should be stored or whether a trimmed version should be stored.

[0181] Property 2: Based on the collected requirements, the BSS can determine the basic blockchain storage structure details. For example, the BSS can decide which and how many blockchains to use, what information to store or what information should be stored on the same chain, and what information to store / what information should be stored on different chains, etc.

[0182] Property 3: After receiving a storage request from a BSS client (e.g., an FL task initiator), the BSS can indicate which FL participants may be involved, and then (on behalf of the BSS client) contact each of the FL participants to deliver (multiple) types of information to be stored in the blockchain system.

[0183] Property 4: Some information may require specific processing. For example, a cropped version of a model can be generated by applying the desired cropping operation to the full version of the model. The BSS can specify which cropping operations should be performed and / or which / which entities / nodes should have the cropping operation applied.

[0184] The BSS may not need to transmit information about the basic blockchain storage organization and structure to FL participants. The BSS can transmit the most important information to FL participants while hiding the details of the blockchain storage. For example, the BSS can only notify FL participants of the blockchain ID chain-1 (i.e., the identifier of the chain used to store information-X), which FL participants can use to generate blockchain transactions for storing information-X. Representative FL data storage configuration

[0185] Figure 7 illustrates an example program for configuring FL data storage using BSS.

[0186] The program may be applicable to programs that support the storage of models and / or data (e.g., FL model updates), such as storing local and / or global model updates to the blockchain with the help of BSS.

[0187] Prerequisites (7-0). The BSS client (“BSS Client-1”) may have administrative privileges over the FL task (“FL Task-1”). BSS Client-1 may be a logical role. For example, BSS Client-1 may be the FL initiator of FL Task-1.

[0188] Step 7-1. BSS Client-1 may send a blockchain storage request for FL Task-1. In the request, BSS Client-1 may specify (indicate and / or include) various information, such as (multiple) types of requests for information related to FL Task-1 that should (or will) be stored in the blockchain, and other storage requests (e.g., other higher-order storage requests). For example, the request may include and / or indicate the FL Task ID, the FL participants involved, information about local model updates (e.g., parameters), information about global model updates (e.g., parameters), training progress and performance data, and any other relevant information (such as the following).

[0189] The FL Task ID is the identifier for FL Task-1. The FL Task ID may be included and / or indicated in the request to indicate that the request is for the corresponding FL Task-1.

[0190] The FL participants involved may be, for example, a list of FL participants involved in FL Task-1 (e.g., identifiers associated with them). The FL participants involved may be included and / or indicated in the request to indicate the FL participants that may be involved in FL Task-1. BSS Client-1 may not be aware that the FL participants involved are feasible. If so, BSS may obtain the information on the FL participants involved from the blockchain system according to step 3.

[0191] Information relating to local model updates (e.g., parameters) may include any information indicating whether to store local model updates, information indicating whether to store the full version of local model updates, information indicating the frequency of storage of the full version of local model updates, information indicating the storage of a reduced or trimmed version of local model updates, information indicating the frequency of storage of trimmed versions, information indicating which model trimming operation(s) can be used, and information indicating that(multiple) entities / nodes will perform(such) model trimming operations.

[0192] Information indicating whether to store local model updates may include and / or be included in the request to indicate that local model updates of each FL participant will and / or should be recorded in the blockchain. Information indicating whether to store the full version of the local model update may include and / or be included in the request to indicate that the full or original version of the local model update will and / or should be recorded in the blockchain.

[0193] Information indicating the frequency of storing the full version of a local model update may include and / or indicate in the request how frequently the full version of a local model update for a given FL participant should be recorded in this blockchain. The full version of a local model update may be large, and storing the full version frequently (e.g., per training round) may be costly in terms of transmission and / or storage resources. Information indicating the frequency of storing the full version of a new local model update for a new training round may indicate that the full version is stored in the blockchain when the difference between the current full version and a previously stored full version of an old local model update exceeds a pre-configured threshold.

[0194] Information indicating the storage of a reduced or cropped version of a local model update may include and / or indicate in the request that reduced and / or cropped versions of local model updates for each FL participant should be recorded in the blockchain. Information indicating the storage frequency of the cropped model may include and / or indicate in the request how frequently cropped local model updates should be recorded in this blockchain. The cropped version of the model may be smaller in size than the full version of the local model update, and such updates may be affordable for recording each training epoch.

[0195] Information indicating which model pruning operation can be used may be included and / or indicated in the request to indicate how to generate the pruned model update using the full model update. Methods may include, for example, storing only the most important updates, performing model distillation, etc.

[0196] Information indicating which entity will perform the model pruning operation may be included and / or indicated in the request to indicate which entity may perform the desired model pruning operation. In a simple case, the FL participant may perform the pruning operation, but this may increase some of the FL participant's workload. Alternatively, the FL participant may deliver a full version of the local model update, and the BSS may process the remainder to produce a pruned version and record it in the blockchain system.

[0197] For global model updates in each round (e.g., those generated by the FL server after local model update aggregation), similar information and / or parameters may be provided, such as information related to global model updates (e.g., parameters), training progress and performance data, and any other relevant information.

[0198] Information relating to global model updates (e.g., parameters) may include any of the following: information indicating whether to store global model updates; information indicating whether to store a full version of global model updates; information indicating the frequency of storage of the full model; information indicating whether to store a trimmed version of global model updates; information indicating the frequency of storage of the trimmed version; information indicating the available model trimming operations; and information indicating that multiple entities / nodes will perform the model trimming operations.

[0199] Information indicating whether to store a global model update may include and / or be included in the request to indicate whether a global model update should be recorded in the blockchain. Information indicating whether to store a full version of the global model update may include and / or be included in the request to indicate that a full or original version of the global model update should be recorded in the blockchain. Information indicating the storage frequency of the full model may include and / or be included in the request to indicate how frequently a full version of the global model should be recorded in this blockchain.

[0200] Information indicating whether to store a trimmed version of the global model update may include and / or indicate in the request whether a trimmed version of the global model update should be recorded in the blockchain. Information indicating the storage frequency of the trimmed model may include and / or indicate in the request how frequently the trimmed global model update should be recorded in the blockchain.

[0201] Information indicating which model trimming operation can be used may be included and / or indicated in the request to indicate how to generate the trimmed model using the full model. Information indicating the entities / nodes(s) to which the model trimming operation will be performed (e.g., the FL server can perform this operation or it needs to rely on the BSS to do so).

[0202] Training progress and performance data and any other relevant information may include, for example, the time cost for a given FL participant to complete local training during round i; the computing resources allocated for local training during round i; etc.

[0203] Step 2. The BSS may first need to verify whether FL Task-1 is a valid task. If BSS Client-1 is not an initiator, for example, by checking other entities, such as the FL task repository or FL job initiator of FL Task-1, the BSS may need to determine and ensure that BSS Client-1 has the corresponding privileges. If BSS Client-1 is an FL job initiator, this verification is not required. The BSS can analyze the storage requirements received in Step 1, and the BSS may need to determine a detailed blockchain storage organization and structure solution. For example, the solution may specify any of the following details:

[0204] A chain may be needed to store the full version of the local model update. However, for a given FL participant, the blockchain may only need to store the full version of the local model update every 5 rounds (depending on the received "storing frequency for full model" parameter).

[0205] A chain may be needed to store the tailored version of the local model update. For a given FL participant, the blockchain may store the tailored version of the local model update every round or every two rounds (depending on the received "storing frequency for tailored model" parameter).

[0206] A chain may be needed to store the full version of the global model update during each training round.

[0207] A chain may be needed to store a cropped version of the global model update during each training round.

[0208] In the above example, four different chains may be needed to store different versions of the model. This chain organization can facilitate future model access within the blockchain system. For example, if a user only intends to retrieve all global model updates for FL Task-1, they may only need to access a specific chain. BSS can also determine other types of storage solutions, which can be entirely dependent on application requirements. For example, BSS can store all types of information (full or trimmed versions of local and / or global model updates) on a single chain, that is, mix all the data together.

[0209] Step 7-3. The BSS may identify whether there is an available blockchain for use based on the storage solution determined in Step 2. If there may be no available blockchain for use in the blockchain system, the BSS may therefore have one or more new chains established. For example, in the above example, the BSS may need four chains to store the four different types of information for FL Task-1. After identifying such chains (and / or one or more such chains that have been established), the BSS may obtain the chain identifier (i.e., the chain_ID of each chain).

[0210] The BSS can collect other useful information from the blockchain. For example, if the BSS Client-1 does not indicate the relevant FL participants for FL Task-1, the BSS may need to check, and can check, whether such information is available from the blockchain system. For example, there may be another management chain in the blockchain system that can be used for FL Task-1, which can be established when FL Task-1 is created. The BSS can access this chain to obtain basic information related to FL Task-1, such as the FL participants involved.

[0211] The BSS may transmit specific information to the BCN in the underlying blockchain system. For example, if the underlying blockchain system is a permissioned blockchain, only authorized parties are allowed to operate. The BSS may indicate which entities / nodes are FL participants (if the underlying BCN does not know this information) and determine that such FL participants have access privileges to generate and store transactions in the blockchain. For example, the BSS may obtain the list of current FL participants from the FL server or any other entity(s) that maintains the list of current FL participants. The BSS may send the list of current FL participants to one (or more) of the BCN ("BCN-1"). BCN-1 may use this list for access control purposes (e.g., only allowing FL participants included in this list to send blockchain transactions and store information in the blockchain). Alternatively, the BSS may collect specific information about the BCN, such as any constraints on FL participants when blockchain transactions are generated. For a given FL participant, the constraint may be which one or more of the BCN it may need to interact with when sending blockchain transactions.

[0212] Step 7-4. The BSS may send blockchain-related instructions, along with other useful information that FL participants may need to know (such as those discussed in Step 3), to each FL participant (e.g., FL Participant-A) to enforce / implement the determined storage solution.

[0213] For a given data segment to be collected from FL participants, any of the following information (e.g., parameters) may be included:

[0214] FL Task ID. This information may include and / or indicate in the message and / or instruction to indicate that this request is for FL Task-1. Assuming that an FL participant may participate in multiple different FL tasks, an FL Task ID corresponding to FL Task-1 may be included to distinguish it from other FL tasks.

[0215] Indicates the information of the data segment to be collected (for example, if the message is sent to FL participants, the data segment may refer to the local model update message, or if the message is sent to the FL server or model aggregator in this step, the data segment may refer to the global model update).

[0216] Instructions to store the full version, the cropped version, or both of the information.

[0217] Information indicating the (multiple) cropping operations to be applied to this data. This parameter may be indicated and / or included if the cropping operation will be performed by an FL participant. This parameter may not be indicated and / or included if the cropping operation will be performed by a BSS participant.

[0218] Indicates where (location) the information for the cropped opcode is downloaded. This parameter may be indicated and / or included when the cropping operation will be performed by an FL participant.

[0219] Detailed instructions for recording the full version of the local model update in the blockchain system. This may indicate the chain identifier for storing the full version of the local model update. For example, chain-1 can be used to store the full version of the local model update. It may also indicate the blockchain transaction format for chain-1, enabling FL participants to create formal blockchain transactions to include the full version of their local model update and submit them to the blockchain system, which records it in chain-1. Any of the following information may be included in the transaction format instructions (formal blockchain transaction headers are not listed for simplicity):

[0220] FL Task ID.

[0221] The sequence number of the corresponding training round.

[0222] Identifier of FL participants, for example, FL participant ID.

[0223] A summary or hash of the local data used for training (e.g., if the local data used for this round has changed compared to previous training rounds).

[0224] If not directly managed by the FL participant, the address and / or location of the local data used for training.

[0225] A summary of the global model update used, that is, the current local model update is based on which previously received global model update sent from the FL server or model aggregator. For example, local training in round i can begin with the received global model update generated by the FL server during round i-1.

[0226] The address and / or location of the global model update used. For example, this could be the address of the FL server.

[0227] A full or cropped version of a local and / or global model update, or a hash value of a full or cropped version of a local and / or global model update.

[0228] Information indicating the number of local and / or global updates included. For example, a transaction may include only one local model update for a given training round. Alternatively and / or additionally, information indicating the number of local and / or global updates included may indicate the number of multiple local model updates over multiple rounds. Alternatively and / or additionally, information indicating the number of local and / or global updates included may indicate the number of multiple local model updates for different FL participants for a specific training round.

[0229] The address of the recipient of this transaction (e.g., a specific BSS or FL server) that can receive, know, and / or notify.

[0230] Training progress and performance data and any other relevant information, such as the time cost spent by a given FL participant in completing local training during round i, the computing resources allocated for local training during round i, etc.

[0231] Detailed instructions for recording the trimmed model update in the blockchain system. The detailed instructions for recording the trimmed model update can be similar to those for a full model update. For example, chain-2 can be used to store a trimmed version of the local model update and can instruct FL participants on the blockchain transaction format of chain-2. In cases where the trimming operation will be performed by the BSS rather than by the FL participants themselves (in which case the FL participants do not need to know which chain(s) will be used to store the trimmed model update), any of the following methods can be used:

[0232] FL participants can directly send the full version of their local model update to the BSS. The BSS can first implement the desired trimming operation to create a trimmed version of the local model update. The BSS can then create a formal blockchain transaction and submit it to the blockchain system, which records it on the target chain.

[0233] Alternatively, FL participants may submit only blockchain transactions to the blockchain system, including the full version of the local model update (e.g., such transactions may be stored on chain-1). After making such information available on chain-1, the BSS may be able to obtain the full version of the local model update. For example, the BSS may access the full version of the model from chain-1, create a trimmed version, and cause its trimmed version to be stored in chain-2.

[0234] BCN Access Information: This may include all information relating to how FL participants should interact with the selected blockchain system, including:

[0235] The specific BCN ID of an FL participant and their interaction. For example, FL participant-A can use BCN-1 for interacting with the corresponding blockchain system.

[0236] The access address of BCN is selected.

[0237] BCN’s work cycle or any other constraints, etc.

[0238] The above details are based on an example description of local model updates on FL participants. The solution can also be used for global model updates on FL servers or model aggregators (in a fully decentralized FL scenario where FL servers do not exist).

[0239] Step 7-5. FL Participant-A can implement the corresponding local configuration based on the received instructions in Step 4. For example, FL Participant-A can send a hello message to BCN-1 to establish an association, connection, and / or dialogue with BCN-1 (if it is not yet able to connect to BCN-1) to send any storage requests in the future. If FL Participant-A has been authorized to send blockchain transactions and / or any other information and / or instructions related to how to interact with BCN-1, BCN-1 can send a response.

[0240] Step 7-6.FL Participant-A can send the response and confirmation to BSS.

[0241] Step 7-7. BSS can send the response and confirmation to BSS Client-1.

[0242] The BSS can be managed by a specific blockchain management node. The blockchain management node can interact with various BCNs. Alternatively, the BSS can be implemented in a fully decentralized manner. For example, each BCN can manage the BSS functional modules used to provide BSS services. In this case, the interaction between the BSS and the BCN becomes an internal interface. A representative FL data storage program...

[0243] Provide new programs that support FL model update storage with the help of BSS, for example, to store local or global model updates to the blockchain.

[0244] Figure 8 illustrates an example program that uses BSS to execute the FL data storage program.

[0245] Prerequisite 8-0. The FL participants in FL task-1 must have been configured and know the information to be written to the blockchain via the procedure shown in Figure 8.

[0246] Step 8-1. FL Participant-A (as one of the FL participants in FL Task-1) can complete the local model update for the current i-th round. Based on this configuration, FL Participant-A knows that the complete version of the local model update can be stored in chain-1 of the blockchain system. FL Participant-A can create a pro-blockchain transaction (Transaction-1) based on the transaction format of chain-1 to store the complete version of the local model update for this round.

[0247] Step 8-2. FL Participant-A can submit Transaction-1 to the blockchain system via BCN-1. After a specific consensus procedure, Transaction-1 can be recorded in chain-1.

[0248] If FL Participant-A is not in the current list of FL participants for FL Task-1, and / or if FL Participant-A does not follow the configuration that BSS can enforce / enforce in Figure 7 in the way it generates Transaction-1, BCN-1 can reject Transaction-1. For example, if FL Participant-A may be sending transactions too frequently and exceeding the "full model storage frequency", BCN-1 can reject some received transactions. Alternatively, as part of step 3 of Figure 7, BSS can instruct BCN-1 to randomly reject transactions from specific or any FL participant. Thus, transactions received from FL participants (e.g., FL Participant-A) can be discarded by BCN-1 based on the probability configured by BSS. Random discarding of transactions helps mitigate the risk of recording malicious local model updates. In general, as part of step 3 of Figure 7, BSS can configure some blockchain access control rules for BCN-1, which can be used by BCN-1 in step 2 of this document to authorize any received transactions from FL participants. For example, BCN-1 may decide whether to accept an access request from a given FL participant or FL server based on any of the following access control criteria: (i) whether the FL participant currently has privileges to access a specific (e.g., permissioned) blockchain system; (i) whether the FL participant is interacting with its designated BCN; (ii) whether the FL participant is accessing the BCN at the correct time window, e.g., not in the BCN's sleep cycle; (iii) whether the FL participant uses the correct security protocols and messages when interacting with the BCN; (iv) etc.

[0249] Other FL participants may also simultaneously submit their local model updates to the blockchain system. For each training round, there may be multiple blockchain transactions submitted by multiple FL participants, and each transaction may include local model updates. Transactions containing local model updates need to be verified and added to a block. The BSS may instruct the blockchain system to store transactions containing local model updates from the same training round in the same block (if they will be recorded on the same chain). The BSS may notify the BCN of such instructions in step 3 of Figure 7. Alternatively, the BSS may instruct the blockchain system to group transactions containing local model updates from different training rounds and store the grouped transactions in the same block.

[0250] Step 8-3. Depending on the configuration, the BSS can notify the availability of new local model updates generated by FL Participant-A via FL Participant-A or via BCN-1.

[0251] Step 8-4. The BSS obtains a new local model update. Based on the configuration, the BSS knows that it needs to perform a model pruning operation. Therefore, the BSS can create a pruned version of the local model update included in Transaction-1. The BSS knows that the pruned version of the local model update can be stored in chain-2 of the blockchain system. The BSS can create a sub-blockchain transaction (Transaction-2) based on the transaction format of chain-2 to store the pruned version of the local model update for this round.

[0252] Step 8-5. The BSS can submit Transaction-2 to the blockchain system via BCN-1. After the consensus process, Transaction-2 can be recorded in chain-2. For example, in addition to normal information, it can include any of the following:

[0253] FL Task-ID.

[0254] Related or related transaction ID. This may include a related or related transaction ID that indicates whether this transaction can be associated with other transactions. For example, Transaction-2 may be established by the BSS based on its related Transaction-1. The ID of Transaction-1 may be included in this parameter to associate / link the two transactions.

[0255] The sequence number of the corresponding training round.

[0256] The address of the recipient of this transaction (e.g., a specific BSS or FL server) that can receive, know, and / or notify.

[0257] Training progress and effectiveness data and any other relevant information.

[0258] Additionally, the storage of such transactions in the basic blockchain system depends on the specific storage solution. For example, all transactions storing local and / or global model updates during round i (generated by FL participants for the full version or by BSS for the trimmed version) can be stored in the same block and recorded on the same chain.

[0259] The above details are based on an example description of local model updates on FL participants. The solution can also be used to store global model updates on FL servers or model aggregators.

[0260] In one context (e.g., a general context), the solution can be applied to any of the following contexts:

[0261] FL participants can record their local model updates on the chain specifically for their own purposes. FL participants can participate in multiple FL tasks, and they can record local model updates from multiple FL tasks on the same chain.

[0262] Data and / or model storage procedures may not need to be executed in each round. For example, FL participants may store their local model updates every x rounds. All local model updates in round x can be placed in the same blockchain transaction and submitted to the blockchain system. In this way, the interaction between the FL application and the blockchain system can be minimized.

[0263] Storing the model (e.g., local or global model updates or the final trained model) in a blockchain system can refer to two possible scenarios. In the first scenario ("Scenario 1"), data can be directly written to blockchain transactions and stored on-chain (as explained above). In the second scenario ("Scenario 2"), only the data summary (i.e., certain hash functions may need to be applied to these local and / or global model updates to generate the data summary) can be stored on-chain, while the actual and / or original data can be stored off-chain. Solutions (e.g., all the solutions disclosed herein) can be applied to both scenarios.

[0264] Provide a representative solution regarding the disclosure of this document, including a second representative sample. The BAS may, for example, be provided based on the second representative sample. The BAS is primarily responsible for facilitating model access. The relationship between the BAS and the BSS may be that the BSS is responsible for efficiently storing data in the blockchain, while the BAS possesses knowledge of data organization and chain structure in a basic blockchain system and can provide efficient data access services.

[0265] Some functionalities of BAS can be described as follows. The BAS client only needs to (e.g., may) specify high-level requirements (e.g., what the BAS client wants to retrieve) without specifying details related to the data organization and chain structure within the blockchain system (e.g., which chain should be accessed for retrieving the desired data and / or model). BAS can handle most of the details, such as: 1) interacting with the blockchain system; 2) identifying the correct chain for access; 3) retrieving the required information; 4) performing other (e.g., necessary) processing if needed; and 5) transmitting the retrieved data back to the client. There can be many different use cases related to data and / or model access via BAS, including the following procedures, which illustrate how BAS can facilitate blockchain data access. These procedures can be applied in various situations.

[0266] Figure 9 illustrates an example program for blockchain data access operations in FL applications.

[0267] Prerequisite 9-0. The blockchain system may have recorded various models and / or data related to FL Task-1. For example, it may have recorded local model updates for each FL participant in FL Task-1. It may have recorded global model updates and the final trained model generated for FL Task-1. It may have recorded the work progress and performance data of FL participants (e.g., how much time a particular FL participant spends performing local training in each round). The BAS client (“BAS Client-1”) may be a BAS client and may have specific needs to access desired information related to FL Task-1. The BAS Client-1 may not have any knowledge about how data related to FL Task-1 is stored in the blockchain system, such as in which chains, in what format, etc.

[0268] Step 9-1. BAS Client-1 can send a blockchain access request to BAS. BAS Client-1 can specify high-level requirements regarding the information to be accessed. For example, given a specific FL Task-1, BAS Client-1 can specify high-level requirements regarding the information to be accessed. The three individual use cases listed below are examples of information that can be accessed related to a specific FL Task-1.

[0269] Scenario 1: BAS Client-1 may intend to retrieve a specific local model update generated by FL participant p during the 10th round of training.

[0270] Scenario 2: BAS Client-1 may attempt to retrieve the average time cost of local training for FL participant p.

[0271] Scenario 3: BAS Client-1 may attempt to retrieve a trained model generated by FL Task-1. The desired model should have the highest possible model accuracy while maintaining a model size limit of less than 10 Mb.

[0272] Step 9-2. The BAS can analyze the request and identify where the data may be located in the blockchain system. Because the BAS can exchange information with the BSS, it can have overall knowledge of how the data related to FL Task-1 may be stored in the blockchain system. For example:

[0273] For case 1, BAS can identify that local model updates generated by a specific FL participant p can be stored in chain-1.

[0274] For scenario 2, BAS can identify that the local training progress and performance data of FL participant p can be stored in chain-2.

[0275] For scenario 3, BAS can identify that the full version of the trained model generated by FLTask-1 can be stored in chain-3 and that the pruned version of the trained model is not recorded by the blockchain system. Based on the information exchanged with BSS, BAS can know the specific pruning operations that can be performed on the full version of the trained model and how to perform such operations.

[0276] Step 9-3. BAS can retrieve the desired data from the blockchain system, that is, via BCN-1. For example:

[0277] For case 1, BAS can retrieve the local model update generated by a specific FL participant p from chain-1.

[0278] For scenario 2, BAS can retrieve local training progress and performance data of FL participant p from chain-2.

[0279] For case 3, BAS can retrieve the full version of the trained model generated by FL Task-1 from chain-3.

[0280] Step 9-4. If necessary and / or upon request, BAS may perform further processing. For example:

[0281] For scenario 1, BAS does not need to perform further processing on the retrieved data. If BAS Client-1 requests or otherwise notifies BAS to provide the returned results in a different format, BAS may perform formatting processing (e.g., the retrieved data from the blockchain system may be stored as a blockchain transaction, and BAS Client-1 requests or otherwise notifies BAS to provide the results in a simple JSON file).

[0282] For scenario 2, BAS can calculate the average local training cost of FL participant p (across all training rounds) based on local training progress and performance data retrieved from chain-2 for multiple training rounds.

[0283] For scenario 3, BAS can perform various pruning operations based on the full version of the trained model retrieved from chain-3. Then, BAS can compare the pruned model outputs from various pruning operations to determine the pruned model with the highest model accuracy from pruned models smaller than a given size (e.g., 10 Mb) (e.g., based on specific test data provided by BSS and / or by BAS Client-1).

[0284] Step 9-5. BAS may send the response along with the obtained / requested information to BAS Client-1, such as retrieved data and / or information retrieved from retrieved data (e.g., metrics based on local training progress and performance data, or a trimmed model generated based on the retrieved full version of the trained model).

[0285] The BAS can be managed by a specific blockchain management node. This blockchain management node can interact with various BCNs. Alternatively, the BAS can be implemented in a fully decentralized manner. For example, each BCN can manage the BAS functional modules used to provide BAS services. In this case, the interaction between the BAS and the BCN becomes an internal interface.

[0286] A representative solution is provided regarding the disclosure of this document, including a third representative sample. An MR or model catalog may be provided, for example, based on a third representative sample. The MR allows the client to identify and / or discover models to be retrieved. For example, before issuing a model access operation, the BAS client may interface with the MR to identify and / or discover models to be retrieved. As another example, the client may interface with the MR to identify and / or discover different versions of various models that can be stored on different chains. As another example, the client may interface with the MR to identify and / or discover trained models generated by multiple FL participants. A trained model for a specific FL task may be the result of the efforts of multiple FL participants, and if the client wishes to download the trained model, it may need to pay a certain amount of money to the model owner, i.e., the multiple FL participants. In various embodiments, the client may interface with the MR to identify and / or discover the FL participants involved in the generation of the trained model, and this information can be used to obtain rights to a given trained model.

[0287] MR can operate on top of or as part of the underlying blockchain. Some of the functionality of MR may include: (i) enabling MR clients (e.g., BAS clients) to discover desired models, for example by generating model access requests to BAS; and / or providing model transaction assistance between MR clients (e.g., BAS clients) and FL participants, so that the client may not have to interact directly with the model owner (e.g., FL participants) to pay specific fees to such FL participants.

[0288] Figure 10 illustrates an example procedure for model discovery and model trading via MR.

[0289] Prerequisite 10-0. The blockchain system may have recorded the trained models generated by various FT tasks (FL Task-1). These trained models may have been made public to MR for model trading (and specific model information may be used as information items in MR, which will be described later). FL participants (or FL initiators) who are the owners of the models and / or data in FL Task-1 may have established a smart contract with MR to specify how to distribute the transaction revenue. MR client ("MR Client-1") may have the need to identify specific FL trained models and be willing to pay specific fees for downloading and / or using the models.

[0290] Step 10-1. MR Client-1 may send a model discovery request to MR. The model discovery request may indicate and / or include any of the following information:

[0291] Model type, which can indicate the type of model to be discovered, such as a driving behavior prediction model.

[0292] The allowed model size indicates the maximum size of the model.

[0293] One or more available inputs that may indicate one or more types of inputs that MR Client-1 may provide to the model when making predictions on such inputs (e.g., the input may be a given road segment and time).

[0294] One or more expected output types, which may indicate the type of desired output of the model to be trained, for example, the probability of an accident occurring at a given road segment and time.

[0295] Maximum Fee to be Paid, which indicates the maximum amount of money that MR Client-1 is authorized to pay for downloading and using the model. MR Client-1 may not need to have any knowledge about how the model can be stored in the underlying blockchain system or who needs to pay. MR can handle such items.

[0296] One of the prerequisites (prerequisite 10-0) is that the model has been trained, for example, by being made public to MR by the model owner. Information similar to the items listed above (e.g., model type, model size, version, expected input, expected output, desired cost to be paid, etc.) may have been included in the model publicization request sent from the model owner to MR.

[0297] Step 10-2. After receiving a model discovery request from MR Client-1, MR may check its internal repository to identify the model (e.g., if it meets the requirements) based on the information sent from MR Client-1. When a model is published to the repository during its model publication and / or registration process (as mentioned in the prerequisite steps), for a particular model, any of the following information may be made available as information items to describe the models stored in MR:

[0298] Model ID: A trained model may have a global identifier that can be associated with the corresponding FL task ID. The model ID indicates that the model was generated through a specific FL task.

[0299] Model type and purpose: This indicates the purpose of the model, such as predicting driving behavior on a given road segment during a given time period.

[0300] One or more inputs: This indicates the types of inputs that may be needed when applying the model.

[0301] One or more outputs: This indicates the type of output, that is, the predictions that can be generated by the model.

[0302] Storage Location: This indicates where the model can be stored, i.e., on which chain (or in which off-chain database). Multiple versions of the model may be stored on different chains (e.g., the full version of the trained model may be stored on chain-1, while the pruned model may be stored on chain-2). All of this information may be stored in the MR repository used for its purpose. Some or all of this information may not be exposed to the MR client.

[0303] Usage Fee: This indicates the price of the model. Therefore, if an MR user wants to use or download the model, they need to pay this cost.

[0304] Smart Contract ID, used to distribute revenue received from model transactions: This indicates which smart contract is applied to distribute transaction revenue (paid by MR clients) among model owners (e.g., different FL participants).

[0305] Based on the above information and the requirements received from MR Client-1, MR can identify the desired model.

[0306] Step 10-3. This step may be optional. For an identified model, if certain necessary information may not be immediately available in the MR, the MR may need and can collect more information from the blockchain system if necessary. For example, the MR may want to know advanced details about how the model was generated, such as which FL participants it was based on, what data it was based on, etc.

[0307] Step 10-4. The MR can accept the payment from MR Client-1. This procedure can be completed via a smart contract between MR Client-1 and the MR. The MR can prepare to trigger the smart contract to automatically distribute income among FL participants. Alternatively, the MR can help establish a smart contract directly between MR Client-1 and FL participants, and after MR Client-1 successfully downloads the model, the payment can be automatically distributed to FL participants.

[0308] Step 10-5. MR can trigger the execution of a smart contract with the model's owner. After the smart contract is executed, the transaction revenue collected from MR Client-1 can be distributed among multiple FL participants (i.e., the model's owner).

[0309] Step 10-6. MR can send back a response along with information about the identified model based on the information sent from MR Client-1 (e.g., if the requirements are met).

[0310] Steps 10-7. The model is ready for MR Client-1 to access. MR Client-1 can now become a BAS client. MR Client-1 (as a BAS client) can access the BAS to retrieve the desired model indicated in step 6 (by using the model access procedure as described in the previous paragraphs). The BAS can be located in the same place as the MR.

[0311] Alternatively, an integrated solution can be implemented where model discovery via MR and model access via BAS can be completed simultaneously. In other words, after MR identifies and pays for the model (in step 5), MR can immediately work with BAS to retrieve the model from the base chain. The retrieved model can be directly carried to MR Client-1 in step 6.

[0312] Step 10-8. After obtaining the model in MR Client-1 and downloading it via BAS, the model can be used for different purposes.

[0313] Provides representative solutions regarding the disclosures of this document, including the fourth representative sample. MDSS may, for example, provide solutions based on the fourth representative sample. MDSS can directly assist in model deployment and model scoring within the blockchain system (e.g., hosted and / or run by a selected BCN) without requiring a model download procedure. For example, a model scoring API may be exposed by MDSS, and MDSS clients may call this API to perform model scoring using ML models deployed in the system. MDSS may select the appropriate BCN that is running a specific model for performing model scoring. In this way, fully decentralized AI / ML model deployment can be achieved by utilizing the blockchain system.

[0314] There are many different ways and / or scenarios to utilize MDSS. Three example scenarios are described below. A representative MDSS enablement model deployment and scoring for supporting user mobility.

[0315] When a model can be deployed in a blockchain network, the location can be better suited to meet the model storage requests of service users. In other words, different working instances of models hosted on different BCNs can depend on the current location selection of the user's client.

[0316] Figure 11 illustrates an example program for MDSS-enabled model deployment and scoring to support user mobility.

[0317] Prerequisite 11-0. The model (“Model-1”) may be a trained model, which may be generated by FL or other AI and / or ML training procedures and may be owned by a first MDSS client (“MDSS Client-1”). MDSS Client-1 may be a starter, FL participant, FL server, or FL model aggregator for a specific FL task. Model-1 may have been discovered by a second MDSS client (“MDSS Client-2”). MDSS Client-2 may intend to use Model-1 (e.g., via MR). However, Model-1 may be large in size, and MDSS Client-2 does not wish to download Model-1 and deploy and / or run it.

[0318] Steps 1 to 4 belong to the model deployment procedure, and steps 5 to 11 belong to the model scoring procedure. The model deployment procedure and the model scoring procedure may occur at different times.

[0319] Step 11-1.MDSS Client-1 can send a model deployment request to MDSS. MDSS Client-1 may specify its requirements concerning how it may wish Model-1 to be deployed, including, but not limited to, the following:

[0320] MDSS Client-1 can hope that Model-1 is deployed in Area-A and Area-B to provide high-quality services to those two areas. Later steps 2 to 11 may be based on this specific instance situation.

[0321] MDSS Client-1 may require that the average time cost of model scoring for Model-1 should be less than 2 seconds. By using this, MDSS can determine which BCNs can be used as candidate nodes for hosting Model-1. For example, a BCN with more computational resources is desirable. .

[0322] Any other higher order or specific business requirement.

[0323] MDSS Client-1 can specify information / requirements without having any knowledge about the basic blockchain system, for example, how many BCNs can be running Model-1, and where they can be located. Details (e.g., all details) can be handled by MDSS.

[0324] Step 11-2. After receiving a request from MDSS Client-1, MDSS may identify that the first BCN ("BCN-1") may be in Area-A and the second BCN ("BCN-2") may be located in Area-B. MDSS can decide to deploy Model-1 to BCN-1 and BCN-2.

[0325] Step 11-3.MDSS may send requests to BCN-1 and BCN-2 and / or may request such deployment Model-1. If BCN-1 and BCN-2 agree to do so, BCN-1 and BCN-2 may retrieve Model-1, allocate resources (computing and / or storage, etc.), and run Model-1 from chains managed by them, etc., to be ready to accept input for model scoring. BCN-1 and BCN-2 can send individual responses to the MDSS to indicate a successful model deployment.

[0326] Steps 11-4.MDSS may send back responses where Model-1 has been successfully deployed at the desired location, for example, in Area-A and Area-B.

[0327] Step 11-5. MDSS Client-2 is now available in Area-A and can be intended to use Model-1.

[0328] Step 11-6. MDSS Client-2 can send the model scoring request along with the specific input data to be evaluated and other useful background information to MDSS. This background information includes, for example, any of the following:

[0329] Current location of MDSS Client-2.

[0330] Expected processing time, which indicates how long MDSS Client-2 wants to wait.

[0331] The best processing location, for example, the model score that MDSS Client-1 wants to process is in Area-A.

[0332] Minimum acceptable model accuracy: This indicates the minimum accuracy that may be required to perform model scoring on such inputs. For example, MDSS Client-1 may require a model scoring accuracy of at least 60%.

[0333] Step 11-7. Given the current location of MDSS Client-2, MDSS may decide to use BCN-1 in Area-A to serve this request.

[0334] Step 11-8. The model scoring request can then be sent to BCN-1 for processing. For example, it may include any of the following information:

[0335] Users who need this model's scoring operation.

[0336] Model used for model scoring.

[0337] Data input from the user terminal.

[0338] Expected processing time, which indicates how long a model scoring request should take to complete.

[0339] Information that needs to be recorded in the blockchain during the model scoring process.

[0340] BCN-1 can take the input data included in step 6 to run Model-1 locally. BCN-1 can generate model scoring results and send them to MDSS. BCN-1 can record model scoring results and other information (such as how long it takes to implement the model scoring procedure) in the chain.

[0341] Step 11-9. MDSS can send the model scoring results back to MDSS Client-2.

[0342] Steps 11-10. Subsequently, MDSS Client-2 may be moved to Area-B and / or may be intended to be reused in Model-1.

[0343] Steps 11-11. Given the new location of MDSS Client-2, MDSS may decide to use BCN-2 to serve this request. The procedure is the same as steps 7 through 10. Representative MDSS-enabled model deployment to support discriminative scoring.

[0344] A trained model can have different versions. The full version of the model can have a large data size, requiring more computational resources and time to perform model scoring, but it can produce high accuracy results. In contrast, a trimmed version of the model can be smaller in size, requiring less computational resources and time to perform model scoring, but it can produce less accurate results. Depending on the application requirements, a model with high accuracy is sometimes desirable. In other cases, less accurate predictions may be acceptable or even possible.

[0345] Figure 12 illustrates an example program for deploying an MDSS-enabled model to support differential scoring.

[0346] Prerequisite 12-0. Model-1 may be a trained model, which can be generated by FL or other AI and / or ML training programs and may be generated by MDSS Client-1. MDSS Client-1 may be a starter, FL participant, FL server, or FL model aggregator for a specific FL task. Model-1 may have been discovered by MDSS Client-2 that intends to use Model-1. Additionally, Model-1 may have two different versions, one may be a full version and the other may be a trimmed version, and both versions may be recorded in the blockchain system.

[0347] Steps 1 to 4 constitute the model deployment procedure, and steps 5 to 12 constitute the model scoring procedure. The model deployment procedure and the model scoring procedure may occur at different times.

[0348] Step 12-1.MDSS Client-1 can send a model deployment request to MDSS. MDSS Client-1 may specify its requirements concerning how it may wish Model-1 to be deployed. MDSS Client-1 can indicate that both the full and cropped versions of Model-1 need to be deployed.

[0349] Step 12-2. After receiving the request from MDSS Client-1, MDSS may decide to deploy the full version of Model-1 to BCN-1 and the cropped version of Model-1 to BCN-2. The reason for this may be that BCN-1 can have more computational and storage resources than BCN-2.

[0350] Step 12-3.MDSS may send requests to BCN-1 and BCN-2 and may request different versions of the deployed Model-1 thereof. If BCN-1 and BCN-2 agree to do so, BCN-1 and BCN-2 may allocate certain resources (computing and / or storage, etc.) and run separate versions of Model-1. One or more response messages indicating the successful deployment of the respective versions of Model-1 may be sent to the MDSS from either BCN-1 and BCN-2.

[0351] Step 12-4.MDSS may send a response indicating the successful deployment of two versions of Model-1 to MDSS Client-1.

[0352] Step 12-5.MDSS Client-2 can now have application requirements using Model-1. Application requirements may require high accuracy results.

[0353] Step 12-6.MDSS Client-2 may send a model scoring request to the MDSS with the specific input data and requirements to be evaluated (e.g., high accuracy results are required). Parameters similar to those in step 6 of FIG.

[0354] Step 12-7.Given the requirements of MDSS Client-2, MDSS may determine that the full version of Model-1 deployed on BCN-1 shall or will be used to serve this request. MDSS may forward the request to BCN-1, which can implement model scoring and transmit the scoring results back to MDSS. Requests sent to BCN-1 may include and / or indicate information (e.g., parameters) similar to the information indicated in step 8 of FIG.

[0355] Step 12-8. MDSS can send the model scoring results with high accuracy back to MDSS Client-2.

[0356] Step 12-9. Subsequently, MDSS Client-2 may now have another application requirement using Model-1. At this time, this application requirement is a less accurate model.

[0357] Step 12-10. MDSS Client-2 can send another model scoring request along with the specific data and requirements to be evaluated (e.g., low accuracy results may be sufficient) to MDSS.

[0358] Steps 12-11. MDSS can determine whether a trimmed version of Model-1 deployed on BCN-2 should or will be used to serve this request. MDSS can forward the request to BCN-2, which can perform model scoring and return the results.

[0359] Step 12-12. MDSS can return model scoring results with low accuracy to MDSS Client-2. Representative MDSS systems enable co-model scoring.

[0360] For ease of presentation, it may be assumed that the trained model has only one version. A given trained model can be deployed to multiple BCNs. Therefore, it is feasible for a given model scoring task to be performed collaboratively by different BCNs. This is especially true when the data to be evaluated and / or analyzed is large in size. The disclosures in this document consider situations where the input data to be analyzed may not be sent directly from MDSS, but instead, the input data to be analyzed may have been recorded in a blockchain system. For example, an MDSS client may want to use a driving performance prediction model to analyze, say, 1000G of driving behavior data stored in the blockchain, to predict which road segments are more likely to have accidents. However, if the driving performance prediction model is only deployed to one BCN, this node may face a significant workload in performing model scoring on such 1000G of data.

[0361] Figure 13 illustrates an example program for enabling collaborative model scoring in MDSS.

[0362] Prerequisite 13-0. Model-1 may have been deployed in BCN-1 and BCN-2, as well as other BCNs. These BCNs may use Model-1 to implement model scoring.

[0363] Step 13-1. MDSS Client-1 may intend to use Model-1 to analyze specific data that may have been stored in the blockchain system. For example, 1000G of driving behavior data is stored in the blockchain and needs to be analyzed by Model-1.

[0364] Step 13-2. MDSS Client-1 can send a model scoring request and any of the following information:

[0365] Analyze which type of input data, for example, 1000G of driving behavior data.

[0366] Which model to use, i.e., Model-1, for example, a driving performance prediction model.

[0367] Sampling rate. For example, given 1000G of driving behavior data, MDSS Client-1 may want MDSS to randomly evaluate 5% of the data.

[0368] Expected processing time, which indicates how long MDSS Client-1 wants to wait.

[0369] Optimal processing location. This indicates to MDSS Client-1 whether you want model scoring to be processed in a specific region. MDSS can identify the qualified BCN for implementing model scoring in that region.

[0370] Minimum acceptable model accuracy. This indicates the minimum accuracy that may be required to perform model scoring on the input. For example, MDSS Client-1 may require a predictive accuracy of at least 60% for the model scoring results.

[0371] Step 13-3.MDSS can determine that Model-1 has deployed BCN on it.

[0372] Step 13-4. For the BCNs involved in the managed deployment of Model-1, MDSS can issue job assignment requests and job details as described in Step 2 (i.e., the data analyzed and the model used). Other information can also be carried:

[0373] Users who need this model scoring operation.

[0374] Model used for model scoring.

[0375] Input the data to be analyzed.

[0376] Expected processing time, which indicates how long a model scoring request should take to complete.

[0377] Information recorded in the blockchain during the model scoring process.

[0378] Step 13-5. The BCNs involved can implement a consensus protocol to determine how to distribute work among the involved BCNs. For example, the consensus protocol can take into account the currently available resources on each involved BCN, and that the more resources a given node has, the more training load can be allocated.

[0379] Step 13-6. Assuming that after running the consensus protocol in the involved BCN, the final consensus can be that 50% of the data to be analyzed can be processed by BCN-1, and the other 50% of the data can be processed by BCN-2.

[0380] Step 13-7a. BCN-1 can determine which chains store the data to be analyzed, retrieve 50% of the total data to be analyzed from these chains, and use Model-1 to analyze it (i.e., perform model scoring).

[0381] Step 13-7b. BCN-2 can retrieve the other 50% of the data and can use Model-1 to analyze it.

[0382] Step 13-8. The model scoring results from the two BCNs can be sent back to MDSS.

[0383] Step 13-9. MDSS can integrate model scoring results from multiple BCNs (i.e., Node-1 and Node-2). For example, BCN-1 produces model scoring results for the top 50% of the data, and BCN-2 produces model scoring results for the other 50% of the data. MDSS can combine these results to form the final model scoring result. MDSS can perform specific aggregation operations on the model scoring results, such as calculating overall statistics on the scoring results, for example, classifying 30% of the data as Class-A based on Model-1, and classifying the remaining 70% of the data as Class-B based on Model-1. As a result, only these simple statistical results can be returned to MDSS Client-1.

[0384] Steps 13-10.MDSS can send the final integrated model score back to MDSS Client-1.

[0385] The above procedure is described based on a specific instance, namely, analyzing 1000G of driving behavior data. Therefore, a possible solution is to select two BCNs, each receiving 50% of the total workload. The procedure can be applied to many different other scenarios, where collaboration between different BCNs can take other methods and / or forms. A representative middleware layer used to facilitate model storage, access, and deployment in FL applications.

[0386] Several new services can be provided to support model storage, model access, model deployment, and model scoring in FL applications. These new services include BSS, BAS, MR, and MDSS. The new services may be part of a new middleware layer between the upper-layer FL applications and the underlying blockchain system.

[0387] Figure 14 illustrates an instance middleware layer enabling model storage, access, and model deployment in an FL application. When an FL application wishes to use the blockchain system for model storage, access, and deployment, it can interact with services in this middleware layer, and details regarding how to interact with the underlying blockchain system are handled by the middleware layer. Services can be implemented by a single entity or on different entities. FL applications can manage certain client-side functionalities of BSS, BAS, and MDSS. FL applications can use a master-slave architecture to interact with BSS, BAS, MDSS, and / or MR. For example, any of the BSS client, BAS client, MDSS client, and MR client can be managed on the same WTRU managing the FL participant. Client-side functionalities can assist FL participants (such as BSS clients, BAS clients, MDSS clients, and / or MR clients) in communicating with BSS, BAS, MDSS, and / or MR respectively.

[0388] Figure 15 illustrates the instance interaction architecture used in FL applications to enable model storage, access, and model deployment. Similarly, as shown in Figure 14, when an FL application wishes to interact with the blockchain system for model storage, access, and deployment, it can communicate with a specific blockchain management node that has BSS, BAS, MR, and / or MDSS capabilities. This blockchain management node can be inside or outside the blockchain system. The blockchain management node can be a proxy node or a networking node, which can be located between the blockchain system and the FL system and interconnect the blockchain system and the FL system. Similarly, FL applications can manage certain client-side functionalities of BSS, BAS, MDSS, and / or MR. FL applications can use a master-slave architecture to interact with BSS, BAS, MDSS, and / or MR. For example, any of the BSS client, BAS client, MDSS client, and MR client can be managed on the same WTRU managing the FL participants. The client-side functionality can assist FL participants (such as BSS clients, BAS clients, MDSS clients, and / or MR clients) in communicating with the BSS, BAS, MDSS, and / or MR managed by the management node, respectively.

[0389] Alternatively, the service can also be deployed directly on each of the BCNs. In this case, compared to Figure 15, there may be no blockchain management node in the system.

[0390] Figure 16 illustrates the instance interaction architecture for enabling model storage, access, and model deployment in an FL application. Figure 16 illustrates a fully distributed implementation option for these services. The FL application can manage certain client-side functionalities of the BSS, BAS, MDSS, and MR. The FL application can interact with the BSS, BAS, MDSS, and / or MR using a master-slave architecture. For example, any of the BSS client, BAS client, MDSS client, and MR client can be managed on the same WTRU managing the FL participant. Client-side functionalities can assist FL participants (such as BSS clients, BAS clients, MDSS clients, and / or MR clients) in communicating with the BSS, BAS, MDSS, and / or MR managed by the BCN, respectively. Representative O-RAN Implementation

[0391] The O-RAN architecture enables AI and / or ML functionality through two logical nodes for the Radio Access Network (RAN), namely, the non-real-time RAN intelligence controller (RIC) and the near-real-time RAN intelligence controller (NRT-RIC). For example, applying FL to O-RAN is feasible through any of the following scenarios:

[0392] Scenario 1: Service Management and Orchestration (SMO) acts as the FL server, while O-RAN units (i.e., O-RUs, O-DUs, and / or O-CUs) can be FL participants. The SMO can create FL tasks (e.g., to predict RAN performance), select some O-RAN units as FL participants, and install the FL tasks onto the participating O-RAN units. An O-RU (or O-DU and / or O-CU) as an FL participant can receive an initial global model from the SMO, train it based on its locally collected RAN-related data, generate local model updates, and send local model updates to the SMO. The SMO can aggregate local model updates (such as those received from participating O-RAN units), generate global model updates, and send global model updates to the participating O-RAN units. Participating O-RAN units can continue the above procedures to train their models using the new global model updates and their local RAN-related data. The final global model can be generated by the SMO.

[0393] Scenario 2: The RIC acts as the FL server, while O-RAN units (i.e., O-RUs, O-DUs, and / or O-CUs) can be FL participants. The RIC can create FL tasks (e.g., to predict RAN performance), select some O-RAN units as FL participants, and install the FL tasks onto the participating O-RAN units. An O-RU (or O-DU and / or O-CU) as an FL participant can receive an initial global model from the RIC, train it based on its locally collected RAN-related data, generate local model updates, and send the local model updates to the RIC. The RIC can aggregate the local model updates received from the participating O-RAN units, generate global model updates, and send global model updates to the participating O-RAN units. The participating O-RAN units continue the above procedures to train their models using the new global model updates and their local RAN-related data. The final global model can be generated at the RIC.

[0394] Scenario 3: The SMO acts as the FL management node and the RIC acts as the FL server. O-RAN units (i.e., O-RUs, O-DUs, and / or O-CUs) may be FL participants. The SMO may create FL tasks (e.g., to predict RAN performance), select some O-RAN units as FL participants, and send the FL tasks and a list of selected O-RAN units to the RIC. Alternatively, the SMO may send the FL tasks directly to each selected O-RAN unit. The RIC may install the FL tasks to each selected participating O-RAN unit. An O-RU (or O-DU and / or O-CU) as an FL participant may receive an initial global model from the RIC (or SMO), train it based on its locally collected RAN-related data, generate local model updates, and send local model updates to the RIC. The RIC may aggregate local model updates received from participating O-RAN units, generate global model updates, and send global model updates to participating O-RAN units. Participating O-RAN units can continue the above procedures to train their models using the new global model update and their local RAN-related data. Once the FL training procedure is complete, the final global model can be generated at the RIC. The RIC can then send the final global model to the SMO.

[0395] Scenario 4: The NRT-RIC acts as an FL server, and O-RAN units (i.e., O-RU, O-DU, and / or O-CU) can be FL participants. The NRT-RIC can create FL tasks (e.g., to predict RAN performance), select some O-RAN units as FL participants, and install the FL tasks to the participating O-RAN units. The O-RU (or O-DU and / or O-CU) can receive the initial global model from the NRT-RIC, train it based on its locally collected RAN-related data, generate local model updates, and send the local model updates to the NRT-RIC. The NRT-RIC can aggregate the local model updates received from the participating O-RAN units, generate global model updates, and send global model updates to the participating O-RAN units. The participating O-RAN units can continue the above procedures to train their models using the new global model updates and their local RAN-related data. The final global model can be generated in the NRT-RIC.

[0396] Scenario 5: The O-CU acts as an FL server, and the O-DUs can be FL participants. The O-CU can create FL tasks (e.g., to predict RAN performance), select some O-DU units as FL participants, and install the FL tasks onto the participating O-DU units. This procedure can be performed by the SMO (or RIC) representing the O-CU. An O-DU as an FL participant can receive an initial global model from the O-CU (or SMO or RIC), train it based on its locally collected RAN-related data, generate local model updates, and send local model updates to the O-CU. The O-CU can aggregate the local model updates received from the participating O-DU units, generate global model updates, and send global model updates to the participating O-DU units. The participating O-DU units can continue the above procedure to train the model using the new global model updates and their local RAN-related data. The final global model can be generated in the O-CU, which can forward the final global model to the SMO (or RIC).

[0397] Deployable services (BSS, BAS, MR, and MDSS) can be integrated with O-RAN for O-RAN entities to enhance their RIC functionality, as described in the FL scenario above. Figure 16 illustrates an example of O-RAN and service integration.

[0398] The blockchain system can be deployed in the RAN, edge network, and / or core network, and can interface and interact with all O-RAN entities and the core network. When the blockchain system is deployed in the RAN, O-Cloud can provide storage and computing resources to the blockchain system, and therefore the BCN can be managed by the O-Cloud entity. Other O-RAN entities and CN entities can interact with O-Cloud to interact with the BCN.

[0399] Each O-RAN entity and core network can manage FL-related entities, such as FL participants, FL servers, and FL model aggregators. As an example, each O-RU, O-DU, and / or O-CU can manage FL participants, and SMO, RIC, and / or NRT-RIC can manage FL servers.

[0400] Services (BSS, BAS, MR, MDSS) may be integrated into SMO, RIC, NRT-RIC, and / or CN. Alternatively, SMO, RIC, NRT-RIC, and / or CN may interface to services (BSS, BAS, MR, MDSS), which may be deployed as independent entities.

[0401] Figure 17 illustrates an example O-RAN implementation for services (BSS, BAS, MR, MDSS). Representative ETSI PDL implementation.

[0402] The ETSI Industry Specification Group (ISG) Licensed Distributed Ledger (PDL) has defined a PDL framework to support a variety of PDL-related applications.

[0403] Figure 18 illustrates an example ETSI PDL implementation for services (BSS, BAS, MR, MDSS). BSS, BAS, MR, and MDSS can be viewed as new services within the PDL platform's management and governance modules. Alternatively, BSS, BAS, MR, and MDSS can be implemented as part of the API and tool abstraction layer shown in Figure 18. As another alternative, BSS, BAS, MR, and MDSS can be implemented as part of common functionality within the ETSI PDL framework.

[0404] Figure 19 illustrates an example ETSI PDL implementation for services (BSS, BAS, MR, MDSS), representing a typical 3GPP implementation.

[0405] BCN can also be deployed within a 3GPP infrastructure. Therefore, services can be deployed within the 3GPP system illustrated in Figure 20. Figure 20 illustrates an example 3GPP implementation for services (e.g., BSS, BAS, MR, MDSS).

[0406] In Figure 20, the BCN can be deployed in both the edge network and the core network. WTRUs can be FL participants, which can interact with their FL servers or model aggregators (i.e., to implement FL training procedures between FL participants and FL servers). Network functions in the core network can be FL participants and / or FL servers. Network functions in the edge network can be FL participants and / or FL servers. FL servers can be deployed in the core network via, for example, a control link, or via, for example, a data link in the data network. Similarly, WTRUs can use data links to interact with the BCN (e.g., to record their local and global model updates in the blockchain system). BSS, BAS, MR, and MDSS can be considered as new network functions in the core network, and they can interact with FL participants and the BCN via control links to implement various procedures.

[0407] New network functions for AI / ML model storage, access, and deployment (MSAD) as disclosed herein can be provided in 5G systems. Therefore, BSS, BAS, MDSS, and MR can be services provided by this MSAD. Thus, all procedures in the preceding paragraphs can be represented as interactions with the MSAD in the 3GPP system. For example, the BSS user terminal, BAS user terminal, MDSS user terminal, and MR user terminal can be represented as a WTRU in the 3GPP system, allowing the WTRU to act as an FL task initiator, FL participant, and / or FL model aggregator, etc. Communication between the BSS user terminal, BAS user terminal, MDSS user terminal, and / or MR user terminal and the corresponding BSS, BAS, MDSS, and / or MR can be represented as communication between the WTRU and the MSAD in the 3GPP system.

[0408] Regarding the model deployment and collaborative model scoring procedures in the 3GPP system, the procedures in Figure 13 can be applied to collaboration between different BCNs in other ways and / or in many other different scenarios.

[0409] A given model scoring task and / or a request received by MSAD in a 3GPP system may have any of the following alternatives for implementing model scoring in multiple BCNs running different models (the following alternatives are not limited to 3GPP systems and are supported by their equivalent general BSS, BAS, MDSS, and / or MR services):

[0410] Multiple BCNs manage the same model, and each of them can perform a model scoring procedure on a portion of the input data. For example, two BCNs can be running the same model, and each of them can evaluate 50% of the input data used for model scoring.

[0411] Multiple BCNs manage different types of models, and each of them can implement a model scoring procedure. MSAD can select the model with the highest score. The result with the highest accuracy can be selected as the final model score result.

[0412] Multiple BCNs manage and run the same model, with each managing only a portion of the model's components. For example, complex neural network-based AI / ML can have thousands of layers. Some BCNs may manage only the first 50% of the model's layers, while other BCNs manage the remaining and / or last 50% of the total layers. Collaboration among multiple BCNs for model scoring can be implemented, for example, given data to be scored, the data can first be evaluated by the BCNs with the first 50% of the model's total layers, and then intermediate results can be sent to the programs of the next 50% of the BCNs with the model's total layers. Two BCNs can work together to achieve a complete model score.

[0413] Multiple BCNs manage different types of models for different purposes. For example, the raw data to be analyzed may not be ready for use, and some feature extraction operations may need to be performed first using Model-1 (e.g., which may be managed by BCN-1). Then, the extracted features generated by Model-1 may need to be sent to another Model-2 for model scoring to be performed using Model-2 (managed by another BCN-2), and Model-2 can generate the final model scoring results. A representative middleware layer for Federated Data Management (FDM).

[0414] The solutions disclosed herein can be used to support general blockchain-enabled data management for any type of application (not limited to the FL applications otherwise disclosed herein). For example, a new service group can be defined as a Blockchain-Enabled Federation Data Management Service (FDMS). FDMS can provide several data management-related operations and / or data management-related services supported by the blockchain system, such as data sharing, data collection, data retrieval, data discovery, data storage, data marketplace (or any other data management-related operations). FDMS can serve as a new intermediary layer between upper-layer data management applications and the underlying blockchain system.

[0415] Figure 21 illustrates a blockchain-enabled federated data management service (FDMS) for enabling federated data management of any type of application.

[0416] For any upper-layer application that wishes to use the blockchain system for data sharing, data collection, data retrieval, data storage, data discovery, data marketplaces, etc., it can interact with the FDMS in this middleware layer. Details regarding how to interact with the underlying blockchain system (e.g., all) can be handled by this middleware layer. The application can manage certain client-side functionalities of the FDMS. Upper-layer applications can interact with the FDMS using a master-slave architecture, where the FDMS in the middleware layer acts as a server and the upper-layer application operates as a client. For example, the FDMS client can be managed on a WTRU, and this client can assist the WTRU used for communication with the FDMS in the middleware layer.

[0417] FDMS may have any of the following capabilities (e.g., for supporting blockchain-enabled data collection):

[0418] For a specific application, if it wishes to initiate a specific data collection task, it may send a data collection task request to FDMS.

[0419] The data collection initiator can also indicate which data collectors should participate in the data collection task, or FDMS can analyze the required information stored in the basic blockchain system to determine a group of qualified data collectors.

[0420] FDMS can also interact with basic blockchain systems to establish specific smart contracts to build trust and collaboration among task initiators and data collectors that do not come from the same organization and do not trust each other.

[0421] The identity of the data collector can be assigned by the basic blockchain system, stored in the basic blockchain system, and / or managed by the basic blockchain system via FDMS in the middleware.

[0422] Collected data or hash summaries and / or abstracts thereof may also be written to the blockchain. FDMS may determine how collected data should be stored in the underlying blockchain system, such as which data should be stored on which specific chain. FDMS may need to determine that a given data collector has the correct privileges to operate the desired chain.

[0423] FDMS can also help implement integrity checks on collected data. For example, once collected data is sent to the data collection initiator, it may be desirable to determine that the data is original and has not been tampered with. The data collection initiator can send a hash summary and / or digest to FDMS, and FDMS can compare this hash summary and / or digest with records stored in the underlying blockchain system, thus enabling verification of data integrity.

[0424] In situations where a reward mechanism may be needed in the system, FDMS can help establish smart contracts for distributing rewards among different untrusted data collectors. For example, rewards can be distributed based on how much data a given data collector contributes.

[0425] Joint data collection typically involves multiple parties (e.g., multiple organizations, multiple data owners, multiple data providers, and / or multiple devices). Consequently, the successful completion of a joint data collection process may require successfully collecting the correct / appropriate data from each and every party involved. FDMS can utilize an underlying blockchain system to assist in managing the completion of joint data collection processes. For example, the act of collecting data from one party can be recorded by FDMS in a blockchain transaction, which can then be sent to the blockchain system via FDMS. FDMS can instruct the underlying blockchain system not to generate any new blocks for such transactions until data collection from all parties has been successfully completed and all corresponding blockchain transactions have been written to and verified by the underlying blockchain system.

[0426] FDMS may have any of the following capabilities (e.g., to support blockchain-enabled data sharing, data storage, data discovery, and data marketplace).

[0427] FDMS client-1 can send data to be shared to FDMS and FDMS can be responsible for storing the data in the appropriate location in the underlying blockchain system (e.g., a new transaction in the appropriate chain).

[0428] FDMS client-1 can indicate whether data can be shared with various entities and whether data sharing is free.

[0429] Another FDMS client-2 can interface with FDMS to request specific segments of data shared by FDMS client-1. FDMS can establish a smart contract between FDMS client-1 and FDMS client-2 for this data sharing.

[0430] If the data to be shared is stored in a specific chain, FDMS may need and can ensure that FDMS client-2 has the appropriate privileges to access that chain so that the shared data can be retrieved. For example, FDMS can determine that client-2's access rights are dynamically adjusted to support data sharing needs from upper-layer applications.

[0431] If data sharing is only valid for a limited period of time, FDMS may need to, and can determine, that once the period expires, FDMS client-2 can no longer retrieve data from the chain.

[0432] After FDMS client-2 can receive data, the reward can be automatically paid to FDMS client-1.

[0433] FDMS can support advanced data sharing, such as one-to-many or many-to-many sharing. For example, by using a blockchain system, a given data segment established by FDMS client-1 can be efficiently shared and / or delivered to other parties (as recipients). For example, FDMS can identify whether multiple data recipients support the same type of multicast mechanism, and if so, the data can be multicast to those recipients.

[0434] Additionally, data marketplaces can be supported by FDMS. Data owners or providers can publish their data to FDMS for sharing and / or trading. FDMS can write summaries and / or abstracts of publicly available data or similar information to the underlying blockchain system. Other parties can send data discovery requests to FDMS to find and identify desired data. FDMS can act as a negotiator between data providers and data consumers. Data transaction agreements can be established as smart contracts and stored in the blockchain system for traceability purposes.

[0435] Figure 22 illustrates an instance interaction architecture for facilitating federated data management for any type of application (Alternative-1). For general applications, when they wish to interact with the blockchain system for data management operations, they can communicate with a specific blockchain management node that has FDMS capabilities. This blockchain management node can be inside or outside the blockchain system. The blockchain management node can be a proxy node or a networking node, which can be positioned between the blockchain system and the specific application system and interconnect the blockchain system and the specific application system. Similarly, applications can also manage certain client-side functionalities of FDMS. Applications can interact with FDMS using a master-slave architecture.

[0436] Alternatively, FDMS can also be deployed directly on each of the blockchain nodes. In this case, there may be no blockchain management node in the system.

[0437] Figure 23 illustrates the instance interaction architecture for facilitating federated data management for any type of application (Alternative-2). Figure 23 illustrates this fully decentralized implementation option for the FDMS service. Similarly, applications can also manage certain client-side functionalities of FDMS. Applications can interact with FDMS using a master-slave architecture. For example, FDMS clients can be managed on a WTRU, and this WTRU can communicate with FDMS managed by blockchain nodes.

[0438] Figure 24 illustrates an example of FDMS in an ETSI PDL implementation - alternative embodiment 1. Figure 24 illustrates a PDL implementation of FDMS. FDMS can be viewed as a new service within the PDL platform's management and governance modules. Alternatively, FDMS can be implemented as part of an API and tool abstraction layer. Alternatively, FDMS can be implemented as part of common functionality within the ETSI PDL framework.

[0439] Figure 25 illustrates an example ETSI PDL implementation of FDMS, where FDMS is part of the common functionality. There is another way to define the interaction between the FDM system and the PDL system. In the context of PDL-based Federation Data Management (FDM), there are two independent systems, for example, a PDL system and an FDM system. The FDM system consists of FDM nodes. Each FDM node has traditional FDM functionality. The PDL system includes PDL nodes, and each PDL node has PDL functionality. To utilize PDL, these two systems need to interact with each other. The proposed FDMS can be implemented using an FDM-PDL proxy, which is included as a logical entity to connect the two systems. The main component of the FDM-PDL proxy (FPP) is the FDM service (FDMS). Through the FDMS, the FDM system can access the PDL system, for example, to store FDM-related operation records to the PDL chain. FDMS provides the following functions: 1) finding the appropriate PDL chain from the PDL system based on requests from the FDM system; 2) interacting with the PDL system on behalf of the FDM system; 3) buffering requests from the FDM system and sending them to the PDL system; and 4) buffering notifications and / or responses from the PDL system and forwarding them to the FDM system. As a logical entity, FPP can be integrated with the PDL system. In one embodiment, FPP can be implemented as part of common functionality within the PDL framework. In this embodiment, FDM applications can utilize FPP to access other common functionality and access the API and tool abstraction layer. In one embodiment, FPP can be implemented as part of the API and tool abstraction layer. FDM applications can use FPP and other APIs to access the PDL platform. In one embodiment, FPP can be implemented as part of platform, governance, and interoperability support. Using this embodiment, FPP can access PDL platform information, and therefore it can help find the appropriate PDL chain for different FDM applications. Alternatively, another distributed architecture solution integrates traditional FDM functionality, PDL functionality, and FPP into each FDM node. In one embodiment, each FDM node is extended to have both FPP and PDL functions. The FDM functions within an FDM node invoke PDL functions via the FPP. In one embodiment, the FDM function in one FDM node can interact with the FDM functions in another FDM node and the basic PDL functions in each FDM node via the FPP. The FDM functions in two or more FDM nodes exchange messages via the basic PDL functions and the PDL network. In one embodiment, the FDM functions can be used to manage the basic PDL functions and the PDL network, particularly for managing PDL-related data. Conclusion

[0440] 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 and apparatus 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.

[0441] For simplicity, the foregoing embodiments are a discussion of terminology and structure relating to devices with infrared capability (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to such systems and can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0442] 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 of a snapshot, a single image, and / or multiple images displayed on a time-based basis. 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) similar. Examples of WTRUs that may represent any of the WTRUs described herein are detailed in 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.

[0443] Additionally, the methods provided herein can be incorporated into computer-readable media for use in computer programs, software, or firmware implementations 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 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). The processor associated with the software can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

[0444] Variations of the methods, apparatus, 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 and the like) providing any suitable voltage.

[0445] Furthermore, in the embodiments provided above, the processing platform, computing system, controller, and other devices containing a processor are mentioned. 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.”

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

[0447] Data bits may also be stored 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.

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

[0449] There are very few distinctions between hardware and software implementations of the system. The purpose of hardware or software is usually (but not always; in certain contexts, the choice between hardware and software can become significant) a design choice representing a trade-off between cost and efficiency. Various carriers (e.g., hardware, software, and / or firmware) may exist by which the programs and / or systems and / or other technologies described herein are implemented, and preferred carriers may vary depending on the context in which the programs and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are of paramount importance, the implementer may choose a carrier that is primarily hardware and / or firmware. If flexibility is of paramount importance, the implementer may choose a implementation that is primarily software. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0450] The foregoing embodiments have illustrated various embodiments of the apparatus and / or program using block diagrams, flowcharts, and / or examples. 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 one embodiment, several portions 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. However, those skilled in the art will recognize that some aspects 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 any combination thereof, and will recognize that designing circuit systems and / or writing code for software and / or firmware will be entirely within the scope of the art to which this disclosure pertains. Additionally, those skilled in the art will understand that the mechanisms of the subject matter disclosed herein can be distributed as program products in various forms, and will understand that the illustrative embodiments of the subject matter disclosed herein are applied independently of the specific type of signal-bearing media 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.)).

[0451] 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), a computing entity (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 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 network computing / communication systems.

[0452] 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 that are 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 operable coupling 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.

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

[0454] 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 introductory 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 of items (including zero). Furthermore, as used herein, the term "number" is intended to include any number (including zero).

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

[0456] As will be understood by one of ordinary skill in the art, for any and all purposes, such as 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 units refers to a group having 1, 2, or 3 units. Similarly, groups with 1 to 5 units refer to groups with 1, 2, 3, 4, or 5 units and so on.

[0457] Furthermore, unless such effect is stated, the scope of the patent application should not be construed as limited to the order or elements provided. Additionally, the use of the phrase "means for" in any claim is intended to invoke 25 USC §112, ¶ 6 or the means-plus-function claim format, and any claim without the phrase "means for" is not intended to do so. [Simplified Explanation of the Diagram]

[0006] A more detailed understanding can be obtained from the following embodiments by way of examples combined with the accompanying drawings. Similar to the embodiments, there are examples of such diagrams. Thus, the drawings and embodiments are not considered as limitations, and other equally valid examples are feasible and possible. Furthermore, similar element symbols ("ref.") in the figures indicate similar elements, and wherein: [Figure 1A] is a system diagram illustrating an example communication system; [Figure 1B] is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used in the communication system illustrated in Figure 1A; [Figure 1C] is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used in the communication system illustrated in Figure 1A; [Figure 1D] is a system diagram illustrating a further example RAN and a further example CN that can be used in the communication system illustrated in Figure 1A; [Figure 2] illustrates an example workflow of a blockchain system; [Figure 3] illustrates an example architecture of a blockchain system; [Figure 4] is a block diagram illustrating a communication system configured as a 5G system (5GS); [Figure 5] illustrates various programs that can be implemented in 5GS; [Figure 6] Illustrate an example of blockchain-enabled federated learning and training program management for smart transportation applications; [Figure 7] Illustrate an example program for FL data storage configuration; [Figure 8] Illustrate an example program for executing FL data storage; [Figure 9] Illustrate an example program for blockchain data access operations in FL applications; [Figure 10] Illustrate an example program for model discovery and model transactions via a model repository; [Figure 11] Illustrate an example program for enabling model deployment and scoring using Model Deployment and Scoring Service (MDSS) to support client mobility; [Figure 12] Illustrate an example program for enabling model deployment using MDSS to support differential scoring; [Figure 13] Illustrate an example program for enabling collaborative model scoring using MDSS; [Figure 14] Illustrate an example middleware layer for enabling model storage, access, and model deployment in FL applications; [Figure 15] Illustrate an example interactive architecture for enabling model storage, access, and model deployment in FL applications. [Figure 16] illustrates the instance interaction architecture for enabling model storage, access, and model deployment in FL applications; [Figure 17] illustrates an instance O-RAN implementation; [Figure 18] illustrates an instance ETSI PDL implementation; [Figure 19] illustrates an instance ETSI PDL implementation; [Figure 20] illustrates an instance 3GPP implementation;[Figure 21] illustrates a blockchain-enabled federated data management service (FDMS) for enabling federated data management for any type of application; [Figure 22] illustrates an instance interaction architecture for enabling federated data management for any type of application; [Figure 23] illustrates an instance interaction architecture for enabling federated data management for any type of application; [Figure 24] illustrates an instance ETSI PDL embodiment for FDMS; and [Figure 25] illustrates an instance ETSI PDL embodiment for FDMS.

Claims

1. A method for enabling the storage of distributed learning data in a transmission / reception unit, the method comprising: receiving information indicating a blockchain storage request from a user terminal device via either a wired or wireless communication, the information including information associated with a distributed task; obtaining information identifying one or more blockchains based on a blockchain storage solution, wherein the blockchain storage solution is based on the information indicating a blockchain storage request, and wherein obtaining the information identifying one or more blockchains includes identifying the availability of one or more blockchains in a blockchain system based on the blockchain storage solution; determining instructions based on the blockchain storage solution, wherein the instructions include at least some of the information identifying one or more blockchains, and wherein the instructions specify a first blockchain and a second blockchain, the first blockchain being used to store a first version of a model update, the second blockchain being different from the first blockchain and being used to store a second version of the model update; and transmitting the instructions via either a wired or wireless communication to a plurality of participant nodes configured to participate in the generation of the distributed learning data.

2. The method of request item 1 includes: determining the blockchain storage solution based on the information indicating a blockchain storage request.

3. The method of claim 1, wherein obtaining information identifying one or more blockchains comprises: obtaining from the blockchain system information identifying the at least one blockchain created by the blockchain system in response to a request sent from the transmission / reception unit to create at least one blockchain, the request being sent via either wired or wireless communication and in response to a determination based on the blockchain storage solution and the number of available one or more blockchains in the blockchain system.

4. The method of claim 1, wherein the one or more blockchains are on one or more nodes of a plurality of nodes in the blockchain system, and wherein the information identifying the one or more blockchains includes information identifying the one or more nodes of the plurality of nodes.

5. The method of request item 1, wherein the instructions are configured to execute the blockchain storage solution.

6. The method of request item 1, wherein the information indicating a blockchain storage request indicates that the blockchain storage request is for a decentralized task.

7. The method of request item 1, wherein the information indicating a blockchain storage request includes the information associated with a decentralized task.

8. The method of request item 1, wherein the information indicating a blockchain storage request includes an identifier of a decentralized task.

9. As in request item 1, where: The client device includes an application; and at least one of the following: the blockchain storage request originates from the application executed on the transmission / reception unit or on another transmission and reception unit; and the information indicating a blockchain storage request is received from the application executed on the transmission / reception unit or on another transmission and reception unit.

10. The method of request item 1, wherein the blockchain storage request instructs a model pruning operation and an entity or node to implement the pruning.

11. The method of any one of Request 1 to Request 10, wherein: The first version is a complete version; and the second version is a trimmed version.

12. A transmission / reception unit comprising a circuit system including a transmitter, a receiver, a processor, and a memory, configured to: receive information indicating a blockchain storage request from a user terminal device via either a wired or wireless communication, the information including information associated with a distributed task; obtain information identifying one or more blockchains based on a blockchain storage solution, wherein the blockchain storage solution is based on the information indicating a blockchain storage request, and wherein obtaining the information identifying one or more blockchains includes, based on the blockchain storage solution, identifying the availability of one or more blockchains in a blockchain system comprising multiple nodes; determine instructions based on the blockchain storage solution, wherein the instructions include at least some of the information identifying one or more blockchains, and wherein the instructions specify a first blockchain and a second blockchain, the first blockchain being used to store a first version of a model update, the second blockchain being different from the first blockchain and being used to store a second version of the model update; and transmit the instructions via either a wired or wireless communication to a plurality of participant nodes configured to participate in generating the distributed learning data.

13. The transmission / reception unit of request item 12 is configured to: determine the blockchain storage solution based on the information indicating a blockchain storage request.

14. The transmission / reception unit of claim 12, wherein the information configured to identify one or more blockchains includes: being configured to obtain information from the blockchain system identifying the at least one blockchain created by the blockchain system in response to a request sent from the transmission / reception unit to create at least one blockchain, the request being sent via either wired or wireless communication and in response to a determination based on the blockchain storage solution and the number of one or more blockchains available in the blockchain system.

15. The transmission / reception unit of request item 12, wherein the one or more blockchains are one or more nodes of the plurality of nodes, and wherein the information identifying the one or more blockchains includes information identifying the one or more nodes of the plurality of nodes.

16. The transmission / reception unit as described in request item 12, wherein the instructions are configured to implement the blockchain storage solution.

17. The transmission / reception unit of request item 12, wherein the information indicating a blockchain storage request indicates that the blockchain storage request is for a decentralized task.

18. The transmission / reception unit of request item 12, wherein the information indicating a blockchain storage request includes information associated with a decentralized task.

19. The transmission / reception unit of request item 12, wherein the information indicating a blockchain storage request includes an identifier of a distributed task.

20. The transmission / reception unit as described in request item 12, wherein: The client device includes an application and at least one of the following: the blockchain storage request originates from the application executed on the transmission / reception unit or on another transmission and reception unit; and the information indicating a blockchain storage request is received from the application executed on the transmission / reception unit or on another transmission and reception unit.

21. The transmission / reception unit of request item 12, wherein the blockchain storage request instructs a model pruning operation and an entity or node to implement the pruning.

22. The transmission / reception unit of any one of requests 12 to 20, wherein: The first version is a complete version; and the second version is a trimmed version.

Images