Security classification eligibility measurement and capability assessment

Abstract

A wireless transmit / receive unit (WTRU) may send a request for a CoS. The CoS may include, for example, an indication of a security confidence level associated with the WTRU. The WTRU may receive a CoS, for example from a network. The received CoS may be evaluated based on the one or more parameters. The WTRU may receive an operation initiation message, such as an artificial intelligence machine learning (AIML) initiation message. The operation initiation message may be based on the received CoS. When the evaluated CoS matches the desired CoS, the WTRU may receive an operation initiation message. The one or more parameters may include, for example, a security profile associated with the WTRU. The security profile may include one or more of a hardware profile and / or a software profile.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 456,647, filed April 3, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Wireless Transmit / Receive Units (WTRUs) can play a role in connecting other WTRUs to the network, such as in 5GS and / or future generations of wireless communications. In addition to their role as regular end devices, WTRUs can also function in connecting other WTRUs to the network, such as as AI / ML segmenters, WTRU relays, and / or so on. For example, a WTRU can act as an intermediate node to process data and / or relay traffic from other WTRUs to downstream networks. For example, a WTRU can additionally or alternatively perform functions such as data / model distribution and / or AI / ML inference as part of its forwarding to downstream networks. WTRUs can utilize, for example, hardware and / or software capabilities such as a secure environment, supported security protocols, supported security algorithms, the performance required to deliver the task, up-to-date software patches, and / or server capabilities (such as AI / Machine Learning (ML) application servers (AS) and / or authentication servers / gateways). Summary of the Invention

[0003] The WTRU may include a processor. The processor may be configured to send a Security Classification (CoS), (e.g., receive an evaluated CoS from a Network Data Analysis Function (NWDAF) and / or from a Unified Data Manager (UDM)), and / or receive an operation initiation message. The operation initiation 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. For example, when the CoS matches a desired CoS, an operation initiation message may be sent from an Application Function (AF) to the WTRU. The one or more parameters may include a WTRU security profile.

[0004] The processor can be configured to send a request message to the AF. The request message may be associated with AI / ML segmentation discovery. The processor can be configured to receive AI / ML selection messages from the AF and / or perform AI / ML segmentation. The processor can be configured to send a discovery request message to the network and / or receive a discovery response message. The discovery request message may include a WTRU identifier and / or a security classification (CoS). The discovery response message may be generated, for example, by the Network Direct Discovery Name Management Function (DDNMF). Additionally or alternatively, the discovery response message may be generated based on the WTRU identifier and / or the CoS. The WTRU identifier may include a Restricted Proximity Service (ProSe) Application User ID (RPAUID).

[0005] The network can receive the CoS from the WTRU. The network can evaluate the CoS at the NWDAF. For example, the network can evaluate (e.g., the evaluated) CoS based on one or more parameters. The security confidence level can be evaluated based on the CoS and / or one or more of the parameters. The network can send an operation initiation message to the WTRU. The operation initiation message can be based on the evaluated CoS. When the CoS matches the expected CoS, the operation initiation message can be sent from the AF to the WTRU. One or more parameters may include the WTRU security profile. The network can receive a request message at the AF. The request message may be associated with AI / ML segmentation discovery. The network can send an AI / ML selection message from the AF to the WTRU. When the CoS matches the expected CoS, the AI / ML selection message can be sent from the AF to the WTRU. The network can, for example, receive a discovery request message from the WTRU. The discovery request message may include the WTRU identifier and / or the CoS. The network can, for example, generate a discovery response message via DDNMF. The discovery response message may be based on the WTRU identifier and / or the CoS. The WTRU identifier may include the Restricted ProSe Application User ID (RPAUID).

[0006] The WTRU can send a request for a CoS. The CoS may include, for example, an indication of a security confidence level associated with the WTRU. The WTRU may receive the CoS, for example, from the network. The received CoS may be evaluated based on one or more parameters. The WTRU may receive an operation initiation message, such as an Artificial Intelligence Machine Learning (AIML) initiation message. The operation initiation message may be based on the received CoS. The WTRU may receive the operation initiation message when the evaluated CoS matches the desired CoS. The one or more parameters may include, for example, a security profile associated with the WTRU. The security profile may include one or more of a hardware profile and / or a software profile.

[0007] The WTRU can receive the evaluated CoS from the Network Data Analysis Function (NWDAF). The evaluated CoS can be assessed based on one or more of the following: subject authority, security status, security policy rules, network status, subject behavior history, subject attributes, reputation, and / or recommendations from another entity. The CoS can be evaluated by the network. Indications of security confidence levels can be alternatively or additionally associated with intermediate node functions. The WTRU can send data, for example, based on analysis filters. These analysis filters may include one or more of the following: Region of Interest (AoI), Single Network Slice Auxiliary Information (S-NSSAI), DNN, service characteristics, valid application identifiers, the target of the analysis report, service usage thresholds, security profiles associated with the WTRU, and / or authorizations associated with the WTRU.

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

[0009] The network entity may receive data, for example, based on an analysis filter. Additionally or alternatively, the network entity may evaluate the CoS based on the received data. The network entity may compare the evaluated CoS with the expected CoS. When the evaluated CoS matches the expected CoS, the network entity may send the operation initiation message.

[0010] The one or more parameters may include, for example, a security profile associated with the WTRU. The security profile may include one or more hardware profiles and / or software profiles. The network entity may send the evaluated CoS from the Network Data Analysis Function (NWDAF) to, for example, the WTRU. The network entity may evaluate the CoS based on one or more of the following: principal privileges, security status, security policy rules, network status, principal behavior history, principal attributes, reputation, and / or recommendations from another entity. The indication of the security confidence level may alternatively or additionally be associated with intermediate node functions.

