Network enforcement of ai / ml distribution access control using modified akma

Abstract

A WTRU may receive, via a transceiver, a model distribution request via a user plane communication and / or a control plane communication. The WTRU may establish, via at least one user plane communication, an application session with an artificial intelligence (AI) / machine learning (ML) application function (AF). The WTRU may determine an AI or ML key to receive the model distribution. The WTRU may receive, via the transceiver, the model distribution from the AI / ML AF. The WTRU may verify a security level of the model distribution from the AI / ML AF using the AI / ML key.

Description

NETWORK ENFORCEMENT OF AI / ML DISTRIBUTION ACCESS CONTROL USING MODIFIED AKMACROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to United States Provisional Patent Application No. 63 / 518,919 filed in the United States of America on August 11 , 2023, the entire contents of which are incorporated herein by reference.BACKGROUND

[0002] An AI / ML model may be partitioned. One way to partition an AI / ML model may be via federated learning (FL). Federated Learning (FL) may be a machine learning paradigm where one or more (e.g., multiple) parties collaboratively execute machine learning models without having to centralize their data.SUMMARY

[0003] A wireless transmit / receive unit (WTRU) receive a model distribution request. The WTRU may send an application session establishment request. The WTRU may receive an application session establishment response. The WTRU may determine an application function (AF) key. The WTRU may determine an artificial intelligence (Al) and / or machine learning (ML) key (e.g., Al and / or ML AF key) to receive an Al model. The WTRU may receive the Al model from the AI / ML AF.

[0004] A WTRU may send a model distribution request. The WTRU may send an application session establishment request. The WTRU may receive an application session establishment response. The WTRU may determine an application function (AF) key. The WTRU may determine an artificial intelligence (Al) or machine learning (ML) key (e.g., Al and / or ML AF key) to send an Al model. The WTRU may perform Al or ML model watermarking by using the Al and / or ML key (e.g., Al and / or ML AF key). The WTRU may send the model to the AI / ML AF.

[0005] A WTRU may receive, via a transceiver, a model distribution request via a user plane communication and / or a control plane communication. The WTRU may establish, via at least one user plane communication, an application session with an artificialintelligence (Al) / machine learning (ML) application function (AF). The WTRU may determine an Al and / or ML key (e.g., Al and / or ML AF key) to receive the model distribution. The WTRU may receive, via the transceiver, the model distribution from the AI / ML AF. The WTRU may verify the security level of the model distribution from the AI / ML AF using the AI / ML key (e.g., Al and / or ML AF key).

[0006] The model distributed from the AI / ML AF may include a federated learning configuration. The WTRU may use the federated learning configuration to receive the model distribution and / or verify the security level of the model.

[0007] The WTRU may subscribe to the AI / ML AF to receive the model distribution request. For example, the WTRU may use an Al and / or ML key (e.g., Al and / or ML AF key) to subscribe to the AI / ML AF to receive the model distribution request. Receiving the model distribution request may include receiving one or more of a model identification (ID), environmental information, contextual information, and / or an indication that the model distribution is available to be distributed. The WTRU may use the model ID, the contextual information, and / or a watermark to verify the security level of the model distribution. The security level may restrict network access to a ML included in the model distribution. The environmental information may include one or more environmental parameters. Determining the Al and / or ML key (e.g., Al and / or ML AF key) may include binding the AI / ML key (e.g., Al and / or ML AF key) to the model ID and / or to the one or more environmental parameters.

[0008] The WTRU may determine a global model and / or a set of AI / ML features associated with the model distribution based on the Model ID. The WTRU may establish the application session with the AI / ML AF based on reception of the model distribution request. The model distribution request may indicate that a ML model is available. The WTRU may send an application session establishment request to establish the application session with the AI / ML AF. The WTRU may generate an authentication and key management (AKMA) key and / or and AKMA key ID (A-KID) based on a key associated with an authentication server function. The WTRU may receive a ML model protected using the AI / ML key (e.g., Al and / or ML AF key).BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0010] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0013] FIG. 2 depicts an example of three categories of federated-learning (FL).

[0014] FIG. 3 depicts a table that exemplifies a comparison of main characteristics between (e.g., conventional) horizontal FL (HFL), Vertical FL (VFL), and federated transfer learning (FTL).

[0015] FIGs. 4A and 4B depict an example flowchart illustrating network enforcement of artificial intelligence (Al) / machine learning (ML) distribution access control using modified authentication and key management for applications (AKMA).

[0016] FIGs. 5A and 5B depict an example flowchart illustrating network enforcement of AI / ML distribution control from the wireless transmit / receive unit (WTRU) to the AI / ML server.

[0017] FIGs. 6A and 6B depict an example flowchart depicting network enforcement for AI / ML data collection and / or AI / ML training delivery.

[0018] FIGs. 7A and 7B depict an example flowchart depicting a model distribution (e.g., over 5GC) using (e.g., 3GPP) network data analytics framework.DETAILED DESCRIPTION

[0019] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice,data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0020] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriptionbased unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a headmounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0021] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c,102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0022] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (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 wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e. , one for each sector of the cell. In an embodiment, the 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 may be used to transmit and / or receive signals in desired spatial directions.

[0023] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may 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 may be established using any suitable radio access technology (RAT).

[0024] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement aradio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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).

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

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

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

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

[0029] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones),a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0030] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E- UTRA, or WiFi radio technology.

[0031] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol(UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0033] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0034] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0035] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0037] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

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

[0039] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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, and the like.

