Method, architecture, apparatus, and system for assertion of wireless transmit / receive unit (WTRU) reliability

Abstract

Procedures, methods, architectures, devices, systems, devices, and computer program products directed to relayed WTRU reliability assertions. In one embodiment, the apparatus may be configured to send a request message to the relayed WTRU to obtain information indicating the reliability of the relayed WTRU for execution as a relay, receive from the relayed WTRU a response to the request message including information indicating the reliability of the relayed WTRU for execution as a relay, and authenticate the information indicating the reliability of the relayed WTRU using a key identifier.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 336,441, filed Apr. 29, 2022, which is hereby incorporated by reference in its entirety.

[0002] (Field of the Invention) The present disclosure generally relates to the fields of communication, software, and coding, and includes, for example, methods, architectures, devices, systems for asserting relay WTRU reliability, methods, devices, and systems for using proximity - based services (ProSe) and other relay applications from WTRUs to a network.

Brief Description of the Drawings

[0003] A more detailed understanding can be obtained from the following detailed description in conjunction with the accompanying drawings, which are given by way of illustration only. The figures of such drawings, like the detailed description, are examples. Therefore, the figures and the detailed description should not be regarded as limiting, and other equally effective examples are possible and likely. Further, similar reference numerals ( "references") in the figures indicate similar elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

[0004] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc. and / or any element thereof performs various operations, processes, algorithms, functions, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element thereof is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0005] Exemplary Communication System The methods, apparatuses, and systems provided herein are well-suited for communication including both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with reference to FIGS. 1A - 1D, in which the various elements of the network may utilize, execute, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0006] FIG. 1A is a system diagram illustrating an exemplary communication system 100 in which one or more of the 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 a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of 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-FDM), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filter type OFDM, filter bank multicarrier (FBMC), etc.

[0007] As shown in FIG. 1A, 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 will 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 can 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, which may all be referred to as "stations" and / or "STAs", can be configured to transmit and / or receive wireless signals and can be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), home electronics devices, devices operating in commercial and / or industrial wireless networks, etc. (or be any of them). Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0009] Base station 114a can be part of RAN 104 / 113 and can 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. Base station 114a and / or base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell can provide wireless service coverage to a specific geographic area that can be relatively fixed or can change over time. The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a can employ multiple-input multiple-output (MIMO) technology and can utilize multiple transceivers for each or any sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0011] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a of the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish an air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

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

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

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

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), 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 communication (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0016] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as, for example, an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can implement a wireless 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0017] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connections, video distribution, etc., and / or can implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 that may utilize NR radio technology, CN 106 / 115 can communicate with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0018] CN106 / 115 may also function as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other network 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices may use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs, and may use the same RAT as the RAN104 / 114 or a different RAT.

[0019] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multi-mode function (e.g., the WTRU102a, 102b, 102c, 102d may include a plurality of transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use IEEE802 wireless technology.

[0020] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0021] The processor 118 may be a general-purpose processor, a dedicated 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 function 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 depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated, for example, in an electronic package or chip.

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

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

[0024] The transceiver 120 may be configured to modulate signals transmitted by the transmitting / receiving element 122 and demodulate signals received by the transmitting / receiving element 122. As noted above, the WTRU 102 may have a multimode capability. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

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

[0027] Processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from the GPS chipset 136, WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via air interface 116 and / or may determine its own location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

[0028] Processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connections. For example, elements / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Elements / peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0029] The WTRU 102 may include a full-duplex radio communicator for which transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio communicator may include an interference management unit for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke coil) or via signal processing through a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio communicator for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0030] Figure 1C is a system diagram illustrating RAN 104 and CN 106, according to one embodiment. As described above, RAN 104 may communicate with WTRU 102a, 102b, and 102c via air interface 116, using E-UTRA radio technology. RAN 104 may also communicate with CN 106.

[0031] RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, eNode-B 160a may transmit and receive radio signals with WTRU 102a, for example, using multiple antennas.

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

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

[0034] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via the S1 interface and may function as a control node. For example, the MME 162 may serve roles such as authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway while the WTRUs 102a, 102b, 102c first participate, etc. The MME 162 may provide control plane functions for switching between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0035] SGW 164 can be connected to each of the eNodeBs 160a, 160b, and 160c within RAN 104 via the S1 interface. SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW 164 can perform other functions such as fixing the user plane during handover between eNodeBs, initiating paging when DL data is available to the WTRUs 102a, 102b, and 102c, and managing and storing the contexts of the WTRUs 102a, 102b, and 102c.

[0036] SGW 164 can be connected to PGW 166, and PGW 166 can provide the WTRUs 102a, 102b, and 102c with access to a packet switched network such as the Internet 110 in order to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0037] CN 106 can facilitate communication with other networks. For example, CN 106 can provide the WTRUs 102a, 102b, and 102c with access to a circuit switched network such as PSTN 108 in order to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 can include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide the WTRUs 102a, 102b, and 102c with access to other networks 112 that can include other wired and / or wireless networks owned and / or operated by other service providers.

[0038] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use a (e.g., temporary or permanent) wired communication interface with the communication network.

[0039] In a representative embodiment, the other network 112 can be a WLAN.

[0040] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or interface to a distribution system (DS) or another type of wired / wireless network that conveys traffic within and / or outside the BSS. Traffic destined for an STA that originates outside the BSS can arrive through the AP and be sent to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP so as to be sent to their respective destinations. Traffic between STAs within the BSS can be sent, for example, through the AP, where the source STA can send the traffic to the AP and the AP can send the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS communication mode may also be referred to herein as the "ad hoc" communication mode.

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

[0042] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, for example, by combining 20 MHz channels adjacent or non - adjacent to the primary 20 MHz channel to form a 40 MHz wide channel.

[0043] A very high throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel can be formed by combining multiple adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non - adjacent 80 MHz channels, which can be referred to as an 80 + 80 configuration. In the case of the 80 + 80 configuration, after channel encoding, the data can pass through a segment parser that can divide the data into two streams. The inverse fast fourier transform (IFFT) process and time - domain processing can be performed separately for each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the aforementioned operations for the 80 + 80 configuration can be reversed, and the combined data can be transmitted to the media access control (MAC) layer, entity, etc.

[0044] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine-type communication (MTC) such as MTC devices in a macro coverage area. The MTC device may have limited capabilities, including support for certain capabilities, e.g., support for a particular and / or limited bandwidth (e.g., supporting only these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0045] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by an STA from among all STAs operating in a BSS that support a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode even when an AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) setting can depend on the state of the primary channel. When the primary channel is busy, for example, an STA (that only supports the 1 MHz operation mode) is transmitting to an AP, the entire available frequency band may be considered busy even though most of the frequency band may remain available and idle.

[0046] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on national regulations.

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

[0048] RAN113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Thus, gNB 180a, for example, may transmit and / or receive radio signals to and from WTRU 102a using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of such component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0049] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or absolute times of varying and persistent lengths).

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

[0051] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, coordination between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0053] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can authenticate users of WTRUs 102a, 102b, and 102c, support network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), select specific SMFs 183a and 183b, manage registration areas, terminate NAS signaling, perform mobility management, etc. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on, for example, the type of services being used by WTRUs 102a, 102b, and 102c. For example, different network slices can 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, etc. AMF 162 can provide control plane functions for exchanges between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or Wi-Fi.

[0054] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, enforcing policies and controlling QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0055] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 for WTRU102a, 102b, and 102c, for example, to facilitate communication between WTRU102a, 102b, and 102c and IP-compatible devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0056] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Additionally, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112 that may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b through UPF184a, 184b via an N3 interface with UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0057] In view of FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more or all of the functions described herein with respect to any of WTRU102a-d, base stations 114a-b, eNode Bs 160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any other element / device described herein may be performed by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0058] An emulation device can be designed to implement one or more tests of other devices in an experimental environment and / or an operator network environment. For example, one or more emulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device for the purpose of testing and / or can perform the test using over-the-air wireless communication.

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