[0011] A WTRU can send a discovery request message to, for example, a network. The discovery request message may include one or more of a WTRU identifier and / or a CoS. The WTRU can receive a discovery response message from, for example, a network. The discovery response message may be generated by the Network Direct Discovery Name Management Function (DDNMF). The discovery message may be generated based on the WTRU identifier and / or one or more of the CoS. The WTRU identifier may include a Restricted ProSe Application User ID (RPAUID).

[0012] Alternatively or additionally, the security confidence level can be evaluated based on CoS and / or one or more of 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 principal permissions, security status, security policy rules, network status, principal behavior history, principal attributes, reputation, and / or recommendations from another entity. The WTRU may, for example, receive an operation initiation message from the network. The operation initiation message may be based on the evaluated CoS. The WTRU may receive the operation initiation message when the evaluated CoS matches the expected CoS. The CoS may include, for example, an indication of the security confidence level associated with the WTRU. The indication of the security confidence level may, alternatively or additionally, be associated with intermediate node functionality. Attached Figure Description

[0013] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0014] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0015] Figure 1C The illustration shows a method according to one embodiment. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0016] Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used in the communication system.

[0017] Figure 2 An example of a CoS program is shown.

[0018] Figure 3The illustration shows an example of CoS exchange between the WTRU and the network.

[0019] Figure 4 An example of a CoS program with AI / ML segmentation is illustrated.

[0020] Figure 5 The illustration shows an example of a CoS discovery request procedure.

[0021] Figure 6 An example of a CoS discovery procedure for AI / ML segmentation is illustrated. Detailed Implementation

[0022] Figure 1A This is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0023] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0024] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNode B, home node B, home eNode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

[0027] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 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 one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0029] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

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

[0031] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0032] For example, Figure 1ABase station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

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

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

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

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

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

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

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

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

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

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

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

[0044] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0045] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for 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 hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

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

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

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

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

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

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

[0055] In a representative embodiment, another network 112 may be a WLAN.

[0056] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as an "ad-hoc" communication mode.

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

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

[0059] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0060] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0061] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the available band remains idle and can be available.

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

[0063] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

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

[0065] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time).

[0066] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

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

[0069] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or so on. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

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

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

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

[0073] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): 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. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0074] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0075] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0076] WTRUs can play a vital role in connecting other WTRUs to a network, such as in 5GS and / or future generations of wireless communications. Beyond their role as regular end devices, WTRUs can also function in connecting other WTRUs to a network, such as as AI / ML splitters, WTRU relays, and / or more. WTRUs can act as intermediate nodes, for example, to process data and / or relay traffic from other WTRUs to downstream networks. For example, to ensure successful and / or secure communication, the capabilities and / or authorization performed as an intermediate node, and / or the security of the WTRU acting as an intermediate node, may be important. This paper introduces the Security Classification (CoS) parameter for WTRUs, for example, to implement the process of selecting WTRUs for the role of one or more intermediate nodes.

[0077] This document defines the procedures for the CoS of a WTRU. The CoS may include qualifications that can demonstrate the security capabilities and / or authorization that the WTRU can perform as an intermediate node (e.g., in a 3GPP network). Qualifications (e.g., capabilities and / or authorization) may be associated with securely performing AI / ML operations as a relay, performing AI / ML operations as an intermediate / master node, a model aggregator, and / or whether the WTRU is able and / or authorized, for example, to perform threat and / or privacy violation detection on AI / ML model data before forwarding it downstream.

[0078] The CoS of a WTRU can be used (e.g., 5GS) to help identify and / or select a WTRU as an intermediate node role, for example, for network / application functions such as relaying traffic to the network for other WTRUs, AI / ML segmentation / agent, (one or more) AI / ML training, and / or so on. For example, the identification and / or selection of a WTRU (e.g., as an intermediate node) can be based at least in part on the CoS.

[0079] The Certificate of Status (CoS) can be dynamically evaluated and / or updated, for example, within a UDM and / or via a security policy. The evaluation algorithm can be based on one or more of the following: the WTRU's hardware and / or software capabilities, supported network protocols, supported security algorithms, operating system version and / or security patches, the WTRU's additional resources and / or willingness to act as an intermediary node to perform data / service processing; 5GC network authorization for the requested role; one or more security policy rules; the subject's (e.g., WTRU) behavioral history; one or more reputations; and / or the like. The CoS can reflect, for example, the security qualifications, capabilities (e.g., WTRU capabilities), and / or authorization in performing security operations for one or more of the following: relaying services, processing data (e.g., received data) (e.g., before forwarding downstream); detecting security threats and / or privacy violations (e.g., on received data); data / model aggregation; data / model distribution; and / or the like. The CoS can be digitally signed by a cybersecurity authority. Additionally or alternatively, the CoS can be retrieved and / or pushed to other entities as other WTRU parameters within a UDM or security policy.

[0080] One or more WTRUs can be identified, authorized, and / or selected, for example, to perform as one or more intermediate nodes. WTRUs can act as intermediate nodes, for example, for the successful deployment of a communication network (e.g., to provide assurance). The security capabilities and / or security qualifications of the WTRU (e.g., which will perform as an intermediate node) can be identified and / or accessed, for example, to enable (e.g., for such a role) the process of selecting an intermediate WTRU.

[0081] For example, in (e.g.) current 5GS and / or future generation wireless communication systems, the WTRU may not be able to act as an access terminal device. The WTRU can act as an intermediate entity in the communication chain, such as as an agent, a master node of an entity group, and / or one or more volunteer WTRUs (e.g., which can process and / or distribute shared data and / or models for use cases such as ProSe, AI / ML segmentation, UAV, etc.).