[0040] The processor 118 may also be coupled to the 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 in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0041] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touchsensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0043] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0044] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0045] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0046] The CN 106 shown in FIG. 1 C 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 elements are depicted as part of the CN 106, itwill be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0047] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0048] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0049] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0050] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0051] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use(e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0052] In representative embodiments, the other network 112 may be a WLAN.

[0053] A WLAN in Infrastructure Basic Service 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 an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11 e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0054] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0055] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0056] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0057] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0058] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among allSTAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0059] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0060] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0061] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the 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 an embodiment, the gNBs 180a, 180b, 180c mayimplement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0063] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0064] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane informationtowards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0065] The CN 115 shown in FIG. 1 D 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 elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0066] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may 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 machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the 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.

[0067] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0068] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may 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.

[0069] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

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

[0071] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wirelesscommunication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0072] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0073] Embodiments are described herein for network enforcement of artificial intelligence (Al) / machine learning (ML) distribution access control using modified authentication and key management for applications (AKMA). The AI / ML AF:

[0074] The AI / ML application function (AF) may send (e.g., at 424 in FIG. 4A 400) a Naanf_AKMA_ApplicationKey_Get request to the network exposure function (NEF) with the AKMA Key ID (A-KID) to proxy the request to the AKMA anchor function (AAnF). The AAnF may request the KAF for the WTRU. KAF may refer to AKMA key shared between the AF and the WTRU. The AF may (e.g., also) include its identity (AF_ID), Model-ID, and / or environmental / contextual information (public land mobile network (PLMN) ID, cell ID, etc.), in the request.

[0075] The NEF may send (e.g., forward) (e.g., at 440 in FIG. 4B 401 ) the response to the AI / ML AF with the KAI / ML AF, the KAI / ML AF expiration time (KAI / ML AF exptime), and / or generic public subscription identifier (GPSI) (e.g., external ID). KAI / ML AF may be a session and / or intermediate key that the AI / ML AF may use for (e.g., either) protection of the Al model and / or for deriving one or more keys used for protection of the Al model during its distribution to the WTRU and / or for access control. Based on local policy, the NEF may use the Nudm_SubscriberDataManagement service to translate subscription permanent identifier (SUPI) to GPSI (e.g., external ID) and / or may include GPSI (e.g., external ID) in the response. If WTRU Id is not needed and / or indication is received inthe incoming request, the NEF may not provide the GPSI (e.g., external ID) to the AF. The NEF may not send the SUPI to the AF.

[0076] The AI / ML AF may protect (e.g., at 448 in FIG. 4B 401 ) the model it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF).

[0077] The NEF may receive (e.g., at 424 in FIG. 4A 400) a Naanf_AKMA_ApplicationKey_Get request from AAnF with the A-KID to request the application specific key (KAF) for the WTRU and / or may forward it to the AAnF. The AF may (e.g., also) include its identity (AF_ID), Model-ID, and / or environmental / contextual information (PLMN ID, cell ID, etc.), in the request.

[0078] The selected AAnF may receive (e.g., at 428 in FIG. 4A 400) from the NEF a Naanf_AKMA_ApplicationKey_Get request with the A-KID, Model-ID, and / or environmental / contextual information (PLMN ID, etc.) included in the message to request the KAF for the WTRU.

[0079] If an AKMA specific key (KAKMA) is not present in the AAnF, the AAnF may continue with an error response (e.g., at 430 of FIG. 4A 400). The AAnF may send a Nudm_SDM_Get Request (e.g., Identifier Translation, SUPI, query request for (environmental) parameters that are needed for AF key binding to the unified data management (UDM)).

[0080] The AAnF may receive (e.g., at 432 of FIG. 4B 401 ) the reply from the UDM with Nudm_SDM_Get Response (e.g., GPSI, query response on (environmental) parameters that are needed for AF key binding to AAnF).

[0081] The AAnF may cryptographically bind (e.g., at 436 of FIG. 4B 401 ) KAF with Model-ID and / or environmental / contextual information (PLMN ID, etc.) to produce K I / ML AF.

[0082] The AAnF may reply to the NEF (e.g., at 438 of FIG. 4B 401 ) with Naanf_AKMA_Application_Key_Get Response and / or may include KAI / ML AF, the KAI / L AF expiration time (KAI / ML AF exptime) instead of KAF, the KAF expiration time (KAF exptime).

[0083] The WTRU may derive (e.g., at 446 of FIG. 4B 401 ) a AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) from KAF by binding it to the Model ID and / or environmental parameters. For example, the AI / ML AF key may designate the entity that produced thekey (e.g., AF may reference the source of the key, the functional entity that produces the key). The WTRU may use (e.g., at 450 in FIG. 4B 401 ) a AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) from KAF that is bound to the Model ID and / or environmental parameters to enforce the network access control to the distributed AI / ML model.

[0084] Embodiments are described herein for network enforcement or AI / ML distribution control from the WTRU to the AI / ML server.

[0085] The WTRU may have trained a model, with a model ID, and / or the WTRU may send the model to an AIML AF (e.g., collaborative learning scenario). The same mechanism (e.g., as described herein, as shown in FIGs. 4A 400 and 4B 401 ) may take place, between the WTRU to the AIML AF via 5GC in the uplink direction. This approach may ensure that the WTRU is equipped to send the AIML Model to AIML AF assisted by network AIML access control.

[0086] The WTRU may decide (e.g., at 502 of FIG. 5A) the AIML model is ready for distribution.

