Parameter configuration and registration for implementing collaborative relay networks

Abstract

There may be a cooperative WTRU network or a cooperative relay network, which may be a device-to-device network with more than one degree / level of working / cooperative nodes. In order to implement a cooperative relay network, there may be a method for parameter configuration. In particular, procedures may be disclosed herein for configuring parameters held by a WTRU in a collaborative network and / or for configuring parameters for discovering other WTRUs in a collaborative device-to-device network. In an example, a network element receives and stores information related to performing a collaborative task (VFL). The information may include a list of WTRUs participating in the same VFL application, a WTRU ID identifying each WTRU within the system, a user ID (e.g., GPSI, SUPI), a supported FL or AI / ML model, features and data types / tags supported by the FL application and / or other WTRUs, and sidelink QoS related parameters. The information may be used to generate policy parameters.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 465,665, filed May 11, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Device-to-device (D2D) direct communication protocols enable two devices to communicate directly, with or without network assistance. For D2D communication, different scenarios exist depending on whether the involved WTRU is within or outside cellular network coverage. Sidelink (SL) communication allows neighboring devices to communicate directly without data packets traversing the network. Target applications include mission-critical services, vehicle-to-everything (V2X) services, and the Industrial Internet of Things (IIoT). D2D communication promises ultra-low latency links, making it an attractive solution for various emerging applications such as augmented reality (AR), virtual reality (VR), and / or extended reality (XR). Summary of the Invention

[0003] One approach can be performed by a first network element. This first network element can receive VFL information regarding the execution of collaborative tasks related to a longitudinal federated learning (VFL) application. This information may include, for example, a list of wireless transmit / receive units (WTRUs) participating in the VFL application, an identifier associated with each WTRU in the list, and quality of service (QoS) related parameters. In some cases, the WTRUs in the list are in a device-to-device (D2D) communication environment. The first network element can determine policy parameters based on the VFL information regarding the execution of collaborative tasks related to the VFL application. The first network element can then send these policy parameters to a second network element or a WTRU.

[0004] In some examples, the policy parameter may include one or more Policy and Charging Control (PCC) rules. In some cases, the first network element may include a Policy Control Function (PCF), and the policy parameter may be generated and determined based on the VFL information. In this case, the policy parameter can be sent to the second network element.

[0005] The VFL information may include a user ID, an indication of one or more federated learning (FL) or artificial intelligence / machine learning (AI / ML) models, one or more grouping filter sets, and / or an indication of one or more features or data types supported by the VFL application.

[0006] In some cases, the first network element may include a Session Management Function (SMF), and the policy parameters can be received from a second network element. In this case, the second network element may include a Policy Control Function (PCF), and the policy parameters may include Policy Charging and Control (PCC) rules.

[0007] A method performed by a first network element (e.g., a PCF or SMF) may include the following: The method may include receiving VFL information regarding the performance of a collaborative task related to a longitudinal federated learning (VFL) application. The VFL information may include a list of radio transmit / receive units (WTRUs) participating in the VFL application, an identifier associated with each WTRU in the list, and / or quality of service (QoS) related parameters. In some examples, the WTRUs in the list may be in a device-to-device (D2D) communication environment. The method may include determining policy parameters based on the VFL information regarding the performance of the collaborative task related to the VFL application. The policy parameters may include one or more policy and charging control (PCC) rules. The method may include sending the policy parameters to a second network element or WTRU.

[0008] The first network element may include a Policy Control Function (PCF), and the method may include generating policy parameters based on the VFL information to determine the policy parameters. In such an example, the policy parameters may be sent to the second network element.

[0009] The VFL information may include a user ID, an indication of one or more federated learning (FL) or artificial intelligence / machine learning (AI / ML) models, one or more grouping filter sets, and / or an indication of one or more features or data types supported by the VFL application.

[0010] This method may include using the N2 interface to send the policy parameters and the QoS-related parameters to the RAN node via the Access and Mobility Management Function (AMF).

[0011] The first network element may include a Session Management Function (SMF), and the method may include receiving the policy parameter from a second network element (e.g., determining the policy parameter). The second network element may include a Policy Control Function (PCF), and the policy parameter may include Policy Charging and Control (PCC) rules.

[0012] A method that can be implemented by a network element (e.g., a network element including an Application Function (AF) or Application Service (AS)). The method may include detecting VFL events related to a Vertical Federated Learning (VFL) application. The method may include generating VFL parameters associated with the VFL application based on the detection of the VFL event. The VFL event may be a new cooperating WTRU joining the VFL application, an update to the VFL application, and / or an update to a feature supported by the VFL application. The method may include sending the parameters associated with the FL application. The network element may include an AF and / or an AS, and may send the parameters associated with the FL application to a Policy Control Function (PCF) and / or a Session Management Function (SMF).

[0013] The VFL parameters may include one or more sidelink (SL) QoS rules, a list of cooperating WTRUs associated with the VFL application, and / or one or more features supported by the VFL application. The VFL parameters may include indications of WTRU-to-WTRU connection status, whether a WTRU is a cooperating relay WTRU or a non-relay WTRU, and / or whether a WTRU is connected to one or more relay WTRUs. The VFL parameters may include a mapping or topology of the interconnectivity of multiple WTRUs associated with the VFL application. The VFL parameters may include one or more packet filter sets, indications of federated learning (FL) models or artificial intelligence or machine learning (AI / ML) models, or WTRU opt-out policies or triggers. Attached Figure Description