[0060] According to one embodiment, a method for asserting the relay WTRU reliability executed by a remote WTRU is described, the method including any of the following actions. - The remote WTRU can obtain a relay reliability evidence token (information) from a relay during a discovery procedure or during link establishment with the relay, or from an application function (AF) before or after link establishment with the relay (AF connection information is pre-set or provided during connection via the relay). - The remote WTRU can verify the relay reliability evidence token even when outside of macro coverage. - The remote WTRU can use the relay WTRU reliability evidence token to make a determination regarding the reliability of the relay WTRU. If the remote WTRU is considered trustworthy, the connection with the relay WTRU is advanced, or if the relay WTRU is considered untrustworthy, the relay WTRU connection is rejected.

[0061] According to one embodiment, a method for asserting the reliability of a remote WTRU executed by a relay WTRU is described, and this method includes any of the following actions. - The relay WTRU can obtain the remote WTRU reliability evidence token (information) from the remote WTRU during the discovery procedure or during link establishment with the remote WTRU, or from the AF before or after link establishment with the remote WTRU (e.g., AF connection information is pre-set). - The relay WTRU can verify the remote WTRU reliability evidence token even outside of macro coverage, either through its own available macro coverage or autonomously. - The relay WTRU can use the remote WTRU reliability evidence token to make a determination regarding the reliability of the remote WTRU. If the remote WTRU is considered trustworthy, the connection with the remote WTRU is advanced, or if the remote WTRU is considered untrustworthy, the remote WTRU connection is rejected.

[0062] According to one embodiment, a method for network - controlled assertion of relay reliability executed by a remote WTRU is described, and this method includes any of the following actions. The remote WTRU performs an evaluation of the relay reliability of the relay WTRU during network - controlled authentication. The remote WTRU requests a proof result in a connection request with the relay WTRU. The remote WTRU may receive a proof result protected by a network access key (e.g., in Direct Security Mode Complete (DSMC)) based on the remote WTRU primary authentication. The remote WTRU may verify the security of the result and pass the result to a higher layer before proceeding with link establishment.

[0063] According to one embodiment, a method for WTRU remote proof during an extended PDU session establishment procedure executed by a WTRU is described, and this method includes any of the following actions. The WTRU may execute a remote proof procedure as part of an extended PDU session establishment using remote proof. The remote proof may be executed via the SMF on the NAS. The relay WTRU receives proof - of - evidence information in PDU establishment, accepts the message, and may present it to other WTRU / network entities (e.g., a remote WTRU desiring to connect to a WTRU operating as a relay).

[0064] According to one embodiment, a method for WTRU remote proof during an extended registration procedure executed by a WTRU is described, and this method includes any of the following actions. The WTRU may execute a remote proof procedure as part of a registration procedure extended with remote proof. The remote proof may be executed via the AMF on the NAS. The WTRU may receive proof - of - evidence during a WTRU / UE configuration update (UCU) procedure and present it to other WTRU / network entities (e.g., a remote WTRU desiring to connect when operating as a relay).

[0065] Proximity - based Service (ProSe) Proximity Service (ProSe) is a service that can be provided by a 3GPP system based on WTRUs being in proximity to each other. To provide proximity services, a WTRU can perform a ProSe discovery procedure to discover other nearby WTRUs.

[0066] There can be two ProSe discovery modes, namely Model A and Model B.

[0067] In Model A, as illustrated in Figure 2, a WTRU (e.g., the announcing WTRU) can broadcast an announcement message (211) using a ProSe code (which can be associated with the ID of the announcing WTRU or with the service provided by the announcing WTRU). Other WTRUs (monitoring WTRUs) that receive the announcement message can know that the announcing WTRU may be in proximity.

[0068] In Model B, as illustrated in Figure 3, a WTRU (e.g., the discovery - side WTRU) can broadcast a request message (311) along with a ProSe query code (which can be associated with the ID of the WTRU to be discovered or with the ProSe service to be discovered). Other WTRUs (discovered WTRUs) that receive the request message can respond to the request (312a, 312b) using, for example, a ProSe response code (which can be associated with the ID of the discovered WTRU or with the ProSe service provided by the discovered WTRU). The discovery - side WTRU knows that the discovered WTRU may be in proximity.

[0069] Using both discovery modes, group discovery (for discovering WTRUs belonging to a specific group) and WTRU - network relay discovery (for discovering a WTRU - network relay that provides a connection to the 5G network) can be performed.

[0070] For group discovery, the discovery message (announcement, invitation / request / response) may further include a group ID. For WTRU-network relay discovery, the discovery message (announcement, invitation / request / response) may indicate the WTRU-network relay service using a relay service code (instead of the ProSe code).

[0071] WTRU-network relay As illustrated in FIG. 4, the ProSe WTRU-network relay entity 402 may provide a function to support a connection to the network for the remote WTRU 401.

[0072] If the remote WTRU 401 is outside the NR coverage and cannot communicate directly with the core network 106 / 115 (or is within the NR coverage but prefers to use unicast (e.g., PC5) for communication), the remote WTRU 401 may discover and select a WTRU-network relay / (e.g., relay) WTRU 402. The remote WTRU 401 may establish a unicast (e.g., PC5) session with the WTRU-network relay 402, and the WTRU-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 the IP address / prefix assignment, the traffic between the remote WTRU 401 and the network may be relayed by the WTRU-network relay 402.

[0073] Trust assertion The following subsections provide background information on two modes (models) of reliability verification.

[0074] Passport model The passport model can be so named because, as illustrated in FIG. 5, it is similar to the way a country issues passports to its citizens. The nature of the evidence that an individual can provide (e.g., is required to provide) to a local government is specific to the country involved. The citizen retains control of the generated passport document and presents it to other entities, such as an airport immigration desk, when it can (e.g., is required to) exercise its citizenship or identity claim. The passport can be considered sufficient because it guarantees citizenship and identity claims and is issued by a trusted institution. 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.

[0075] In this model, the prover 501 can transmit evidence 505 to the verifier 502 (S511), and the verifier can compare the evidence 505 with its evaluation policy (S512). The verifier 502 can then return a proof result 503 (S513). If the proof result 503 is a favorable result, the prover 501 can then present the proof result 503 (and possibly additional claims) to the relying party 504 (S514), and the relying party can compare this information with its evaluation policy (S515).

[0076] The evidence 505 in this context can be any parameter of the set of parameters that an entity (such as a WTRU, relay, function, etc. in the context of telecommunications) provides to the verifier functional entity 502.

[0077] The evaluation policy in the context of trustworthiness can include any combination of one or more conditions to be satisfied in the evidence. For example, "All required SW updates have been executed" = true, and "The hardware storage container is locked" = true.

[0078] The above process can fail in any of the following cases. - If the verification machine 502 does not issue a positive proof result 503 because the evidence 505 does not meet the evidence evaluation policy. - The proof result 503 can be inspected by the dependent party 504, and if the result does not meet the policy based on the evaluation policy of the proof result, the process may fail. - If the verification machine 502 is unreachable or unavailable, the process may fail.

[0079] Note that the proof result 503 (e.g., a passport) can be designed so that the dependent party 504 (e.g., an airport immigration desk) does not need to be online to inspect the proof result against its evaluation policy.

[0080] Background Check Model The background check model is so named because, as illustrated in FIG. 6, it is similar to the way employers and volunteer organizations conduct background checks. When a job applicant provides claims about their education or past experience, the employer contacts the respective institutions or previous employers to verify the claims. Volunteer organizations often conduct a police background check on job applicants to determine their reliability. Thus, in this analogy, the job applicant is the proof machine 601, the employer is the dependent party 602, and the organization that issues the report is the verification machine 603.

[0081] In this model, the proof machine 601 can transmit the evidence 604 to the dependent party 602 (S611), and the dependent party can pass the evidence to the verification machine 603 (S612). The verification machine 603 can compare the evidence 604 with its evaluation policy (e.g., then) (S613) and return the proof result 605 to the dependent party 602 (S614). The dependent party 602 can compare the proof result 605 with its evaluation policy (S615).