[0087] The WTRU may send (e.g., at 504 of FIG. 5A) a Model Distribution Request (e.g., Model-ID, environmental / contextual information (PLMN-ID, etc.) to the AIML AF using the pre-established security context (e.g., see pre-condition #2, pre-requisite 2 of FIG. 5A).

[0088] As described herein, procedures 506 to 522 may be similar to procedures 422 to 438 of FIGs. 4A 400 and 4B 401 .

[0089] The NEF may forward (e.g., at 12 of FIG. 5B) the response to the AI / ML AF with the KAI / ML AF, the KAI / ML AF expiration time (KAI / ML AF exptime), and / or GPSI (e.g., external ID).

[0090] The AI / ML AF may send (e.g., at 13 of FIG. 5B) Application Session Establishment Response to the WTRU.

[0091] The WTRU may derive (e.g., at 14 of FIG. 5B) KAF from KAKMA.

[0092] The WTRU may derive (e.g., at 15 of FIG. 5B) a AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) from KAF by binding it to the Model ID and / or environmental parameters.

[0093] The WTRU may (e.g., also) protect the model (e.g., at 16 of FIG. 5B) it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) it derived at 15.

[0094] The WTRU may commence model distribution (e.g., at 17 of FIG. 5B) to the target AIML AF using application layer security established with AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF). The model may be bound to the Model ID, and / or contextual information, and / or could be watermarked to protect its ownership and / or provenance.

[0095] Embodiments are described herein for network enforcement for AI / ML data collection and / or AI / ML training delivery.

[0096] The access control mechanisms from the one or more embodiments described herein (e.g., as shown in FIGs. 5A-6B) can be used for the task of Data collection (e.g., data collection from the WTRU by the AI / ML server for the purpose of training and / or inference) and / or in the context of AI / ML model training (e.g., which may include data collection, and / or model transfer). FIGs. 6A-6B depict an example call flow diagram that illustrates how to use such mechanisms for AI / ML training between the WTRU and the AIML AF.

[0097] The same pre-requisites (e.g., as shown in FIGs. 4A and 5A) may be used herein.

[0098] The WTRU may derive (e.g., at 5 of FIG. 6A) AI / ML data collection (DC) AF Key (KAI ML DC AF) from KAF by binding it to the Dataset-ID , purpose , Model ID, and / or environmental parameters.

[0099] The WTRU may (e.g., also) protect the model (e.g., at 6 of FIG. 6A) it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML DC AF) it derived as described herein (e.g., at 5).

[0100] The WTRU may commence model distribution (e.g., at 7 of FIG. 6B) to the target AIML AF using application layer security established with AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML DC AF).

[0101] Embodiments are described herein for model distribution (e.g., over 5GC) using (e.g., 3GPP) network data analytics framework. A WTRU may subscribe to model distribution using an extended version of the 3GPP ML Model provisioning service. Forexample, the WTRU may receive, via a transceiver, the model distribution from the AI / ML AF using the AI / ML (e.g., AF) key. The WTRU may use the Al and / or ML (e.g., AF) key to subscribe to the AI / ML AF to receive the model distribution request. The security credentials can be used for the communication in one or more (e.g., both) directions. For example, the security credentials can be used to distribute the model from the server to the WTRU. For example, the security credentials may be used for the (e.g., trained) model submission from the WTRU to the AI / ML server.