[0014] FIG. 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0015] FIG. 1B The illustration shows an embodiment that can be used FIG. 1A The system diagram shows an exemplary wireless transmit / receive unit (WTRU) used in the communication system.

[0016] FIG. 1C The illustration shows an embodiment that can be used FIG. 1A The system diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown.

[0017] FIG. 1D The illustration shows an embodiment that can be used FIG. 1A The system diagram shows another exemplary RAN and another exemplary CN used in the communication system shown.

[0018] FIG. 2 The diagram illustrates a comparison of WTRU operations when running raw federated learning (FL) and collaborative federated learning.

[0019] FIG. 3 The diagram illustrates the three categories of FL.

[0020] Figure 4 illustrates an exemplary structure of a vertically divided FL model.

[0021] FIG. 5 This is a system diagram illustrating a collaborative WTRU network used to implement longitudinal federated learning (VFL).

[0022] FIG. 6 This is a flowchart illustrating an exemplary parameter configuration for a distributed collaborative learning network using direct communication.

[0023] FIG. 7 This is a flowchart illustrating the WTRU registration process using FL information. Detailed Implementation

[0024] FIG. 1A This diagram illustrates an exemplary communication system 100 that can be used to implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing 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 Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0025] like FIG. 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments consider any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, any of WTRUs 102a, 102b, 102c, and 102d may be referred to as a “station” and / or “STA”, configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs. Furthermore, any descriptions herein that refer to UEs may equally apply to WTRUs (and vice versa). For example, WTRU can be configured to execute any flow or procedure described herein as being executed by the UE (and vice versa).

[0026] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to connect to at least one radio interface of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NRNodeB, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single unit, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0027] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, 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 radio service coverage for a specific geographic area, which may be relatively fixed or may vary over time. A 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 per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to send and / or receive signals in a desired spatial direction.

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

[0029] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish 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 (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0031] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

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

[0033] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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), etc.

[0034] FIG. 1ABase station 114b can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. FIG. 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may access Internet 110 without needing to go through CN 106 / 115.

[0035] RAN 104 / 113 can communicate with CN 106 / 115, which can be any network type configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data 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, etc. CN 106 / 115 can provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although FIG. 1A Not shown, but it should 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 or a different RAT than RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0037] 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, FIG. 1A The WTRU 102c shown can be configured to communicate with base station 114a (which may employ cellular-based radio technology) and base station 114b (which may employ IEEE 802 radio technology).

[0038] FIG. 1B This is a system diagram illustrating an exemplary WTRU 102. (Example:) FIG. 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing units while remaining consistent with the embodiments.

[0039] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. AlthoughFIG. 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0042] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0043] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 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 may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 may access and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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 user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access and store data in memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

[0044] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to and / or control 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0045] 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0046] The processor 118 may be further coupled to other peripheral devices 138, which may include software and / or hardware modules providing one or more additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may include one or more of the following: 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.

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

[0048] FIG. 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

[0050] 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 UL and / or DL, etc. FIG. 1C As shown, eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0051] FIG. 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing units is depicted as part of CN 106, it should be understood that any of these units may be owned and / or operated by an entity other than the CN operator.

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

[0053] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0055] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional wired communication equipment. For example, CN 106 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0056] Despite WTRU in FIGS. 1A-1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0058] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic from outside the BSS to a STA can reach and be transmitted to the STA via the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for transmission to the corresponding destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can transmit the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0059] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS 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 listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0060] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0061] Very High Throughput (VHT) STAs support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which is referred to as an 80+80 configuration. For the 80+80 configuration, channel-coded data is delivered via a segmented parser that splits the data into two streams. Each stream can be individually processed using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the merged data can be sent to Media Access Control (MAC).

[0062] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier used 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 instrument-type control / machine-type communication, such as MTC devices in macro 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 batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0063] WLAN systems supporting multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band may be considered busy, even if most of the band is still idle and potentially available.

[0064] In the United States, the available frequency band for 802.11ah is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah varies from 6MHz to 26MHz depending on the country code.

[0065] FIG. 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0066] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. 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 use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0067] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using multiple or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths).

[0068] 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 simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with another RAN (e.g., eNode-B 160a, 160b, and 160c) while simultaneously communicating / connecting with gNBs 180a, 180b, and 180c. For example, WTRUs 102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

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

[0070] FIG. 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing units is depicted as part of the CN 115, it should be understood that any of these units may be owned and / or operated by an entity other than the CN operator.

[0071] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act 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., handling PDU sessions with different requirements), selecting specific SMFs 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized 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, and services for Machine Type Communication (MTC) access. AMF 162 provides control plane functionality for switching between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as WiFi).

