Method, architecture, apparatus and system for asserting wireless transmit / receive unit (WTRU) trustworthiness

Abstract

Processes, methods, architectures, apparatuses, systems, devices, and computer program products relate to asserting relay WTRU trustworthiness. In an embodiment, an apparatus may be configured to send a request message to a relay WTRU to obtain information indicating a credibility of execution of the relay WTRU as a relay; receiving a response to the request message from the relay WTRU, the response including information indicating the reliability of execution of the relay WTRU as a relay; and authenticating information indicating the credibility of the relay WTRU using the key identifier.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 336,441, filed on April 29, 2022, which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to the fields of communications, software, and coding, including, for example, methods, architectures, devices, and systems related to asserting the trustworthiness of a relay WTRU, such as using Proximity-Based Services (ProSe) and other WTRU-to-network relay applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding can be obtained from the detailed description given below in conjunction with the accompanying drawings by way of example. The figures (such as the detailed description) in such drawings are examples. Therefore, the figures (FIGs.) and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("ref.") in the various figures indicate the same elements, and wherein:

[0005] Figure 1A is a system diagram illustrating an example communication system;

[0006] Figure 1B It shows that it can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0007] Figure 1C It shows that it can be Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0008] Figure 1D It shows that it can be Figure 1A A system diagram of a further example RAN and a further example CN used within the illustrated communication system;

[0009] Figure 2 An example of 5G ProSe direct discovery with a first model A is shown;

[0010] Figure 3 An example of 5G ProSe direct discovery with a second model B is depicted;

[0011] Figure 4 An example of an architecture model using ProSe WTRU to network relay is shown;

[0012] Figure 5An example of a passport model is shown;

[0013] Figure 6 An example of a background check model is shown;

[0014] Figure 7 An example of a relay discovery procedure with relay WTRU trustworthiness is shown;

[0015] Figure 8 An example of using a solicitation procedure to assert the trustworthiness of a remote WTRU and a relay is shown;

[0016] Fig. 9 An example of using a notification procedure to assert the trustworthiness of a remote WTRU and a relay is shown;

[0017] Fig.10 An example of asserting the trustworthiness of a remote WTRU and a relay during a unicast (e.g., PC5) link establishment procedure is shown;

[0018] Fig.11 shows the process of relay connection establishment using network-assisted remote attestation;

[0019] Fig.12 shows the process of relay connection establishment for remote attestation assisted by ProSe Key Management Function (PKMF);

[0020] Fig.13 A process for WTRU remote attestation during PDU session establishment is shown;

[0021] Fig.14 shows the process of WTRU remote attestation during the registration process;

[0022] Fig.15 Another example of a method for asserting the authenticity of a relay WTRU is shown; and

[0023] Fig.16 Another example of a method for asserting the authenticity of a relay WTRU is shown. DETAILED DESCRIPTION

[0024] In the following detailed description, many specific details are set forth to provide a comprehensive understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be implemented without some or all of the specific details set forth herein. In other cases, well-known methods, processes, components and circuits have not yet been described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein may be implemented in place of or in conjunction with the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein. Although various embodiments are described and / or claimed herein, wherein devices, systems, equipment, etc. and / or any of their elements perform operations, processes, algorithms, functions, etc. and / or any part thereof, it should be understood that any embodiments described and / or claimed herein assume that any device, system, equipment, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0025] Example Communication System

[0026] The methods, devices, and systems provided herein are well suited for communications involving both wired and wireless networks. Figures 1A-1D An overview of various types of wireless devices and infrastructure is provided in which various elements of the network can utilize, perform, be arranged according to and / or adapted for the methods, apparatuses, and systems provided herein and / or be configured for the methods, apparatuses, and systems provided herein.

[0027] Figure 1A 1 is a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable 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 (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0028] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

[0031] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0032] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

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

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

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

[0036] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

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

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

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

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

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

[0042] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together, such as in an electronic package or chip.

[0043] The transmission / reception element 122 can be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station via an air interface 116. For example, in one embodiment, the transmission / reception element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmission / reception element 122 can be, for example, an emitter / detector configured to transmit and / or receive IR, UV or visible light signals. In one embodiment, the transmission / reception element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmission / reception element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0045] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-modal capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

[0048] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0049] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, electronic game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Component / peripheral 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographic location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0050] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (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 to reduce and / or substantially eliminate self-interference through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or through the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

[0053] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-Bs 160a, 160b, and 160c may communicate with each other via an X2 interface.

[0054] Figure 1C The CN 106 shown in FIG. 1 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although each of the foregoing elements is described as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0059] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (eg, temporarily or permanently) a wired communications interface with a communications network.

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

[0061] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating from outside the BSS to a STA may be reached by the AP and may be delivered to the STA. Traffic from a STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within a BSS may be sent by the AP, where the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between source and destination STAs (e.g., directly between them) using direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

[0062] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) or a width dynamically set by signaling. The primary channel can be an operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, such as in an 802.11 system. For CSMA / CA, a STA (e.g., 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, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0063] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, formed via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0064] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two discontinuous 80MHz channels, which can be called an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser, which can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The stream can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, an entity, etc.

[0065] 802.11af and 802.11ah support sub-1GHz operating modes. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metering type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., in order to maintain very long battery life).

[0066] WLAN systems (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy transmitting to the AP, for example, due to a STA (supporting only the 1MHz operating mode), the entire available band may be considered busy, even if most of the band remains idle and may be available.

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

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

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

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

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

[0072] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interworking between NR and E-UTRA, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0073] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is described 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.

[0074] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing, for example, to customize CN support for the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

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

[0076] The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, for example, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0078] Given that Figures 1A-1D as well as Figures 1A-1D Corresponding descriptions of, one or more or all of the functions described herein with respect to any of the following: WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other element / device described herein (multiple) may be performed by one or more policy elements / devices (not shown). A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0079] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. 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 in order 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. For testing purposes, the simulation device can be directly coupled to another device, and / or over-the-air wireless communication can be used to perform the test.

[0080] One or more simulation devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario in a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas).

[0081] According to an embodiment, a method performed by a remote WTRU to assert the authenticity of a relay WTRU is described, the method comprising any of the following actions:

[0082] -The remote WTRU can obtain the relay credibility evidence token (information) from the relay during the discovery process or during the link establishment with the relay, or obtain the relay credibility evidence token (information) from the application function (AF) before or after the link establishment with the relay (AF connection information pre-configured or provided via the relay during connection).

[0083] - The remote WTRU may verify the relay authenticity evidence token even when outside macro coverage.

[0084] - The remote WTRU may use the relay WTRU authenticity evidence token to make a decision regarding the relay WTRU authenticity and continue the connection with the relay WTRU if the relay WTRU is deemed authentic, or reject the relay WTRU connection if the relay WTRU is deemed unauthentic.

[0085] According to an embodiment, a method performed by a relay WTRU to assert the authenticity of a remote WTRU is described, the method comprising any of the following actions:

[0086] -The relay WTRU can obtain the remote WTRU credibility evidence token (information) from the remote WTRU during the discovery process or during the link establishment with the remote WTRU, or obtain the remote WTRU credibility evidence token (information) from the AF before or after the link establishment with the remote WTRU (for example, the AF connection information is pre-configured).

[0087] - The relay WTRU may autonomously verify the remote WTRU authenticity evidence token via its available macro coverage or even when out of macro coverage.

[0088] - The relay WTRU may use the remote WTRU authenticity evidence token to make a decision regarding the authenticity of the remote WTRU and continue the connection with the remote WTRU if the remote WTRU is deemed authentic, or reject the remote WTRU connection if the remote WTRU is deemed unauthentic.

[0089] According to an embodiment, a method for network controlled assertion of relay trustworthiness performed by a remote WTRU is described, the method comprising any of the following actions: The remote WTRU performs an assessment of relay trustworthiness of a relay WTRU during network controlled authorization. The remote WTRU requests an attestation result in a connection request with the relay WTRU. The remote WTRU may receive an attestation result protected by a network access key based on the remote WTRU primary authentication (e.g., in Direct Security Mode Complete (DSMC)). The remote WTRU may verify the security of the result and pass the result to upper layers before continuing with link establishment.