[0102] The existing Nnwdaf_MLModelProvision_Subscribe service operation be extended for (e.g., to allow) one or more other entities, beyond the Network Data Analytics Function (NWDAF) to subscribe to Model Distribution services, including (e.g., 3GPP) Network Functions (e.g., session management function (SMF), application management function (AMF), policy control function (PCF)), Application Function (e.g., an AI / ML Application Function), and / or the WTRU. The WTRU can (e.g., also) subscribe to the ML Model Provisioning service, over (e.g., either) the User Plane (UP) and / or the Control Plane (CP). The WTRU can subscribe to this service over the CP, e.g., directly towards the Model Training Logical Function (MTLF), over a new service based interface (e.g., using a uplink (UL) non-access stratum (NAS) TRASPORT message and / or using a network function (NF) (e.g., SMF) as an anchor to contact the MTLF. When using the ML Provisioning Service over the UP, for example, the WTRU can contact the AI / ML AF to request that a model be provisioned from MTLF.

[0103] AI / ML model access control may be provided herein. AI / ML AF may compile the AI / ML Model and / or may distribute the model to the appropriate entities (e.g., WTRU and / or Edge Node) to be (e.g., either) used for direct prediction and / or inference.

[0104] While prediction may used to estimate the value of the response variable, inference may be used to understand the relationship between the predictors and the response variables.

[0105] There may be a (e.g., strong) desire to control the distribution of AI / ML models based on the Model ID and / or various environmental and / or contextual information.

[0106] A goal of the AI / ML model distribution access control may be to allow model access, and / or its use for prediction and / or inference to (e.g., only) authorized entities and / or (e.g., only) within the context for which the AI / ML model was developed.

[0107] An AI / ML model may be partitioned. One way to partition an AI / ML model may be via federated learning (FL). Federated Learning (FL) may be a machine learning paradigm where one or more (e.g., multiple) parties collaboratively execute machine learning models without having to centralize their data.

[0108] FIG. 2 depicts an example of three categories of FL 200. Three categories of FL may include: Horizontal Federated Learning (HFL) 225; Vertical Federated Learning (VFL) 250; and Federated Transfer Learning (FTL) 275. In HFL 225, the participants may share the same feature space while holding different data. In VFL 250, each party may keep (e.g., both) its data and / or model local but exchange intermediate computed results. In FTL 275, datasets may differ in (e.g., both) feature and / or sample spaces with limited overlaps. For example, electroencephalogram (EEG) data from one or more (e.g., multiple) subjects with heterogeneous distributions collaboratively build braincomputer interface (BCI_ models using FTL).

[0109] Due to their differences in data partitions, for example, HFL 225 and VFL 250 may adopt (e.g., very) different training protocols. Each party in HFL 225 may train a local model and / or may exchanges model update(s) (e.g., parameters and / or gradients) with a server, which aggregates the updates and / or sends the aggregating result back to each party. While in VFL, each party may keep both its data and model local but exchange intermediate computed results. The output of the HFL training procedure may be a global model shared among one or more (e.g., all) parties, while each party in the VFL may own a separate local model after training. During inference time, for example, each party in HFL may use the global model separately, while one or more parties in VFL may (e.g., need to) collaborate to make inferences. FL can also be categorized into cross-device and / or cross-silo settings. The cross-device FL may involve one or more (e.g., a vast number of) mobiles and / or edge devices as the participating parties. In contrast, for example, the participating parties in the cross-silo FL may (e.g., typically) include a limited number of organizations. HFL can be either cross-device or cross-silo FL, while VFL (e.g. , typically) may belong to the cross-silo FL.

[0110] FIG. 3 depicts an example comparison 300 of main characteristics between HFL, VFL, and FTL. Moreover, allowing one or more (e.g., all) nodes to hold the complete feature set, may not be realistic and / or secure. Therefore, VFL may provide a (e.g., more)promising federated learning, where different features may be vertically distributed across participants (e.g., vertical federated learning (VFL)).

[0111] In VFL, each party may (e.g., only) have a disjoint subset of features. VFL may have been gaining traction for use cases where privacy is critical for use cases such as, military, finance, and / or healthcare. For example, consider two different companies in the same city, one is a bank, and the other is an e-commerce company. Their user sets may be likely to include most of the residents of the area, so the intersection of their user space may be large. Since the bank records the user’s revenue and / or expenditure behavior and / or credit rating, and / or the e-commerce retains the user’s browsing and purchasing history, their feature spaces may be very different. Both parties may have a prediction model for product purchase based on user and product information.

[0112] Al Model may be owned by the mobile network operator (MNO), be in MNO custody, and / or be owned / in custody of a 3rd Party (e.g., AF). Its distribution may be achieved over the UP (e.g., over the top (OTT)), over the 5G core network (CN)- controlled UP, or the CP (e.g., unlikely for large models).

[0113] Many chip-vendor companies may support (e.g., only) OTT UP-based model distribution.

[0114] Controlling and / or enforcing which parties (e.g., WTRUs and / or Edge Nodes) can use and / or modify Al models may be addressed herein. Controlling and / or enforcing a particular (e.g., higher) level of security based on the MNO / AF policy and / or environmental factors (e.g., contextual information) may be addressed herein.

[0115] How to enforce that the Al model that is either owned by the MNO, in MNO custody, and / or owned by a third Party AF may be used (e.g., and / or modified) (e.g., only used and / or modified) by the intended entity may be addressed herein. How to make sure that (e.g., only) the model that is intended to be used on a particular network is used by the WTRU on that network may be addressed herein.

[0116] The terms environmental information and contextual information may be used interchangeably herein; the terms may denote the environment and / or the context (e.g., external conditions) in which the model may be (e.g., either) distributed and / or intended to work. Examples of environmental and / or contextual information are PLMN ID, cell ID, serving area ID, time of day, date of the year, and / or weather conditions.

[0117] Embodiments may be described herein with respect to network enforcement of AI / ML distribution access control using modified AKMA.

[0118] FIGs. 4A and 4B depict an example flowchart illustrating network enforcement of artificial intelligence (Al) / machine learning (ML) distribution access control using modified authentication and key management for applications (AKMA) 400, 401.

[0119] Pre-requisite 1 414 (e.g., Pre-condition #1 ) may include the following. Before communication between the WTRLI 402 and the AKMA AF can start, the WTRU 402 and / or the AKMA AF may (e.g., need to) know whether to use AKMA. This knowledge may be implicit in the specific application of the WTRU 402 and the AKMA AF and / or indicated by the AKMA AF to the WTRU 402.

[0120] Pre-requisite 2 416 (e.g., Pre-condition #2) may include the following. The WTRU 402 may have to establish security context over UP with AI / ML AF 410. Such security context may be established using (e.g., 3GPP) bootstrapping functionality, pre-existing and / or pre-provisioned credentials, and / or one or more (e.g., any) available method(s). If AKMA is used for pre-condition 2 416, procedures 434 (e.g., in the AAnF 406) and / or procedure 444 (e.g., in the WTRU 402) can be skipped.

[0121] At 418, the AI / ML AF 410 may decide that the ML model is ready for distribution. In case VFL, FTL, and / or a hybrid learning framework is used, for example, the AF may decide that vertical and / or horizontal FL configuration is ready for distribution.

[0122] At 420, the AI / ML AF 410 may send a Model Distribution Request (e.g., Model- ID, environmental / contextual information (PLMN-ID, etc.) to the WTRU 402 using the pre-established security context (e.g., see pre-condition #2 416). For example, a WTRU may receive, via a transceiver, a model distribution request via a user plane communication and / or a control plane communication. The request 420 may indicate to the WTRU 402 that another (e.g., new) model is available but does not include the ML model. Additionally or alternatively, the WTRU 402 may have subscribed with the AI / ML AF 410 to receive Model Distribution notifications indicating that another (e.g., new) ML model is available. For example, the WTRU 402 may use the Al and / or ML (e.g., AF) key to subscribe the AI / ML AF 410 to receive the model distribution request (e.g., ML model). The WTRU may receive an ML model protected using the AI / ML (e.g., AF) key (e.g., to decrypt the ML Model). In scenarios where VFL, FTL, and / or a hybrid learningframeworks are used, for example, the Model-ID may be used for uniquely identifying a global model and / or a set of AI / ML features (e.g., may be specified as a description of the outcome of the features, without disclosing what exactly the features are). For example, the WTRU may determine a global model and / or a set of AI / ML features associated with the model distribution based on the Model ID.

[0123] At 422, upon receiving the Model Distribution Request and / or Notification, the WTRU 402 may initiate communication with the AI / ML AF 410 and / or may include the derived A-KID in the Application Session Establishment Request message. For example, the WTRU may send an application establishment request to establish the application session with the AI / ML AF. The WTRU 402 may generate the AKMA Anchor Key (KAKMA) and an AKMA Key ID (A-KID) from the KAUSF before initiating communication with the AI / ML Application Function. For example, the WTRU may generate an AKMA and / or the (A-KID) based on a key associated with an authentication server function. The AUSF 404 may be a part of the (e.g., 5G) Core Network architecture. The AUSF 404 may produce the key KAUSF. The WTRU 402 may derive KAF (e.g., see procedure 444) before initiating the communication with the AI / ML AF 410 and / or afterward.

[0124] At 424, the AI / ML AF 410 may send a Naanf_AKMA_ApplicationKey_Get request to a AAnF 406 with the A-KID to request the KAF for the WTRU 402. The AF may (e.g., also) include its identity (AF_ID), Model-ID, and / or environmental / contextual information (PLMN ID, cell ID, etc.), in the request. For example, the WTRU 402 receiving, via the transceiver, the model distribution request may include the WTRU 402 receiving one or more of a model identification (ID), environmental information, contextual information, and / or an indication that the model distribution is available to be distributed. The environmental information may include one or more environmental parameters. Environmental and / or contextual information may include one or more of a day of the year, a time of the day, geolocation information (e.g., elevation, weather information, PLMN ID, IMSI / SUPI IMEI).

[0125] At 426, if the AI / ML AF 410 is authorized by the NEF 408, the NEF 408 may discover and / or may select an AAnF.

[0126] At 428, the NEF 408 may send a Naanf_AKMA_ApplicationKey_Get request to the selected AAnF 406 with the A-KID, Model-ID, and / or environmental / contextual information (PLMN ID, etc.) included in the message to request the KAF for the WTRU 402.

[0127] At 430, if KAKMA is present in AAnF 406, (e.g., see Pre-requisite #1 414) the AAnF 406 may continue with procedure 434. If KAKMA is not present in the AAnF 406, the AAnF 406 may continue with procedure 430 with an error response. The AAnF 406 may send Nudm_SDM_Get Request to the UDM. The request 430 may include an Identifier Translation, SUPI, and / or (e.g., environmental) parameter identifiers that are included (e.g., needed) for AF key binding. The request 430 may ask for parameter identifiers and / or receive parameter values.

[0128] At 432, the UDM 412 may reply to the AAnF 406 with Nudm_SDM_Get Response. The response 432 may include GPSI, and / or (e.g., environmental) parameters values that are included (e.g., needed) for AF key binding to AAnF 406.

[0129] At 434, the AAnF 406 may derive KAF from KAKMA

[0130] At 436, the AAnF 406 may (e.g.., cryptographically) bind KAF with Model-ID and / or environmental / contextual information (PLMN ID, etc.) to produce KAI / ML AF and / or to determine a KAI / ML AF expiration time.

[0131] At 438, the AAnF 406 may reply to the NEF with Naanf_AKMA_Application_Key_Get Response and / or may include KAI / ML AF, the KAI / ML AF expiration time (KAI / ML AF exptime) instead of KAF, the KAF expiration time (KAF expire).

[0132] At 440, the NEF 408 may forward the response to the AI / ML AF 410 with the KAI / ML AF, the KAI / ML AF expiration time (KAI / ML AF exptime), and / or GPSI (e.g., external ID). Based on local policy, for example, the NEF may use the Nudm_SubscriberDataManagement service to translate SUPI to GPSI (e.g., external ID) and / or may include GPSI (e.g., external ID) in the response. If WTRU Id is not needed and / or indication is received in the incoming request, for example, the NEF 408 may not provide the GPSI (e.g., external ID) to the AF. The NEF 408 may not send the SUPI to the AF.

[0133] At 442, the AI / ML AF 410 may send an Application Session Establishment Response to the WTRU 402. For example, the WTRU may establish, via at least oneuser plane communication, an application session with an artificial intelligence (Al) I machine learning (ML) application function (AF). The WTRII may establish the application session with the AI / ML AF based on reception of the model distribution request. The model distribution request may indicate that a ML model is available.

[0134] At 444, the WTRU 402 may derive KAF from KAKMA. For example, the WTRU may determine an Al and / or ML AF key to receive the model distribution. The model distribution may include the AI / ML model. When the model is distributed from its source to its destination, for example, the package (e.g., model distribution) may include the ML model. Determining the Al and / or ML AF key may include binding the AI / ML Key to the Model ID and / or to one or more environmental parameters (e.g., as described herein). For example, when the source of the model binds the model protection key to the Model ID and / or one or more environmental parameters, the destination may be able to decrypt the model with correct decryption key, which may (e.g., also) be bound to the same one or more parameters (e.g., the Model ID and / or environmental parameters).

[0135] At 446, the WTRU 402 may derive AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) from KAF by binding it to the Model ID and / or environmental parameters.

[0136] At 448, additionally or alternatively, the AI / ML AF 410 may protect the model it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF). This may be achieved by the AI / ML AF 410 as soon as it obtains the KAI / ML AF (e.g. based on procedure 440). In scenarios where VFL, FTL, and / or a hybrid learning framework is used, a feature description and / or related meta data / configuration information may be shared with the WTRU. Therefore, it may the protect this information from provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF). This may be achieved by the AI / ML AF 410 as soon as it obtains the KAI / ML AF (e.g. based on procedure 440).

[0137] At 450, the AI / ML AF 410 may commence model distribution to the target WTRU using application layer security established with AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF). The model distribution may include the distribution of the AI / ML model. For example, the WTRU 402 may receive, via the transceiver, the model distribution from the AI / ML AF 410. The WTRU may receive an ML model using the AI / ML key (e.g., Al and / or ML AF key). The WTRU 402 may verify a security level of the model distributionfrom the AI / ML AF 410 using the AI / ML key (e.g., Al and / or ML AF key). The security level may restrict network access to a ML model included in the model distribution. The security level may include a value that corresponds to the encryption key size. For example, 1 may correspond to a 128-bit key, 2 may correspond to a 256-bit key, and / or 3 may correspond to a 512-bit key. For example, as described herein (e.g., with respect to FIGs. 4A-4B), the model may be bound to the Model ID, and / or contextual information, and / or could be watermarked to protect its ownership and / or provenance. For example, the WTRU 402 may use the Model ID, the contextual information, and / or a watermark to verify the security level of the model distribution. For example, the Model ID and / or the contextual information may be input(s) in the encryption key; without the correct Model ID, and / or the contextual information, the destination of the model distribution may not be able to produce the correct decryption key for the model decryption. The model distributed from the AI / ML AF 410 may include a federated learning configuration, as described herein. The WTRU 402 may use the federated learning configuration to receive the model distribution and / or verify the security level of the model distribution.

[0138] Embodiments are described herein for network enforcement or AI / ML distribution from the WTRU to the AI / ML server.

[0139] In examples, a similar approach may be adopted for a scenario when the WTRU has trained a model, with a model ID, and / or the WTRU sends the model to an AI / ML AF (e.g., collaborative learning scenario). The same mechanism (e.g., with respect to FIGs. 4A 400 and 4B 401) may take place, between / from the WTRU to the AI / ML AF via 5GC in the uplink direction. This approach may ensure that the WTRU is equipped to send AI / ML model to the AI / ML AF assisted by network AI / ML access control.

[0140] FIGs. 5A and 5B depict an example flowchart illustrating network enforcement of AI / ML distribution control from the wireless transmit / receive unit (WTRU) 501 to the AI / ML server 500, 525. The same pre-requisites (e.g., pre-requisites 1 414 and prerequisite 2 416 as shown in FIGs. 4A) may be used herein.

[0141] At 502, the WTRU 501 may decide the AIML model is ready for distribution.

[0142] At 504, the WTRU 501 may send a Model Distribution Request (e.g., Model-ID, environmental / contextual information (PLMN-ID, etc.) to the AIML AF using the pre- established security context (e.g., see pre-condition #2)

[0143] Procedures 506 to 522 may be similar to procedures 422 to 438 of FIGs. 4A-4B.

[0144] At 524, the NEF 507 may forward the response to the AI / ML AF 509 with the KAI / ML AF, the KAI / ML AF expiration time (KAI / ML AF exptime), and / or GPSI (e.g., external ID).

[0145] At 526, the AI / ML AF 509 may send a Application Session Establishment Response to the WTRU 501 .

[0146] At 528, the WTRU 501 may derive KAF from KAKMA

[0147] At 530, the WTRU 501 may derive AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) from KAF by binding it to the Model ID and / or environmental parameters.

[0148] At 532, the WTRU 501 may (e.g., also) protect the model it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF) (e.g., derived at 530).

[0149] At 534, the WTRU 501 may commence model distribution to the target AIML AF using application layer security established with AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML AF). The model may be bound to the Model ID, and / or contextual information, and / or could be watermarked to protect its ownership and / or provenance.

[0150] Embodiments are provided herein for network enforcement for AI / ML data collection and / or AI / ML training delivery.

[0151] The (e.g., general) framework (with respect to FIGs. 4A-5B)may be used for one or more tasks additional to AI / ML model prediction and / or inference. The one or more mechanisms (e.g., with respect to FIGs. 4A-5B) for the task of Data collection (e.g., data collection from the WTRU by the AI / ML server for the purpose of training and / or inference), and / or in the context of AI / ML model training (e.g., which may include data collection, and / or model transfer) may (e.g., also) be used herein.

[0152] FIGs. 6A and 6B depict an example flowchart depicting network enforcement for AI / ML data collection and / or AI / ML training delivery 600, 625. For example, FIGs. 6A and 6B may describe an example of how to use such mechanisms for AI / ML training between the WTRU and the AIML AF. The same pre-requisites (e.g., pre-requisites 1 and 2 as shown in FIGs. 4A and 5A) may be used herein.

[0153] At 602, training data may be ready at the WTRU 601 to be collected (e.g., transferred to the AIML AF).

[0154] At 604, the WTRU 601 may send a Data collection request to the AI / ML AF including (e.g., Dataset-ID, purpose, Model-ID, and / or environmental / contextual information (PLMN-ID, etc.)).

[0155] At 606, the same procedures (e.g., procedures 506 to 522 of FIGs. 5A-5B may be similar to procedures 422 to 438 of FIGs. 4A-4B) may be performed. The Aanf 603 may generate (e.g., at some point) a AIML DC AF key by binding AF key with environment parameters including dataset-ID, purpose and / or model-ID.

[0156] At 608, the WTRU 601 may derive KAF from KAKMA.

[0157] At 610, the WTRU 601 may derive AI / ML DC AF Key (KAI / ML DC AF) from KAF by binding it to the Dataset-ID, purpose, and / or Model ID and / or environmental parameters.

[0158] At 612, the WTRU 601 may (e.g., also) protect the model it is distributing from model provenance infringement by watermarking it with the AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML DC AF) (e.g., derived at 610).