[0082] The resource access protocol between the prover 601 and the relying party 602 may include the evidence 604 instead of the proof result 605, and the evidence 604 is not processed by the relying party 602. Since the evidence 604 can be transferred (e.g., simply) to a trusted verifier, the relying party 602 may not use (e.g., need) a parser therefor, and thus any serialization format can be used for the evidence. (For example, the only) requirement may be that the evidence 604 can be encapsulated in a format used (e.g., required) by the resource access protocol between the prover 601 and the relying party 602.

[0083] Similar to the passport model, the proof result can still be consumed by the relying party.

[0084] During the selection of a relay WTRU (either a WTRU-network relay or a WTRU-WTRU relay), it may be desirable to base the decision to select a particular relay WTRU on its reliability.

[0085] The relay WTRU may be assumed to be a trusted entity. This type of trust may be referred to as "trust by order" or colloquially as "because I said so". Such an assumption about trust in a ProSe relay may be convenient, but it may not address valuable use cases where the nature of the services supported by the ProSe relay uses trust placed in the ProSe relay that is not evidence-based and / or not based on assumptions and / or orders.

[0086] Any of the following may be provided: techniques for the WTRU to verify that the claimed reliability and / or properties (e.g., supported services) of the relay WTRU are valid and / or permitted; techniques for the relay WTRU to check whether the properties of the remote WTRU are as claimed; techniques for enabling the remote WTRU to evaluate the reliability of the ProSe relay (e.g., before using services provided via such a relay).

[0087] The techniques proposed herein define possible ways to assert claims of reliability from the ProSe relay to the remote WTRU (e.g., to select a relay WTRU based on reliability) or from the remote WTRU to the relay WTRU (e.g., to enable only trusted remote WTRUs (e.g.) to use the relay WTRU).

[0088] Evidence of the reliability of the relay WTRU may first be obtained by the participating relay WTRU (refer to the passport model) and / or analyzed in-situ by the remote WTRU (refer to the background check model). Note that the nature of the background check model may use (e.g., may require) online verification of the proof evidence by the verifier. If "direct" online verification is used (e.g., required), it may not be a good solution when it may be necessary to use a connection to the verifier and the corresponding solution has to operate outside the coverage. It can be said that an indirect connection, e.g., access to the verifier using control plane signaling relayed over the network, can be used when a direct connection may not be available. In addition, the remote WTRU may be able to establish secure end-to-end communication with the verifier (AF) to obtain evidence of reliability.

[0089] The proposed embodiments focus on an L3 relay that establishes a PDU session for a remote WTRU, but a solution with an L2 relay where the remote WTRU establishes the PDU session and the relay only relays packets is also possible.

[0090] Assertion of reliability from a ProSe relay to a remote WTRU An assertion of reliability from the relay WTRU can be obtained by the remote WTRU before the remote WTRU is connected to the macrocellular network via the relay WTRU, and thus before the remote WTRU can contact the verifier and obtain a proof result from the verifier. The background check model can use (e.g., require) connectivity to the verifier, while the passport model can be configured such that the remote WTRU (dependent party) can inspect proof results coming from the relay WTRU (prover) and compare them to its evaluation policy.

[0091] The proof results can be obtained during or after the relay discovery procedure and before completion of the relay selection procedure and / or establishment of a unicast (e.g., PC5) link with the relay WTRU.

[0092] Figure 7 illustrates a relay discovery procedure using relay WTRU reliability, and this method includes any of the following actions. 7.0a: A (e.g., relay) WTRU 702 can supply its assertion of reliability to a verifier 705. 7.0b: The verifier 705 can reply to the WTRU 701 with a processed proof result, along with an expiration time that can be signed, for example, by the verifier's private key. 7.0c: A (e.g., relay) WTRU 702 can hold the proof result received from step 7.0b for further presentation upon request. 7.1: Network (e.g., 5GS / 5G system) registration and / or PDU session connection establishment procedures with the RAN 703 and / or core network 704 for the remote and (e.g., relay) WTRU. 7.2: A (e.g., remote) WTRU 701 may request a proof result from a (e.g., relay) WTRU during a unicast (e.g., PC5) discovery procedure. 7.3: A (e.g., relay) WTRU 702 may provide its own proof result (e.g., from step 7.0c) to a (e.g., remote) WTRU 701 that may verify the (e.g., relay) WTRU reliability using the public key of the verification mechanism. 7.4: A (e.g., remote) WTRU 701 may hold the proof result received from step 7.3 (or may store that this particular (e.g., relay) WTRU 702 may be trusted within a validity period, e.g., or may be pre-set in a policy condition). The stored proof result may be re-used for further proof if the policy allows skipping steps 7.2 and 7.3, e.g., if the (e.g., remote) WTRU 701 discovers this (e.g., relay) WTRU 702 again later, and (e.g., then) steps 7.2 and / or 7.3 may be skipped based on the stored proof result. A validity timer may be associated with the proof result. Upon expiration of such a validity timer, the resulting proof may be deleted from the (e.g., remote) WTRU 701. The (e.g., remote) WTRU 701 may hold the proof result for further decision-making (e.g., the (e.g., remote) WTRU 701 may compare the reliability of two or more (e.g., relay) WTRUs and subsequently select the most reliable (e.g., relay) WTRU and / or a path through a reliability-based path switching mechanism). 7.5a: Positive acknowledgement response (success) of a (e.g., relay) WTRU proof procedure. A (e.g., remote) WTRU may proceed with a unicast (e.g., PC5) link establishment procedure with the (e.g., relay) WTRU after sending an ACK message, e.g., and / or may skip the ACK message and proceed with unicast (e.g., PC5) link establishment (e.g., immediately). 7.5b: Negative Acknowledgment Response (Failure) of (e.g., Relay) WTRU Authentication Procedure. (E.g., Remote) WTRU 701 may send a NACK message to (e.g., Relay) WTRU 702. (E.g., Remote) WTRU 701 may not be able to proceed with unicast (e.g., PC5) link establishment with this (e.g., Relay) WTRU 702.

[0093] The (e.g., Relay) WTRU 702 described in this section may be a WTRU - network relay. The principle of reliability authentication may also be applied to the WTRU - to - WTRU relay. For example, a WTRU that establishes an end - to - end unicast (e.g., PC5) link with a peer WTRU via a WTRU - to - WTRU relay may verify the reliability of the WTRU - to - WTRU relay before establishing an end - to - end unicast (e.g., PC5) link with the peer WTRU via this WTRU - to - WTRU relay.

[0094] Assertion of Reliability Procedure The reliability assertion may be made using various procedures, such as unicast (e.g., PC5) discovery or unicast (e.g., PC5) link establishment. In addition, models of passport or background checks or combinations thereof may be used. Details are provided in the following sub - sections.

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

[0096] A remote WTRU may be used to identify a WTRU that connects to the network via a WTRU - network relay. In this document, a remote WTRU may also be used to identify a WTRU that connects to a WTRU - to - WTRU relay.

[0097] Using the Authentication Result Figure 8 illustrates the reliability assertion of (e.g., Remote) WTRU 801 and (e.g., Relay) WTRU 802 using a solicitation procedure.

[0098] During the discovery procedure (request / response): 8.1 - A (e.g., remote) WTRU 801 may send a request message, which may include its authentication result, to a (e.g., relay) WTRU 802. 8.2 - When receiving the request message, a (e.g., relay) WTRU 802 may check the digital signature of the authentication of the (e.g., remote) WTRU using the public key of the verifier and its validity period, and / or may compare the authentication result with its evaluation policy. 8.3 - If the authentication result of the (e.g., remote) WTRU is successfully verified, a (e.g., relay) WTRU 802 may send a request response message, which may include, for example, its authentication result. If the authentication result of the (e.g., remote) WTRU cannot be successfully verified, the relay 802 cannot send a request response. 8.4 - When receiving the request response message, a (e.g., remote) WTRU 801 may check the signature of the authentication of the relay using the public key of the verifier and its validity period, and / or may compare the authentication result of the relay with its evaluation policy. 8.5 - If successful, a (e.g., remote) WTRU 801 may select this relay 802 and / or may initiate unicast (e.g., PC5) link establishment. If not successful, a (e.g., remote) WTRU 801 cannot initiate unicast (e.g., PC5) link establishment with this relay 802 and may internally track this relay and the verification that ended in failure for a period of time / a certain time (e.g., on the blacklist of the relay).