[0082] A WTRU can be configured with one or more security capabilities. For example, security capabilities can be associated with (e.g., represented by) hardware and / or software capabilities. Associated hardware and / or software capabilities may include one or more of the following: a secure environment, supported security protocols, supported security algorithms, performance required to deliver the task, up-to-date software patches, and / or server capabilities (e.g., AI / ML AS and / or authentication server / gateway). WTRUs (e.g., different WTRUs) can implement different roles. For example, in an AI / ML segmentation, the selected WTRU-B can be configured to perform AI / ML operations. WTRU-B can perform AI / ML operations on behalf of WTRU-A. WTRU-B can have (e.g., receive) information sent by WTRU-A and / or perform one or more AI / ML operations (e.g., before sending to the AI / ML server). For example, if a WTRU is not correctly selected (e.g., from a security perspective), WTRU-A's private information can be sent (e.g., leaked) to WTRU-B. For example, if a WTRU is not correctly selected (e.g., from a security perspective), WTRU-B can manipulate information before performing AI / ML operations. For example, if the WTRU is not correctly selected (e.g., for security reasons), WTRU-B can replay the information later. For example, if the WTRU is not correctly selected (e.g., for security reasons), WTRU-B can impersonate WTRU-A (e.g., even if WTRU-A does not exist and / or is performing an inference operation). For example, WTRU-B can resend information and / or messages.

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

[0084] For example, for distributed FLs and / or hierarchical FLs, WTRUs and / or Application Functions (AFs) may (e.g., reside) in one or more zones associated with different regulations, rules, and / or laws. Intermediate models may contain privacy violation information that might not be sent to the AF before being filtered by the network (e.g., the 5G core network (5GC)). Additionally or alternatively, intermediate nodes may be associated with the 5GC service network. For example, when the 5GC (e.g., from one or more end clients) receives one or more intermediate models (e.g., after the 5GC receives one or more intermediate models from one or more end clients) and / or aggregates one or more intermediate models into the next level / group level intermediate models, the 5GC may perform threat detection and / or privacy violation detection. The 5GC may send locally aggregated intermediate models to the next aggregator. (e.g., the final) AS may not (e.g., be able to) identify and / or extract problematic intermediate models, such as those already mixed with other intermediate models.

[0085] The selection of a WTRU (e.g., in different role selection decisions) can be based on one or more of the WTRU's security eligibility, security capabilities, and / or authorization from the network. The network can verify the WTRU's CoS to obtain authorization, for example, to perform an operation. This operation can be a specific action. Additionally or alternatively, the network can verify the WTRU's CoS to obtain authorization, for example, as an intermediate node, during a procedure in which the WTRU performs some function.

[0086] In some examples, one or more CoS parameters may be provided. CoS parameters may include one or more eligibility measures for the WTRU and / or may reflect security eligibility and / or capabilities. The WTRU / user's CoS may be stored in the WTRU security policy, for example, in a Unified Data Manager (UDM) and / or Policy Control Function (PCF). The CoS may be retrieved and / or sent (e.g., pushed) to other entities, such as by leveraging 5GS procedures (e.g., as another WTRU parameter in the UDM). Additionally or alternatively, the CoS may be delivered (e.g., via the WTRU security policy). The selection of WTRUs (e.g., via 5GS) may be based on the WTRU CoS, for example, by determining one or more of the following: enabling network / application functions (e.g., relaying traffic from other WTRUs to the network), AI / ML segmentation / agent, determining WTRUs participating in AI / ML training(s), and / or so on.

[0087] For example, the CoS can be dynamically evaluated and / or updated when one or more attributes associated with it (e.g., those determining the CoS) change. The evaluation of the CoS can be based on one or more of the WTRU's hardware and / or software capabilities, supported network protocols, supported security algorithms(s), operating system version and / or (one or more) security patches, the WTRU's additional resources and / or willingness to act as an intermediary node to perform data / service processing, and / or 5GC network authorization (e.g., for requested roles, security policy rules, subject behavior history, reputation, and / or so on). The CoS can include indications (e.g., reflections) of one or more of the qualifications, authorizations, and / or capabilities of a subject (e.g., the WTRU) to act as an intermediary node, such as where the WTRU can function as more than just an end device.

[0088] The CoS can identify one or more of the security capabilities, authorization, and / or qualifications of the WTRU, for example, to enable the WTRU to be selected to securely perform AI / ML operations (e.g., as a relay), AI / ML operations as an intermediate / master node, model aggregation, and / or detection of threats and / or privacy violations in AI / ML model data (e.g., if the WTRU is capable). The CoS can be digitally signed, for example, by a cybersecurity authority. For example, when the subject of the CoS is offline, the CoS can be retrieved and / or pushed to other entities. The entity receiving the CoS (e.g., the WTRU, 5GC, or network device) can verify the digital signature of the CoS. Additionally or alternatively, entities can evaluate the capabilities and / or authorization of the WTRU (e.g., the subject WTRU) via the CoS (e.g., before making any decisions). Decisions can include one or more of the following: selecting the subject as an intermediate node to perform AI / ML operations, selecting a relay, data / model distribution, model aggregation, acting as a local master for group AI / ML clients, and detecting security threats and / or privacy violations in intermediate models before group aggregation.