[0159] At 614, the WTRU 601 may commence model distribution to the target AIML AF 605 using application layer security established with AI / ML Key (e.g., Al and / or ML AF key) (KAI / ML DC AF).

[0160] Once the data is collected at the AIML AF, for example, it may be used for training.

[0161] Once the training is ready (e.g., at 616), the trained ML model may ready for distribution to the WTRU.

[0162] The embodiments herein may implement a similar procedure to that shown with respect to FIGs. 4A and 4B (e.g., procedures 420 to 442). The AIML AF 605 may receive (e.g., at the end of this procedure) a AI / ML training key (TR) AF and / or KAI / ML TR AF from the AAnF 603 (e.g., which may be different from the AI / ML DC AF Key and / or KAI / ML DC AF because it may be bound to one or more different parameters from the key for data collection).

[0163] At 622, the WTRU 601 may be able to derive the AI / ML TR AF key and / or (e.g., hence) the AIML AF 605 can send the model with model-ID and / or the WTRU 601 may be able to recover the model using the derived KAI / ML TR AF key.

[0164] At 624, the AI / ML AF 605 may watermark the AI / ML model for provenance and / or ownership protection, for example, by using the AI / ML TR AF key to produce watermark.

[0165] At 626, the AI / ML AF 605 may send the (e.g., trained) model distribution (e.g., model-ID, ML model) to the WTRU 601 .

