EP4690888A1

EP4690888A1 - Class of security qualification measurements and capability evaluation

Info

Publication number: EP4690888A1
Application number: EP24722884.4A
Authority: EP
Inventors: Zhibi Wang; Saad Ahmad; Ulises Olvera-Hernandez; Achref METHENNI; Samir Ferdi
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-04-03
Filing date: 2024-04-03
Publication date: 2026-02-11
Also published as: WO2024211364A1; CN120937405A

Abstract

A Wireless Transmit/Receive Unit (WTRU) may send a request for CoS. The CoS may include an indication of a security confidence level, for example associated with the WTRU. The WTRU may receive a CoS, for example from a network. The received CoS may be evaluated based on one or more parameters. The WTRU may receive an operation start message, for example an artificial intelligence machine learning (AIML) start message. The operation start message may be based on the received CoS. The WTRU may receive the operation start message when the evaluated CoS matches a desired CoS. The one or more parameters may include a security profile, for example associated with the WTRU. The security profile may include one or more of a hardware profile and/or a software profile.

Description

Class of Security Qualification Measurements and Capability Evaluation

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No. 63/456,647 filed on April 03, 2023, the entire contents of which are incorporated herein by reference.

BACKGROUND

[0002] A wireless transmit/receive unit (WTRU) may play a role in connection other WTRUs to a network, for example in the 5GS and/or future generation of wireless communication. The WTRU may play a role in connecting other WTRUs to the network in addition to the role as a regular terminal device, for example as AI/ML Splitting, WTRU Relay, and/or etc. For example, the WTRU may behave as an intermediate node to process data and/or relay the traffic from other WTRUs to the downstream network. The WTRU may additionally, or alternatively, perform functionalities such as data/model distribution and/or part of AI/ML inference, for example before forwarding downstream. The WTRU may process the data, for example utilizing hardware and/or software capabilities such as secure environment, security protocols supported, security algorithms supported, performance needed to deliver the tasks, latest software patches, and/or capabilities of a server such as an artificial intelligence Al/machine learning (ML) application server (AS) and/or authentication server/gateway.

SUMMARY

[0003] A WTRU may include a processor. The processor may be configured to send a classification of security (CoS), receive an evaluated CoS (e.g., from a network data analytics function (NWDAF) and/or from a unified data manager (UDM)), and/or receive an operation start message. The operation start message may be based on the evaluated CoS. The evaluated CoS may be evaluated based on the WTRU CoS and/or one or more parameters. An operation start message may be sent from an application function (AF) to the WTRU, for example when the CoS matches a desired CoS. The one or more parameters may include a WTRU security profile.

[0004] The processor may be configured to send a request message to an AF. The request message may be associated with an AI/ML splitting discovery. The processor may be configured to receive an AI/ML selection message from the AF and/or perform AI/ML splitting. The processor may be configured to send a discovery request message to a network and/or receive a discovery response message. The discovery request message may include a WTRU identifier and/or a classification of security (CoS). The discovery response message may be generated, for example by a network direct discovery name management function (DDNMF). Additionally, or alternatively, the discovery response message may be generated may be based on the WTRU identifier and/or the CoS. The WTRU identifier may comprise a restricted proximity service (ProSe) application user ID (RPAUID). [0005] A network may receive a CoS from a WTRU. The network may evaluate the CoS at a NWDAF. For example, the network may evaluate the (e.g., evaluated) CoS based on one or more parameters. A security confidence level may be evaluated based on one or more of the CoS and/or one or more parameters. The network may send an operation start message to the WTRU. The operation start message may be based on the evaluated CoS. The operation start message may be sent from an AF to the WTRU when the CoS matches a desired CoS. The one or more parameters may include a WTRU security profile. The network may receive a request message at an AF. The request message may be associated with an AI/ML splitting discovery. The network may send an AI/ML selection message from the AF to the WTRU. The AI/ML selection message may be sent from the AF to the WTRU when the CoS matches a desired CoS. The network may receive, for example from a WTRU, a discovery request message. The discovery request message may include a WTRU identifier and/or a CoS. The network may generate a discovery response message, for example by a DDNMF. The discovery response message may be based on the WTRU identifier and/or the CoS. The WTRU identifier may include a restricted ProSe application user ID (RPAUID). [0006] A WTRU may send a request for CoS. The CoS may include an indication of a security confidence level, for example associated with the WTRU. The WTRU may receive a CoS, for example from a network. The received CoS may be evaluated based on one or more parameters. The WTRU may receive an operation start message, for example an artificial intelligence machine learning (Al ML) start message. The operation start message may be based on the received CoS. The WTRU may receive the operation start message when the evaluated CoS matches a desired CoS. The one or more parameters may include a security profile, for example associated with the WTRU. The security profile may include one or more of a hardware profile and/or a software profile.

[0007] The WTRU may receive the evaluated CoS from a network data analytics function (NWDAF). The evaluated CoS may be evaluated based on one or more of a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, and/or a referral from another entity. The CoS may be evaluated by the network. The indication of the security confidence level may alternatively, or additionally, be associated with an intermediate node function. The WTRU may send data, for example based on an analytics filter. The analytic filter may include one or more of an area of interest (Aol), single - network slice assistance information (S-NSSAI), DNN, a traffic characteristic, a valid application identifier, a target of analytic reporting, a traffic usage threshold, a security profile associated with the WTRU, and/or an authorization associated with the WTRU.

[0008] A network entity may receive request for a CoS. The CoS may include an indication of a security confidence level, for example associated with a WTRU. The network entity may evaluate the CoS, for example based on one or more parameters. The network entity may send the evaluated CoS, for example to the WTRU. The network entity may send an operation start message, for example to the WTRU. The operation start message may be based on the evaluated CoS.

[0009] The network entity may receive data, for example based on an analytics filter. Additionally, or alternatively, the network entity may evaluate the CoS based on the received data. The network entity may compare the evaluated CoS to a desired CoS. The network entity may send the operation start message when the evaluated CoS matches the desired CoS.

[OO1 O] The one or more parameters may include a security profile, for example associated with the WTRU. The security profile may include one or more of a hardware profile and/or a software profile. The network entity may send the evaluated CoS, for example to the WTRU, from a network data analytics function (NWDAF). The network entity may evaluate the CoS based on one or more of a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, and/or a referral from another entity. The indication of the security confidence level may alternatively, or additionally, be associated with an intermediate node function.