[0090] According to an embodiment, a method of WTRU remote attestation performed by a WTRU during an enhanced PDU session establishment procedure is described, the method comprising any of the following actions: The WTRU may perform a remote attestation procedure as part of a PDU session establishment enhanced with remote attestation. The remote attestation may be performed by an SMF on a NAS. A relay WTRU may receive the attestation evidence information in a PDU establishment, accept the message and present it to other WTRUs / network entities (e.g., a remote WTRU that wishes to connect with the WTRU acting as a relay).

[0091] According to an embodiment, a method of remote attestation of a WTRU during an enhanced registration procedure performed by a WTRU is described, the method comprising any of the following actions: The WTRU may perform a remote attestation procedure as part of a registration procedure enhanced with remote attestation. The remote attestation may be performed by the AMF over NAS. The WTRU may receive attestation evidence during a WTRU / UE Configuration Update (UCU) procedure and present it to other WTRU / network entities (e.g., to a remote WTRU that wishes to connect when acting as a relay).

[0092] Proximity-based Services (ProSe)

[0093] Proximity Services (ProSe) are services that may be provided by the 3GPP system based on the proximity of WTRUs to each other. To provide proximity services, a WTRU may perform a ProSe discovery procedure to discover other WTRUs in proximity.

[0094] There can be two ProSe discovery modes: Model A and Model B.

[0095] In model A, if Figure 2 As shown, a WTRU (e.g., an announcer WTRU) may broadcast an announce message (211), for example, the announce message having a ProSe code (which may be associated with an ID of the announcer WTRU or associated with a service provided by the announcer WTRU). Other WTRUs (monitoring WTRUs) that receive the announce message may know that the announcer WTRU may be nearby.

[0096] In model B, if Figure 3 As shown, a WTRU (e.g., a discoverer WTRU) may broadcast a solicitation request message (311), for example, the solicitation request message having a ProSe query code (which may be associated with an ID of a WTRU to be discovered or associated with a ProSe service to be discovered). Other WTRUs (discovered WTRUs) receiving the solicitation request message may respond to the request (312a, 312b), for example, the response having a ProSe response code (which may be associated with an ID of a discovered WTRU or associated with a ProSe service provided by the discovered WTRU). The discoverer WTRU knows that the discovered WTRU may be nearby.

[0097] Both discovery modes can be used to perform group discovery (discovering WTRUs belonging to a specific group), WTRU to network relay discovery (discovering WTRU to network relays that provide connectivity to the 5G network).

[0098] For group discovery, the discovery message (announcement, solicitation request / response) may additionally include a group ID. For WTRU to network relay discovery, the discovery message (announcement, solicitation request / response) may use a relay service code (instead of a ProSe code) to indicate a WTRU to network relay service.

[0099] WTRU to Network Relay

[0100] like Figure 4 As shown, the ProSe WTRU to network relay entity 402 may provide functionality to support a remote WTRU 401 to connect to the network.

[0101] If the remote WTRU 401 is outside of NR coverage and cannot communicate directly with the core network 106 / 115 (or is within NR coverage but prefers to communicate using unicast (e.g., PC5)), the remote WTRU 401 may discover and select a WTRU-to-network relay / (e.g., relay) WTRU 402. The remote WTRU 401 may establish a unicast (e.g., PC5) session with the WTRU-to-network relay 402, and the WTRU-to-network relay 402 may establish a PDU session (or a PDN connection in an evolved packet core (EPC)) for the remote WTRU 401, or the remote WTRU 401 may establish a PDU session via the (e.g., relay) WTRU 402. After IP address / prefix allocation, traffic between the remote WTRU 401 and the network may be relayed by the WTRU-to-network relay 402.

[0102] Trust Assertions

[0103] The following subsections provide background information on the credibility verification of the two modes (models).

[0104] Passport Model

[0105] like Figure 5 As shown, the passport model may be so named because it is similar to the way in which a country issues passports to its citizens. The nature of the evidence that an individual may (e.g., need to) provide to their local authorities is specific to the country in question. The citizen retains control of the resulting passport document and presents it to other entities such as an airport immigration desk when they can (e.g., need to) assert citizenship or identity claims. The passport can be considered sufficient because it proves citizenship and identity claims and it is issued by a trusted authority. Thus, in this immigration desk analogy, the citizen is the prover 501, the passport issuing authority is the verifier 502, the passport is the proof result 503, and the immigration desk is the relying party 504.

[0106] In this model, the prover 501 may transmit the evidence 505 to the verifier 502 (S511), and the verifier 502 may compare the evidence 505 with its evaluation strategy (S512). The verifier 502 may (e.g., then) return the proof result 503 (S513). If the proof result 503 is successful, the prover 501 may (e.g., then) present the proof result 503 (and possible additional claims) to the relying party 504 (S514), and the relying party 504 may compare the information with its evaluation strategy (S515).

[0107] In this context, the evidence 505 may be any parameter from a set of parameters provided to the verifier function 502 by an individual (a WTRU, relay, function, etc. in the telecommunications context).

[0108] An evaluation policy in the context of credibility may include any combination of one or more conditions satisfied in the evidence. For example, "all required software updates have been performed" = true and "the hardware cabinet is locked" = true.

[0109] The above process may fail in any of the following situations:

[0110] - Since the evidence 505 does not pass the evidence evaluation strategy, the verifier 502 may not issue a positive proof result 503.

[0111] - The process may fail when the attestation result 503 can be checked by the relying party 504 and, based on the evaluation policy of the attestation result, the result does not pass the policy.

[0112] - The process may fail when the verifier 502 may be unreachable or unavailable.

[0113] Note that the attestation result 503 (eg, a passport) may be designed in such a way that a relying party 504 (eg, an airport immigration desk) may not need to be online to check the attestation result against its evaluation policy.

[0114] Background Check Model

[0115] like Figure 6 As shown, the background check model is so named because it is similar to the way employers and volunteer organizations perform background checks. When a prospective employee makes a claim about education or previous experience, the employer will contact the appropriate agency or previous employer to verify the claim. Volunteer organizations often perform police background checks on prospective employees to determine the trustworthiness of the prospective employee. Therefore, in this analogy, the prospective employee is the certifier 601, the employer is the relying party 602, and the organization issuing the report is the verifier 603.

[0116] In this model, the prover 601 may transmit the evidence 604 to the relying party 602 (S611), and the relying party 602 may pass it to the verifier 603 (S612). The verifier 603 (e.g., then) may compare the evidence 604 with its evaluation strategy (S613), and may return the proof result 605 to the relying party 602 (S614). The relying party 602 may compare the proof result 605 with its evaluation strategy (S615).

[0117] The resource access protocol between the prover 601 and the relying party 602 may include evidence 604 instead of the proof result 605, but the evidence 604 is not processed by the relying party 602. Since the evidence 604 may (e.g., only) be forwarded to the trusted verifier, any serialization format may be used for the evidence, since the relying party 602 may not use (e.g., does not need) a parser for it, the (e.g., only) requirement may be that the evidence 604 may be encapsulated in the format used (e.g., required) by the resource access protocol between the prover 601 and the relying party 602.

[0118] Similar to the passport model, the attestation result can still be used by relying parties.

[0119] During the selection of a relay WTRU (WTRU-to-network relay or WTRU-to-WTRU relay), it may be desirable to decide to select a particular relay WTRU based on its trustworthiness.

[0120] The relay WTRU may be assumed to be a trusted entity. This type of trust may be referred to as "trust by command," or, colloquially, "because I decided to do so." While such an assumption about trust in the ProSe relay may be convenient, it may not address high-value use cases where the nature of the services supported by the ProSe relay may use (e.g., require) trust in the ProSe relay that is based on evidence and / or not based on assumptions and / or commands.

[0121] Any of the following may be provided: technology for a WTRU to verify that the trustworthiness and / or attributes (e.g., supported services) claimed by a relay WTRU are valid and / or allowed; technology for a relay WTRU to check whether the attributes of a remote WTRU are as claimed; technology that enables a remote WTRU to evaluate the trustworthiness of a ProSe relay (e.g., before using services provided via such a relay).