[0166] Embodiments may be described herein for a model distribution (e.g., over 5GC) using (e.g., 3GPP) network data analytics framework. A WTRU may subscribe to model distribution using an extended version of the 3GPP ML Model provisioning service.

[0167] The existing Nnwdaf_MLModelProvision_Subscribe service operation may be extended to allow other entities, beyond the NWDAF, to subscribe to Model Distribution services, including 3GPP Network Functions (e.g., SMF, AMF, PCF), Application Function (e.g., an AIML Application Function), and / or the WTRU. The WTRU can (e.g., also) subscribe to the ML Model Provisioning service, over (e.g., either) the User Plane (UP) and / or the Control Plane (CP). The WTRU can subscribe to this service over the CP, e.g., directly towards the MTLF, over another (e.g., new) service based interface, e.g., using a UL NAS TRASPORT message and / or using a NF (e.g., SMF) as an anchor to contact the MTLF. When using the ML Provisioning Service over the UP, for example, the WTRU can contact the AIML AF to request that a model be provisioned from MTLF.

[0168] The procedure may be Network Initiated. The AIML AF may request ML Model Distribution either directly from the MTLF or through the NEF. Two or more delivery alternatives may be included herein. Delivery Alternative 1 may include the AIML AF receiving the model and distributing it to the WTRU via the UP. Delivery Alternative 2 may include the AIML AF requesting that the model be delivered from the MTLF directly to the WTRU over CP (e.g., a downlink (DL) NAS TRANSPORT message)