[0011] A WTRU may send a discovery request message, for example to a network. The discovery request message may include one or more of a WTRU identifier and/or a CoS. The WTRU may receive a discovery response message, for example from the network. The discovery response message may be generated by a network direct discovery name management function (DDNMF). The discovery message may be generated based on one or more of the WTRU identifier and/or the CoS The WTRU identifier may include a restricted ProSe application user ID (RPAUID).

[0012] Additionally, or alternatively, a security confidence level may be evaluated based on one or more of the CoS and/or one or more parameters. The one or more parameters may include a WTRU security profile. The security profile may include one or more of a hardware profile and/or a software profile. The one or more parameters may include one or more of a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, and/or a referral from another entity. The WTRU may receive an operation start message, for example from the network. The operation start message may be based on an evaluated CoS. The WTRU may receive the operation start message when the evaluated CoS matches a desired CoS. The CoS may include an indication of a security confidence level, for example associated with the WTRU. The indication of the security confidence level may alternatively, or additionally, be associated with an intermediate node function.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0015] FIG. 1C 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. [0016] 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.

[0017] FIG. 2 illustrates an example of a CoS procedure.

[0018] FIG. 3 illustrates an example of CoS exchanges between a WTRU and a network. [0019] FIG. 4 illustrates an example of a CoS procedure with AI/ML splitting.

[0020] FIG. 5 illustrates an example of a CoS discovery request procedure.

[0021] FIG. 6 illustrates an example of a CoS discovery procedure for AI/ML splitting.

DETAILED DESCRIPTION

[0022] 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 uniqueword DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0023] 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 ON 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 subscription-based 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 head-mounted 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.

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

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

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

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

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

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

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

[0032] The base station 114b in FIG. 1 A 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 ON 106/115. [0033] 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.

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

[0035] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multimode 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. 1A 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.

[0036] FIG. 1B 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 sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

[0041] 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 light-emitting 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), read-only 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 memory stick, 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).

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

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

[0044] 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 touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

[0045] 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 half-duplex 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)). [0046] FIG. 1C 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.

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

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

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

[0050] 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. [0051] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 81 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.

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

[0053] The ON 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.

[0054] Although the WTRU is described in FIGS. 1A-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.

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

[0056] 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.11e DLS or an 802.11z 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.

[0057] When using the 802.11 ac 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.

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

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

[0060] 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.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 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).

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

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

[0063] FIG. 1 D is a system diagram illustrating the RAN 113 and the ON 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.

[0064] 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 may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

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

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

[0067] 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 information towards 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.

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

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

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

[0073] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, 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.

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

[0075] 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. [0076] A WTRU may play an important role in connecting other WTRUs to the network, for example in the 5GS and/or future generation of wireless communication. The WTRU may play a role in connecting other WTRUs to the network in addition to the role as a regular terminal device, for example as AI/ML splitting, WTRU relay, and/or etc. The WTRU may act as an intermediate node, for example to process data and/or relay traffic from other WTRUs to the downstream network. The capability and/or authorization to perform as the intermediate node, and/or the security of a WTRU as intermediate node may be important, for example to guarantee successful and/or secure communication. A classification of security (CoS) parameter of a WTRU is introduced herein, for example to enable the process of selecting the WTRU for the role as an intermediate node(s).

[0077] A procedure of CoS of a WTRU is defined herein. The CoS may include a qualification that may demonstrate a WTRU’s security capability and/or authorization to perform as an intermediate node (e.g., in a 3gpp network). The qualification (e.g., capability and/or authorization) may be associated with performing AI/ML operation securely as a relay, an AI/ML operation as intermediate/master node, a model aggregator, and/or if the WTRU is capable and/or authorized to perform a threat and/or privacy violation detection on AI/ML model data, for example before forwarding downstream.

[0078] A CoS of a WTRU may be used (e.g., by 5GS) to help in identifying and/or selecting a WTRU to perform as the intermediate node role, for example for network/application functionalities such as relay of other WTRU’s traffic to network, AI/ML splitting/proxy, AI/ML training(s), and/or etc. For example, identification and/or selection of a WTRU (e.g., as an intermediate node) may be at least partially based on a CoS.

[0079] The CoS may be evaluated dynamically and/or updated, for example in the UDM and/or via security policy. An evaluation algorithm may be based on one or more of a WTRU’s hardware and/or software capabilities, networking protocol supported, security algorithms supported, operation system version and/or security patches, a WTRU’s extra resource and/or willingness to perform as intermediate node to process the data/traffic, 5GC network authorization for the roles requested, security policy rule(s), subject (e.g., WTRU) behavior history, reputation(s), and/or etc. The CoS may reflect the security qualification of the subject (e.g., WTRU), capability (e.g., WTRU capability), and/or authorization in performing security operations, for example for one or more of relaying traffic, processing data (e.g., received data) (e.g., before forwarding downstream), security threat and/or privacy violation detection (e.g., on data received), data/model aggregation, data/model distributions, and/or etc. The CoS may be digitally signed by a network security authority. Additionally, or alternatively, the CoS may be retrieved and/or pushed to other entities as other WTRU parameters in UDM or security policy.

[0080] One or more WTRUs may be identified, authorized, and/or selected, for example to perform as one or more intermediate nodes. The WTRU may act as an intermediate node, for example for successful deployment (e.g., to guarantee) of a (e.g., future) communication network. Security capabilities and/or security qualification of the WTRU (e.g., that will perform as the intermediate node) may be identified and/or accessed, for example to enable a process in selecting the intermediate WTRUs (e.g., for such roles). [0081] In (e g. , present) 5GS and/or a future generation of a wireless communication system for example, a WTRU might not act as an access terminal device. The WTRU may act as an intermediate entity in the communication chain, for example as one or more of a proxy, a master node of a group of entities, and/or a volunteer WTRU (e.g., that may process and/or distribute a shared data and/or model for AI/ML operation in use cases like ProSe, AI/ML Splitting, UAV, etc.)