[0122] The techniques proposed herein define possible ways to assert trustworthiness claims: from a ProSe relay to a remote WTRU (e.g., selecting a relay WTRU based on trustworthiness) or from a remote WTRU to a relay WTRU (e.g., (e.g., only) trusted remote WTRUs are allowed to use the relay WTRU).

[0123] Evidence of the relay WTRU's trustworthiness may be initially obtained by a participating relay WTRU (see passport model) and / or analyzed on-site by a remote WTRU (see background check model). Note that the nature of the background check model may use (e.g., require) online verification of the attestation evidence by the verifier. If "direct" online verification is used (e.g., required), connectivity to the verifier may be used (e.g., required) and may not be desirable when the corresponding solution has to work out of coverage. It can be said that when direct connectivity may not be available, it may be possible to use indirect connectivity, for example, using control plane signaling relayed to the network to access the verifier. In addition, the remote WTRU may be able to establish secure end-to-end communication with the verifier (AF) to obtain evidence of trustworthiness.

[0124] Although the proposed embodiments focus on L3 relay, where the relay WTRU establishes a PDU session for the remote WTRU, L2 relay solutions are also possible where the remote WTRU establishes a PDU session and the relay only relays packets.

[0125] Asserting a trustworthiness claim from the ProSe relay to the remote WTRU

[0126] Before the remote WTRU connects to the macro cellular network through the relay WTRU, and therefore before the remote WTRU can contact the verifier to obtain the attestation result from the verifier, the trustworthiness assertion from the relay WTRU may be obtained remotely. The background check model may use (e.g., require) connectivity to the verifier, while the passport model may be configured in such a way that the remote WTRU (relying party) will be able to check the attestation results from the relay WTRU (prover) and compare them with its evaluation policy.

[0127] The attestation result may be obtained during or after the relay discovery process and before the relay selection process is completed and / or the unicast (eg, PC5) link establishment with the relay WTRU is completed.

[0128] Figure 7 A relay discovery procedure with relay WTRU trustworthiness is shown, the method comprising any of the following actions:

[0129] 7.0a: The (eg, relay) WTRU 702 may provide a verifier 705 with an assertion of its trustworthiness.

[0130] 7.0b: The verifier 705 may reply (eg, relay) the WTRU 701 with, for example, the processed attestation result along with a validity time which may be signed by the verifier's private key.

[0131] 7.0c: (eg, relay) The WTRU 702 may save the attestation result received from step 7.0b for further presentation upon request.

[0132] 7.1: Remote and (e.g. relay) WTRU network (e.g. 5GS / 5G system) registration and / or PDU session connectivity establishment procedure with the RAN 703 and / or core network 704.

[0133] 7.2: The (eg, remote) WTRU 701 may request a certification result from a (eg, relay) WTRU during a unicast (eg, PC5) discovery procedure.

[0134] 7.3: The (e.g., relay) WTRU 702 may provide its attestation result (e.g., from step 7.0c) to the (e.g., remote) WTRU 701, which may verify the (e.g., relay) WTRU's authenticity using the verifier's public key.

[0135] 7.4: The (e.g., remote) WTRU 701 may save the attestation result received from step 7.3 (or may remember that this particular (e.g., relay) WTRU 702 may be trusted (e.g., within a validity time) or pre-configured in policy conditions). If the policy allows skipping of steps 7.2 and 7.3, for example, if the (e.g., remote) WTRU 701 later discovers the (e.g., relay) WTRU 702 again, the saved attestation result may be reused for further attestation, and (e.g., then) steps 7.2 and / or 7.3 may be skipped based on the saved attestation result. A validity timer may be associated with the attestation result. Upon expiration of such validity timer, the resulting attestation may be deleted from the (e.g., remote) WTRU 701. The (e.g., remote) WTRU701 may save the attestation result for further decision making (e.g., the (e.g., remote) WTRU 701 compares the trustworthiness of more than one (e.g., relay) WTRU and then selects a path through the most trusted (e.g., relay) WTRU and / or path switching based on the trustworthiness).

[0136] 7.5a: Positive confirmation (success) of the (e.g., relay) WTRU authentication procedure. For example, after sending the ACK message, the (e.g., remote) WTRU may continue with the unicast (e.g., PC5) link establishment procedure with the (e.g., relay) WTRU, and / or may skip the ACK message and continue (e.g., immediately) with the unicast (e.g., PC5) link establishment.

[0137] 7.5b: Negative Acknowledgement (Failure) of the (e.g., Relay) WTRU Authentication Procedure. The (e.g., Remote) WTRU 701 may send a NACK message to the (e.g., Relay) WTRU 702. The (e.g., Remote) WTRU 701 may not continue with the unicast (e.g., PC5) link establishment with the (e.g., Relay) WTRU 702.

[0138] The (e.g., relay) WTRU 702 discussed in this section may be a WTRU-to-network relay. The principles of trustworthiness proof may also be applied to a WTRU-to-WTRU relay, for example, a WTRU establishing an end-to-end unicast (e.g., PC5) link with a peer WTRU via a WTRU-to-WTRU relay may verify the WTRU-to-WTRU relay trustworthiness before establishing an end-to-end unicast (e.g., PC5) link with a peer WTRU via the WTRU-to-WTRU relay.

[0139] Assertion of Credibility Process

[0140] Various procedures may be used to make assertions of credibility, such as unicast (e.g., PC5) discovery or unicast (e.g., PC5) link establishment. In addition, a passport or background check model or a combination thereof may be used. The following subsections provide details.

[0141] The term "relay" or "relay WTRU" may refer to a WTRU-to-network relay and / or a WTRU-to-WTRU relay (unless otherwise stated).

[0142] A remote WTRU may be used to identify a WTRU that is connected to a network via a WTRU-to-network relay. It may also be used in this document to identify a WTRU that is connected to a WTRU-to-WTRU relay.

[0143] Use proven results

[0144] Figure 8 The use of a solicitation procedure to assert the trustworthiness of a (eg, remote) WTRU 801 and a (eg, relay) WTRU 802 is shown.

[0145] During the discovery process (solicitation request / response):

[0146] 8.1 - The (eg, remote) WTRU 801 may send a solicitation request message to the (eg, relay) WTRU 802 which may include its attestation result.

[0147] 8.2- Upon receiving the solicitation request message, the (e.g., relay) WTRU 802 may check the digital signature of the (e.g., remote) WTRU's attestation using the verifier's public key and its validity time, and / or it may compare the attestation result with its evaluation policy.

[0148] 8.3-If the attestation result of the (e.g., remote) WTRU is successfully verified, the (e.g., relay) WTRU 802 may send a solicitation response message, for example, including its attestation result; if the attestation result of the (e.g., remote) WTRU is not successfully verified, the relay 802 may not send a solicitation response.

[0149] 8.4- Upon receiving the Solicitation Response message, the (eg, remote) WTRU 801 may check the signature of the relayed attestation using the verifier's public key and its validity time, and / or it may compare the relayed attestation result with its evaluation policy.

[0150] 8.5-If successful, the (e.g., remote) WTRU 801 may select the relay 802 and / or trigger a unicast (e.g., PC5) link establishment. If unsuccessful, the (e.g., remote) WTRU 801 may not trigger a unicast (e.g., PC5) link establishment with the relay 802 and may internally track the relay and its unsuccessful verification (e.g., on a relay blacklist) for a period of time / a certain period of time.

[0151] Fig. 9 The assertion of the trustworthiness of a (eg, remote) WTRU 901 and a (eg, relay) WTRU 902 using an announcement procedure is shown.

[0152] During the discovery process (notification):

[0153] 9.1 - The (eg, relay) WTRU 902 may send a notification message to the (eg, remote) WTRU 901 including its attestation result.

[0154] 9.2- Upon receiving the notification message, the (e.g. remote) WTRU 901 may check the signature of the (e.g. relay) WTRU's attestation, for example using the verifier's public key and its validity time, and / or it may compare the attestation result with its evaluation policy.

[0155] 9.3- If successful, the (e.g., remote) WTRU 901 may select the (e.g., relay) WTRU 902 and trigger a unicast (e.g., PC5) link establishment. The remote WTRU 901 may send its attestation result, for example, on a Direct Communication Request (DCR) message and / or include it during the authentication or security mode process (e.g., on an Authentication Response or Direct Security Mode Complete message).