[0099] Figure 9 illustrates the reliability assertions of a (e.g., remote) WTRU 901 and a (e.g., relay) WTRU 902 using the notification procedure.

[0100] During the discovery procedure (notification): 9.1 - A (e.g., relay) WTRU 902 may send a notification message, which may include its authentication result, to a (e.g., remote) WTRU 901. 9.2 - When receiving an indication message, a (e.g., remote) WTRU 901 may check the signature of the proof of a (e.g., relay) WTRU using, for example, the public key of a verifier and its validity period, and / or may compare the proof result with its evaluation policy. 9.3 - If successful, a (e.g., remote) WTRU 901 may select this (e.g., relay) WTRU 902 and initiate unicast (e.g., PC5) link establishment. The remote WTRU 901 may send its proof result, for example, on a direct communication request (DCR) message and / or may include its proof result during authentication or security mode procedures (e.g., on an authentication response or direct security mode complete message). 9.4 - When a WTRU receives the proof result of a (e.g., remote) WTRU, a (e.g., relay) WTRU 902 may check the signature of the proof of the (e.g., remote) WTRU using the public key of the verifier and its validity period, 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 procedure. If not successful, the (e.g., relay) WTRU may stop the unicast (e.g., PC5) link establishment procedure by, for example, 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).

[0101] A (e.g., relay) WTRU 902 may internally track this (e.g., remote) WTRU 901 and its failed verification over a period of time / a certain time (e.g., add it to the blacklist of the (e.g., remote) WTRU).

[0102] Figure 10 illustrates the trust assertions of a (e.g., remote) WTRU 1001 and a (e.g., relay) WTRU 1002 during a unicast (e.g., PC5) link establishment procedure.

[0103] During unicast (e.g., PC5) link establishment (no proof of trust during discovery or no discovery): 10.1 - (e.g., remote) WTRU 1001 may send a (e.g., DCR) message containing its proof result to (e.g., relay) WTRU 1002. 10.2 - When receiving a (e.g., DCR) message, (e.g., relay) WTRU 1002 may check the signature of the (e.g., remote) WTRU's proof using the verifier's public key and its validity period, and / or compare the proof result with its evaluation policy. 10.3 - If successful, (e.g., relay) WTRU 1002 may send its proof result, e.g., during authentication or security mode procedures (e.g., in an authentication request or a direct security mode command message). If not successful, (e.g., relay) WTRU 1002 may stop the unicast (e.g., PC5) link establishment procedure, e.g., by not responding to a DCR message and / or by sending a rejection message (e.g., a direct link communication rejection including a reason value such as a trust failure). 10.4 - When receiving the proof result of a (e.g., relay) WTRU, (e.g., remote) WTRU 1001 may check the digital signature of the (e.g., relay) WTRU's proof using the verifier's public key and its validity period, and / or compare the proof result with its evaluation policy. 10.5 - If successful, (e.g., remote) WTRU 1001 may continue the link establishment procedure. If not successful, (e.g., remote) WTRU 1001 may stop the unicast (e.g., PC5) link establishment procedure, e.g., by not responding to a DCR message and / or by sending a rejection message (e.g., a direct link communication rejection). 10.6 - (e.g., relay) WTRU 1002 may send a direct communication accept (DCA) message and establish a unicast (e.g., PC5) unicast link.

[0104] According to an embodiment, a (e.g., remote) WTRU 1001 may send the resulting proof using, for example, a Direct Security Mode (DSM) completion message (instead of including a DCR message), and then a (e.g., relay) WTRU 1002 may send the resulting proof using, for example, a DCA message. For example, upon receiving a DCA message, a (e.g., remote) WTRU 1001 may break the link if it cannot successfully verify the proof result of a (e.g., relay) WTRU.

[0105] There may be no need to re - execute the proof result to check whether authentication and / or security procedures are, for example, periodically re - executed.

[0106] Using proof of evidence According to some embodiments, the steps described in the above section (“Using the proof result”) can be reused in both the remote WTRU and the relay WTRU that provide proof of evidence instead of proof of the result. The remote WTRU and the relay WTRU may be able to (e.g., need to) access the network to obtain the proof of the result from a verifier. According to some embodiments, if the verifier already has the evidence of the WTRU, the WTRU ID can be sent to the verifier to obtain the proof. 1) During the discovery procedure (request / response): a) A remote WTRU may send a request message including proof of its own evidence. The proof evidence may be protected for integrity and / or re - transmission between the WTRU and the verifier. b) A relay WTRU may send a proof request message including the evidence to the verifier and / or may wait to receive the proof result before sending (or not sending) a response message including the proof evidence. The proof evidence may be signed by the verifier. c) A remote WTRU may send a proof request including the evidence from the relay WTRU to the verifier to obtain the proof of the result. 2) During the discovery procedure (announcement): a) The relay WTRU may send an indication message including proof of its own evidence. b) The remote WTRU may send a proof request including evidence from the relay WTRU to the verifier to obtain the resulting proof. 3) During unicast (e.g., PC5) link establishment (where there is no proof of trust or no discovery during discovery): a) The remote WTRU may send a DCR message that may include proof of its own evidence. b) Upon receiving the DCR message, the relay WTRU may send a proof request including evidence to the dependent party and wait to receive the proof result. c) If the verification of the proof of the remote WTRU's result is successful, the relay may send proof of its own evidence to the remote WTRU during the authentication procedure or security establishment procedure. d) The remote WTRU may send the evidence of the relay WTRU to the dependent party to obtain the proof result of the relay WTRU and may continue with the procedure described in the above section ("Using the proof result").

[0107] Using the proof result and evidence in combination The resulting evidence and proof can be combined and used. This may be useful, for example, when a WTRU-network relay (e.g., that can always) access the network is used and a remote WTRU (that may not have network access) is used.

[0108] The steps described in the above section ("Using Proof Results") can be reused by a remote WTRU that provides its own evidence and a relay WTRU that provides proof of its own results. The relay WTRU may obtain proof of the results of the remote WTRU from a relying party. The remote WTRU may be configured with an evaluation policy. The verification function may be collocated 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 verification function may be reached via the user plane. The remote WTRU may be configured with a local policy by a verification function (e.g., PKMF) while it is within network coverage. For example, the remote WTRU may use its own local policy to verify relay proof evidence while it is outside coverage and may request the verification function AF to verify the relay proof evidence while it is within coverage. The remote WTRU may request proof verification from the verification function AF during discovery, during unicast (e.g., PC5) link establishment, or afterwards.

[0109] Network-controlled assertion of relay reliability The remote WTRU may perform an assessment of the relay reliability of the relay WTRU during network-controlled authorization.

[0110] Precondition: The remote WTRU can discover and / or select a relay WTRU that broadcasts an indication of proof capability or a relay service code (RSC) associated with such an indication.

[0111] The relay WTRU may perform any of the following actions. - The remote WTRU may send a connection request that includes a request for network identification information (e.g., a subscription concealed identifier (SUCI)) and / or an indication of proof results. - The remote WTRU may execute a primary authentication procedure, e.g., via a relay WTRU, and / or may derive materials for a network access key and / or a relay access key, e.g., during the procedure. - The remote WTRU may receive a message containing a relay authentication result protected (e.g., for integrity with the MAC) using the network access key, e.g., during security mode command procedures. - The remote WTRU may verify the authentication result protection using, e.g., the network access key and / or may pass the result to a higher layer for further evaluation. - The remote WTRU may proceed with connection establishment and / or may abort the connection establishment procedure when accepting (e.g., upon acceptance) an authentication result from a higher layer (e.g., the application layer).