[0082] The WTRU may be configured with one or more security capabilities. For example, security capabilities may be associated with (e.g., signified by) hardware and/or software capabilities. Associated hardware and/or software capabilities may include one or more of secure environment, security protocols supported, security algorithms supported, performance needed to deliver the tasks, latest software patches, and/or capabilities of a server (e.g., AI/ML AS and/or authentication server/gateway). WTRUs (e.g., different WTRUs) may implement different roles. For example, in AI/ML splitting, a selected WTRU-B may be configured to perform AI/ML operations. The WTRU-B may perform AI/ML operations on behalf of a WTRU-A. The WTRU-B may have (e.g., receive) information sent by the WTRU-A and/or perform one or more AI/ML operations (e.g , before sending to the AI/ML server) Privacy information of WTRU-A may be sent (e.g., revealed) to the WTRU-B, for example if a WTRU is not selected properly (e.g., from a security aspect). WTRU-B may manipulate information before performing AI/ML operations, for example if a WTRU is not selected properly (e.g., from security aspect). WTRU-B may replay the information later, for example if a WTRU is not selected properly (e.g., from security aspect). WTRU-B may impersonate WTRU-A (e.g., even if the WTRU-A is not present and/or performing the inference operation), for example if a WTRU is not selected properly (e.g., from security aspect). For example, WTRU-B may send the information and/or message again.

[0083] A WTRU client may send a trained model to a (e.g., local) AI/ML node, for example in the case of distributed federated learning (FL) and/or hierarchical FL. The AI/ML node may aggregate models from a set of WTRUs, for example to form a local aggregated AI/ML model. The AI/ML node may deliver the aggregated AI/ML model to a next level aggregator. The local aggregator may be configured to perform threat detection of the received models, for example to prevent a malicious WTRU from performing an AI/ML attack. Example attacks (e.g., AI/ML attacks) may include data poisoning and/or trained model containing privacy violation. The local aggregator may perform threat detection of the received models, for example before the aggregation.

[0084] The WTRU and/or an application function (AF) may be (e.g., reside) in an area(s) associated with different regulations, rules, and or laws, for example for distributed FL and/or hierarchical FL. An intermediate model may contain privacy violation information, that for example may not be sent to the AF before it is screened by a network (e.g., 5G core network (5GC)). Additionally, or alternatively, an intermediate node may be associated with the 5GC serving network. The 5GC may perform threat detection and/or privacy violation detection, for example when (e.g., after) the 5GC receives one or more intermediate models (e.g., from the end clients) and/or aggregates the one or more intermediate models into a next level/group level intermediate model. The 5GC may send the local aggregated intermediate model to the next aggregator. The (e.g., final) AS may not (e.g., be able to) identify and/or extract a problematic intermediate model, for example that has been already mixed with other intermediate models.

[0085] Selection of a WTRU (e.g., in different role selection decisions) may be based on one or more of a WTRU security qualification, WTRU security capability, and/or WTRU authorization from the network. The network may verify a WTRU CoS for authorization, for example to perform operations. The operations may be specific operations. Additionally, or alternatively, the network may verify a WTRU CoS for authorization, for example during a procedure for a WTRU to perform some functionalities, for example as an intermediate node.

[0086] In some examples, one or more CoS parameters may be provided. A CoS parameter may include one or more qualification measurements for a WTRU, and/or may reflect security qualification and/or capability. The CoS of a WTRU/user may be stored, for example in the unified data manager (UDM) and/or a WTRU's security policy in a policy control function (PCF). The CoS may be retrieved and/or sent (e.g., pushed) to other entities, for example with 5GS procedures (e.g., as other WTRU parameters in UDM). Additionally, or alternatively, the CoS may be delivered (e.g., via WTRU security policy). Selection of a WTRU (e.g., by 5GS) may be based on a WTRU CoS, for example by one or more of determining to enable the network/application functionalities (e.g., relay of other WTRU's traffic to network), AI/ML splitting/proxy, determining a WTRU that participates in AI/ML training(s), and/or etc.

[0087] The CoS may be evaluated dynamically and/or updated, for example when one or more attributes associated with (e.g., that determine) the CoS change. The evaluation of CoS may be based on one or more of the WTRU's hardware and/or software capabilities, a network protocol supported, security algorithm(s) supported, operation system version and/or security patch(es), a WTRU's extra resource and/or willingness to perform as intermediate node to process the data/traffic, and/or 5GC network authorization (e.g., for the roles requested, security policy rules, the subject behavior history, reputations, and/or etc.). The CoS may include an indication of (e.g., reflect) one or more of a qualification, authorization, and/or capability of the subject (e.g., WTRU) to perform as the intermediate node, for example where the WTRU may play a role as more than a terminal device.

[0088] The CoS may identify one or more of a WTRU's security capability, authorization, and/or qualification, for example so that a WTRU may be selected to perform one or more of an AI/ML operation securely (e.g., as relay), AI/ML operating as intermediate/master node, model aggregation, and/or threat and/or privacy violation detection in AI/ML model data (e.g., if the WTRU is capable). The CoS may be digitally signed, for example by a network security authority. The CoS may be retrieved and/or pushed to other entities, for example when the subject of the CoS is offline. The entity (e.g., WTRU, 5GC, or network device) that receives the CoS may verify the digital signature of the CoS. Additionally, or alternatively, the entity may assess the capability and/or authorization of the WTRU (e.g., subject WTRU), for example via the CoS (e.g., before making any decision). A decision may include one or more of selecting the subject as the intermediate node to perform the AI/ML operation, selecting a relay, data/model distribution, model aggregation, acting as the local master role of a group AI/ML client, security threat and/or privacy violation detection on intermediate model before a group aggregation, and/or etc. [0089] Systems and methods associated with CoS of a WTRU/user are described herein. The CoS may include a qualification that may demonstrate a WTRU's security capability and/or authorization to perform as an intermediate node in a network (e.g., in a 3gpp network). The qualification (e.g., capability and/or authorization) may be associated with one or more of whether a WTRU is capable and authorized to perform AI/ML operation securely (e.g., as a relay), AI/ML operation as an intermediate/m aster node, model aggregation, and/or if the WTRU is capable and/or authorized to perform the threat and/or privacy violation detection in AI/ML model data (e.g., to be processed by the WTRU). Selection of a WTRU, for example in determining to enable the network/application functionalities (e.g., relay of another WTRU’s traffic to network, AI/ML splitting/proxy, a WTRU that participates AI/ML trainings, and/or etc.), may be based on the CoS of a WTRU (e.g., by 5GS).