[0089] This document describes systems and methods associated with the CoS of a WTRU / user. The CoS can include eligibility to demonstrate the security capabilities and / or authorization a WTRU can perform as an intermediate node in a network (e.g., in a 3GPP network). Eligibility (e.g., capabilities and / or authorization) can be associated with one or more of the following: whether the WTRU is capable and authorized to securely perform AI / ML operations (e.g., as a relay), AI / ML operations as an intermediate / master node, model aggregation, and / or whether the WTRU is capable and / or authorized to perform threat and / or privacy violation detection in AI / ML model data (e.g., to be processed by the WTRU). For example, in determining whether to enable network / application functions (e.g., relaying another WTRU's traffic to the network, AI / ML segmentation / proxies, WTRUs participating in AI / ML training, and / or so on), the selection of the WTRU can be based on its CoS (e.g., via 5GS).

[0090] The CoS can be dynamically evaluated and / or updated within the Unified Data Manager (UDM) and / or via security policies. Evaluation algorithms can be based on one or more of the WTRU's hardware and / or software capabilities, supported network protocols(s), supported security algorithms(s), operating system(s) versions(s) and / or security patches(s), additional resources of the WTRU and / or its willingness to act as an intermediate node to process data / services, 5GC network authorization for the requested(s) roles(s), security policy(s) rules(s), subject behavior history, reputation, and / or the like. The CoS can include indications (e.g., reflections) of one or more of the WTRU's (e.g., subject WTRU) security qualifications(s), capabilities (e.g., WTRU capabilities), security confidence levels, and / or authorization to perform security operations, such as relaying services, performing operations on received data (e.g., before forwarding to downstream), detecting security threats and / or privacy violations on data received prior to the operation, data / model aggregation, data / model distribution, and / or the like. Indications of security confidence levels can be associated with the WTRU and / or intermediate functions. For example, when acting as (e.g., a specific) intermediate function, an indication of the security confidence level can be associated with the WTRU. The CoS can be digitally signed by a cybersecurity authority and / or can be retrieved and / or pushed to other entities, such as as a UDM and / or other WTRU parameter in a security policy.

[0091] For example, using any procedure for requesting(one or more) WTRU parameters and / or requesting(one or more) WTRU policy requests with(one or more) indications for a CoS request, a WTRU can request and / or receive a CoS signed by an authorized authority from its home network. For example, when a CoS is requested by another entity (e.g., in AI / ML operations, such as to determine whether a WTRU is capable and / or authorized to act as an intermediary node in an AI / ML role), the WTRU can provide the CoS to the requesting entity. The WTRU can receive CoS information, for example, along with one or more parameters. Additionally or alternatively, the WTRU can receive CoS information to implement a discovery procedure. For example, when a WTRU decides to participate in an AI / ML operation, the CoS information and / or discovery procedure can be used in the WTRU selection process (e.g., after discovery). The WTRU can perform threat detection and / or privacy violation detection on models received from participating AI / ML WTRUs (e.g., before it performs group aggregation of intermediate models received from participating WTRUs). For example (e.g., in the case of an AI / ML intermediate model aggregator role), if the WTRU is qualified and / or selected as an intermediate node in the AI / ML operation, the WTRU can perform threat detection and / or privacy violation detection on the models received from the AI / ML participating WTRU (e.g., before it performs group aggregation of intermediate models received from the participating WTRU). The WTRU can then deliver the group-aggregated models, for example, along with (e.g., a WTRU CoS signed by an authoritative body) to (e.g., the next) aggregator.

[0092] The WTRU can receive data from an upstream entity (e.g., WTRU or AS), perform security screening, and / or take action on the AI / ML data (e.g., for its own sake). For example, if the WTRU performs one or more roles in AI / ML segmentation, AI / ML relay / agent, and / or data / model distribution, the WTRU can receive data from an upstream entity (e.g., WTRU or AS), perform security screening, and / or take action on the AI / ML data (e.g., for its own sake). The WTRU can deliver the processed AI / ML data, for example, along with (e.g., a WTRU CoS signed by an authorizing authority), to one or more downstream entities. After completing the WTRU portion of the AI / ML operation, the WTRU can deliver the processed AI / ML data, for example, along with (e.g., a WTRU CoS signed by an authorizing authority), to one or more downstream entities.

[0093] Enhancements as described herein (e.g., enhancements to 3GPP network data analytics features) can enable analytics generation to determine the CoS of network entities, such as determining the CoS of a WTRU or a set of WTRUs accessing a specific network resource (e.g., a specific network slice and / or a specific Data Network Name (DNN)). One or more analytics IDs and / or one or more analytics filters can enhance the network data analytics framework.

[0094] Analysis identifiers (IDs) can be configured for one or more roles (e.g., for use in one or more roles). Roles can include a set of roles and / or capabilities that qualify a WTRU to be one or more of, such as a middle node, relay node, agent node, aggregator, UAV group leader, and / or security gateway node. Additionally or alternatively, the analysis ID can include one or more capabilities. Capabilities can include a set of security capabilities, such as threat detection, privacy violation detection, supported protocol(s), AI / ML model aggregation, and / or supported AI / ML operations. Analysis filters can include one or more of the following: Region of Interest (AoI), Single Network Slice Auxiliary Information (S-NSSAI), DNN, one or more service characteristics, one or more valid application IDs, analysis report target, service usage threshold, WTRU security profile, and / or WTRU authorization.

[0095] The AoI can include, for example, the geographic location and / or cell / TA / RA in which the analysis is generated. S-NSSAI can include a network slice that provides resources for applications used by WTRUs to run AI / ML operations. The DNN can include WTRU access permissions, such as when an assessment is being performed. Service characteristics can include whether the service corresponds to an application AI / ML operation. Valid application IDs can include the application ID of the application running during a CoS assessment (e.g., during an assessment window / period). The time window can include the time window when the assessment should occur. The target of the analysis report can include a single WTRU subscription persistent identifier (SUPI) or a WTRU group (e.g., an internal group ID or a list of WTRUs). Service usage thresholds can include an acceptable level of service generated by WTRUs and / or WTRU groups, such as when running applications with specific service characteristics. WTRU security profiles can include WTRU hardware and / or software security profiles, such as data remotely authenticated via WTRUs and / or stored in the UDM. WTRU authorization can include, for example, WTRU security policies authorizing the requested role.

[0096] The Network Data Analysis Function (NWDAF) can utilize the services of one or more other Network Functions (NFs) to, for example, collect information that enables the NWDAF to generate CoS analysis for a list of WTRUs or WTRUs. The NWDAF can collect information, for example, about the hardware and / or software capabilities of the WTRUs from the UDM and / or UDR. The NWDAF can collect information from the PCF to, for example, determine how a service triggers policies from the PCF. The NWDAF can collect service usage information, for example, from the OAM and / or from the UPF that handles services for a specific application.

[0097] The example input data used by NWDAF can be summarized in Table 1. information source describe WTRUID AMF, SMF, AF GPSI Group ID AMF, SMF, AF Identifier of WTRU groups provided by AF AoI AMF, SMF Areas of interest, such as geographic location, neighborhood, TA, or RA. S-NSSAI SMF Information used to identify resources in a network slice DNN SMF The DNN where PDU sessions supporting AI / ML services reside (one or more) application IDs SMF, AF Application IDs for both AI / ML services and the applications using those services Effective time window AF The time window in which data collection should be performed Business usage threshold OAM, UPF This should be permitted for business operations running AI / ML applications. Security capabilities AMF, UDM, AUSF Supported security protocols / algorithms, etc. Security policy rules PCF, UDM, AUSF Authorize WTRU to act as an intermediary node WTRU security profile WTRU, UDM WTRU security features, software version, patches Behavioral Reputation UDM WTRU logs, reputation, recommendations Authorization AUSF, PCF Authorize WTRU to act as an intermediate node for execution. Table 1. Example of input data for CoS evaluation.

[0098] Output analysis is disclosed in this document. NWDAF can provide consumers with analytical results, such as one or more of UDM, PCF, and / or AF. The analysis and / or results may include the CoS of WTRU and / or WTRU groups, as shown in Table 2, for example.

[0099] Table 2. Example output analysis for Cos evaluation.

[0100] Systems and methods for the CoS evaluation framework can be utilized to perform functions as described herein. The CoS framework can evaluate the CoS of a WTRU performing, for example, the role of an intermediary node (e.g., in use cases, performing one or more of AI / ML operations, relays, agents, gateways, and / or UAV group leaders within FL operations). Intermediary nodes can perform network unit functions such as relay nodes, agents, security gateways, AI / ML aggregators in distributed hierarchical FLs, AI / ML server functions in segments, and / or more. CoS can be evaluated dynamically, for example, to present the WTRU's qualifications and / or roles for qualifying it as an intermediary node (e.g., in use cases like AI / ML, ProSe, and / or UAV). Network Data Analysis Functions (NWDAF) (e.g., in 3GPP 5G systems) can derive the CoS for one or more WTRUs participating, for example, as an intermediary node in (e.g., specific) application operations and / or using specific network resources (e.g., specific S-NSSAI and / or DNN).

[0101] CoS evaluation functionality can implement resource access policies. Resource access policies can help network entities (e.g., WTRUs) act as intermediary nodes. For example, resource access policies can be used to determine whether a WTRU (e.g., a principal WTRU) is authorized and / or configured to perform the required functions (e.g., within network functions such as AI / ML operations). Resource access policies can be dynamically formed, for example, based on one or more of the resources accessed, operational roles, and / or one or more of the principle of least privilege. The CoS framework can be utilized to determine the scope(s) of the CoS, such as location, time range, and / or one or more of the network identified by DNN / S-NSSAI / DNS. The CoS, for example, along with its scope, can be digitally signed and / or can be verified by the entity that makes the decision for selecting the intermediary node.

[0102] Figure 2 An example of CoS procedure 200 is illustrated. At 212, AF 210 can select a candidate set of network entities. The candidate set of network entities can function, for example, as an intermediate node in an AI / ML FL. AF 210 can request CoS analysis from NWDAF 204, for example, associated with a candidate set (e.g., WTRU 202 or a group of WTRUs). AF 210 can select candidates based on the characteristics of the service type of the application operation to be performed. AF can send candidate sets and / or indications of candidate sets to, for example, Network Exposure Function (NEF) 208. NEF 208 can obtain a list that may include (e.g., matching the indicated criteria) one or more WTRU 202s. NEF 208 can query the Unified Data Manager / Unified Data Storehouse (UDM / UDR) to obtain, for example, a list that may include (e.g., matching the indicated criteria) one or more WTRU 202s. NEF 208 can map requests from AF 210. NEF 208 can map requests from AF 210 to, for example, a set of analytics IDs and / or analytics filtering information for the requested role, to derive (e.g., specific) CoS analytics to match the requested role in the WTRU list.

[0103] At point 214 (e.g., once NEF 208 receives the candidate set), NEF 208 may send (e.g., forward) an AF request to NWDAF 204, which may include (e.g., accommodate) a CoS evaluation function. NWDAF 204 may obtain WTRU CoS evaluation data, for example, from another NF206. The evaluation data can be used to evaluate the CoS of a network entity (e.g., WTRU 202) as a candidate for a role in supporting operations (e.g., FL intermediate model threat detection and / or aggregation operations). The dataset may include one or more parameters as disclosed herein (e.g., as in Table 1). For example, one or more parameters may include one or more of security profiles, principal permissions, security status, security policy rules, network status, principal behavior history, principal attributes, reputation, and / or recommendations from another entity. CoS can be evaluated based on one or more of these parameters. The security profile may include one or more of hardware profiles and / or software profiles (e.g., associated with WTRU). CoS data analysis provided by NWDAF 204 may be valid, for example, based on the validity window provided by NWDAF 204.

[0104] At 216, NWDAF 204 may collect data from one or more NF 206, for example, based on the analysis filters and / or analysis IDs provided by AF 210. WTRU may send data based on the analysis filters and / or analysis IDs. Additionally or alternatively, NWDAF 204 may collect data from one or more NF 206, for example, as described in Table 1 and / or elsewhere herein.

[0105] At 218, NWDAF 204 may, for example, use data collected from one or more related NFs 206 (e.g., as described herein) to evaluate the CoS of one or more WTRUs 202 in the candidate set. The CoS of WTRUs 202 and / or WTRU groups 202 associated with network resources (e.g., S-NSSAI, DNN, and / or AF 210) may be generated by NWDAF 204 and / or may be provided to requesting AF 210 and / or any other analysis consumer (e.g., an analysis consumer that may require it). NWDAF 204 may use one or more algorithms to perform one or more evaluations, for example, using data collected at 216. The data may include one or more of clustering, neural networks, fuzzy logic, rule bases, and / or so on. Alternatively or additionally, NWDAF 204 may use one or more combined algorithms to produce (e.g., optimal) analysis (e.g., with greater flexibility). The network may send the evaluated CoS to, for example, WTRUs. For example, the evaluated CoS may be sent from NWDAF 204.

[0106] CoS output from NWDAF 204 can be digitally signed by NWDAF 204. The digital signature can be verified, for example, by one or more CoS consumers. CoS can be written using UDR / UDM, for example, for subsequent retrieval (e.g., without triggering costly re-evaluation). CoS can have validity ranges, such as time and / or location, as described in Table 2 and / or elsewhere herein.

[0107] At 220, the CoS for each network entity (e.g., each WTRU 202 in the candidate set) can be sent to NEF 208, for example, for further filtering (e.g., using one or more resource access policies). At 222, for example, once the resource access policies are applied, NEF 208 can send a filtered set of candidate network elements to be used by the relevant AF 210. Alternatively or additionally, scoring results (one or more) can be sent to AF 210, which can, for example, decide which WTRU 202 can participate in the role of application operation.

[0108] At point 224, for example, after AF 210 selects one or more WTRUs 202 that match the role using the received CoS, AF 210 can perform related operations (e.g., it can initiate an operation, for example, by sending an instruction along with a CoS signed by an authorized authority to the WTRU 202 that can play the desired role). For example, if the CoS matches the desired CoS, the digitally signed CoS can be used by the WTRU 202 that requested to participate in the intermediate node role. Applying an operation initiation may include an operation initiation message. The operation initiation message may be based on the evaluated CoS. The operation initiation message may be sent based on a match between the evaluated CoS and a desired (e.g., a predetermined CoS). For example, the network may compare the evaluated CoS with the desired CoS.

[0109] Figure 3 An example of CoS exchange 300 between the WTRU and the network is illustrated. At 306, the WTRU 302 can perform PDU session establishment. For example, during the PDU session establishment procedure, the WTRU 302 can provide the CoS acquired during the initiation of application operations (e.g., as described herein). The SMF can regard the presence of the CoS as an indication of the WTRU's capabilities and / or authorization manifested as intermediate node functionality. Additionally or alternatively, the CoS, along with subscription data within the session management subscription data used for PDU session establishment, can be used by the SMF, for example, to determine whether the WTRU 302 complies with authorization (e.g., on the DNN provided by the WTRU 302 during the PDU session establishment request).

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

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

[0112] At 310, 5GC / AS 304 can send a PDU session establishment accept message to WTRU 302. Application operations can be associated with (e.g., specific) DNN / S-NSSAI, such as with FL-specific QoS / charging requirements. For example, PDU session resources can be allocated if the AF (e.g., based on WTRU 302 CoS as described herein) can grant WTRU 302 authorization to participate in (e.g., specific) operations.

[0113] At 312, for example, successful CoS verification provided to WTRU 302 via a transparent container in the PDU session establishment accept message can be used to trigger the initiation of application operations. At 314, WTRU 302 can participate in one or more operations.

[0114] Figure 4 An example of a CoS procedure 400 with AI / ML segmentation is illustrated. At 410, the CoS of WTRU 402 can be evaluated, for example, using one or more inputs as described herein (e.g., in Table 1). The CoS can be stored in UDM / PCF 404 and / or presented to WTRU 402. Alternatively or additionally, the CoS of WTRU 402 can be requested from other NFs and / or external AFs 408 via NEF 406.

[0115] At 412, the AI / ML segmentation discovery procedure can be performed, for example, using existing mechanisms (e.g., the PC5 discovery procedure for ProSe as specified in 3GPP). One or more (e.g., a group) WTRU 402 candidates can be discovered participating in the AI / ML segmentation procedure, for example, as a result of the AI / ML segmentation discovery procedure.

[0116] WTRU 402 can perform AI / ML segmentation. For example, WTRU 402 can receive a request from the origin WTRU 402. This request may include an AI / ML request. WTRU 402 can receive the output of layer 1-5 operations, for example, along with the request. WTRU 402 can perform AI / ML operations of layers 6-15 and / or send the results to AS 408 (e.g., to perform the remaining AI / ML operations of layers 16-24). Additionally or alternatively, WTRU can send a CoS digitally signed by an authorized authority. WTRU 402 can, for example, perform security threat detection on the input from the origin WTRU 402 before (e.g., if necessary) performing AI / ML operations of layers 6-15, and / or (e.g., only) continue if no security threat is detected. For example, when AS 408 receives a request from the intermediate WTRU 402, AS 408 can verify the CoS in the message (e.g., before it continues with the remaining AI / ML operations). WTRU 402 may include multiple WTRUs. For example, different WTRUs may perform one or more different operations as described herein.

[0117] For example, if peer(s) WTRU 402 already possesses a CoS prior to the discovery process, the CoS can be sent in one or more discovery messages and / or verified by the receiving peer. Alternatively, the receiving peer can request a CoS from the sending peer's CoS repository NF (e.g., UDM / Policy Control Function (PCF)). During the discovery process, for example, all entities can present a corresponding CoS including authorized roles and / or capabilities. Peers can verify the CoS to verify / confirm that WTRU 402 is authorized and / or capable of being that role(s).

[0118] Alternatively or additionally, WTRU 402 may request AI / ML AF 408 to locate a relay node on behalf of WTRU 402, for example, by sending the request along with relevant information to AF 408. This relevant information may include one or more of performance requirements, location, relay node role, AI / ML application ID, and / or more. For example, if no relay node is found for the AI / ML segment (e.g., at 412), WTRU 402 may request AI / ML AF 408 to locate a relay node on behalf of WTRU 402.

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

[0120] At position 422, an AI / ML split may be possible. AF 408 may match the requested CoS with the CoS received from the UDM404 of candidate WTRU 402, and / or select the matching (e.g., best match) WTRU 402 to perform the splitting role and / or initiate the AI / ML split. In one or more procedures, additional information for communication between WTRU 402 and the relay may be included, such as certificate ID and / or more.

[0121] Figure 5 The illustration shows an example CoS discovery request procedure 500. At 512, WTRU 502 can establish (e.g., secure) a connection with the 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 may include, for example, an indication that WTRU 502 is interested in announcing, monitoring, and / or discovering something. The WTRU identifier (e.g., the restricted discovery request message) may additionally or alternatively include one or more WTRU identity fields, which may, for example, be set to an International Mobile Subscriber Identity (IMSI). The command field in the message may indicate what type of ProSe operation is requested, such as a ProSe query operation for the discovering WTRU 502 and / or a ProSe response operation for the discovered WTRU 502.

[0122] The discovery request message may include a discovery type, which may be set to restricted discovery, for example. The discovery model field may indicate whether ProSe discovery uses model A or model B. The application ID may represent a unique identifier for the WTRU application, such as an identifier that has triggered the transmission of the discovery request message. The discovery request message may additionally or alternatively include an application-level container, such as 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 CoS.

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

[0124] At 516, 5G DDNMF 504 can send an authorization request to Prose / AI / ML application server (AS) 510. The authorization request may include one or more fields. These fields may include RPAUID and / or request type. 5G DDNMF 504 may locate ProSe application server 510, for example, based on the application ID (e.g., received at 512). The request type may be set, for example, according to ProSe operations, to restricted discovery / monitoring, restricted discovery / announcement, restricted discovery / query, and / or restricted discovery / response. Additionally or alternatively, the request message may include application-level containers, such as those for monitoring WTRU 502 and / or discoverer WTRU 502.

[0125] At 518, ProSe / AI / ML AS 510 can perform authorization on the received request. AS 510 can check whether the CoS information for the requested WTRU is available, for example, at UDM 506. AS 510 can verify the CoS information, for example, by determining (e.g., ensuring) the existence of a timer, whether the validity of the CoS has expired (e.g., the timer has not expired), and / or whether the CoS information exists. For example, if the CoS information does not exist in UDM 506, AS 510 can perform a CoS evaluation procedure (e.g., a procedure as described herein). Figure 2 (After the procedure in the program). AS 510 can use the retrieved CoS and / or newly generated CoS, along with other ProSe-related parameters, to decide whether to authorize the discovery request.

[0126] At 520, the ProSe / AI / ML AS 510 can send (e.g., return) an authorization response (e.g., one or more ProSe discovery WTRU IDs (one or more PDUIDs), response type) message to the 5G DDNMF 504. The one or more PDUIDs can correspond to, for example, RPAUIDs stored in the ProSe application / AI / ML server 510. For similar content such as declaring WTRU 502 and / or other types of ProSe discovery operations (e.g., monitoring WTRU 502, discoverer WTRU 502, and / or found WTRU 502), the response type can be set to restricted discovery / declaration acknowledgment (ack). The 5G DDNMF 504 can verify that at least one of the received PDUIDs belongs to the requesting WTRU 502. Additional or alternatively, other parameters may be included. At 522, the 5G DDNMF 504 can obtain one or more of the following: one or more ProSe codes, one or more discovery filters, and / or one or more validity timers.

[0127] The network can send an operation initiation message to, for example, WTRU 502. The operation initiation message can be based on the evaluated CoS. For example, the network can determine to send an operation initiation message when the evaluated CoS matches the expected (e.g., predetermined) CoS.

[0128] The WTRU can be a monitoring WTRU 502 (e.g., Model A). For example, if the PLMN ID in the target PDUID indicates a Home Public Land Mobile Network (HPLMN) and / or if at least one of the received pairs (e.g., the target PDUID and / or the target RPAUID) corresponds to a valid ProSe restricted code, such as including a valid PC5 radio technology match as indicated by the PC5_tech parameter (e.g., at 512), then, for example, to monitor WTRU 502, the ProSe function in the HPLMN can retrieve the ProSe restricted code (e.g., corresponding to one or more of the target PDUID, application ID, and target RPAUID). The ProSe function in the HPLMN can (e.g., in the context of announcing WTRU 502) store the PDUID of the monitoring WTRU 502. For example, if restricted direct discovery with extended application control is used, the ProSe restricted code can be replaced by a ProSe restricted code prefix. For example, if the declaration enable indicator is stored in the WTRU context, HPLMN's ProSe function can trigger a declaration warning procedure (e.g., as described in this paper) to notify the declaration WTRU 502 to perform a declaration.

[0129] For example, when declaring a WTRU 502 (e.g., Model A), a 5G DDNMF 504 can assign a ProSe restricted code and / or an associated validity timer. The ProSe restricted code may correspond to an RPAUID (e.g., which is included in a discovery request from the WTRU 502). The ProSe function may, for example, store one or more of the RPAUID, the ProSe restricted code, and / or the associated validity timer in the user context.

[0130] WTRU can be discoverer WTRU 502 (e.g., model B). For example, for discoverer WTRU 502, 5GDDNMF 504 can assign one or more of the following: ProSe response code, ProSe query code, and / or (one or more) associated discovery query filters. Additionally or alternatively, the ProSe function can assign a validity timer (e.g., which can be associated with the ProSe response code). The ProSe response code can correspond to RPAUID (e.g., which can be included in a discovery request from WTRU 502). The validity timer can indicate the validity period of the code (e.g., how long this ProSe response code will be valid). The ProSe function can, for example, store one or more of the following in the user context: RPAUID, ProSe response code, ProSe query code, (one or more) discovery query filters, and / or associated validity timers.

[0131] The WTRU can be the discoverer WTRU 502 (e.g., Model B). For example, for the discoverer WTRU 502, the 5G DDNMF 504 can locate the context of (one or more) the discoverer WTRU 502. For example, the 5G DDNMF 504 can locate the context of (one or more) the discoverer WTRU 502 if the PLMN ID in the target PDUID indicates the HPLMN and / or if at least one of the received (target PDUID, target RPAUID) pairs corresponds to a valid ProSe response code (e.g., including a valid PC5 radio technology match as indicated by the PC5_tech parameter, e.g., at 512). The ProSe function in the HPLMN can retrieve the ProSe query code and / or the associated validity timer. The ProSe query code can be the code used by the ProSe function to construct a discovery query filter (e.g., such that it can trigger the discoverer WTRU 502 to send a response). The ProSe function can, for example, assign one or more discovery response filters based on the ProSe response code. The ProSe response code can be assigned to the discoverer WTRU 502. Validity timers can indicate the validity period of a code (e.g., how long a ProSe query code and / or ProSe response code will be valid).

[0132] At 524, 5G DDNMF 504 can return (e.g., send) a discovery response message to WTRU 502. The discovery response message can be generated by the network (e.g., DDNMF) based on one or more of the WTRU identifier and / or CoS. Depending on the type of ProSe discovery operation requested, the discovery response message can include different information. The message can include, for example, fields for monitoring WTRU 502. Fields can include one or more of discovery filters, metadata indicators, discovery entry IDs, application-level containers, and / or PC5_tech. Discovery filters can include (e.g., the ProSe restricted code to be monitored) and / or TTL (e.g., indicating how long the relevant ProSe restricted code in the discovery filter will be valid after being received). The discovery response message can include one or more fields (e.g., discovery model, one or more ProSe query codes, one or more discovery response filter validity timers, [PC5_tech], etc.). The discovery model can indicate that model B was used. Discovery response filters can be generated by 5G DDNMF 504, for example, based on the ProSe response code.

[0133] For example, if Figure 5If the process is successful (e.g., at and / or after 524), then WTRU 502 can be ready to perform the ProSe discovery operation. For example, between WTRU-A and WTRU-B, there may be a (e.g., restricted) ProSe discovery procedure for AI / ML segmentation operations. This procedure is valid for both Model A and Model B discovered by ProSe.

[0134] Figure 6 The illustration shows an example CoS discovery procedure 600 for AI / ML segmentation. At 614, the WTRU-A 602 can execute a CoS-knowing restricted ProSe discovery procedure, such as, for example, as described herein (e.g., as shown in the image). Figure 5 The WTRU-A 602 can be, for example, a declared WTRU for model A. The WTRU-A 602 can be, for example, a discoverer WTRU for model B.

[0135] At 616, WTRU-B 604 may additionally or alternatively perform a CoS-known restricted ProSe discovery procedure, for example, as described herein (e.g., as shown in the image). Figure 5 As described in the diagram (in Chinese). WTRU-A 602 can be, for example, a monitoring WTRU for model A. WTRU-B 604 can be, for example, a discoverer WTRU for model B. Once successful (e.g., after 616), WTRU-A 602 and / or WTRU-B 604 can be ready to perform PC5 ProSe discovery. At 618, WTRU-A 602 and WTRU-B 604 can perform PC5 ProSe restricted discovery. At 620 (e.g., once successful), WTRU-A 602 and WTRU-B 604 can (e.g., further) negotiate AI / ML capabilities for AI / ML segmentation.

[0136] In some examples, there may be a security policy for delivering CoS to, for example, decision points (e.g., entities). Decision points may make decisions about the selection of intermediate nodes for AI / ML operations (e.g., using CoS information in the security policy). CoS may be additionally or alternatively requested by consumers of CoS, for example (e.g., directly) from UDM / UDR 608.

Claims

1. A wireless transmit / receive unit (WTRU) including a processor, said processor being configured to: Send a request for a security classification (CoS), the CoS including an indication of the security confidence level associated with the WTRU; Receive CoS from the network; and Receive the Artificial Intelligence Machine Learning (AIML) operation start message, in which, The AIML operation initiation message is received based on the received CoS.

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

3. The WTRU according to claim 1, wherein, The one or more parameters include a security profile associated with the WTRU.

4. The WTRU according to claim 3, wherein, The security configuration file includes one or more of the following: a hardware configuration file or a software configuration file.

5. The WTRU according to claim 1, wherein, The received CoS is received from the Network Data Analysis Function (NWDAF).

6. The WTRU according to claim 1, wherein, The received CoS is evaluated based on one or more of the following: subject authority, security status, security policy rules, network status, subject behavior history, subject attributes, reputation, or recommendations from another entity.

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

8. The WTRU according to claim 1, wherein, The processor is further configured to send data based on analysis filters.

9. The WTRU according to claim 8, wherein, The analysis filters include one or more of the following: Region of Interest (AoI), Single Network Slice Auxiliary Information (S-NSSAI), DNN, service characteristics, valid application identifier, target of the analysis report, service usage threshold, security profile associated with the WTRU, or authorization associated with the WTRU.

10. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Send a request for a security classification (CoS), the CoS including an indication of the security confidence level associated with the WTRU; Receive CoS from the network; as well as Receive an Artificial Intelligence Machine Learning (AIML) operation initiation message, wherein the AIML operation initiation message is received based on the received CoS.

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

12. The method according to claim 10, wherein, The one or more parameters include a security profile associated with the WTRU.

13. The method according to claim 12, wherein, The security configuration file includes one or more of the following: a hardware configuration file or a software configuration file.

14. The method of claim 10, wherein, The received CoS is received from the Network Data Analysis Function (NWDAF).

15. The method according to claim 10, wherein, The received CoS is evaluated based on one or more of the following: subject authority, security status, security policy rules, network status, subject behavior history, subject attributes, reputation, or recommendations 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 intermediate node functionality.

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

18. The method according to claim 17, wherein, The analysis filters include one or more of the following: Region of Interest (AoI), Single Network Slice Auxiliary Information (S-NSSAI), DNN, service characteristics, valid application identifier, target of the analysis report, service usage threshold, security profile associated with the WTRU, or authorization associated with the WTRU.

Images