[0156] 9.4- Upon receiving the attestation result of the (e.g., remote) WTRU, the (e.g., relay) WTRU 902 may check the signature of the attestation of the (e.g., remote) WTRU using the public key of the verifier and its validity time, and / or may compare it with its evaluation policy. If successful, the (e.g., relay) WTRU 902 may continue the unicast (e.g., PC5) link establishment process. If unsuccessful, the (e.g., relay) WTRU may stop the unicast (e.g., PC5) link establishment process, for example, by not responding to a message from the (e.g., remote) WTRU 901 and / or by sending a rejection message (e.g., an authentication failure message or a direct security mode rejection message, or a direct communication rejection message).

[0157] The (eg, relay) WTRU 902 may internally track the (eg, remote) WTRU 901 and its unsuccessful authentication (eg, put it on the (eg, remote) WTRU's blacklist) over a period of time.

[0158] Fig.10 The assertion of the trustworthiness of the (eg, remote) WTRU 1001 and the (eg, relay) WTRU 1002 during a unicast (eg, PC5) link establishment procedure is shown.

[0159] During unicast (e.g., PC5) link establishment (no trust proof or no discovery during discovery):

[0160] 10.1 - The (eg, remote) WTRU 1001 may send a message to the (eg, relay) WTRU 1002 including its certification result (eg, DCR).

[0161] 10.2- Upon receiving the (e.g., DCR) message, the (e.g., relay) WTRU 1002 may check the signature of the (e.g., remote) WTRU's attestation using the verifier's public key and its validity time, and / or it may compare the attestation result with its evaluation policy.

[0162] 10.3-If successful, the (e.g., relay) WTRU 1002 may send its certification result, for example, during the authentication or security mode process (e.g., in an authentication request or direct security mode command message); if unsuccessful, the (e.g., relay) WTRU 1002 may stop the unicast (e.g., PC5) link establishment process, for example, by not responding to the DCR message and / or by sending a rejection message (e.g., a direct link communication rejection including a cause value (e.g., credibility failure)).

[0163] 10.4-Upon receiving the attestation result of the (e.g., relayed) WTRU, the (e.g., remote) WTRU 1001 may check the digital signature of the (e.g., relayed) WTRU's attestation using the verifier's public key and its validity time, and / or it may compare the attestation result with its evaluation policy.

[0164] 10.5-If successful, the (e.g., remote) WTRU 1001 may continue the link establishment process; if unsuccessful, the (e.g., remote) WTRU 1001 may stop the unicast (e.g., PC5) link establishment process, for example, by not responding to the DCR message and / or by sending a rejection message (e.g., direct link communication rejection).

[0165] 10.6 - (eg, relay) The WTRU 1002 may send a Direct Communication Accept (DCA) message and may establish a unicast (eg, PC5) unicast link.

[0166] According to an embodiment, the (e.g., remote) WTRU 1001 may send its result certification, for example, using a Direct Security Mode (DSM) Complete message (rather than including a DCR message), and then the (e.g., relay) WTRU 1002 may send its result certification, for example, using a DCA message. For example, upon receiving the DCA message, if the (e.g., remote) WTRU 1001 cannot successfully verify the certification result of the (e.g., relay) WTRU, it may tear down the link.

[0167] There may be no need to, for example, periodically redo the attestation results to check whether the authentication and / or security procedures were re-executed.

[0168] Use evidence to prove

[0169] According to some embodiments, the steps described in the previous section ("Using the Attestation Results") may be repeated in the case where both the remote WTRU and the relay WTRU provide their proof of evidence instead of their proof of results. The remote WTRU and the relay WTRU may (e.g., need to) access the network to obtain the proof of results from the verifier. According to some embodiments, if the verifier already has the WTRU's proof, the WTRU ID may be sent to the verifier to obtain the proof:

[0170] 1) During the discovery process (solicitation request / response):

[0171] a) The remote WTRU may send a solicitation request message including its proof of witness. The proof of witness may be integrity and / or replay protected between the WTRU and the verifier.

[0172] b) The relay WTRU may send an attestation request message including a proof to the verifier, and / or may wait to receive an attestation result before sending (or not sending) a solicitation response message including its attestation proof. The attestation proof may be signed by the verifier.

[0173] c) The remote WTRU may send a certification request including the evidence from the relay WTRU to the verifier to obtain certification of the result.

[0174] 2) During the discovery process (notification):

[0175] a) The relay WTRU may send a notification message including its proof.

[0176] b) The remote WTRU may send a certification request including the evidence from the relay WTRU to the verifier to obtain certification of the result.

[0177] 3) During unicast (e.g., PC5) link establishment (no trust proof or no discovery during discovery):

[0178] a) The remote WTRU may send a DCR message which may include its proof.

[0179] b) Upon receiving the DCR message, the relay WTRU may send an attestation request including evidence to the relying party and wait to receive the attestation result.

[0180] c) If the verification of the remote WTRU's proof of result is successful, the relay may send its proof of result to the remote WTRU during the authentication procedure or the security establishment procedure.

[0181] d) The remote WTRU may send the relay WTRU's proof to the relying party to obtain the relay WTRU's attestation result and continue the process described in the previous section ("Using the Attestation Result").

[0182] Use a mix of proven results and evidence

[0183] A combination of proof and result proof may be used. This may be useful, for example, in situations where a WTRU to network relay is used (which may (eg, always) have network access) and a remote WTRU is used (which may not have network access).

[0184] The steps described in the previous section ("Using the Attestation Result") may be repeated in the case where the remote WTRU provides its evidence and the relay WTRU provides its result attestation. The relay WTRU may obtain the result attestation of the remote WTRU from the relying party. The remote WTRU may be configured with an evaluation policy. The verifier function may be co-located with an AF such as a ProSe Key Management Function (PKMF) or a Direct Discovery Name Management Function (DDNMF). When the remote WTRU is within coverage, the verifier function may be reached through the user plane. When within network coverage, the remote WTRU may be configured with a local policy by the verification function (e.g., PKMF). For example, the remote WTRU may use its local policy to verify the relay attestation evidence when out of coverage and request the verifier AF to verify the relay attestation evidence when in coverage. The remote WTRU may request attestation verification from the verifier AF during discovery, during unicast (e.g., PC5) link establishment, or thereafter.

[0185] Network Control Assertion of Relay Trustworthiness

[0186] The remote WTRU may perform an evaluation of the relay trustworthiness of the relay WTRU during network controlled authorization.

[0187] Prerequisite: A remote WTRU may discover and / or may select a relay WTRU that broadcasts an indication proving capabilities or a relay service code (RSC) associated with such an indication.

[0188] The remote WTRU may perform any of the following actions:

[0189] - The remote WTRU may send a connection request including a network identity (eg, Subscription Hidden Identifier (SUCI)) and / or an indication of the result of the request authentication.

[0190] - The remote WTRU may perform a master authentication procedure, for example via a relay WTRU, and / or derive network access keys and / or relay access key material, for example, during this procedure.

[0191] - The remote WTRU may receive a message, for example during the security mode command procedure, including a relay attestation result protected using a network access key (eg, for integrity with a MAC).

[0192] - The remote WTRU may verify the attestation result protection, for example using a network access key, and / or pass the result to upper layers for further evaluation.

[0193] - Upon accepting the attestation result from the upper layer (eg, application layer) (eg, upon accepting the attestation result), the remote WTRU may continue with the connection establishment, and / or may abort the connection establishment process.

[0194] The relay WTRU may perform any of the following actions:

[0195] - The relay WTRU may receive a connection request from a remote WTRU including an indication of a network identity (eg, SUCI) and / or a request authentication result.

[0196] -The relay WTRU may send a request message including the evidence claim to the network (e.g., AMF).

[0197] - The relay WTRU may receive a response message from the network that includes a protected relay certificate (e.g., at least integrity, protected using a network access key or authenticator private key as described below, with an included MAC) and / or relay access key material.

[0198] - The relay WTRU may send a request message including a protected relay certification result to the remote WTRU, for example, during the security mode command procedure.