[0090] The CoS may be evaluated dynamically and/or updated in the unified data manager (UDM) and/or via security policy. An evaluation algorithm may be based on one or more of a WTRU’s hardware and/or software capabilities, network protocol(s) supported, security algorithm(s) supported, operation system version(s) and/or security patch(es), a WTRU's extra resource and/or willingness to perform as intermediate node to process the data/traffic, 5GC network authorization for the role(s) requested, security policy rule(s), the subject behavior history, reputations, and/or etc. The CoS may include an indication of (e.g., reflect) one or more of the security qualification(s) of the WTRU (e.g., subject WTRU), capability (e.g., WTRU capability), a security confidence level, and/or authorization in performing security operations, for example one or more of relaying traffic, performing operations on data received (e.g., before forwarding to the downstream), security threat and/or privacy violation detection on data received before the operation, data/model aggregation, data/model distributions, and/or etc. An indication of the security confidence level may be associated with the WTRU and/or an intermediate function. For example, the indication of the security confidence level may be associated with the WTRU when acting as an (e.g., specific) intermediate function. The CoS may be digitally signed by a network security authority and/or may be retrieved and/or pushed to other entities, for example as other WTRU parameters in UDM and/or security policy.

[0091] A WTRU may request and/or receive the CoS signed by the authority from a home network, for example using any procedure(s) for WTRU parameter(s) request and/or WTRU policy request(s) with indication(s) for the CoS request. The WTRU may provide the CoS to a requesting entity, for example when the CoS is requested by another entity (e.g., in the AI/ML operation, for example to decide if the WTRU is capable and/or authorized for an AI/ML role as the intermediate node). A WTRU may receive the CoS information, for example along with one or more parameters. Additionally, or alternatively, the WTRU may receive the CoS information to enable a discovery process. The CoS information and/or discovery process may be used for a WTRU selection process (e.g., after the discovery), for example when the WTRU decides to participate in the AI/ML operation. A WTRU may finish the threat detection and/or privacy violation detection on the model received from the AI/ML participating WTRU (e.g., before it performs the group aggregation of the intermediate model received from participating WTRUs). For example (e.g., in the case for the AI/ML intermediate model aggregator role) if a WTRU is qualified for and/or selected as an intermediate node in AI/ML operation, the WTRU may finish the threat detection and/or privacy violation detection on the model received from the AI/ML participating WTRU (e.g., before it performs the group aggregation of the intermediate model received from participating WTRUs). The WTRU may deliver the group aggregated model to a (e.g., the next) aggregator, for example along with the WTRU CoS (e.g., signed by the authority).

[0092] A WTRU may receive the data from an upstream entity (e.g., a WTRU, or AS), perform security screening, and/or act on the AI/ML data (e.g., for its part). The WTRU may receive the data from an upstream entity (e.g., a WTRU, or AS), perform security screening, and/or act on the AI/ML data (e g., for its part), for example if the WTRU performs the role for one or more of AI/ML splitting, AI/ML relay/proxy, and/or data/model distribution. The WTRU may deliver the processed AI/ML data to one or more downstream entities, for example along with the WTRU CoS (e.g., signed by the authority). The WTRU may deliver the processed AI/ML data to one or more downstream entities, for example along with the WTRU CoS (e.g., signed by the authority), after finishing the WTRU part of an AI/ML operation.

[0093] Enhancements (e g., to a 3GPP network data analytics feature) as described herein may enable generation of analytics to determine the CoS of a network entity, for example to determine the CoS of a WTRU or a set of WTRUs with access to specific network resources (e.g., a specific Network Slice and/or at a specific data network name (DNN)). Analytic ID(s) and/or analytics filter(s) may enhance network data analytics framework.

[0094] An analytic identifier (ID) may be configured (e.g., for use in) one or more roles. A role may include a set of roles and/or capabilities that a WTRU is qualified for, for example one or more of an intermediate node, relay node, proxy node, aggregator, UAV group lead, and/or security gateway node. Additionally, or alternatively, the analytic ID may include one or more capabilities. A capability may include a set of security capabilities, for example one or more of threat detection, privacy violation detection, protocol(s) supported, AI/ML model aggregation, and/or AI/ML operations supported. An analytic filter may include one or more of an area of interest (Aol), single - network slice assistance information (S-NSSAI), DNN, traffic characteristic(s), valid application ID(s), target of analytic reporting, traffic usage threshold, WTRU security profile, and/or WTRU authorization.

[0095] Aol may include geographical location and/or Cell/TA/RA, for example where the analytics are generated). S-NSSAI may include a network slice providing the resources used by the WTRU to run an application of AI/ML operation traffic. DNN may include access by the WTRU, for example when the evaluation is taking place. A traffic characteristic may include whether the traffic corresponds to an application AI/ML operation. A valid application ID may include an application ID of an application running while the CoS evaluation is conducted, for example during the evaluation window/period. A time window may include a time window when the evaluation should take place. A target of analytic reporting may include a single WTRU subscription permanent identifier (SUPI) or a group of WTRUs (e.g., an Internal Group ID or a list of WTRUs)). A traffic usage threshold may include an acceptable level of traffic generated by a WTRU and/or a group of WTRUs, for example when running an application with a specific traffic characteristic. A WTRU security profile may include a WTRU hardware and/or software security profile, for example via WTRU remote attestation and/or data stored in UDM. WTRU authorization may include a WTRU security policy, for example for the role authorization requested.

[0096] A network data analytics function (NWDAF) may use services of one or more other network functions (NFs), for example to collect information that may enable the NWDAF to produce CoS analytics for a WTRU or a list of WTRUs. The NWDAF may collect information from the UDM and/or UDR, for example regarding WTRU hardware and/or software capabilities. The NWDAF may collect information from the PCF, for example to determine how services trigger policies from the PCF The NWDAF may collect traffic usage information, for example from the CAM and/or from the UPF that is handling traffic for a particular application.

Example input data used by the NWDAF may be summarized in Table 1 .

Table 1. Example input data for CoS evaluation