[0072] SMF 183a and 183b can connect to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b and configure service routes through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0074] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0075] Given FIGS. 1A-1D And to FIGS. 1A-1D As described herein, one or more of the functions described herein, relating to one or more of the following: 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 182ab, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other equipment described herein, may be performed by one or more emulation devices (not shown). Emulation devices may be configured to emulate one or more devices that perform one or more of the functions described herein. For example, emulation devices may be used to test other equipment and / or simulate network and / or WTRU functions.

[0076] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may perform tests using over-the-air wireless communication.

[0077] One or more simulation devices may perform one or more (including all) functions when not implemented or deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used in test scenarios within a test laboratory and / or an undeployed (e.g., under test) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0078] The following acronyms (and others) may be used in this document: Acknowledgment (ACK); Access Network (AN); Federated Transfer Learning (FTL); Lateral Federated Learning (HFL); Radio Access Network (RAN); Time-Sensitive Network (TSN); Uplink (UL); Ultra-Reliable Low-Latency Communication (URLLC); Vertical Federated Learning (VFL).

[0079] This article describes the parameter configurations used to implement cooperative relay networks.

[0080] PCF can receive and store information related to performing collaborative tasks (such as VFL). This information may include, for example, a list of WTRUs participating in the same VFL application, WTRU IDs identifying each WTRU within the system, user IDs (e.g., GPSI, SUPI), supported FL and / or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and / or sidelink QoS-related parameters. This information can be used to generate policy parameters.

[0081] SMF can receive and store information related to the execution of a collaborative task (VFL). This information may include a list of WTRUs participating in the same VFL application, WTRU IDs identifying each WTRU within the system, user IDs (e.g., GPSI, SUPI), supported FL or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and / or sidelink QoS-related parameters. This information can be used to manage PDU sessions related to the collaborative task.

[0082] The WTRU receives and stores information related to performing cooperative tasks (VFL). This information may include a list of WTRUs participating in the same VFL application, a WTRU ID identifying each WTRU within the system, a user ID (e.g., GPSI, SUPI), supported FL or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and / or sidelink QoS-related parameters. This information can be used to update the WTRU's local configuration.

[0083] This document describes WTRU registration for implementing cooperative relay networks. A WTRU can send messages to the network to register its capabilities associated with forming a cooperative network for performing cooperative tasks (such as VFLs). A WTRU can receive authorization from the 5G system that considers information related to its type and capabilities; this information can also be used to authorize a specific WTRU type within the cooperative network (e.g., authorizing the WTRU to become a cooperative relay WTRU). In some cases, a WTRU can be authorized to serve as more than one WTRU type or WTRU capability.

[0084] The WTRU can receive a registration acceptance message from the 5G system. This message may contain information related to approved WTRU capabilities. The WTRU can be configured with multiple configurations for both Uu and PC5 connectivity. The registration acceptance message may include codes / IDs associated with cooperative operations, which the WTRU can use or provide as a service to other WTRUs depending on the capabilities / services it is authorized to suppress or the type of WTRU it can suppress (e.g., cooperative relay). The WTRU (endpoint or intermediate) can use these codes in sidelink WTRU discovery. The registration acceptance message may include known WTRUs supporting FL and direct communication, known intermediate WTRUs and the types of WTRUs they hold, and / or known topologies.

[0085] D2D communication supports technologies such as Proximity Services (ProSe) and Group Communication. ProSe allows devices that are close to each other to communicate (one-to-one communication). This can be achieved through D2D discovery and D2D direct communication processes. The discovery mechanism allows a WTRU to discover another WTRU within its neighborhood, which can be done directly by the WTRU or over the network. The Group Communication mechanism allows WTRUs to communicate one-to-many in a highly resource-efficient manner, allowing messages to be easily propagated to a large number of WTRUs via a common downlink stream.

[0086] For unicast communication, communication entities can uniquely identify a WTRU (e.g., a one-to-one communication link) using source / destination Layer-2 identifier (ID) pairs. An application layer ID can be associated with one or more vehicle-to-everything (V2X) applications within the same WTRU. In scenarios where a WTRU has more than one application layer ID, each application layer ID within the same WTRU can be considered a different WTRU. A WTRU can maintain both the application layer ID and a Layer-2 ID for unicast links. Applications can use link IDs instead of Layer-2 IDs, allowing changes to the application layer ID and / or Layer-2 ID without requiring application updates.

[0087] A user ID (e.g., an Evolved Packet Core (EPC) ProSe user ID) can uniquely identify a WTRU that has registered with ProSe. An application group ID can uniquely identify the application group to which a WTRU belongs, a user within a specific application context, and / or a group of users within a specific application context.

[0088] In a device-to-device federated learning (FL) scenario, the application server may have transport latency requirements for each FL member running in a WTRU. Some of these WTRUs may be far from the gNB, and they may be unable to meet the transport latency requirements imposed by the FL application, thus holding valuable datasets and causing FL performance degradation.

[0089] This performance limitation can be mitigated by using device-to-device communication, which allows FL members to transfer their local machine learning (ML) parameters to nearby WTRUs, which can then use the models received from other devices to train their local models, such as... FIG. 2 As shown.