[0199] - Upon successful completion of the security mode procedure (eg, upon successful completion of the security mode procedure), the relay WTRU may continue with the connection establishment, for example, using the relay access key material.

[0200] The network (e.g., AMF) may perform any of the following actions:

[0201] -The network (e.g., AMF) may receive a request message for authorization of the remote WTRU from the relay WTRU, the message including the evidence assertion from the relay.

[0202] - The network (e.g., AMF) may initiate a primary authentication procedure for a remote WTRU, for example via a relay WTRU, and / or may derive a network access key during this procedure.

[0203] - In the event that the remote WTRU authentication is successful (e.g., upon authentication success), the AMF may send a request message to the verifier (e.g., application function) including the relay identity (e.g., General Public Subscription Identifier (GPSI)), the evidence claim from the relay.

[0204] -The network (e.g., AMF) may receive a response message including the attestation result and / or validity time of the relay WTRU which may be protected with the verifier's digital signature.

[0205] -The network (e.g., AMF) may send a response message to the relay WTRU including an attestation result, for example, integrity protected using a network access key or an authenticator (e.g., AF) private key, where the key may be known to the remote WTRU and the network or authenticator, but unknown to the relay WTRU (e.g., a key (KAUSF) stored in AUSF (Authentication Server Function (AUSF)), a key (KAMF) stored in AMF, an authenticator private key of a public key pair), and the message may be protected, for example, using the relay WTRU access key material.

[0206] Fig.11 An example of a method for relaying connection establishment using network-assisted remote attestation is shown, the method comprising any of the following actions:

[0207] 11.0a / 11.0b-For example, the (e.g., remote) WTRU 1101 and the (e.g., relay) WTRU 1102 may be registered and / or configured with an RSC, for example, associated with parameters required for remote attestation. The (e.g., remote) WTRU 1101 and / or the (e.g., relay) WTRU 1102 may be equipped with an evaluation policy (e.g., at the application layer).

[0208] 11.1 - A (eg, remote) WTRU 1101 may discover a (eg, relay) WTRU 1102 serving a RSC.

[0209] 11.2-Depending on the remote attestation requirement parameters of the RSC, the (eg, remote) WTRU 1101 may send a (eg, DCR) message including any one of a SUCI, an RSC, and an attestation result request (ARR) indication.

[0210] 11.3 - (eg, Relay) The WTRU 1102 may send a Relay Key Request message including the remote and relay identities, RSC and ARR.

[0211] 11.4 - The (eg, remote) WTRU 1101 may perform primary authentication, for example, via the (eg, relay) WTRU's network node 1103 (eg, AMF).