Output analytics are disclosed herein. The NWDAF may provide analytics results to a consumer, for example one or more of a UDM, PCF, and/or AF Analytics and/or results may include a CoS for a WTRU and/or a group of WTRUs, for example as shown in Table 2. [0097] Systems and methods for CoS evaluation framework may be utilized for performing functions as herein. The CoS framework may evaluate a CoS of a WTRU, for example to perform as a role of an intermediate node (e.g., in use cases, for example one or more of carrying out AI/ML operations in FL operations, relay, proxy, gateway, and/or UAV group lead). An intermediate node may perform network element functionalities, for example one or more of a relay node, proxy, security gateway, AI/ML aggregator in distributed hierarchical FL, AI/ML server functionality in splitting, and/or etc. The CoS may be evaluated dynamically, for example to present the WTRU qualification and/or roles for which the WTRU qualifies as an intermediate node (e.g., in use cases like AI/ML, ProSe, and/or UAV). The network data analytics function (NWDAF) (e.g., in a 3GPP 5G system) may derive the CoS for a WTRU and/or WTRUs, for example that is participating in an (e.g., specific) application operation as an intermediate node and/or using specific network resources (e.g., a specific S-NSSAI and/or DNN).

[0098] The CoS evaluation function may enforce a resource access policy. The resource access policy may assist network entities (e.g., a WTRU) role as an intermediate node. For example, a resource access policy may be used to determine whether the WTRU (e.g., subject WTRU) is authorized and/or configured to perform the needed functionalities (e.g., within a network functionality such as an AI/ML operation). The resource access policy may be dynamically formed, for example as a function of one or more of the resources accessed, operation role, and/or least privilege principle(s). The CoS framework may be utilized to decide the scope(s) of a CoS, for example one or more of a location, time range, and/or a network identified by DNN/S-NSSAI/DNS. The CoS, for example along with its scope, may be digitally signed and/or may be validated by entities that make decisions for intermediate node selection.

[0099] FIG. 2 illustrates an example of a CoS procedure 200. At 212 an AF 210 may select a candidate set of network entities. The candidate set of network entities may play a role, for example as an intermediate node in AI/ML FL. The AF 210 may request CoS analytics from an NWDAF 204, for example associated with the candidate set (e.g., a WTRU 202 or a group of WTRUs). The AF 210 may select candidates based on the characteristics of the traffic type of application operation to be executed. The AF may send the candidate set and/or an indication of the candidate set, for example to a network exposure function (NEF) 208. The NEF 208 may obtain a list that may include one or more WTRUs 202 (e.g., that match the indicated criteria). The NEF 208 may query a unified data manager/unified data repository (UDM/UDR), for example to obtain a list that may include one or more WTRUs 202 (e.g., that match the indicated criteria). The NEF 208 may map a request from the AF 210. The NEF 208 may map the request from the AF 210 onto a set of analytic IDs, for example for a requested role and/or analytics filtering information to derive (e.g., specific) CoS analytics to match the role requested in the list of WTRUs.

[0100] At 214 (e.g., once the candidate set is received by the NEF 208) the NEF 208 may send (e.g., forward) the AF request to the NWDAF 204, which may for example include (e.g., house) CoS evaluation functionality. The NWDAF 204 may obtain WTRU CoS evaluation data, for example from other NFs 206. The evaluation data may be used to evaluate the CoS of a network entity (e.g., a WTRU 202), for example as a candidate to support capabilities in a role in the operations (e.g., FL intermediate model threat detection and/or aggregation operations). The data set may include one or more parameters as disclosed herein, for example as in Table 1 For example, the one or more parameters may include one or more of a security profile, a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, and/or a referral from another entity. The CoS may be evaluated based on one or more of the parameters. A security profile may include one or more of a hardware profile and/or a software profile (e.g., associated with the WTRU). The CoS data analytics provided by the NWDAF 204 may be valid, for example in accordance with the validity window provided by the NWDAF 204. [0101] At 216 the NWDAF 204 may collect data from the NF(s) 206, for example according to the analytics filters and/or analytics ID provided by the AF 210. The WTRU may send data based on the analytics filters and/or analytics ID. Additionally, or alternatively, the NWDAF 204 may collect data from the NF(s) 206, for example as described in Table 1 and/or elsewhere herein.

[0102] At 218 the NWDAF 204 may evaluate the CoS of one or more WTRU 202 in the candidate set, for example using the data collected from the relevant NF(s) 206 (e.g., as described herein). The CoS for a WTRU 202 and/or a group of WTRUs 202 associated with network resources (e.g., S-NSSAI, DNN and/or AF 210) may be produced by the NWDAF 204 and/or may be provided to the requesting AF 210 and/or any other analytic consumer (e.g., that may require it). The NWDAF 204 may use an algorithm(s) to perform the evaluation(s), for example using data, for example collected at 216. Data may include one or more of clustering, neural network, fuzz logics, rule base, and/or etc. Alternatively, or additionally, the NWDAF 204 may use a combined algorithm(s) to produce (e.g., the best) analytics (e.g., with more flexibility). The network may send the evaluated CoS, for example to the WTRU. For example, the evaluated CoS may be sent from the NWDAF 204.

[0103] The CoS output from the NWDAF 204 may be digitally signed by the NWDAF 204. The digital signature may be validated, for example by the CoS consumer(s). The CoS may be written in UDR/UDM, for example for subsequent retrieval (e.g., without incurring costly reevaluation). CoS may have a validity scope, for example time and/or location, for example as in Table 2 and/or elsewhere herein.

[0104] At 220 the CoS for each network entity (e.g., for each WTRU 202 in the candidate set) may be sent to the NEF 208, for example for further screening (e.g., using one or more resource access policy). At 222 the NEF 208 may send the screened set of candidate network elements to be used for the relevant AF 210, for example once resources access policies are applied. Alternatively, or additionally, the scoring result(s) may be sent to the AF 210 that, for example may make the decision as to which WTRUs 202 may participate in the role in the application operation.