[0090] FIG. 2 The diagram illustrates a comparison of WTRU operations when running raw federated learning (FL) and collaborative federated learning.200 FIG. 2 The mechanism illustrated in the diagram allows up to six WTRUs to participate in communication using D2D communication, which may be superior to other mechanisms, such as using four WTRUs directly connected to the eNB. Enabling D2D communication allows WTRUs that may not meet transmission latency requirements to communicate, but D2D communication can also reduce energy consumption because ML model parameters can be transmitted to other WTRUs, rather than potentially remote gNBs.

[0091] Federated Learning (FL) is a machine learning paradigm in which multiple parties can collaborate to execute machine learning models without centralizing their data. The three categories of FL include: Horizontal Federated Learning (HFL), Vertical Federated Learning (VFL), and Federated Transfer Learning (FTL). FIG. 3 The diagram illustrates these three categories of federated learning (300).

[0092] like FIG. 3 As shown, in the HFL category, participants can share the same feature space while holding different data. In the VFL category, each party can keep its data and model localized but exchange intermediate computation results. In the FTL category, datasets may differ in both feature and sample spaces, with limited overlap. For example, EEG data from multiple heterogeneous objects can be used to collaboratively build a BCI model using FTL.

[0093] Due to their differences in data partitioning, HFL and VFL may employ very different training protocols. In HFL, each party can train a local model and exchange model updates (e.g., parameters or gradients) with a server, which can aggregate updates and / or send the aggregated results back to each party. In VFL, each party can keep its data and model local, but exchange intermediate computation results. The output of the HFL training process can be a global model shared by each party. In VFL, each party can have a separate local model after training. During inference time, each party in HFL can use the global model independently, while parties in VFL can collaborate for inference. FLs can be categorized into "cross-device" and "cross-silo" settings. Cross-device FLs can involve a large number of mobile or edge devices as participants. Participants in cross-silo FLs can be a limited number of organizations. HFLs can be either cross-device or cross-silo FLs. VFLs can be cross-silo FLs. These differences between HFL, VFL, and FTL are illustrated in Table 1. Allowing each node to hold complete features may be blocked and / or less secure. Therefore, VFL offers a more promising form of federated learning where different features are distributed longitudinally across participants, i.e., longitudinal federated learning (VFL).

[0094]

[0095] Table 1 In Virtual Feature Spaces (VFLs), each party can possess disjoint subsets of features. VFLs can be used in privacy-critical use cases such as the military, finance, and healthcare. For example, consider two different companies in the same city, one a bank and the other an e-commerce company. Their user sets may include residents of the area, so they may have overlapping user spaces. However, their feature spaces may differ because the bank's records may retain users' income and / or spending behavior and credit ratings, while the e-commerce company may retain users' browsing and purchase history. Both parties may have product purchase prediction models based on user and product information. Backpropagation algorithms can be used for such models.

[0096] Figure 4 illustrates example diagrams 400a and 400b of a vertically partitioned FL model. A process for enabling collaborative FL may be lacking. VFL can share intermediate results among participating FL nodes and allows larger FL tasks to be decomposed into subtasks that can be trained and executed independently (e.g., towards solving larger problems, as described in the famous "divide and conquer" principle), thereby establishing a multi-hop topology for FL logic tasks. However, VFL can leverage participating FL nodes for collaborative inference.

[0097] The implementation example describes a federated learning enabler using the HFL algorithm via direct device connectivity. In such scenarios, traffic flows may traverse a single relay / master device or connect directly to a network relay via a Uu reference point. In this context, solutions can be implemented for discovery, model distribution, establishing Uu (e.g., PDU sessions) and sidelink connections that meet QoS requirements.

[0098] When VFLs are applied to a network, interconnected local VFL nodes can be overlaid on a D2D network, where the FL nodes correspond to WTRUs. In doing so, topologies that go beyond the initial one can be established, such as... FIG. 5 As shown, multiple interconnected worker node layers are established to form a cooperative multi-hop D2D network.

[0099] FIG. 5 This is a system diagram 500 illustrating a collaborative WTRU network for implementing Vertical Federated Learning (VFL). The partitioning of FL tasks can be done for various purposes, including supporting VFL algorithms (such as...). FIG. 5 (as shown), supports the increased complexity of VFL AI / ML tasks, leverages the distributed availability of AI / ML features that can be used for models (e.g., features for a single model are available in different locations), privacy concerns regarding the centralization of sensitive data, the resource scarcity of WTRU, and / or other inherent benefits of fully accessing VFL.

[0100] A process can be implemented to enable VFL and obtain the benefits it provides, where a device can perform VFL. VFL can be useful for use cases where a WTRU wants to share intermediate results of the FL process with other WTRUs or the network while keeping its data and model local. VFL can lead to collaboration among participating FL nodes (in this case, WTRUs) when making inferences.

[0101] In the embodiments described herein, parameters related to the VFL can be configured for implementation. WTRUs can register to participate in the VFL, as described herein. FL workload allocation to WTRUs can consider a one-hop distance, similar to a star topology. Processes can be implemented to enable topologies similar to a tree (thus introducing cascaded / multi-hop direct device connection paths and relay nodes) or a mesh topology (where one device can connect to more than one device to complete a task). The terms cascade and collaboration are used interchangeably.