[0169] The procedure may be WTRU initiated. The WTRU may request the model through AIML AF over the UP (e.g., the procedures may be the same as in a network initiated procedure). Additionally or alternatively, the WTRU may request the model over the CP, and / or the following alternative(s) can be used: A direct request from the WTRU to the MTLF (e.g., using new NAS TRANSPORT message); and / or a request through an anchor NF such as the SMF.

[0170] FIGs. 7A and 7B illustrate the different alternatives that may enable (e.g., either, both) the Network Initiated and / or WTRU initiated ML Model distribution, using the 5GC Network Data Analytics Function 700, 725. For example, FIGs. 7A and 7B depict an example 5GC-based model provisioning request using NWDAF.

[0171] At 702, the WTRU 701 may determine that another (e.g., new) Model is required to, e.g., enable AI / ML inference according to certain business logic (e.g., image recognition).

[0172] At 704a, the WTRU 701 may request Model Provisioning from the AIML AF 703, and / or it may provide details of the type of model as well as environmental / contextual information, (e.g., as described herein).

[0173] At 706a, the AIML AF 703, as a result of a WTRU request (e.g., WTRU initiated) and / or as a result of an internal event (NW initiated), may subscribe to Model Provisioning and / or it may indicate to the NWDAF (e.g., MTLF) whether it wants the notification to be delivered to it (e.g., the AMFL AF itself) and / or to a WTRU (e.g., 701 ) and / or one or more WTRUs.