[0105] At 224 the AF 210 may carry out the relevant operation (e.g., it may start the operations, for example by sending the indication along with CoS signed by the authority to the WTRUs 202 that can play the required role), for example after AF 210 selects the WTRU(s) 202 that matches the roles with received CoS. The digitally signed CoS may be used by the WTRU 202 that requests to participate in intermediate node role, for example if the CoS matches required CoS. The application operation start may include an operation start message. The operation start message may be based on an evaluated CoS. The operation start message may be sent based on the evaluated CoS matching a desired (e.g., predetermined CoS). For example, the network may compare the evaluated CoS to the desired CoS.

[0106] FIG. 3 illustrates an example of CoS exchanges 300 between a WTRU and a network. At 306 a WTRU 302 may perform PDU session establishment. During the PDU session establishment procedure for example, the WTRU 302 may provide the CoS obtained during the start of the application operation (e.g., as described herein). The presence of the CoS may be taken by an SMF as an indication of WTRU capability and/or authorization to behave as the intermediate node functionality. Additionally, or alternatively, the CoS along with subscription data, for example within the session management subscription data used for PDU session establishment, may be used by the SMF, for example to determine whether the WTRU 302 is subject to authorization (e.g., on the DNN provided by the WTRU 302 during the PDU session establishment request).

[0107] Alternatively, or additionally, the WTRU CoS may be sent by an application agent, for example during a PDU session establishment request procedure. The WTRU CoS may be sent within a transparent container, for example in the NAS messages (e.g., as part of an event notification). At 308 the AF may verify the CoS digitally signed by the authority from the WTRU 302 that sends the request.

[0108] Alternatively, or additionally, the CoS may not be provided by an untrusted WTRU 302 and/or retrieved from UDR/UDM. If a CoS is not established, then the WTRU 302 may be rejected, for example until the AF has performed a CoS evaluation procedure (e.g., as herein). In some examples, the WTRU 302 may not be authorized by 5GC/AS 304 to participate until a valid CoS is set.

[0109] At 310 a 5GC/AS 304 may send a PDU session establishment accept message to the WTRU 302. An application operation may be associated with a (e.g., particular) DNN/S-NSSAI, for example with FL specific QoS/charging requirements. PDU session resources may be allocated, for example on the condition that the AF may grant authorization for the WTRU 302 to participate in an (e.g., specific) operation (e.g., based on WTRU 302 CoS as herein).

[0110] At 312 the successful verification of the CoS provided to the WTRU 302 in the PDU session establishment accept message, for example via a transparent container, may be used by the application to trigger the start of an application operation. At 314 the WTRU 302 may participate in the operation(s).

[0111] FIG. 4 illustrates an example of a CoS procedure 400 with AI/ML splitting. At 410 a CoS of a WTRU 402 may be evaluated, for example using one or more inputs as herein (e.g., in Table 1). The CoS may be stored in the UDM/PCF 404 and/or presented to the WTRU 402. The CoS of a WTRU 402 may alternatively, or additionally, be requested from other NF and/or external AF 408 through NEF 406.

[0112] At 412 the AI/ML splitting discovery procedure may be performed, for example using existing mechanisms (e.g., PC5 discovery procedure for ProSe specified by the 3gpp). One or more (e.g., a set of) WTRU 402 candidates may be discovered for participating in the AI/ML splitting procedure, for example as a result of an AI/ML splitting discovery procedure.

[0113] The WTRU 402 may perform the AI/ML splitting. For example, the WTRU 402 may receive a request from the origin WTRU 402. The request may include an AI/ML request. The WTRU 402 may receive output of layer 1-5 operation, for example with the request. The WTRU 402 may perform the AI/ML operation of layer 6-15 and/or send the result to the AS 408 (e.g., to perform the remaining layer 16-24 AI/ML operation). Additionally, or alternatively, the WTRU may send the CoS that is digitally signed by the authority. The WTRU 402 may (e.g., need) perform the security threat detection on input from the origin WTRU 402 and/or (e.g., only) proceed when there is no security threat detected, for example before performing a layer 6-15 AI/ML operation. The AS 408 may validate the CoS in the message (e.g., before it continues the remaining AI/ML operation), for example when the AS 408 receives the request from the intermediate WTRU 402. The WTRU 402 may include multiple WTRU. For example, different WTRUs may perform different operation(s) as described herein.

[0114] The CoS may be sent in the discovery message(s) and/or validated by the receiving peer, for example if the peer WTRU(s) 402 already possesses the CoS before the discovery procedure. The CoS may, for example otherwise, be requested by the receiving peer from the sending peer’s CoS repository NF (e.g., UDM/policy control function (PCF)). For example, during the discovery procedure, (e.g., all) entities may present a respective CoS that include authorized roles and/or capabilities. The peer may validate the CoS to be validate/confirm that the WTRU 402 is authorized and/or capable for the role(s).

[0115] Alternatively, or additionally, the WTRU 402 may request the AI/ML AF 408 to locate a relay node on behalf of the WTRU 402, for example by sending the request to the AF 408 along with related information. The related information may include one or more of performance requirement, location, relay node role, AI/ML application ID, and/or etc. the WTRU 402 may ask The AI/ML AF 408 to locate a relay node on behalf of the WTRU 402, for example if there is no relay node discovered for the AI/ML splitting (e.g., at 412).

[0116] At 414 the AI/ML AF 408 may request the CoS for the candidate set of network entities (e.g., WTRUs 402) to be executed, for example based on one or more of the location of the requesting WTRU 402 and/or requirements for the role of AI/ML operation (e.g., AI/ML splitting). The AI/ML AF 408 may send the CoS request to the NEF 406. At 416 the NEF 406 may forward the request to the UDM 404. At 418 the UDM 404 may send the requested CoS to the NEF 406. At 420 the NEF 406 may send the CoS value in a response message, for example back to the AI/ML AF 408.

[0117] At 422 there may be AI/ML splitting. The AF 408 may match the requested CoS with a CoS received from the UDM 404 of candidate WTRUs 402, and/or select the WTRU 402 that match (e.g., that best match) to perform the splitting role and/or start AI/ML splitting. At one or more procedures, other information used for the communication between the WTRU 402 and the relay may be included, for example credentials ID and/or etc. [0118] FIG. 5 illustrates an example CoS discovery request procedure 500. At 512 a WTRU 502 may establish a (e.g., secure) connection with a 5G direct discovery name management function (DDNMF) 504 and/or send a restricted discovery request message. The restricted discovery request message may include a WTRU identifier. The WTRU identifier may include a restricted ProSe application user ID (RPAUID), which for example may include an indication of what the WTRU 502 is interested to announce, monitor, and/or discover. The WTRU identifier (e.g., restricted discovery request message) may additionally, or alternatively, contain WTRU identity field(s), which for example may be set to international mobile subscriber identity (IMSI). A command field in the message may indicate what type of ProSe operation is requested, for example a ProSe query operation for a discoverer WTRU 502 and/or a ProSe response operation for a discoveree WTRU 502.