[0102] This article discloses cooperative WTRU networks, or cooperative relay networks, which can be device-to-device networks with more than one degree / level of working / cooperative nodes, such as... FIG. 5 As shown. These networks can be viewed as a collection of multi-hop D3D networks.

[0103] Act as an FL working node (e.g.) FIG. 5 The WTRU shown can be a cooperative WTRU. This cooperative WTRU is capable of hosting one or more FL worker nodes, WTRU-to-WTRU relays, WTRU-to-network relays, and / or acting as a multi-hop relay.

[0104] Collaborative WTRU can host master / coordinator / collaborative FL nodes (such as...) FIG. 5 As shown), a cooperative WTRU can receive the final result of the FL execution. A cooperative WTRU can be connected to (at least one) parent cooperative WTRU (hosting its parent FL node) on a branch. A parent cooperative WTRU can have one or more working / subtree / child / sibling / branch / leaf WTRUs (hosting working nodes), where its own artificial intelligence / machine learning (AI / ML) learning or inference can depend on the results of its working / subtree / child / sibling / branch / leaf nodes.

[0105] Collaborative WTRUs can collect intermediate data from subtrees / child / sibling / branch / leaf nodes (if any) and / or combine / update the model. Alternatively, a collaborative WTRU can act as a fully functional FL server, where the global model is stored and updated. Collaborative WTRUs can have any combination of capabilities, including intermediate result data processing, data relay, and / or collaborative node / task coordination.

[0106] This document discloses QoS processing for cooperative WTRUs. Each WTRU can maintain a different PC5 QoS context and / or PC5 QoS rules for each PC5 QoS flow identified by a PC5 QoS Flow Identifier (PFI) (based on the destination node (e.g., cooperative relay) identified by the Destination Layer-2 ID). Cooperative WTRUs can maintain multiple (e.g., two) PC5 flows. Control flows can be used to share control information and metadata associated with the formed VFL cooperative network / WTRU group.

[0107] The result stream can be used to exchange (intermediate or complete) results. This paper discloses a set of grouping filters for cooperative WTRUs. This set of grouping filters can support grouping filters based on at least any combination of the following: FL grouping type, grouping direction, cooperative node capabilities, hop count, layer, degree of WTRU in the entire topology, and / or whether the source / destination is a cooperative node.

[0108] FL grouping types can include control groups, result groups, and / or model groups. Grouping direction can define one direction that can be distinguished as business flow from a collaborating node to a child collaborating node, and / or another direction that can be distinguished as business flow from a child collaborating node to a parent collaborating node. Collaborating node capabilities can include intermediate result data processing, data relay, and / or FL node / task coordination. When a WTRU is assigned a PFI, the WTRU can be associated with the collaborating node capabilities of the destination WTRU.

[0109] When a cooperating WTRU forwards / routes results upstream toward the primary WTRU that generated the final result, it may prioritize processing its own results over those of its worker nodes. This could be because its own results are computed using the results of its worker nodes, and therefore may include the results of its worker nodes (or a processed version of those results).

[0110] This document discloses parameter configurations for implementing cooperative relay networks. Specifically, this document may disclose procedures for configuring parameters held by WTRUs in a cooperative network and / or for discovering other WTRUs in a cooperative device-to-device network.

[0111] In the example, the PCF receives and stores information related to performing a cooperative task (VFL). This information may include a list of WTRUs participating in the same VFL application, WTRU IDs identifying each WTRU within the system, user IDs (e.g., GPSI, SUPI), supported FL or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and sidelink QoS-related parameters. This information can be used to generate policy parameters.

[0112] SMF can receive and store information related to performing collaborative tasks (VFLs). This information may include a list of WTRUs participating in the same VFL application, WTRU IDs identifying each WTRU within the system, user IDs (e.g., GPSI, SUPI), supported FL or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and sidelink QoS-related parameters. This information can be used to manage PDU sessions related to the collaborative task.

[0113] WTRUs can receive and store information related to performing cooperative tasks (VFLs). This information may include a list of WTRUs participating in the same VFL application, a WTRU ID identifying each WTRU within the system, a user ID (e.g., GPSI, SUPI), supported FL or AI / ML models, features and data types / tags supported by the FL application and / or other WTRUs, and sidelink QoS-related parameters. This information can be used to update the WTRU's local configuration.

[0114] FIG. 6 This is a flowchart 600 illustrating an exemplary parameter configuration for a distributed collaborative learning network using direct communication. (See flowchart 600 for example.) FIG. 6 As shown, at 602, an event can trigger training or inference using FL to create, modify, or update configuration information in the core network, NG-RAN, and WTRU. This configuration information enables network devices in the cellular communication system to assist applications (such as FL applications) in transmitting application data that can be used in the cooperative network.

[0115] Examples of such triggers can include network-based triggers and application events. Network triggers can include triggers such as the discovery or registration of WTRUs / cooperative WTRUs and the joining of WTRUs to an application via SL or Uu reference points. Application events can include events such as FL application events that trigger application functions / application servers (AF / AS) (e.g., V2X application servers), application startup, model updates, and / or changes to application configuration (e.g., updated features).