[0212] 11.5a / 11.5b-After a successful primary authentication, the network node 1103 (e.g., AMF) of the (e.g., relaying) WTRU may initiate a remote attestation procedure of the (e.g., relaying) WTRU 1102 and the (e.g., remote) WTRU 1101 to the authenticator (e.g., AF) 1104 via a proxy authenticator 1105 (e.g., Network Slice Specific Authentication and Authorization Function (NSSAAF)). The network node 1103 (e.g., AMF) may send the identity of the WTRU subject to remote attestation, the identifier of the service / resource for which remote attestation may be requested before access is granted (e.g., Single Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), RSC). The remote attestation procedure may be performed between the WTRU and the authenticator 1104 over NAS transport, with the AMF / proxy acting as an intermediary. The network node 1103 (e.g., AMF) may store the attestation result (AR) of the relay WTRU 1102 / remote WTRU 1101 and use it in a subsequent relay connection request with an ARR (e.g., during device-to-device (D2D) communication, as a relay as described above, e.g., trust-based path switching). The AR may be securely bound to a valid time, location, public land mobile network (PLMN), and / or RSC. The transmitted AR may be protected (e.g., using the AMF's authenticator signature, MAC) by the authenticator 1104 and / or the network node 1103 (e.g., AMF).

[0213] 11.6 - The (eg, relay) WTRU 1102 may receive the AR of the (eg, relay) WTRU 1102 and the (eg, remote) WTRU 1101 from the network node 1103 (eg, AMF).

[0214] 11.7 - The (eg, relay) WTRU 1102 may verify that the AR of the (eg, remote) WTRU may be acceptable (eg, against an evaluation policy).

[0215] 11.8 - The (eg, relay) WTRU 1102 may send the (eg, relay) WTRU's AR to the (eg, remote) WTRU 1101, for example, in a protected DSM command message.

[0216] 11.9 - The (eg, remote) WTRU 1101 may verify that the AR of the (eg, relay) WTRU may be acceptable (eg, against an evaluation policy).

[0217] 11.10 - The (eg, remote) WTRU 1101 may send a DSM Complete message to complete the unicast (eg, PC5) link setup.

[0218] 11.11 - The (eg, remote) WTRU 1101 and the (eg, relay) WTRU proceed with the remainder of the relay connection procedure.

[0219] According to some embodiments, if (e.g., when) an evidence claim is provided to the PKMF, the remote WTRU may obtain an attestation result from the PKMF (e.g., having or demonstrating verifier capabilities). In the case of requesting a key to access a relay service, the remote WTRU may receive a protected attestation result from the PKMF (e.g., signed by the remote WTRU's PKMF). According to an embodiment, for example, the remote WTRU may receive a relay access key on the condition that the remote WTRU attestation result meets certain credibility criteria (e.g., established for the relay service RSC). When requesting a relay access key based on an RSC configuration, the remote WTRU may determine the requirements for generating an evidence claim, which RSC configuration indicates that the PKMF's attestation can be used (e.g., required) to obtain access to the relay service. The relay WTRU may perform similar steps on its PKMF to be authorized to provide relay services.

[0220] Fig.12 An exemplary method of relay connection establishment using PKMF-assisted remote attestation is shown, the method comprising any of the following actions:

[0221] 12.1-The (e.g., remote) WTRU 1201 may perform a key request procedure using its PKMF 1204. The key request may include a request for an attestation result. For example, upon successful completion of the remote attestation procedure, the (e.g., remote) WTRU 1201 may obtain a new ProSe Remote User Key (PRUK) / PRUK ID.

[0222] 12.2 - The (eg, remote) WTRU 1201 may discover the (eg, relay) WTRU 1202 that is serving the RSC.

[0223] 12.3 - The (eg, remote) WTRU 1201 may send a (eg, DCR) message including any one of the PRUK ID, RSC, and ARR indications.

[0224] 12.4 - The (e.g., relay) WTRU 1202 may send a (e.g., Key Request) message including any one of the PRUK ID, RSC, and ARR to its PKMF 1203 (12.4a). The PKMF 1203 of the relay WTRU may initiate a remote attestation procedure with the (e.g., relay) WTRU (e.g., if no valid AR is available for relay / RSC) (12.4b). The PKMF 1203 of the (e.g., relay) WTRU may store the AR from the (e.g., relay) WTRU 1202 (12.4c). The PKMF 1203 of the (e.g., relay) WTRU may send a Key Request message to the PKMF 1204 of the (e.g., remote) WTRU, forwarding the parameters from the relay and the AR (e.g., AR relay) for the (e.g., relay) WTRU 1202 (12.4d). The PKMF 1204 of the (e.g., remote) WTRU may initiate a remote attestation procedure with the (e.g., remote) WTRU (e.g., if no valid AR is available for the (e.g., remote) WTRU / RSC) (12.4b). If the AR of the (e.g., remote) WTRU 1201 and / or the (e.g., relay) WTRU 1202 is acceptable (12.4e) (e.g., based on the evaluation policy of RSC / S-NSSAI / DNN), the PKMF 1204 of the (e.g., remote) WTRU may send a key response message to the PKMF 1203 of the (e.g., relay) WTRU, including the (e.g., remote) WTRU 1201 (e.g., AR-Remote) (12.4f). The PKMF 1204 of the (e.g., relay) WTRU may check that the AR of the (e.g., remote) WTRU 1201 (e.g., AR-Remote) is acceptable (12.4e). The PKMF 1204 of the relay WTRU may send a Key Response message to the (eg, relay) WTRU 1202 to authorize the unicast (eg, PC5) link establishment (12.4g).

[0225] 12.5 - The (eg, remote) WTRU 1201 and the (eg, relay) WTRU 1202 may perform a Direct Security Mode Control (DSMC) procedure.

[0226] 12.6 - The (eg, remote) WTRU 1201 and the (eg, relay) WTRU 1202 may continue with the remainder of the relay connection procedure.

[0227] WTRU authenticity assertion based on remote attestation during PDU session establishment using an authentication / attestation server

[0228] According to an embodiment, the WTRU (e.g., acting as a relay) trustworthiness may be established based on the resources accessed during the session management process, e.g., S-NSSAI, DNN. An example may be the trustworthiness of a WTRU (e.g., relay) that wishes to access or provide access to sensitive resources (e.g., sensitive / government agency DNs).

[0229] WTRU remote attestation may be performed by an attestation server (e.g., co-located with an authentication, authorization, and accounting (AAA) server) as part of an enhanced PDU session with secondary authentication and / or attestation. The WTRU may perform remote attestation, which may occur after exchanging authentication messages with an authentication server. The SMF may determine that remote attestation may be used (e.g., required) (e.g., supplemental) based on subscription information associated with the DNN or based on local configuration. The remote attestation protocol with the AAA server may be performed via the SMF over NAS transport (e.g., using the Extensible Authentication Protocol (EAP) or other transport). Remote attestation evidence / results (e.g., as an AAA signature token signed by a verifier) ​​may be provided by the AAA server to the WTRU via the network (e.g., in a NAS message, PDU session establishment acceptance or rejection). Based on the evaluation policy of the AAA server, the AAA may provide a positive or negative result to the network / WTRU, and the network (SMF) may accept or reject the PDU session establishment accordingly. The WTRU may use the attestation result to communicate with other WTRUs or network entities in subsequent processes.

[0230] According to an embodiment, a WTRU (e.g., acting as a relay) may present remote attestation evidence (e.g., in a broadcast message or during link establishment according to the above embodiments) to a remote WTRU that may wish to use the relay service. According to an embodiment, the WTRU may act as a residential gateway, etc. According to an embodiment, the WTRU may present such an attestation result when connected to a server (e.g., an edge network server). The remote WTRU and the relay WTRU may be configured with an RSC associated with an indication of an assertion claim of a credibility requirement. Based on this indication, the relay WTU may be expected to obtain and present credibility information evidence in accordance with the above embodiments. The remote WTRU may determine whether to select / connect the relay WTRU based on the credibility requirement indication and the credibility information evidence provided by the relay. For example, if the credibility information satisfies the evaluation policy of the remote WTRU (e.g., configured with an RSC), the remote WTRU may select / connect the relay WTRU. The evaluation policy may specify a required minimum credibility value (e.g., above 80%, 100%), for example, based on a scoring system.

[0231] The remote attestation server in this embodiment may be a network function (NF) in the mobile network operator (MNO) domain, or may be operated by a third party (e.g., AF, remote attestation server). If operated by a third party, the remote attestation server may communicate with the core network via a network exposure function (NEF). As an NF in the MNO domain, the attestation server may be co-located with an existing function (e.g., AUSF) or provided as a service of an existing function (e.g., AUSF).

[0232] Fig.13 An example method for WTRU remote attestation during PDU session establishment is shown, the method comprising any of the following actions:

[0233] 13.0 - The (eg, relay) WTRU 1301 may register with the network. The (eg, relay) WTRU 1301 may provide its remote attestation capabilities during the registration process.

[0234] 13.1 - The (e.g., relay) WTRU 1301 may send a PDU Session Establishment Request to access a slice / DN, where the DN may require remote attestation. The first network node (e.g., AMF) 1302 may check whether the (e.g., relay) WTRU 1301 can be authorized for DN access based on the (e.g., relay) WTRU 1301 remote attestation capability and / or DN usage (e.g., required) for remote attestation based on subscription data.

[0235] 13.2-The second network node (e.g., SMF) 1303 may determine that the DN may use (e.g., require) remote attestation of the WTRU (e.g., based on the DN subscription data). The second network node (e.g., SMF) 1303 may determine that the DN may use (e.g., require) secondary authentication of the WTRU prior to access.

[0236] 13.3-If necessary, based on the determination of the previous steps, the second network node (e.g., SMF) 1303 may initiate a secondary authentication of the (e.g., relay) WTRU 1301 through the Data Network Authentication Authorization Accounting (DN-AAA) server 1308. For example, the second network node (e.g., SMF) 1303 may keep performing UPF 1305 configuration (N4 Session Modification) until the subsequent remote attestation step is successfully completed.

[0237] 13.4-The second network node (e.g., SMF) 1303 may initiate remote attestation of the (e.g., relay) WTRU 1301 through the verifier function based on the determination of the previous step. The verifier 1307 may be co-located with the DN-AAA server 1308. The second network node (e.g., SMF) 1303 may find the verifier information (e.g., fully qualified domain name (FQDN)) based on any of local configuration, subscription data, a request from the (e.g., relay) WTRU 1301, a message from the DN-AAA 1308 server during the authentication process. The (e.g., relay) WTRU 1301 may perform a remote attestation protocol with the verifier via the SMF / UPF. The (e.g., relay) WTRU 1301 may exchange remote attestation messages with the verifier function (e.g., in a NAS container) over a NAS transport (e.g., transparent to the network). According to an embodiment (e.g., instead of using UPF), the second network node (e.g., SMF) 1303 may exchange remote attestation protocol messages via NEF 1306. After successfully completing the remote attestation process, the verifier function may send the final remote attestation result to the second network node (e.g., SMF) 1303. The second network node (e.g., SMF) 1303 may store the successful remote attestation result associated with the DNN locally and / or in a unified data management (UDM).

[0238] 13.5 - The second network node (eg, SMF) 1303 may send the remote attestation result to the (eg, relay) WTRU 1301 in a PDU Session Setup Accept message.

[0239] 13.6 - (eg, relay) The WTRU 1301 stores the remote attestation result. The (eg, relay) WTRU 1301 may provide the result for use during subsequent procedures (eg, during D2D communication, as a relay as described above, eg, trust-based path switching).

[0240] According to an embodiment, in response to receiving a PDU session establishment accept message that may include authenticator information (e.g., FQDN) and a remote attestation pending indication, a remote attestation process may be performed by a (e.g., relay) WTRU. The (e.g., relay) WTRU may perform remote attestation with the authenticator on a user plane (UP) using the established PDU session. The SMF may restrict the traffic on the PDU session (e.g., configure the UPF accordingly) for the (e.g., relay) WTRU communication with the authenticator (e.g., not allowing any other DN traffic). In the event that the remote attestation is successfully completed (e.g., when the remote attestation is successfully completed), the authenticator may notify the SMF of the successful remote attestation via the NEF / PCF (e.g., using the API Nnef_AFSessionWithQoS). The SMF may update the UPF (e.g., N4 session modification) to allow traffic to the DN, and / or may notify the WTRU of access to the DN during the PDU session modification process.

[0241] WTRU authenticity assertion based on remote attestation during the registration process using an authentication / attestation server

[0242] According to an embodiment, WTRU trustworthiness may be established during a registration management process. An example may be the trustworthiness of a WTRU (e.g., a relay) that wishes to access or provide access to sensitive resources (e.g., a sensitive network slice). An example may be the trustworthiness of a relay that may (e.g., needs to) use such a slice to provide one or more highly sensitive relay services (e.g., for use by a government agency).

[0243] WTRU remote attestation may be performed by an attestation server (e.g., co-located with the AAA server) as part of an enhanced registration process with secondary authentication and / or attestation. The WTRU may perform remote attestation after exchanging authentication messages with the authentication server. The AMF may determine that remote attestation may be used (e.g., required) (e.g., supplemented) based on the WTRU subscription information. The remote attestation process with the AAA server may be performed via the AMF over NAS transport (e.g., using EAP or other transport). Remote attestation evidence / results (e.g., as an AAA signature token signed by the verifier) ​​may be provided by the AAA server to the WTRU via the network (e.g., in a NAS message, WTRU configuration update process). Based on the evaluation policy of the AAA server, the AAA may provide a positive or negative result to the network / WTRU, and the network (AMF) may decide to deregister the WTRU or provide access based on the WTRU's credibility (e.g., authorize non-relay services on behalf of the remote WTRU, deny a request for PDU session access). The WTRU may use the attestation result to communicate with other WTRUs or network entities in subsequent processes.

[0244] According to an embodiment, remote attestation evidence may be used by a WTRU acting as a relay (or residential gateway, etc.) in accordance with the above embodiments (e.g., during relay discovery / selection or link establishment with a relay). The remote WTRU may be configured with an RSC associated with an indication of asserted assertions of trustworthiness requirements and use it as described above. The relay WTRU may be configured with an indication of asserted assertions of trustworthiness requirements. Such an indication may apply to one or more or any PLMN. Based on the indication, the relay WTRU may be expected to obtain and present trustworthiness information evidence in accordance with the above embodiments.

[0245] As in the above embodiments, the remote attestation server may be a NF in the MNO domain or operated by a third party.

[0246] Fig.14 An example method for remote attestation of a WTRU during a registration process is shown, the method comprising any of the following actions:

[0247] 14.1 - (eg, relay) The WTRU 1401 may send a Registration Request message which may include its remote attestation capabilities and / or an S-NSSAI which may be subject to remote attestation.

[0248] 14.2- The network node (e.g., AMF) 1402 may check whether the (e.g., relay) WTRU 1401 may be authorized for S-NSSAI access. If the (e.g., relay) WTRU 1401 has remote attestation capability, the network node (e.g., AMF) 1402 may determine that the S-NSSAI may be subject to remote attestation based on the subscription information of the slice. The network node (e.g., AMF) 1402 may determine whether to perform remote attestation based on any previous attestation results for the S-NSSAI and / or whether remote attestation is in progress.

[0249] 14.3-The network node (e.g., AMF) 1402 may send a Registration Acceptance including a Remote Attestation Pending indication.

[0250] 14.4-The network node (e.g., AMF) 1402 may initiate a slice-specific authentication process (e.g., if the slice is subject to both authentication and remote attestation).

[0251] 14.5-The (e.g., relay) WTRU 1401 may perform a remote attestation process with the verifier 1405 (e.g., using a network control plane transport). The (e.g., relay) WTRU 1401 may exchange remote attestation messages with the verifier function via the network node (e.g., AMF) 1402 / NSSAAF 1403 (e.g., in a NAS container). The NSSAAF 1403 may route the messages to the verifier 1405 (which may be co-located with the AAA-S / AAA server 1404) based on the S-NSSAI. In the event that the remote attestation process completes successfully (e.g., afterwards), the verifier function may send the final remote attestation result to the network node (e.g., AMF) 1402.

[0252] 14.6-Based on the result of the remote attestation process, the network node (e.g., AMF) 1402 may initiate a WTRU configuration update process to send the remote attestation result to the (e.g., relay) WTRU 1401.

[0253] 14.7 - (eg, relay) The WTRU 1401 stores the remote attestation results. The (eg, relay) WTRU 1401 provides the results during subsequent procedures (eg, during D2D communications, acting as a relay as described above).

[0254] Credibility Token

[0255] A trustworthiness token may be an electronic document used to prove the binding of a WTRU's (e.g., remote or relay) identity to verified trustworthiness evidence. The token may include and be cryptographically bound to information about the WTRU's (e.g., remote or relay) identity, the listed evidence submitted to and verified by the verifier, and include a digital signature of the entity that has verified the evidence (e.g., verifier AF). If the signature is valid, and the entity that examines the token (e.g., remote or relay WTRU) trusts the verifier, it may use the evidence to establish secure communications with another entity (e.g., remote or relay WTRU).

[0256] Since the entity analyzing the credibility token can check the credibility token using the public key of the entity that has verified the evidence (e.g., the verifier AF), this check can be achieved without an online check with the entity that has verified the evidence (e.g., the verifier AF).

[0257] Fig.15 An example of a method 1500 implemented by the WTRU 102 for asserting the authenticity of a relay WTRU is shown.

[0258] According to an embodiment, the WTRU 102 may be configured to send a request message to the relay WTRU to obtain information indicating the trustworthiness of the relay WTRU to perform as a relay (1510).

[0259] According to an embodiment, the WTRU 102 may be configured to receive a response to the request message from the relay WTRU, the response including information indicating the trustworthiness of the relay WTRU to perform as a relay (1520).

[0260] According to an embodiment, the WTRU 102 may be configured to perform authentication using a key identifier, which indicates the trustworthiness of the relay WTRU (1530).

[0261] According to an embodiment, the WTRU 102 may be configured to establish a unicast link with a relay WTRU on the condition that information indicative of the authenticity of the relay WTRU is authenticated.

[0262] According to an embodiment, the unicast link is a PC5 link.

[0263] According to an embodiment, the WTRU 102 may be configured to obtain a key identifier from a network entity.

[0264] According to an embodiment, the information indicative of the trustworthiness of the relay WTRU is associated with a validity period.

[0265] According to an embodiment, the WTRU 102 may be configured to send a confirmation message to the relay WTRU on the condition that the information indicating the authenticity of the relay WTRU is authenticated.

[0266] According to an embodiment, the WTRU 102 may be configured to store information indicating the trustworthiness of the relay WTRU.

[0267] Fig.16 Another example of a method 1600 implemented by the WTRU 102 for asserting the authenticity of a relay WTRU is shown.

[0268] According to an embodiment, the WTRU 102 may be configured to send information to the relay WTRU indicating a request for a trustworthiness criterion associated with the relay WTRU (1610).

[0269] According to an embodiment, the WTRU 102 may be configured to receive information from a relay WTRU indicating: (1) a trustworthiness criterion associated with the relay WTRU, and / or (2) a score associated with the trustworthiness criterion (1620).

[0270] According to an embodiment, the WTRU 102 may be configured to authenticate information indicating the authenticity criteria (1630), for example using a public key of a network entity and / or a network access key.

[0271] According to an embodiment, the WTRU 102 may be configured to establish a unicast link (1640) with the relay WTRU, for example, under the condition that information indicating the credibility criteria is authenticated and / or under the condition that a score associated with the credibility criteria is better than a threshold.

[0272] According to an embodiment, the WTRU 102 may be configured to obtain additional information indicating: (1) a trustworthiness criterion associated with the further relay WTRU, and (2) a score associated with the trustworthiness criterion associated with the further relay WTRU.

[0273] According to an embodiment, a unicast link is established with a relay WTRU on the condition that a score associated with the trustworthiness criteria of the relay WTRU is better than a score associated with the trustworthiness criteria of another relay WTRU.

[0274] According to an embodiment, the additional information is obtained from a storage unit of the remote WTRU.

[0275] According to an embodiment, the integrity of information indicative of trustworthiness criteria associated with a relay WTRU is protected by a network entity.

[0276] According to an embodiment, the trustworthiness criteria of the relay WTRU is verified by a network entity.

[0277] According to an embodiment, the unicast link is a PC5 link.

[0278] According to an embodiment, the credibility criterion is associated with a time period during which the information indicative of the credibility criterion is valid.

[0279] According to an embodiment, the trustworthiness criteria of a relay WTRU is associated with the resources that the relay WTRU is accessing.

[0280] According to an embodiment, the WTRU 102 may be configured to store information indicating a trustworthiness criterion of the relay WTRU.

[0281] According to an embodiment, the WTRU 102 may be configured to send information indicating the trustworthiness criteria of the remote WTRU to the relay WTRU, wherein the information is integrity protected by a network entity.

[0282] in conclusion

[0283] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this application, which are intended to illustrate various aspects. Without departing from the spirit and scope of the present invention, many modifications and changes may be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of this application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. According to the foregoing description, in addition to the methods and devices listed here, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents to which these claims are assigned. It should be understood that the present disclosure is not limited to a specific method or system.

[0284] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of devices having infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0285] It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may refer to any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" and its abbreviation "HMD" may represent or include (i) a wireless transmission and / or reception unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities (e.g., tetherable), which is particularly configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities configured with less than all of the structure and functionality of a WTRU; or (iv) the like. References herein Figures 1A-1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various embodiments disclosed above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0286] In addition, the methods provided herein can be implemented in a computer program, software, or firmware, which is contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0287] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source that provides any suitable voltage, such as a battery, etc.

[0288] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being "executed", "computer executed" or "CPU executed".

[0289] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in the ultimate conversion or reduction of electrical signals and maintain the data bits in memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations with specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0290] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside exclusively on a processing system or distributed across multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0291] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0292] There is little distinction between hardware and software implementations of various aspects of the system. The use of hardware or software is typically (but not always, as in some cases the choice between hardware and software may become important) a design choice that represents a cost-efficiency tradeoff. There may be various means to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means may vary with the environment in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a tool that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0293] The foregoing detailed description has been described various embodiments of the device and / or process by using block diagrams, flow charts and / or examples. To the extent that such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation in such block diagrams, flow charts or examples can be implemented individually and / or together by various hardware, software, firmware or any combination thereof in fact. In an embodiment, several parts of the subject matter described herein can be implemented by application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be implemented in whole or in part equivalently in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as a combination thereof in fact, and according to the present disclosure, designing circuits and / or writing codes for software and / or firmware will be completely within the skill of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually perform the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media, such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc., and transmission type media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0294] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein and then use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into data processing systems through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application program, one or more interactive devices such as a touch pad or screen, and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or velocity, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those components typically found in data computing / communication and / or network computing / communication systems.