[0112] The relay WTRU may perform any of the following actions. - The relay WTRU may receive from the remote WTRU a connection request containing network identification information (e.g., SUCI) and / or an indication requesting an authentication result. - The relay WTRU may send a request message containing an assertion of evidence to the network (e.g., the AMF). - The relay WTRU may receive from the network a response message containing a protected relay authentication (e.g., at least integrity protected with the included MAC using the network access key or the authentication machine private key as described below) and / or relay access key materials. - The relay WTRU may send a request message containing a protected relay authentication result to the remote WTRU, e.g., during security mode command procedures. - The relay WTRU may proceed with connection establishment when (e.g., upon completion) the security mode procedure completes successfully using, e.g., the relay access key materials.

[0113] The network (e.g., the AMF) may perform any of the following actions. - A network (e.g., AMF) may receive a request message from a relay WTRU for remote WTRU authentication, and the message includes an assertion of evidence from the relay. - A network (e.g., AMF) may initiate a primary authentication procedure for a remote WTRU, e.g., via a relay WTRU, and / or may derive a network access key during the procedure. - If the authentication of the remote WTRU is successful (e.g., when it succeeds), the AMF may send a request message including relay identifier information (e.g., a generic public subscription identifier (GPSI)) and an assertion of evidence from the relay to a verifier (e.g., an application function). - A network (e.g., AMF) may receive a response message including a proof result and / or a validity period of the relay WTRU that may be protected by a digital signature of the verifier. - A network (e.g., AMF) may send a response message including a proof result, e.g., protected for integrity, to the relay WTRU using, e.g., a network access key or a verifier (e.g., AF) private key. The key may be known to the remote WTRU and the network or verifier but not necessarily to the relay WTRU (e.g., a key stored in the authentication server function (AUSF) in the AUSF (KAUSF), a key stored in the AMF (KAMF), a verifier private key of a public key pair). The message may be protected using, e.g., relay WTRU access key material.

[0114] FIG. 11 illustrates an example of a method for establishing a relay connection using network-assisted remote attestation, and this method includes any of the following actions. 11.0a / 11.0b - (e.g., remote) WTRU 1101 and (e.g., relay) WTRU 1102 may be registered and / or configured using, for example, an RSC associated with essential parameters for remote attestation. (e.g., remote) WTRU 1101 and / or (e.g., relay) WTRU 1102 may be supplied with an evaluation policy (e.g., at the application layer). 11.1 - (e.g., remote) WTRU 1101 may discover (e.g., relay) WTRU 1102 that provides a service for the RSC. 11.2 - (e.g., remote) WTRU 1101 may send a message (e.g., DCR) that includes any of SUCI, RSC, and an attestation result request (ARR) indication according to the remote attestation requirement parameters of the RSC. 11.3 - (e.g., relay) WTRU 1102 may send a relay key request message that includes remote identification information and relay identification information, RSC, and ARR. 11.4 - (e.g., remote) WTRU 1101 may perform primary authentication, for example, via a network node 1103 (e.g., AMF) of (e.g., relay) WTRU. 11.5a / 11.5b - After the first authentication is successful, the network node 1103 (e.g., AMF) of the (e.g., relay) WTRU can initiate the remote attestation procedure for the (e.g., relay) WTRU 1102 and the (e.g., remote) WTRU 1101 via the proxy verifier 1105 (e.g., network slice specific authentication and authorization function (NSSAAF)) using the verifier (e.g., AF) 1104. The network node 1103 (e.g., AMF) can send the identification information of the WTRU to be remotely attested, and the identifier of the service / resource for which remote attestation may be required before access is permitted (e.g., single network slice selection assistance information (S-NSSAI), data network name (DNN), RSC). The remote attestation procedure can be executed between the WTRU and the verifier 1104 via the NAS transport using the AMF / proxy acting as an intermediary. The network node 1103 (e.g., AMF) stores the attestation result (AR) of the relay WTRU 1102 / remote WTRU 1101 and can use it in subsequent relay connection requests using the ARR (e.g., during device to device (D2D) communication, as a relay such as a reliability-based path switcher as described above). The AR can be securely associated with the expiration time, location, public land mobile network (PLMN), and / or RSC. The transmitted AR can be protected by the verifier 1104 and / or the network node 1103 (e.g., AMF) (e.g., using a verifier signature, MAC by the AMF). 11.6 - The (e.g., relay) WTRU 1102 can receive the AR for the (e.g., relay) WTRU 1102 and the (e.g., remote) WTRU 1101 from the network node 1103 (e.g., AMF). 11.7 - A (e.g., relay) WTRU 1102 may verify that the AR of a (e.g., remote) WTRU may be acceptable (e.g., with respect to an evaluation policy). 11.8 - A (e.g., relay) WTRU 1102 may send the AR of the (e.g., relay) WTRU to a (e.g., remote) WTRU 1101, e.g., within a protected DSM command message. 11.9 - A (e.g., remote) WTRU 1101 may verify that the AR of the (e.g., relay) WTRU may be acceptable (e.g., with respect to an evaluation policy). 11.10 - A (e.g., remote) WTRU 1101 may send a DSM completion message to complete a unicast (e.g., PC5) link setup. 11.11 - A (e.g., remote) WTRU 1101 and a (e.g., relay) WTRU may proceed with the remaining relay connection procedure.

[0115] According to some embodiments, a remote WTRU may obtain a proof result from a PKMF (e.g., using a verification capability or publicly) when presenting evidence to the PKMF (e.g., when presenting). A remote WTRU may receive a protected proof result from the PKMF for a key request for accessing a relay service (e.g., signed by the PKMF of the remote WTRU). According to an embodiment, a remote WTRU may receive a relay access key on the condition that, e.g., the remote WTRU proof result meets a certain reliability criterion (e.g., established for a relay service, RSC). A remote WTRU may determine requirements for generating an evidence presentation when requesting a relay access key based on an RSC setting indicating that proof by the PKMF may be used (e.g., may be required) to obtain access to a relay service. A relay WTRU may perform similar steps using its own PKMF so as to be granted authorization to provide a relay service.