[0174] At 708a, if the AIML AF 703 requested that the model be delivered to it, for example, the NWDAF may notify about another (e.g., new) model build (e.g., according to the request at 706a).

[0175] At 710a1 , if the AIML AF 703 requested that the model be delivered to it, for example, the AI / ML AF 703 may forward the notification from the NWDAF to a WTRU (e.g., 701 ) and / or the WTRU for which this model is relevant (e.g., additionally or alternatively).

[0176] At 710a2, if the AIML AF requested that the model be delivered to the WTRU, for example, the NWDAF may deliver the model (e.g., directly) to a WTRU and / or one or more WTRUs as per request in step 3a.

[0177] At 704b, the WTRU 701 (e.g., using a NAS TRANSPORT message) may request ML Model provisioning (e.g., directly from the MTLF and / or through a NF, such as SMF).

[0178] At 706b, if the WTRU 701 requested ML Model Provisioning through an anchor function, e.g., the SMF, the one or more NFs that serve(s) as an anchor, may relay the WTRU request to the NWDAF (e g., MTLF).

[0179] At 708b, the MTLF may notify the WTRLI 701 and / or another WTRU about the relevant model(s) request at 704b.

Claims

CLAIMS:1 . A wireless transmit / receive unit (WTRU) comprising: a processor and a transceiver, the processor configured to: receive, via the transceiver, a model distribution request via a user plane communication or a control plane communication; establish, via at least one user plane communication, an application session with an artificial intelligence (Al) I machine learning (ML) application function (AF); determine an Al or ML key to receive the model distribution; receive, via the transceiver, the model distribution from the AI / ML AF; and verify a security level of the model distribution from the AI / ML AF using the AI / ML key.

2. The WTRU of claim 1 , wherein the received model distributed from the AI / ML AF comprises a federated learning configuration, wherein the processor is further configured to use the federated learning configuration to receive the model distribution or verify the security level of the model distribution.

3. The WTRU of claim 1 or 2, wherein the processor is configured to use the Al or ML key to subscribe to the AI / ML AF to receive the model distribution request.

4. The WTRU of any of claims 1 to 3, wherein the processor being configured to receive, via the transceiver, the model distribution request comprises the processor being configured to receive, via the transceiver, one or more of a model identification (ID), environmental information, contextual information, or an indication that the model distribution is available to be distributed.

5. The WTRU of claim 4, wherein the processor is configured to use the Model ID, the contextual information, or a watermark to verify the security level of the modeldistribution, wherein the security level restricts network access to a ML model comprised in the model distribution.

6. The WTRU of claim 4 or 5, wherein the environmental information comprises one or more environmental parameters, and wherein the processor being configured to determine the Al or ML AF key comprises the processor being configured to bind the AI / ML key to the model ID and to the one or more environmental parameters.

7. The WTRU of any of claims 4 to 6, wherein the processor is configured to determine a global model or a set of AI / ML features associated with the model distribution based on the Model ID.

8. The WTRU of claim 1 , wherein the processor is further configured to establish the application session with the AI / ML AF based on reception of the model distribution request, wherein the model distribution request indicates that a ML model is available.

9. The WTRU of any of claims 1 to 8, wherein the processor is configured to send an application session establishment request to establish the application session with the AI / ML AF.

10. The WTRU of any of claims 1 to 9, wherein the processor is further configured to generate an authentication and key management (AKMA) key and AKMA key ID (A- KID) based on a key associated with an authentication server function.11 . The WTRU of any of claims 1 to 10, wherein the processor is configured to receive an ML model protected using the AI / ML key.

12. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving a model distribution request via a user plane communication or a control plane communication;establishing, via at least one user plane communication, an application session with an artificial intelligence (Al) I machine learning (ML) application function (AF); determining an Al or ML key to receive the model distribution; receiving the model distribution from the AI / ML AF; and verifying a security level of the model distribution from the AI / ML AF using the AI / ML key.

13. The method of claim 12, wherein the received model distributed from the AI / ML AF comprises a federated learning configuration, wherein the processor is further configured to use the federated learning configuration to receive the model distribution or verify the security level of the model distribution.1 . The method of claim 12 or 13, further comprising using the Al or ML key to subscribe to the AI / ML AF to receive the model distribution request.

15. The method of any of claims 12 to 14, wherein receiving the model distribution request comprises receiving one or more of a model identification (ID), environmental information, contextual information, or an indication that the model distribution is available to be distributed.

16. The method of claim 15, further comprising using the Model ID, the contextual information, or a watermark to verify the security level of the model distribution, wherein the security level restricts network access to a ML model comprised in the model distribution.

17. The method of claim 15 or 16, wherein the environmental information comprises one or more environmental parameters, and wherein determining the Al or ML AF key comprises the binding the AI / ML key to the model ID and to the one or more environmental parameters.

18. The method of any of claims 15 to 17, further comprising determining a global model or a set of AI / ML features associated with the model distribution based on theModel ID.

19. The method of claim 12, further comprising establishing the application session with the AI / ML AF based on reception of the model distribution request, wherein the model distribution request indicates that a ML model is available.

20. The method of any of claims 12 to 19, further comprising sending an application session establishment request to establish the application session with the AI / ML AF.21 . The method of any of claims 12 to 20, further comprising generating an authentication and key management (AKMA) key and AKMA key ID (A-KID) based on a key associated with an authentication server function.

22. The method of any of claims 12 to 21 , further comprising receiving an ML model protected using the AI / ML key.

Images