[0295] The subject matter described here sometimes shows different components included in or connected to different other components.It should be understood that the architecture described in this way is only an example, and in fact many other architectures that realize the same function can be implemented.In a conceptual sense, any arrangement of components that realize the same function is effectively "associated" so that the desired function can be realized.Therefore, any two components that are combined to realize a specific function here can be regarded as "associated" with each other so that the desired function is realized, without considering the architecture or intermediate components.Similarly, any two components so associated can also be regarded as "operably connected" or "operably coupled" to each other to realize the desired function, and any two components that can be so associated can also be regarded as "operably coupled" to each other to realize the desired function.Specific examples of operable coupling include but are not limited to physically compatible and / or physically interactive components and / or wirelessly interactive and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.

[0296] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art may translate from the plural to the singular and / or from the singular to the plural as appropriate, depending on the context and / or application. For clarity, various singular / plural arrangements may be expressly set forth herein.

[0297] Those skilled in the art will understand that, in general, the terms used herein, especially in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "including" should be interpreted as "including but not limited to", etc.). Those skilled in the art will further understand that if a specific number of a claim recitation is intended to be introduced, such intent will be expressly recited in the claim, and if no such recitation is made, such intent does not exist. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the claims appended below and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be interpreted as implying that the introduction of a claim recitation by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to including only one embodiment of such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., the simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations). In addition, in those cases similar to the convention of "at least one of A, B, and C, etc.", in general, such construction is intended to make the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, and C" will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those cases similar to the convention of "at least one of A, B, or C, etc.", in general, such construction is intended to make the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any disjunctive words and / or phrases that actually represent two or more optional terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B."Furthermore, as used herein, the term "any" followed by a listing of multiple items and / or multiple categories of items is intended to include "any one," "any combination," "any plurality," and / or "any combination of a plurality" of the items and / or categories of items, either alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. And the term "plurality" as used herein is intended to be synonymous with "multiple."