[0116] FIG. 12 illustrates an exemplary method for establishing a relay connection using PKMF-assisted remote attestation, the method including any of the following actions. 12.1 - A (e.g., remote) WTRU 1201 may execute a key request procedure using its own PKMF 1204. The key request may include a request for an attestation result. The (e.g., remote) WTRU 1201 may obtain a new prose remote user key (PRUK) / PRUK ID, for example, after successfully completing a remote attestation procedure. 12.2 - A (e.g., remote) WTRU 1201 may discover a (e.g., relay) WTRU 1202 that provides services for the RSC. 12.3 - A (e.g., remote) WTRU 1201 may send a message (e.g., DCR) that includes any of the PRUK ID, RSC, and ARR indication. 12.4 - A (e.g., relay) WTRU 1202 may send a (e.g., key request) message containing any of the PRUK ID, RSC, and ARR to its own PKMF 1203 (12.4a). The PKMF 1203 of the relay WTRU may initiate a remote attestation procedure using the (e.g., relay) WTRU (e.g., if a valid AR is not available to the 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 transferring parameters from the relay and the AR of the (e.g., relay) WTRU 1202 (e.g., AR-relay) to the PKMF 1204 of the (e.g., remote) WTRU (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 a valid AR is not 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 (e.g., based on an evaluation policy for the RSC / S-NSSAI / DNN) (12.4e), the PKMF 1204 of the (e.g., remote) WTRU may send a key response message containing the (e.g., remote) WTRU 1201 (e.g., AR-remote) to the PKMF 1203 of the (e.g., relay) WTRU (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 (e.g., relay) WTRU 1202 and authorize unicast (e.g., PC5) link establishment (12.4g). 12.5 - The (e.g., remote) WTRU 1201 and the (e.g., relay) WTRU 1202 may execute a direct security mode control (DSMC) procedure. 12.6 - The (e.g., remote) WTRU 1201 and the (e.g., relay) WTRU 1202 may proceed with the remaining relay connection procedure.

[0117] Assertion of WTRU Reliability Based on Remote Authentication During PDU Session Establishment Using an Authentication / Attestation Server According to an embodiment, the reliability of a WTRU (e.g., operating as a relay) can be established based on accessed resources such as, for example, S-NSSAI, DNN, during session management procedures. An example can be a WTRU (e.g., a relay) that desires to access or provide access to a confidential resource (e.g., a confidential / government agency DN).

[0118] WTRU remote authentication can be performed by an attestation server (e.g., collocated with an authentication, authorization, and accounting (AAA) server) as part of an extended PDU session with secondary authentication and / or attestation. The WTRU can perform remote authentication that can follow an authentication message exchange with the authentication server. The SMF can determine that (e.g., supplementary) remote authentication can be used (e.g., required) based on subscription information associated with the DNN or based on local configuration. The remote authentication protocol with the AAA server can be performed via the SMF over the NAS transport (e.g., using the extensible authentication protocol (EAP) or another transport). The remote authentication evidence / result (e.g., as an AAA signed token signed by a verifier) can be provided to the WTRU via the network by the AAA server (e.g., in a NAS message, PDU session establishment acceptance or rejection). Based on the evaluation policy of the AAA server, the AAA can provide a positive or negative result to the network / WTRU, and the network (SMF) can accordingly accept or reject the PDU session establishment. The WTRU can use the attestation result in subsequent procedures for communicating with other WTRUs or network entities.

[0119] According to an embodiment, a WTRU (e.g., operating as a relay) may present remote authentication evidence to a remote WTRU that may desire to use a relay service (e.g., in a broadcast message or during link establishment according to the above embodiments). According to an embodiment, the WTRU may operate as a residential gateway or the like. According to an embodiment, the WTRU may present such authentication results when connecting to a server (e.g., an edge network server). The remote WTRU and the relay WTRU may be configured using an RSC associated with an assertion of reliability requirement instructions. Based on this instruction, the relay WTU may be expected to obtain and present reliability information evidence according to the above embodiments. The remote WTRU may determine whether to select / connect to the relay WTRU based on the reliability requirement instructions and the reliability information evidence provided by the relay. For example, the remote WTRU may select / connect to the relay WTRU if the reliability information meets the evaluation policy (e.g., set by the RSC) of the remote WTRU. The evaluation policy may specify a minimum value of required reliability (e.g., greater than 80%, 100%) based on, for example, a scoring system.

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

[0121] Figure 13 illustrates an exemplary method for performing WTRU remote attestation during PDU session establishment, the method including any of the following actions. 13.0 - (For example, relayed) WTRU 1301 may register with the network. (For example, relayed) WTRU 1301 may provide its remote attestation capabilities during the registration procedure. 13.1 - (For example, relayed) WTRU 1301 may send a PDU session establishment request to access a slice / DN, and the DN may request remote attestation. A first network node (for example, AMF) 1302 may check (for example, relayed) whether WTRU 1301 may be authorized for DN access based on the (for example, relayed) WTRU 1301 remote attestation capabilities and / or DN usage (for example, necessity) based on subscription data. 13.2 - A second network node (for example, SMF) 1303 may determine (for example, based on DN subscription data) that the DN may (for example, may require) use remote attestation of the WTRU. The second network node (for example, SMF) 1303 may determine that the DN may (for example, may require) use secondary authentication of the WTRU before access. 13.3 - The second network node (for example, SMF) 1303 may initiate secondary authentication of (for example, relayed) WTRU 1301 by a data network authentication authorization record (DN-AAA) server 1308 if required based on the decision of the previous step. The second network node (for example, SMF) 1303 may hold off on performing the configuration (N4 session modification) of UPF 1305, for example, until the next remote attestation step is successfully completed. 13.4 - The second network node (e.g., SMF) 1303 may initiate the remote attestation of the (e.g., relay) WTRU 1301 based on the decision 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's information (e.g., fully qualified domain name (FQDN)) based on the opposite of the local configuration, subscription data, requests from the (e.g., relay) WTRU 1301, and messages from the DN-AAA 1308 server during the authentication procedure. The (e.g., relay) WTRU 1301 may execute the remote attestation protocol with the verifier via the SMF / UPF. The (e.g., relay) WTRU 1301 may exchange remote attestation messages (e.g., transparently to the network) with the verifier function (e.g., within the NAS container) via the NAS transport. According to an embodiment (e.g., instead of using the UPF), the second network node (e.g., SMF) 1303 may exchange remote attestation protocol messages via the NEF 1306. After the remote attestation procedure is completed without problems, 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 locally store and / or store the successful remote attestation result associated with the DNN in the unified data management (UDM). 13.5 - The second network node (e.g., SMF) 1303 may send the remote attestation result to the (e.g., relay) WTRU 1301 in the PDU session establishment acceptance message. 13.6 - The (e.g., relay) WTRU 1301 stores the remote attestation result. The (e.g., relay) WTRU 1301 may provide the result for use during subsequent procedures (e.g., during D2D communication, as a relay as described above, e.g., as a reliability-based path switching mechanism).

[0122] According to an embodiment, the remote attestation procedure can be performed by a (e.g., relay) WTRU in response to receiving a PDU session establishment acceptance message that may include verifier information (e.g., FQDN) and a remote attestation hold indication. The (e.g., relay) WTRU can use the established PDU session to perform remote attestation with the verifier via the user plane (UP). The SMF can restrict traffic on the PDU session for the (e.g., relay) WTRU to communicate with the verifier (e.g., configure the UPF accordingly) (e.g., not permit any other DN traffic). If the remote attestation is successfully completed (e.g., upon completion), the verifier can notify the SMF of the successful remote attestation via the NEF / PCF (e.g., using the API Nnef_AFSessionWithQoS). The SMF can update the UPF (e.g., N4 session modification), permit traffic towards the DN, and / or notify the WTRU of the permitted access to the DN during the PDU session modification procedure.

[0123] WTRU Reliability Assertion Based on Remote Attestation During the Registration Procedure Using an Authentication / Attestation Server According to an embodiment, WTRU reliability can be established during the registration management procedure. An example can be a WTRU (e.g., relay) that desires to access or provide access to a confidential resource (e.g., a confidential network slice). An example can be a relay that can provide (e.g., is required to provide) one or more highly confidential relay services (e.g., used by a government agency) using such a slice.

[0124] WTRU remote attestation can be performed by an attestation server (e.g., co-located with an AAA server) as part of an extended registration procedure involving secondary authentication and / or certification. The WTRU can perform remote attestation that can follow authentication message exchange with an authentication server. The AMF can determine (e.g., may require) to use (e.g., supplementary) remote attestation based on WTRU subscription information. The remote attestation procedure with the AAA server can be performed via the AMF on the NAS transport (e.g., using EAP or other transport). The remote attestation evidence / result (e.g., as an AAA signed token signed by a verifier) can be provided to the WTRU via the network by the AAA server (e.g., in a NAS message, in a WTRU configuration update procedure). Based on the evaluation policy of the AAA server, the AAA can provide a positive or negative result to the network / WTRU, and the network (AMF) can determine to deregister the WTRU or provide access (e.g., authorize non-relayed services, reject a PDU session access request on behalf of a remote WTRU) based on the trustworthiness of the WTRU. The WTRU can use the attestation result in subsequent procedures for communicating with other WTRUs or network entities.

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

[0126] As in the above embodiments, the remote attestation server can be an NF within the MNO domain or can be operated by a third party.

[0127] Figure 14 illustrates an exemplary method for performing WTRU remote attestation during the registration procedure, which includes any of the following actions. 14.1 - (e.g., relayed) WTRU 1401 may send a registration request message that may include its own remote attestation capabilities and / or an S-NSSAI that may be subject to remote attestation. 14.2 - A network node (e.g., AMF) 1402 checks whether (e.g., relayed) WTRU 1401 may be authorized for S-NSSAI access. If (e.g., relayed) WTRU 1401 is capable of remote attestation, the network node (e.g., AMF) 1402 may determine, based on the subscription information of its slice, that the S-NSSAI may be subject to remote attestation. The network node (e.g., AMF) 1402 may determine whether remote attestation should be performed based on any previous attestation results for that S-NSSAI and / or whether remote attestation is in progress. 14.3 - The network node (e.g., AMF) 1402 may send a registration acceptance that includes a remote attestation hold indication. 14.4 - The network node (e.g., AMF) 1402 may initiate slice-specific authentication procedures (e.g., if the slice is subject to both authentication and remote attestation). 14.5 - (e.g., relayed) WTRU 1401 may perform a remote attestation procedure with the verifier 1405 (e.g., using network control plane transport). (e.g., relayed) WTRU 1401 may exchange remote attestation messages with the verifier function via the network node (e.g., AMF) 1402 / NSSAAF 1403 (e.g., within the NAS container). NSSAAF 1403 may route the message to the verifier 1405 (which may be co-located with the AAA-S / AAA server 1404) based on the S-NSSAI. If the remote attestation procedure completes successfully (e.g., after completion), the verifier function may send the final remote attestation result to the network node (e.g., AMF) 1402. Based on the results of the remote attestation procedure, network node (e.g., AMF) 1402 may initiate a WTRU configuration update procedure and send the remote attestation results to WTRU 1401 (e.g., via relay). 14.7 - (e.g., via relay) WTRU 1401 stores the remote attestation results. (e.g., via relay) WTRU 1401 provides the results during subsequent procedures (e.g., during D2D communication, as a relay as described above).

[0128] Reliability token A reliability token may be an electronic document used to prove the binding of the identification information of a (e.g., remote or relayed) WTRU using verified evidence of reliability. The token may include information about the identification information of the (e.g., remote or relayed) WTRU, the listed evidence submitted to and verified by the verifier, and be cryptographically bound thereto, and may include the digital signature of the entity (e.g., verifier AF) that verified the evidence. If the signature is valid and the entity (e.g., remote or relayed WTRU) inspecting the token trusts the verifier, that entity can use the evidence to establish secure communication with other entities (e.g., remote or relayed WTRU).

[0129] Such an inspection can be achieved without an online check with the entity (e.g., verifier AF) that verified the evidence, since the entity analyzing the reliability token may inspect the reliability token using the public key of the entity (e.g., verifier AF) that verified the evidence.

[0130] FIG. 15 illustrates an example of method 1500 for assertion of the reliability of a relayed WTRU, implemented by WTRU 102.

[0131] According to an embodiment, WTRU 102 may be configured to send a request message to the relayed WTRU to obtain information indicating the reliability of the relayed WTRU operating as a relay (1510).

[0132] According to an embodiment, the WTRU 102 may be configured to receive, from the relay WTRU, a response to a request message that includes information indicating the reliability of the relay WTRU operating as a relay (1520).

[0133] According to an embodiment, the WTRU 102 may be configured to authenticate using a key identifier, and this information indicates the reliability of the relay WTRU (1530).

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

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

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

[0137] According to an embodiment, the information indicating the reliability of the relay WTRU is associated with a validity period.

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

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

[0140] FIG. 16 illustrates another example of a method 1600 for assertion of the reliability of a relay WTRU implemented by the WTRU 102.

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

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

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

[0144] According to an embodiment, the WTRU 102 may be configured to establish a unicast link with a relay WTRU, for example, on the condition that the information indicating the reliability criterion is authenticated, and / or on the condition that a score associated with the reliability criterion is greater than a threshold (1640).

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

[0146] According to an embodiment, a unicast link is established with a relay WTRU on the condition that a score associated with the reliability criterion of the relay WTRU is greater than a score associated with the reliability criterion of a further relay WTRU.

[0147] According to an embodiment, the further information is obtained from a memory unit of a remote WTRU.

[0148] According to an embodiment, the integrity of the information indicating the reliability criterion associated with the relay WTRU is protected by a network entity.

[0149] According to an embodiment, the reliability criterion of the relay WTRU has been verified by a network entity.

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

[0151] According to an embodiment, the reliability criterion is associated with a period during which the information indicating the reliability criterion is valid.

[0152] According to an embodiment, the reliability criterion of the relay WTRU is associated with the resources accessed by the relay WTRU.

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

[0154] According to an embodiment, the WTRU 102 may be configured to send information indicating the reliability criterion of the remote WTRU to the relay WTRU, and the information is integrity protected by a network entity.

[0155] Conclusion In the above, the features and elements are provided in specific combinations, but it will be understood by those skilled in the art that each feature or each element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the perspective of the specific embodiments described in this application, and these embodiments are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the present invention unless explicitly presented as such. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations 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 is limited together with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0156] For the sake of brevity, the foregoing embodiments have been discussed in relation to the terminology and structure of infrared-compatible devices (i.e., infrared emitters and receivers). However, the embodiments discussed are not limited to these systems and can also be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0157] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can mean any of a snapshot, a single image, and / or a plurality of images displayed over time. 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" or its abbreviation "HMD" can mean (i) a wireless transmit and / or receive unit (WTRU), (ii) any of some embodiments of a WTRU, (iii) a wireless and / or wired compatible (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless and / or wired compatible device configured to have less structure and functionality than all of the structure and functionality of a WTRU, or (iv) the like, or can include the same. Details of exemplary WTRUs that can represent any WTRU listed herein are provided herein with respect to FIGS. 1A-1D. As another example, the various embodiments disclosed herein and the various embodiments below are described as utilizing a head-mounted display. One of ordinary skill in the art will recognize that devices other than a head-mounted display can be utilized and that some or all of the present disclosure and the various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices can include drones or other devices configured to stream information for providing an augmented reality experience.

[0158] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into 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, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, 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 may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0159] Variations of the methods, apparatuses, and systems provided above are possible without departing from the scope of the invention. Considering the wide variety of embodiments that may be applicable, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, the embodiments provided herein include portable devices, which may include or be utilized with any suitable voltage source, such as a battery that provides any suitable voltage.