[0116] At position 604, the AF / AS can provide FL-related information and WTRU-related information to network devices in a cellular communication system by invoking the Network Open Functions (NEF) API. This information (e.g., Vertical Federated Learning (VFL) information or VFL parameters) can be related to collaborative tasks related to performing FL applications (e.g., VFL applications). This information may include a list of WTRUs participating in the same FL application, WTRU IDs identifying each WTRU within the system, user IDs (e.g., GPSI, SUPI), application IDs, group IDs, supported FL or AI / ML models, features and data types / labels supported by the FL application and / or other WTRUs, one or more packet filter sets, sidelink QoS-related parameters, Uu QoS-related parameters, WTRU selection and exit policies and triggers, and / or information related to multiple WTRU types (e.g., handling WTRU types and / or cooperative relays), the corresponding WTRUs associated with the application may hold these types.

[0117] In some examples, the VFL information / parameters may include one or more sidelink (SL) QoS rules, a list of cooperating WTRUs associated with the VFL application, and / or one or more features supported by the VFL application. The VFL parameters may include indications of WTRU-to-WTRU connection status, whether a WTRU is a cooperating relay WTRU or a non-relay WTRU, and / or whether a WTRU is connected to one or more relay WTRUs. The VFL parameters may include a mapping or topology of the interconnectivity of multiple WTRUs associated with the VFL application. The VFL parameters may include one or more packet filter sets, indications of federated learning (FL) models or artificial intelligence or machine learning (AI / ML) models, or WTRU opt-out policies or triggers.

[0118] WTRU opt-out policies and triggers can be used to voluntarily opt out of their own membership and / or opt out of other WTRUs participating in the same application (e.g., based on inactivity timers).

[0119] Information associated with various WTRU types may include a data structure containing any of the following: capabilities, WTRUID, WTRU type, their WTRU-WTRU connections (e.g., which WTRUs are connected to which other WTRUs), the types of neighboring WTRUs at one hop distance (e.g., cooperative relays and non-relays), and whether the WTRU is connected to other relays.

[0120] If configured, the interconnectivity mapping / topology of WTRUs can be provided to participating WTRUs. This allows WTRUs to know their location within the network, giving them a holistic understanding of the entire network. Network Open Functions (NEFs) can query Binding Support Functions (BSFs) to determine which Policy Control Functions (PCFs) serve these WTRUs.

[0121] At 606, the NEF can forward the received information to the identified PCF. The PCF can use the received information to deduce relevant configurations, such as policy parameters (e.g., Policy and Charging Control (PCC) rules) related to the involved WTRU and session. Alternatively or additionally, the NEF can forward the information directly to the SMF at 608. These policy parameters can be determined based on information about the VFL performing collaborative tasks related to the VFL application. In some examples, these policy parameters may include one or more Policy and Charging Control (PCC) rules.

[0122] The PCF can directly pass FL-related information and PCC rule configurations to the SMF. The SMF can store the received configuration information for later use. Additionally, the SMF can also store the received configuration information for later use. FL-related information can be retrieved from the Unified Data Management (UDM) function or service before forwarding to NG-RAN and WTRU.

[0123] At point 610, the PCF can store the received FL and WTRU related information and QoS parameters, and forward them to the RAN via the AMF through the N2 interface. However, this step can be performed independently of the message received from the NEF in the previous step. The FL and WTRU related information and QoS parameters forwarded from the PCF can be transmitted through the RAN, but logically they are not processed by the RAN. Instead, this message comes directly from the core network. Specifically, the forwarded information originates from the PCF, or in some cases from the SMF, and is encapsulated in a message passing through the AMF and RAN, but logically neither the RAN nor the AMF accesses this message.

[0124] At position 612, the WTRU can receive configuration messages from network devices in the cellular communication system. The PCF can configure the WTRU for direct communication for distributed learning tasks. FL-related information (e.g., at position 602) can be sent to the WTRU via the AMF and N1 (NAS) interfaces. This message may include QoS parameters. QoS information and policies can cover any / every link that the WTRU may establish with other WTRUs. This information can also be used as an initial QoS value during SL connection negotiation / establishment.

[0125] This document discloses a process for registering a WTRU to enable a cooperative relay network. The disclosed process allows the WTRU to provide device capabilities (e.g., AI / ML capabilities, cooperative relay capabilities) to network devices in a cellular communication system during the WTRU registration phase. This information can be used to authorize AI / ML and cooperative relay capabilities.

[0126] FIG. 7 This is a flowchart illustrating the WTRU registration process using FL information at point 702. At point 702, the WTRU can register with the network via the RAN (or update / modify an existing registration). At point 702, the WTRU can send a message to the network to register its capabilities associated with forming a cooperative network for performing collaborative tasks (such as VFL).

[0127] At point 706, the WTRU can receive authorization from network equipment in a cellular communication system that considers information related to the WTRU type and capabilities. This information can also be used to authorize a specific WTRU type within a cooperative network (e.g., authorize the WTRU to become a cooperative relay WTRU). A WTRU can be authorized to serve as more than one WTRU type or WTRU capability.