[0119] The discovery request message may include a discovery type, which for example may be set to restricted discovery. A discovery model field may indicate whether the ProSe discovery is using Model A or Model B. The application ID may represent a unique identifier of the WTRU application, for example that has triggered the transmission of the discovery request message. The discovery request message may additionally, or alternatively, include an application level container, for example along with other parameters. For example, for Model A ProSe discovery a request discovery timer field may be included. The discovery request message may additionally, or alternatively, include a CoS.

[0120] At 514 the 5G DDNMF 504 may check for the authorization of the application represented by the application ID. If there is no associated WTRU context for example, the 5G DDNMF 504 may check with a UDM 506 for the authorization for discovery and/or create a new context for this WTRU 502. Additionally, or alternatively, the 5G DDNMF 504 may check with a UDM 506 for the authorization for discovery and/or create a new context for this WTRU 502, for example that may contain the subscription parameters for this WTRU 502.

[0121] At 516 the 5G DDNMF 504 may send an authorization request to a Prose / AI/ML application server (AS) 510. The authorization request may include one or more fields. The field may include RPAUID and/or request type. The 5G DDNMF 504 may locate the ProSe application server 510, for example based on the application ID (e.g., received at 512). The request type may be set to restricted discovery/monitor, restricted discovery/announce, restricted discovery/query, and/or restricted discovery/response, for example depending on the ProSe operation. Additionally, or alternatively, the request message may include an application-level container, for example for the monitoring WTRU 502 and/or discoverer WTRU 502.

[0122] At 518 the ProSe / AI/ML AS 510 may perform authorization of the received request. The AS 510 may check if CoS information for the requesting WTRU is available, for example at UDM 506. The AS 510 may validate the CoS information, for example by determining (e.g., making sure) if there is a timer, that the validity of the CoS has not expired (e.g., that the timer has not expired), and/or if the CoS information exists. The AS 510 may perform a CoS evaluation procedure (e.g., following a procedure as herein, for example as in FIG. 2), for example if CoS information does not exist in UDM 506. The AS 510 may use the retrieved CoS and/or the newly generated CoS, for example along with other ProSe related parameters, to decide whether to authorize the discovery request.

[0123] At 520 the ProSe I AI/ML AS 510 may send (e.g., return) an authorization response (e.g., ProSe discovery WTRU ID(s) (PDUID(s)), response type) message to the 5G DDNMF 504. The PDUID(s) may correspond to the RPAUID, for example stored in the ProSe Application / AI/ML Server 510. The response type may be set to restricted discovery/announce acknowledgment (ack) for the announcing WTRU 502 and/or similar content for other types of ProSe discovery operations, for example monitoring WTRU 502, discoverer WTRU 502, and/or discoveree WTRU 502. The 5G DDNMF 504 may verify that at least one of the received PDUID(s) belongs to the requesting WTRU 502. Other parameters may be included additionally, or alternatively. At 522 the 5G DDNMF 504 may obtain one or more of ProSe code(s), discovery filter(s), and/or validity timer(s).

[0124] The network may send an operation start message, for example to the WTRU 502. The operation start message may be based on an evaluated CoS. The network may determine to send the operation start message, for example when the evaluated CoS matches a desired (e.g., predetermined) CoS.

[0125] A WTRU may be a monitoring WTRU 502 (e.g., Model A). For example for monitoring WTRU 502, the ProSe Function in the home public land mobile network (HPLMN) may retrieve the ProSe restricted code (e.g., corresponding to one or more of that Target PDUID, application ID and target RPAUID), for example if the PLMN ID in the target PDUID indicates the HPLMN and/or if at least one of received pair (e.g., target PDUID and/or target RPAUID) corresponds to a valid ProSe restricted code, for example including a valid PC5 radio technology match as indicated via the PC5_tech parameter (e.g., at 512). The ProSe function in the HPLMN may store (e.g., in the context of the announcing WTRU 502) the PDUID of the monitoring WTRU 502. The ProSe restricted code may be replaced by the ProSe restricted code prefix, for example if restricted direct discovery with application-controlled extension is used. The ProSe function of HPLMN may trigger the announcing alert procedure (e.g., as herein) to notify the announcing WTRU 502 to perform announcing, for example if the announcing enabled indicator is stored in the WTRU context.

[0126] For an announcing WTRU 502 (e.g., Model A) for example, the 5G DDNMF 504 may allocate a ProSe restricted code and/or the associated validity timer. The ProSe restricted code may correspond to the RPAUID (e.g., that was contained in the discovery request from the WTRU 502). The ProSe function may store one or more of the RPAUID, the ProSe restricted code, and/or the associated validity timer, for example in the user context.

[0127] A WTRU may be a discoveree WTRU 502 (e.g., Model B). For discoveree WTRU 502 for example, the 5G DDNMF 504 may allocate one or more of a ProSe response code, a ProSe query code, and/or an associated discovery query filter(s). The ProSe function additionally, or alternatively, may allocate a validity timer (e.g., that may be associated to the ProSe Response Code). The ProSe response code may correspond to the RPAUID (e.g., that may be contained in the discovery request from the WTRU 502). The validity timer may indicate a code validity time (e.g., for how long this ProSe response code is going to be valid). The ProSe function may store one or more of the RPAUID, the ProSe response code, the ProSe query code, discovery query filter(s), and/or the associated validity timer, for example in the user context.