[0160] Furthermore, in the above embodiments, attention should be paid to the processing platform, computing system, controller, and other devices including a processor. These devices may include at least one central processing unit ("Central Processing Unit, CPU") and memory. According to the convention of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations, and operations or instructions, may be referred to as "executed", "executed by a computer", or "executed by a CPU".

[0161] Those skilled in the art will understand that operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that can cause a resultant conversion or reduction of electrical signals, maintains the data bits at memory locations in the memory system, thereby restructuring or otherwise changing the operation of the CPU and the processing of other signals. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic characteristics corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0162] Data bits may also be maintained on a computer-readable medium 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 system readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist exclusively on the processing system or are distributed among a plurality of interconnected processing systems that are local or remote to the processing system. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories may support the provided methods.

[0163] In an exemplary embodiment, any of the 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 body, a network element, and / or any other computing device.

[0164] There is little difference between the hardware implementation and the software implementation of the system aspect. Whether to use hardware or software is generally (not always, but in certain contexts the choice between hardware and software may be crucial) a design choice representing a cost and efficiency trade-off. There may be various means of implementation (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other technologies described herein can be effective, and the preferred means of implementation may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer may primarily select hardware and / or firmware means of implementation. If flexibility is of utmost importance, the implementer may primarily select a software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0165] In the foregoing detailed description, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. As long as such block diagrams, flowcharts, 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 within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, some portions of the subject matter described herein can be implemented via 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, in light of the present disclosure, it is within the scope of the skill of the art to design the circuits, and / or write the code for the software and / or firmware such that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit as one or more computer programs operating on one or more computers (e.g., as one or more programs operating on one or more computer systems), as one or more programs operating on one or more processors (e.g., as one or more programs operating on one or more microprocessors), as firmware, or as substantially any combination thereof. Additionally, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that representative embodiments of the subject matter described herein apply regardless of the particular type of signal transmission medium used to actually carry out the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, and the like, and transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0166] Those skilled in the art will recognize that it is common in the art to describe a device and / or process in the manner described herein and then, using engineering techniques, integrate such described device and / or process into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, an operating system, drivers, a graphical user interface, and computing entities such as application programs, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for detecting position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components as typically found in a data computing / communication system and / or a network computing / communication system.