[0128] At point 716, the WTRU can receive a registration acceptance message from network equipment in the cellular communication system. This message may include information related to approved WTRU capabilities. The WTRU may be configured with multiple configurations for both Uu and PC5 connectivity. The registration acceptance message may include codes / IDs associated with cooperative operations, which the WTRU may use or provide as a service to other WTRUs depending on the WTRU's authorized suppression capabilities / services or the type of WTRU it can suppress (e.g., cooperative relay). WTRUs (endpoints or intermediates) may use these codes in sidelink WTRU discovery. The registration acceptance message may include known WTRUs supporting FL and direct communication, known intermediate WTRUs and the types of WTRUs they hold, and / or known topologies.

[0129] The Radio Access Network (RAN) is a key component of a wireless telecommunications system, connecting various devices to other parts of the network via radio links. The RAN links user equipment (such as mobile phones, computers, or any remotely controlled machines) via fiber optic or wireless backhaul connections. This link connects to the core network, which manages subscriber information, location, etc. A WTRU can indicate its availability and / or capabilities related to establishing a cooperative WTRU network. Cooperative capabilities can be indicated as part of any of the following: V2X, ProSe, or PC5 capability indicators.

[0130] The instructions provided by WTRU may include collaborative WTRU capabilities (e.g., ... FIG. 6 The supported FL or AI / ML models, the AI / ML capabilities that the WTRU can provide, whether the WTRU already knows the existing FL application or group it wishes to join, whether the WTRU will create a new FL application group, and / or whether the WTRU can authorize the WTRU / node to be added to the network (e.g., when the WTRU is a cooperative relay).

[0131] If FL or AI / ML models are supported, the WTRU indicator can include hardware capabilities (such as GPUs, neural processors, sensors) as well as data and software capabilities, such as available features and data types / labels.

[0132] If the WTRU already knows the existing FL application or group it wishes to join, the WTRU indication may include the application ID, the group ID to which the target group is expected to communicate, service flow-related requirements information (e.g., the size and type of service flow that the UL / DL can foresee), the specific time when the WTRU wishes to participate in the communication, the time window when the WTRU wishes to participate in the communication (if the WTRU can generate it), and the specific WTRU ID that the registered WTRU may know in advance to communicate directly with (cooperative relay, processing node—with features / data that the WTRU is interested in).

[0133] Regarding the creation of FL application packets, WTRU indication information can be provided to the network so that it can be transmitted to the appropriate AF / AS. The FL application packet creation request can specify whether the WTRU can authorize the addition / joining of new WTRUs / nodes to the network (e.g., when the WTRU is a cooperative relay).

[0134] At 704, if no valid AMF has been indicated for this communication, the RAN (or the AMF configured to select an AMF) can select an AMF based on the information provided. The RAN forwards the registration request message to the AMF.

[0135] At point 706, the 5G system (AMF) verifies the identity of the WTRU. If the WTRU has not yet sent identity-related information, it does so. The AMF initiates this process by invoking the Authentication Server Function (AUSF).

[0136] At point 708, the UDM component can be selected. For the authorization of services provided by each WTRU or the types of WTRUs that a WTRU can act as (e.g., cooperative relay), the AMF checks with the UDM for any stored information about the WTRUs and authorized services or capabilities (e.g., cooperative relay capabilities). This information may have been previously stored in the UDM. If such information is not present in the UDM, the authorized services / permitted WTRU types can be stored in the UDM for future use after authorization by the AMF.

[0137] At 710, the AMF can select a PCF that supports FL policy configuration and establishes a WTRU policy association with the PCF for WTRU policy / parameter configuration. At 712, the AMF can report the capabilities received at 702 to the PCF and can store them in the UDM. At 714, the PCF can determine the AI / ML or FL policy and parameters for a specific RAT (or path) based on the received WTRU capabilities and WTRU type (e.g., as a processing WTRU and a cooperative relay). The policy parameters can include information related to the path type used for federated learning traffic. For example, the policy parameters can include an indication of the path type (e.g., Uu, PC5, etc.) to be used for transmitting federated learning traffic flows. If the policy parameters are determined at the path granularity, it can determine the AI / ML or FL policies and parameters for different paths (e.g., one path communicates via PC5, and another via Uu). In some scenarios, the WTRU (or PCF) can later decide which path is best suited for the operation.

[0138] At point 716, the WTRU can receive a registration acceptance message from network equipment in the cellular communication system. This message may include information related to the approved WTRU type and / or the duration for which the rule can persist. The WTRU can be configured with multiple configurations for both Uu and PC5 connectivity. It may also include information about the services and cooperative capabilities supported by the PLMN, cell, base station, or WTRU, and / or information about how to access those services and cooperative capabilities. Once the duration for a specific service (e.g., cooperative relay) expires, the WTRU can request authorization for that specific WTRU type again to be able to operate with the requested capabilities. This can be done through the WTRU registration procedure or the PDU session establishment / modification procedure.

[0139] In response to a received registration acceptance message, the WTRU can respond with a registration completion message (e.g., at 718) to a network device in the cellular communication system. This registration acceptance message may include a code / ID associated with AI / ML operations, which the WTRU can use or provide as a service to other WTRUs depending on its authorized suppression capabilities / services or the type of WTRU it can suppress (e.g., cooperative relay). WTRUs (endpoints or intermediates) can use these codes in sidelink WTRU discovery.

[0140] The registration acceptance message may include known WTRUs supporting cooperation and direct communication, known intermediate WTRUs and the WTRU types they hold, and a known topology (likely only including neighboring WTRUs participating in cooperative (AI / ML / FL) operations, up to a specific limit on the number of hops). WTRUs may not be aware of the complete topology of the FL operation. This can limit resource consumption in the direct device network. WTRUs may receive partial topology associated with their location. A WTRU may be authorized with more than one WTRU type. In this case, the aforementioned parameters (e.g., AI / ML processes / tasks) can be generated by each WTRU type that the WRTU is able to suppress.

Claims

1. A first network element, comprising: Processor, wherein the processor is configured to: Receive VFL information about performing collaborative tasks related to a longitudinal federated learning (VFL) application, wherein the VFL information includes a list of wireless transmit / receive units (WTRUs) participating in the VFL application, an identifier associated with each WTRU in the WTRU list, and quality of service (QoS) related parameters; The policy parameters are determined based on the VFL information regarding the execution of collaborative tasks related to the VFL application; as well as The policy parameters are sent to the second network element or WTRU.

2. The first network element as claimed in claim 1, wherein the policy parameters include one or more of a path type for federated learning services and one or more policy and charging control (PCC) rules, wherein the path type is one of Uu and PC5.

3. The first network element as claimed in claim 1, wherein the first network element includes a policy control function (PCF), wherein the processor is configured to generate the policy parameters based on the VFL information to determine the policy parameters, and wherein the policy parameters are sent to the second network element.

4. The first network element as described in claim 3, wherein the VFL information further includes a user ID, an indication of one or more federated learning (FL) or artificial intelligence / machine learning (AI / ML) models, one or more grouping filter sets, or an indication of one or more features or data types supported by the VFL application.

5. The first network element as claimed in claim 3, wherein the processor is configured to use the N2 interface to send the policy parameters and the QoS-related parameters to the RAN node via the Access and Mobility Management Function (AMF).

6. The first network element as claimed in claim 1, wherein the first network element includes a session management function (SMF), and wherein the processor is configured to receive the policy parameters from the third network element.

7. The first network element as described in claim 6, wherein the third network element includes a policy control function (PCF), wherein the policy parameters include policy charging and control (PCC) rules.

8. A method executed by a first network element, the method comprising: Receive VFL information about performing collaborative tasks related to a longitudinal federated learning (VFL) application, wherein the VFL information includes a list of wireless transmit / receive units (WTRUs) participating in the VFL application, an identifier associated with each WTRU in the WTRU list, and quality of service (QoS) related parameters; The policy parameters are determined based on the VFL information regarding the execution of collaborative tasks related to the VFL application; as well as The policy parameters are sent to the second network element or WTRU.

9. The method of claim 1, wherein the policy parameters include one or more of a path type for federated learning operations and one or more policy and charging control (PCC) rules, wherein the path type is one of Uu and PC5.

10. The method of claim 1, wherein the first network element includes a policy control function (PCF), the method further includes generating policy parameters based on the VFL information to determine the policy parameters, and wherein the policy parameters are sent to the second network element.

11. The method of claim 10, wherein the VFL information further includes a user ID, an indication of one or more federated learning (FL) or artificial intelligence / machine learning (AI / ML) models, one or more grouping filter sets, or an indication of one or more features or data types supported by the VFL application.

12. The method of claim 10, further comprising using the N2 interface to send the policy parameters and the QoS-related parameters to the RAN node via the Access and Mobility Management Function (AMF).

13. The method of claim 1, wherein the first network element includes a session management function (SMF), and the method further includes receiving the policy parameters from a third network element.

14. The method of claim 13, wherein the third network element includes a policy control function (PCF), and wherein the policy parameters include policy charging and control (PCC) rules.

15. A method implemented by a network element, the method comprising: Detect VFL events related to longitudinal federated learning (VFL) applications; Based on the detection of the VFL events, VFL parameters associated with the VFL application are generated, wherein the VFL parameters include one or more sidelink (SL) QoS rules, a list of cooperative WTRUs associated with the VFL application, and one or more features supported by the VFL application; and Send the parameters associated with the FL application.

16. The method of claim 15, wherein the VFL event includes a new cooperating WTRU joining the VFL application, an update to the VFL application, or an update to a feature supported by the VFL application.

17. The method of claim 15, wherein the VFL parameters include an indication of WTRU-to-WTRU connection status, an indication of whether the WTRU is a cooperative trunk WTRU or a non-trunk WTRU, or an indication of whether the WTRU is connected to one or more trunk WTRUs.

18. The method of claim 15, wherein the VFL parameters include a mapping or topology of the interconnectivity of a plurality of WTRUs associated with the VFL application.

19. The method of claim 15, wherein the VFL parameters include one or more grouping filter sets, instructions for a federated learning (FL) model or an artificial intelligence or machine learning (AI / ML) model, or a WTRU selection exit strategy or trigger.

20. The method of claim 15, wherein the network element includes an application function (AF) or an application service (AS), and wherein the parameters associated with the FL application are sent to a policy control function (PCF) or a session management function (SMF).

Images