[0128] The WTRU may be a discoverer WTRU 502 (e.g., Model B). For example for discoverer WTRU 502, the 5G DDNMF 504 may locate the discoveree WTRU(s) 502 context. The 5G DDNMF 504 may locate the discoveree WTRU(s) 502 context for example if the PLMN ID in the target PDUID indicates the HPLMN and/or if at least one of received pair of (target PDUID, target RPAUID) corresponds to a valid ProSe response code (e.g., including a valid PC5 radio technology match as indicated via the PC5_tech parameter, for example at 512). The ProSe function in the HPLMN may retrieve the ProSe query code and/or an associated validity timer. The ProSe query code may be the code used by the ProSe function to build the discovery query filter (e.g., such that it can trigger the discoveree WTRU 502 to send the response). The ProSe function may allocate a discovery response filter(s), for example based on the ProSe response code. The ProSe response code may be allocated to the discoveree WTRU 502. The validity timer may indicate a code validity time (e.g., for how long a ProSe query code and/or ProSe response code are going to be valid).

[0129] At 524 the 5G DDNMF 504 may return (e.g., send) a discovery response message to the WTRU 502. The discovery response message may be generated, for example by the network (e.g., DDNMF), based on one or more of a WTRU identifier and/or the CoS. The discovery response message may include different information depending on the type of requested ProSe discovery operation. The message may include fields, for example for a monitoring WTRU 502. A field may include one or more of discovery filter(s), metadata indicator, discovery entry ID, application level container, and/or PC5_tech. The discovery filter may include the ProSe restricted code (e g., to be monitored) and/or the TTL (e.g., that indicates for how long the related ProSe restricted code in the discovery filter is valid after it is received). The discovery response message may include one or more fields fields (e.g., one or more of discovery model, ProSe query code(s), discovery response filter(s) validity timer, [PC5_tech]) in the message. The discovery model may indicate the Model B is used. The discovery response filter may be generated by the 5G DDNMF 504, for example based on the ProSe response code.

[0130] The WTRU 502 may be ready to perform the ProSe discovery operation, for example if the process of FIG. 5 is successful (e.g., at and/or after 524). There may be a (e.g., restricted) ProSe Discovery procedure for AI/ML splitting operation, for example between a WTRU-A and a WTRU-B. This procedure may be valid for both Model A and Model B of ProSe discovery.

[0131] FIG. 6 illustrates an example CoS discovery procedure 600 for AI/ML splitting. At 614 WTRU-A 602 may perform a CoS - aware restricted ProSe discovery procedure, for example as described herein (e.g., as in FIG. 5). WTRU-A 602 may be an announcing WTRU, for example for Model A. WTRU-A 602 may be a discoveree WTRU, for example for Model B.

[0132] At 616 WTRU-B 604 may additionally, or alternatively, perform the CoS - aware restricted ProSe discovery procedure, for example as herein (e.g., as in FIG. 5). WTRU-A 602 may be a monitoring WTRU, for example for Model A. WTRU-B 604 may be a discoverer WTRU, for example for Model B. Once successful, (e.g., after 616) WTRU-A 602 and/or WTRU-B 604 may be ready to perform PC5 ProSe discovery. At 618 WTRU-A 602 and WTRU- B 604 may perform PC5 ProSe restricted discovery. At 620 (e.g., once successful), WTRU-A 602 and WTRU-B 604 may (e.g., further) negotiate the AI/ML capabilities for the AI/ML splitting.

[0133] In some examples, there may be a security policy used for delivering a CoS, for example to the decision point (e.g., entity). The decision point may make the decision regarding intermediate node selection, for example for an AI/ML operation (e.g., using CoS information in the security policy). The CoS may additionally, or alternatively, be requested by the consumer of CoS, for example (e.g., directly) from the UDM/UDR 608.

Claims

CLAIMS:

1 . A wireless transmit/receive unit (WTRU) comprising a processor, the processor configured to: send a request for classification of security (CoS), the CoS comprising an indication of a security confidence level associated with the WTRU; receive a CoS from a network; and receive an artificial intelligence machine learning (AIML) operation start message, wherein the Al ML operation start message is received based on the received CoS.

2. The WTRU of claim 1 , wherein the processor is further configured to receive the AIML operation start message when the received CoS matches a desired CoS.

3. The WTRU of claim 1 , wherein the one or more parameters comprises a security profile associated with the WTRU.

4. The WTRU of claim 3, wherein the security profile comprises one or more of a hardware profile or a software profile.

5. The WTRU of claim 1 , wherein the received CoS is received from a network data analytics function (NWDAF).

6. The WTRU of claim 1, wherein the received CoS is evaluated based on one or more of a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, or a referral from another entity.

7. The WTRU of claim 1, wherein the indication of the security confidence level associated with the WTRU is further associated with an intermediate node function.

8. The WTRU of claim 1 , wherein the processor is further configured to send data based on an analytics filter.

9. The WTRU of claim 8, wherein the analytics filter comprises one or more of an area of interest (Aol), single - network slice assistance information (S-NSSAI), DNN, a traffic characteristic, a valid application identifier, a target of analytic reporting, a traffic usage threshold, a security profile associated with the WTRU, or an authorization associated with the WTRU.

10. A method performed by a wireless transmit/receive unit (WTRU), the method comprising: sending a request for classification of security (CoS), the CoS comprising an indication of a security confidence level associated with the WTRU; receiving a CoS from a network; and receiving an artificial intelligence machine learning (AIML) operation start message, wherein the AIML operation start message is received based on the received CoS.

11. The method of claim 10, further comprising receiving the AIML operation start message when the evaluated CoS matches a desired CoS.

12. The method of claim 10, wherein the one or more parameters comprises a security profile associated with the WTRU.

13. The method of claim 12, wherein the security profile comprises one or more of a hardware profile or a software profile.

14. The method of claim 10, wherein the received CoS is received from a network data analytics function (NWDAF).

15. The method of claim 10, wherein the received CoS is evaluated based on one or more of a subject privilege, a security state, a security policy rule, a network state, subject behavior history, a subject attribute, a reputation, or a referral from another entity.

16. The method of claim 10, wherein the indication of the security confidence level associated with the WTRU is further associated with an intermediate node function.

17. The method of claim 10, further comprising sending data based on an analytics filter.

18. The method of claim 17, wherein the analytic filter comprises one or more of an area of interest (Aol), single - network slice assistance information (S-NSSAI), DNN, a traffic characteristic, a valid application identifier, a target of analytic reporting, a traffic usage threshold, a security profile associated with the WTRU, or an authorization associated with the WTRU.