[0167] The subject matter described in this specification may illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and in practice, many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components for achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components in this specification that are combined to achieve a particular function can be considered to be "associated" with each other so that the desired function is achieved, regardless of the architecture or intervening components. Similarly, any two components thus associated can also be considered to be "operably connected" or "operably coupled" to each other for achieving the desired function, and any two components that can be associated in this way can also be considered to be "operably couplable" to each other for achieving the desired function. Specific examples of operably couplable include, but are not limited to, components that are physically mating and / or physically interacting, and / or wirelessly interacting and / or wirelessly interacting, and / or logically interacting and / or logically interactable components.

[0168] Regarding the use of substantially any plural and / or singular terms in this specification, one of ordinary skill in the art can convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. In this specification, various singular / plural permutations may be explicitly recited for clarity purposes.

[0169] Generally, it will be understood by those skilled in the art that the terms used in this specification, and in particular in the appended claims (e.g., the body of the appended claims), are generally intended to be terms of "non-limitation" (e.g., the term "comprising" should be interpreted as "comprising, but not limited to", the term "having" should be interpreted as "having at least", and the term "including" should be interpreted as "including, but not limited to"). Further, if a specific number of recitations of the introduced claim description is intended, such intention will be expressly recited in the claim, and it will be understood by those skilled in the art that such intention does not exist if there is no such recitation. For example, if only one item is intended, the term "single" or similar words may be used. To assist understanding, the following appended claims and / or the description of this specification may include the use of introductory phrases such as "at least one" and "one or more" to introduce the claim recitation. However, the use of such phrases should not be construed to limit any particular claim that includes the introduced claim description by the introduction of the claim description with the indefinite article "a" or "an" to an embodiment that includes only such one description, even if the same claim includes an introductory phrase such as "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). The same is true for the use of the definite article used to introduce the claim description. In addition, even if a specific number of recitations of the introduced claim description is expressly recited, it will be recognized by those skilled in the art that such recitation should be interpreted to mean at least the recited number (e.g., a simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations).Furthermore, when notations similar to “at least one of A, B, and C, etc.” are used, generally, such a structure is intended in the sense that those skilled in the art will understand the notation (e.g., a “system having at least one of A, B, and C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When notations similar to “at least one of A, B, or C, etc.” are used, generally, such a structure is intended in the sense that those skilled in the art will understand the notation (e.g., a “system having at least one of A, B, or C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It should be further understood by those skilled in the art that any substantially discrete words and / or phrases presenting two or more alternative terms, in any of the specification, claims, or drawings, are intended to contemplate the possibility of including one of the terms, any of the terms, or both terms. For example, the phrase “A or B” should be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any of” following a list of multiple items and / or a list of multiple categories of items is intended to include “any of”, “any combination of”, “any plurality of”, and / or “any plurality of combinations of” the items and / or categories of items, individually 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. In addition, as used herein, the term “number” is intended to include any number including zero. Also, as used herein, the term “plurality” is intended to be synonymous with “multiple”.

[0170] In addition, when a feature or aspect of the present disclosure is described from the perspective of a Markush group, those skilled in the art will recognize that the present disclosure is thereby also described from the perspective of any individual element or subgroup of elements of the Markush group.

[0171] As will be understood by those skilled in the art, for all purposes, such as for the purpose of providing a written description, all ranges disclosed herein also include all possible sub-ranges and combinations of sub-ranges thereof. Any recited range can be readily explained and recognized as being capable of being decomposed into at least equal halves, thirds, fourths, fifths, tenths, etc. of the same range. By way of non-limiting example, each range discussed herein may be readily decomposed into lower thirds, middle thirds, and upper thirds, etc. Also, as will be understood by those skilled in the art, all words such as "up to", "at least", "more than", "less than", etc. include the recited number and mean a range that can be decomposed into subsequent sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0172] Furthermore, the claims should not be read as being limited to the order provided or to the elements provided, unless specifically so recited. In addition, in any claim, the use of the term "means for" is not intended to invoke 35 U.S.C. § 112, paragraph 6, or means-plus-function claim format, and any claim that does not have the term "means for" is not so intended.

Claims

1. A method carried out by a remote wireless transmitter / receiver unit (WTRU), wherein the method is Sending information to the relay WTRU indicating the requirements for the reliability criteria associated with the relay WTRU, Receiving information from the relay WTRU indicating (1) the reliability criteria associated with the relay WTRU, and (2) the score associated with the reliability criteria, Authenticating the information indicating the trust criteria using the public key and / or network access key of the network entity, A method performed by a remote radio transmit / receive unit (WTRU), comprising establishing a unicast link with the relay WTRU, provided that the information indicating the reliability criteria is authenticated and the score associated with the reliability criteria is greater than a threshold.

2. (1) Reliability criteria associated with further relay WTRUs, and (2) Scores associated with the reliability criteria associated with the further relay WTRUs, further including obtaining further information, The method according to claim 1, wherein the unicast link is established with the relay WTRU on the condition that the score associated with the reliability criterion of the relay WTRU is greater than the score associated with the reliability criterion of the further relay WTRU.

3. The method according to claim 2, wherein the further information is obtained from the storage unit of the remote WTRU.

4. The method according to claim 1, wherein the integrity of the information indicating the reliability criteria associated with the relay WTRU is protected by the network entity.

5. The method according to claim 1, wherein the reliability criteria of the relay WTRU are verified by the network entity.

6. The method according to claim 1, wherein the unicast link is a PC5 link.

7. The method according to claim 1, wherein the reliability criterion is associated with a period during which the information indicating the reliability criterion is valid.

8. The method according to claim 1, wherein the reliability criterion of the relay WTRU is associated with the resources being accessed by the relay WTRU.

9. The method according to claim 1, further comprising storing the information indicating the reliability criteria of the relay WTRU.

10. The method according to claim 1, further comprising sending information indicating the reliability criteria of the remote WTRU to the relay WTRU, wherein the information is integrity protected by the network entity.

11. A remote wireless transmit / receive unit (WTRU) comprising a circuit including a transmitter, receiver, processor, and memory, wherein the remote WTRU is Sending information to the relay WTRU indicating the requirements for the reliability criteria associated with the relay WTRU, Receiving information from the relay WTRU indicating (1) the reliability criteria associated with the relay WTRU, and (2) the score associated with the reliability criteria, Authenticating the information indicating the trust criteria using the public key and / or network access key of the network entity, A remote WTRU is configured to establish a unicast link with the relay WTRU, provided that the information indicating the reliability criteria is authenticated and the score associated with the reliability criteria is greater than a threshold.

12. It is further configured to obtain further information indicating (1) a reliability criterion associated with a further relay WTRU, and (2) a score associated with the reliability criterion associated with the further relay WTRU, The remote WTRU according to claim 11, wherein the unicast link is established with the relay WTRU on the condition that the score associated with the reliability criterion of the relay WTRU is greater than the score associated with the reliability criterion of the further relay WTRU.

13. The remote WTRU according to claim 12, wherein the aforementioned further information is obtained from the storage unit of the remote WTRU.

14. The remote WTRU according to claim 11, wherein the integrity of the information indicating the reliability criteria associated with the relay WTRU is protected by the network entity.

15. The remote WTRU according to claim 11, wherein the reliability criteria of the relay WTRU have been verified by the network entity.

16. The remote WTRU according to claim 11, wherein the unicast link is a PC5 link.

17. The remote WTRU according to claim 11, wherein the reliability criterion is associated with a period during which the information indicating the reliability criterion is valid.

18. The remote WTRU according to claim 11, wherein the reliability criterion of the relay WTRU is associated with the resources accessed by the relay WTRU.

19. The remote WTRU according to claim 11, configured to store the information indicating the reliability criteria of the relay WTRU.

20. The remote WTRU according to claim 11, configured to send information indicating the reliability criteria of the remote WTRU to the relay WTRU, wherein the information is integrity protected by the network entity.

Images