[0298] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0299] As will be understood by those skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also include any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily considered to fully describe and be able to divide the same range into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed here can be easily decomposed into a lower third, a middle third, and an upper third, etc. It will also be understood by those skilled in the art that all languages, such as "up to", "at least", "greater than", "less than", etc., include the recorded numbers and refer to the ranges that can be subsequently decomposed into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the range includes each individual member. Therefore, for example, a group with 1-3 cells refers to a group with 1, 2 or 3 cells. Similarly, a group with 1-5 cells refers to a group with 1, 2, 3, 4 or 5 cells, etc.

[0300] Furthermore, the claims should not be read as limited to the order or elements provided unless so stated. Furthermore, the use of the term "means for..." in any claim is intended to refer to 35 U.S.C. §112, 6 or means-plus-function claim format, and any claim without the term “means for…” has no such intention.

Claims

1. A method implemented by a remote wireless transmit / receive unit (WTRU), the method comprising: sending, to the relay WTRU, information indicating a request for a trustworthiness criterion associated with the relay WTRU; receiving information from a relay WTRU, the information indicating: (1) a trustworthiness criterion associated with the relay WTRU, and (2) a score associated with the trustworthiness criterion; authenticating the information indicating the trustworthiness criterion using a public key of the network entity and / or a network access key; as well as A unicast link is established with the relay WTRU, conditional upon the information indicative of the trustworthiness criterion being authenticated, and conditional upon the score associated with the trustworthiness criterion being better than a threshold.

2. The method according to claim 1, further comprising: obtaining additional information indicating: (1) a trustworthiness criterion associated with the additional relay WTRU, and (2) a score associated with the trustworthiness criterion associated with the additional relay WTRU; and Wherein a unicast link is established with the relay WTRU on the condition that a score associated with the trustworthiness criteria of the relay WTRU is better than a score associated with the trustworthiness criteria of another relay WTRU.

3. The method of any one of claims 1-2, wherein the additional information is obtained from a storage unit of a remote WTRU.

4. The method of any one of claims 1-3, wherein the integrity of the information indicating the trustworthiness criteria associated with the relay WTRU is protected by a network entity.

5. The method according to any one of claims 1-4, wherein the trustworthiness criteria of the relay WTRU is verified by a network entity.

6. The method according to any one of claims 1-5, wherein the unicast link is a PC5 link.

7. The method according to any one of claims 1 to 6, wherein the credibility criterion is associated with a time period during which the information indicative of the credibility criterion is valid.

8. The method of any one of claims 1-7, wherein the trustworthiness criteria of the relay WTRU is associated with a resource that the relay WTRU is accessing.

9. The method of any one of claims 1-8, further comprising storing information indicating a trustworthiness criterion of the relay WTRU.

10. The method according to any one of claims 1 to 9, further comprising: Information indicative of a trustworthiness criterion of a remote WTRU is sent to a relay WTRU, wherein the information is integrity protected by a network entity.

11. A wireless transmit / receive unit (WTRU) comprising circuitry, the circuitry comprising any one of a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: sending, to the relay WTRU, information indicating a request for a trustworthiness criterion associated with the relay WTRU; receiving information from a relay WTRU, the information indicating: (1) a trustworthiness criterion associated with the relay WTRU, and (2) a score associated with the trustworthiness criterion; authenticating the information indicative of the trustworthiness criteria using a public key of the network entity and / or a network access key; and A unicast link is established with the relay WTRU, conditional upon the information indicative of the trustworthiness criterion being authenticated, and conditional upon the score associated with the trustworthiness criterion being better than a threshold.

12. The WTRU of claim 11 , configured to: obtaining additional information indicating: (1) a trustworthiness criterion associated with the additional relay WTRU, and (2) a score associated with the trustworthiness criterion associated with the additional relay WTRU; and Wherein a unicast link is established with the relay WTRU on the condition that a score associated with the trustworthiness criteria of the relay WTRU is better than a score associated with the trustworthiness criteria of another relay WTRU.

13. The WTRU of any one of claims 11-12, wherein the additional information is obtained from a storage unit of a remote WTRU.

14. The WTRU of any one of claims 11-13, wherein the integrity of the information indicative of a trustworthiness criterion associated with the relay WTRU is protected by a network entity.

15. The WTRU of any one of claims 11-14, wherein the trustworthiness criteria of the relay WTRU is verified by a network entity.

16. The WTRU of any one of claims 11-15, wherein the unicast link is a PC5 link.

17. The WTRU of any one of claims 11-16, wherein the credibility criterion is associated with a time period for which information indicating the credibility criterion is valid.

18. The WTRU of any one of claims 11-17, wherein the trustworthiness criteria of the relay WTRU is associated with a resource that the relay WTRU is accessing.

19. The WTRU of any one of claims 11-18, configured to store information indicative of a trustworthiness criterion of the relay WTRU.

20. The WTRU according to any one of claims 11-18, configured to send information indicating a trustworthiness criterion of a remote WTRU to a relay WTRU, wherein the information is integrity protected by a network entity.

Images