L3 WTRU - PDU session secondary and slice-specific authentication and authorization using network repeaters

Abstract

A wireless transmit / receive unit (WTRU) may be configured to receive a key identifier. The key identifier may be associated with the second WTRU. Additionally or alternatively, the key identifier may include a 5G ProSe Remote User Key (5GPRUK) identifier (ID). The WTRU may be configured as a WTRU-to-network repeater for the second WTRU. The key identifier may be received during a key request procedure. The key request procedure may be performed by the WTRU on behalf of the second WTRU. The WTRU may be configured to send the key identifier to a network function. The key identifier may be sent to the network function to initiate a secondary authentication procedure. The WTRU may be configured to receive an authentication response message from the second WTRU. The WTRU may be configured to receive a response from the network function.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 323,760, filed March 25, 2022, which is incorporated herein by reference in its entirety. [Background technology]

[0002] Several security procedures on the control plane are specified for 5G proximity services (ProSe) related to authorization and PC5 link security of remote wireless transmit / receive units (WTRUs) and relay WTRUs. For example, authorization and PC5 link security of remote WTRUs and relay WTRUs may be based on remote WTRU authentication (e.g., by the network via the relay WTRU during PC5 link establishment). Summary of the Invention

[0003] A first wireless transmit / receive unit (WTRU) may be configured to receive a key identifier. The key identifier may be associated with a second WTRU. Additionally or alternatively, for example, the key identifier may include a 5G ProSe remote user key (5GPRUK) identifier (ID) associated with the second WTRU. The first WTRU may be configured as a WTRU-to-network relay for the second WTRU. For example, the first WTRU may be a relay WTRU, and the second WTRU may be a remote WTRU. The key identifier may be received during a key request procedure. The key request procedure may be performed by the first WTRU on behalf of the second WTRU.

[0004] The first WTRU may be configured to send a key identifier to a network function. The key identifier may be sent to the network function to initiate a secondary authentication procedure (e.g., a slice-specific authentication procedure). For example, the key identifier may be sent to the network function to initiate a secondary authentication procedure on behalf of the second WTRU. The first WTRU may be configured to receive an authentication message (e.g., from the network function). The authentication message may include a key identifier that can be used to determine that the authentication message is associated with the second WTRU. Additionally or alternatively, the first WTRU may be configured to send an authentication message to the second WTRU. For example, the first WTRU may be configured to send the authentication message to the second WTRU based on the authentication message including the key identifier. The network function may be identified by an access and mobility function (AMF) or a session management function (SMF). The AMF may send the key identifier to the SMF. For example, the SMF may send the key identifier to a ProSe Anchor Function (PAnF) or a ProSe Key Management Function (PKMF).

[0005] The first WTRU may be configured to receive an authentication response message from the second WTRU. The authentication response message may include a key identifier. Additionally or alternatively, the first WTRU may be configured to receive a response from the network function. The response may include the key identifier. Additionally or alternatively, the response may indicate a result of the secondary authentication procedure. The key identifier may be sent to the network function in a remote WTRU report message. The response may include a remote WTRU report response message. The first WTRU may be configured to send an indication that the second WTRU is authorized to communicate over or release the link. For example, the first WTRU may be configured to send an indication that the second WTRU is authorized to communicate over or release the link based on the remote WTRU report response message. The link may be a PC5 link.

[0006] The base station may be configured to receive a key identifier. The key identifier may be received from a first WTRU. The key identifier may be associated with a second WTRU. The first WTRU may be configured as a WTRU-network repeater for the second WTRU. The key identifier may be received during a key request procedure. The key request procedure may be performed by the first WTRU on behalf of the second WTRU. The key identifier may be received to initiate a secondary authentication procedure on behalf of the second WTRU. The base station may be configured to transmit an authentication message. For example, the base station may be configured to transmit an authentication message to the second WTRU. The authentication message may include the key identifier. The authentication message may be transmitted to the second WTRU via the first WTRU. For example, the authentication message may be sent to the second WTRU via the first WTRU based on the authentication message including the key identifier. The base station may be configured to transmit a response to the first WTRU. The response may include the key identifier. Additionally or alternatively, the response may indicate a result of the secondary authentication procedure. The WTRU may release the link with the second WTRU based on the result of the secondary authentication procedure. Data network (DN) information may be obtained from the second WTRU. For example, the secondary authentication may be triggered based on one or more determinations of the DN being authorized, the DN requesting secondary authentication, and a previous authentication. [Brief explanation of the drawings]

[0007] [Figure 1A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C]1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 illustrates an example relating to 5GPRUK / 5GPRUK ID exchange between a remote WTRU, a relay WTRU, and a network using a control plane. [Figure 3A] 10 illustrates an example relating to a key identifier 5GPRUK / 5GPRUK ID exchange between a remote WTRU, a WTRU-network relay, and a network using a user plane. [Figure 3B] 10 illustrates an example relating to a key identifier 5GPRUK / 5GPRUK ID exchange between a remote WTRU, a WTRU-network relay, and a network using a user plane. [Figure 4A] 1 illustrates an example associated with a protocol data unit (PDU) session secondary authentication and authorization (A&A) procedure performed via a Layer 3 WTRU-network repeater. [Figure 4B] 1 illustrates an example associated with a protocol data unit (PDU) session secondary authentication and authorization (A&A) procedure performed via a Layer 3 WTRU-network repeater. [Figure 5A] 10 illustrates an example relating to a network slice specific authentication and / or authorization (NSSAA) procedure performed via a Layer 3 WTRU-network repeater. [Figure 5B] 10 illustrates an example relating to a network slice specific authentication and / or authorization (NSSAA) procedure performed via a Layer 3 WTRU-network repeater. DETAILED DESCRIPTION OF THE INVENTION

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

[0009] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (ioT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a WTRU.

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

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

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

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

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

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

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

[0017] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

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

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

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

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

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

[0023] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 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 together in an electronic package or chip.

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

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

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

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

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

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

[0030] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), 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. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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.

[0031] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference either through hardware (e.g., chokes) or signal processing via 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 for transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

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

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

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

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

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

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

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

[0042] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating at a STA and destined for a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be sent, for example, through the AP, where a source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

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

[0044] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

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

[0047] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active, even though most of the frequency band may remain inactive and available.

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

[0049] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology and communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

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

[0052] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed spectrum. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement a DC mechanism to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0053] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, coordination between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0054] 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 possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0059] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform the tests.

[0061] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] Secondary and slice-specific authentication and authorization for a protocol data unit (PDU) session may be performed using, for example, a Layer 3 WTRU-network relay. The remote WTRU and relay WTRU may establish a PC5 link. For example, the PC5 link may be established via a security procedure (e.g., on the user plane or on the control plane). The relay WTRU may receive and store a security key identifier associated with the remote WTRU. For example, the security key identifier may be received from the network or from the remote WTRU, for example, during a security procedure. The relay WTRU may send a remote WTRU report message to the Layer 3 WTRU-network relay (e.g., to an Access and Mobility Function (AMF) associated with the Layer 3 WTRU-network relay). In some scenarios, the relay WTRU may send a remote WTRU report message to the network after a PC5 link with the remote WTRU is established. For example, the remote WTRU report message may include a security key identifier associated with the remote WTRU and / or one or more identifiers associated with the established PC5 link.

[0063] The Layer 3 WTRU-network relay may determine whether the remote WTRU is authorized and / or authenticated to communicate over the established PC5 link (e.g., via a network function). For example, an AMF associated with the relay may obtain a second identifier (e.g., a subscription permanent identifier (SUPI)) associated with the remote WTRU based on the remote WTRU's key identifier. The AMF may send the second identifier associated with the remote WTRU and / or the remote WTRU's key identifier to a Session Management Function (SMF) associated with the Layer 3 WTRU-network relay. Alternatively or additionally, the SMF associated with the relay may obtain the second identifier (e.g., a subscription permanent identifier (SUPI)) associated with the remote WTRU based on, for example, the remote WTRU's key identifier. The SMF may send the security key identifier associated with the remote WTRU to the PAnF or PKMF and / or receive the second identifier associated with the remote WTRU in response. The SMF may determine whether the remote WTRU is authorized and / or authenticated to communicate over the established PC5 link. For example, the SMF may determine whether the remote WTRU is authorized and / or authenticated to communicate over the established PC5 link based on a second identifier associated with the remote WTRU. The SMF may initiate and / or perform a secondary authentication and authorization procedure for the remote WTRU. For example, the SMF may initiate and / or perform a secondary authentication and authorization procedure for the remote WTRU via a WTRU-network repeater. For example, the secondary authentication and authorization procedure may include sending a key identifier for the remote WTRU to the WTRU-network repeater. The SMF may transmit a result of the authentication and authorization procedure to the WTRU-network repeater. Additionally or alternatively, the SMF may transmit a security key identifier for the remote WTRU to the WTRU-network repeater.If the remote WTRU is authorized and / or authenticated to communicate over the PC5 link, the Layer 3 WTRU-network relay may send an indication to the relay WTRU that the remote WTRU is authorized and / or authenticated to communicate over the established PC5 link. The remote WTRU may communicate over the established PC5 link. In some scenarios, if the remote WTRU is not authorized or authenticated to communicate over the PC5 link, the Layer 3 WTRU-network relay may release the established PC5 link.

[0064] A first wireless transmit / receive unit (WTRU) may be configured to receive a key identifier. The key identifier may be associated with a second WTRU. The key identifier may refer to a key and / or may be generated as random bits. For example, the key identifier may be used to determine an identifier associated with the remote WTRU (e.g., via a lookup table maintained by the network and / or repeater), such as the remote WTRU's SUPI. The key identifier may be used and / or transmitted over the network in place of the remote WTRU's SUPI, e.g., to maintain security across networks and / or network repeaters. In certain scenarios, for example, the key identifier may include a 5G ProSe Remote User Key (5GPRUK) identifier (ID). The first WTRU may be configured as a WTRU-to-Network Repeater for the second WTRU. The key identifier may be received during a key request procedure. The key request procedure may be performed by the first WTRU on behalf of the second WTRU.

[0065] The first WTRU may be configured to send the key identifier to a network function. The key identifier may be sent to the network function to initiate a secondary authentication procedure. For example, the key identifier may be sent to the network function to initiate a secondary authentication procedure on behalf of the second WTRU. The first WTRU may be configured to receive an authentication message. The authentication message may include the key identifier. Additionally or alternatively, the first WTRU may be configured to send the authentication message to the second WTRU. For example, the first WTRU may be configured to send the authentication message to the second WTRU based on the authentication message including the key identifier. The network function may be identified by an Access and Mobility Function (AMF) and / or a Session Management Function (SMF). The AMF may send the key identifier to the SMF. The SMF may send the key identifier to a ProSe Anchor Function (PAnF) and / or a ProSe Key Management Function (PKMF).

[0066] The first WTRU may be configured to receive an authentication response message from the second WTRU. The authentication response message may include a key identifier. Additionally or alternatively, the first WTRU may be configured to receive a response from the network function. The response may include the key identifier. Additionally or alternatively, the response may indicate a result of the secondary authentication procedure. The key identifier may be sent to the network function in a remote WTRU report message. The response may include a remote WTRU report response message. The first WTRU may be configured to send an indication that the second WTRU is authorized to communicate over or release the link. For example, the first WTRU may be configured to send an indication that the second WTRU is authorized to communicate over or release the link based on the remote WTRU report response message. The link may be a PC5 link.

[0067] The base station may be configured to receive a key identifier. The key identifier may be received from a first WTRU. The key identifier may be associated with a second WTRU. The first WTRU may be configured as a WTRU-network repeater for the second WTRU. The key identifier may be received during a key request procedure. The key request procedure may be performed by the first WTRU on behalf of the second WTRU. The key identifier may be received to initiate a secondary authentication procedure on behalf of the second WTRU. The base station may be configured to transmit an authentication message. For example, the base station may be configured to transmit an authentication message to the second WTRU. The authentication message may include the key identifier. The authentication message may be transmitted to the second WTRU via the first WTRU. For example, the authentication message may be sent to the second WTRU via the first WTRU based on the authentication message including the key identifier. The base station may be configured to transmit a response to the first WTRU. The response may include the key identifier. Additionally or alternatively, the response may indicate a result of the secondary authentication procedure. The WTRU may release the link with the second WTRU based on the result of the secondary authentication procedure. Distinguished name (DN) information may be obtained from the second WTRU. For example, the secondary authentication may be triggered based on one or more determinations of the DN being authorized, the DN requesting secondary authentication, and a previous authentication.

[0068] Security procedures related to 5G Proximity Services (ProSe) communications may be performed. For example, security procedures related to 5G ProSe communications may be performed via 5G ProSe (e.g., 5G ProSe Layer 3 WTRU-to-Network Repeater). Security procedures may be performed, for example, on the control plane.

[0069] Certain security procedures on the control plane may be specified for 5G ProSe. The security procedures may be associated with one or more of authorization of a remote WTRU (e.g., an out-of-coverage WTRU), a relay WTRU (e.g., an in-coverage WRU), and PC5 link security. For example, authorization of the remote WTRU and relay WTRU and / or PC5 link security may be based on remote WTRU authentication (e.g., via the relay WTRU during PC5 link establishment by the network).

[0070] The relay WTRU may receive a protected persistent identifier (e.g., a subscription persistent identifier (SUCI)). The relay WTRU may receive the protected persistent identifier in a direct communication request (DCR) message. The relay WTRU may forward the SUCI in a key request message. The key request message can be used to obtain a key from the network. The network may initiate remote WTRU authentication over the relay link (e.g., the PC5 link). Initiating remote WTRU authentication over the relay link may be similar to the primary authentication procedure performed over the Uu interface. The remote WTRU and / or the network may establish a 5G ProSe Remote User Key (5GPRUK) / 5GPRUK identifier from this authentication. The 5GPRUK ID may be used for (e.g., as) an authentication mechanism, for example, for the data network. Additionally or alternatively, the 5GPRUK ID may be used to route one or more messages for the relay WTRU. The relay WTRU may receive a shared key derived from the 5GPRUK from the network and / or may establish security of a PC5 link with the remote WTRU based on the shared key.

[0071] The remote WTRU may provide a key identifier (e.g., a 5GPRUK ID) via the DCR. In certain embodiments, the remote WTRU may provide the 5GPRUK ID via the DCR (e.g., if available) instead of, for example, the SUCI (e.g., so that a remote WTRU authentication procedure is not performed, as a possible optimization). For example, the 5GPRUK may be located and / or acquired based on the provided 5GPRUK ID.

[0072] Security procedures (e.g., certain security procedures) may be performed on the user plane. For example, security procedures performed on the user plane may be specified in 5G ProSe and / or may include one or more procedures of remote WTRU, relay WTRU authorization, and PC5 link security. The security procedures may be based, for example, on the remote WTRU sending a 5GPRUK ID (e.g., via a DCR). The remote WTRU may obtain the 5GPRUK / 5GPRUK ID from a ProSe Key Management Function (PKMF). For example, the remote WTRU may obtain the 5GPRUK / 5GPRUK ID from the PKMF over the user plane connection (e.g., before and / or during PC5 link establishment using a Generic Bootstrapping Architecture (GBA) push mechanism).

[0073] The relay WTRU may receive the 5GPRUK ID and / or SUCI. For example, the relay WTRU may receive the 5GPRUK ID and / or SUCI via a DCR message. The relay WTRU may forward the 5GPRUK ID and / or SUCI to a PKMF associated with the remote WTRU (e.g., over the user plane via the PKMF of the relay WTRU), for example, in a key request message. The relay WTRU may receive a shared key. The shared key may be derived from the 5GPRUK received from the PKMF of the remote WTRU (e.g., via the PKMF associated with the relay WTRU). The relay WTRU may establish security of the PC5 link with the remote WTRU based on the shared key.

[0074] In certain scenarios, a remote WTRU may perform a secondary authentication procedure. In some examples, the secondary authentication procedure may be associated with (e.g., specific to) the DN. The remote WTRU secondary procedure may be performed via a 5G ProSe Layer 3 WTRU-to-network relay (e.g., without a Non-3GPP Interworking Function (N3IWF)). For example, certain organizations (e.g., 3GPP) may be defining procedures that may require secondary authentication for a remote WTRU to access a data network (DN). For example, the secondary authentication may be via an L3 WTRU-to-network relay based on remote WTRU authentication by the network via the relay WTRU (e.g., as described herein). The remote authentication by the network via the relay WTRU may be followed by secondary authentication and / or authorization of the PDU session by the DN (e.g., as part of PC5 link establishment).

[0075] The remote WTRU may perform network slice-specific authentication and / or authorization (NSSAA). For example, the remote WTRU may perform NSSAA via a 5G ProSe Layer 3 WTRU-to-network relay (e.g., without an N3IWF). Certain organizations (e.g., 3GPP) are studying procedures for the remote WTRU to access single-network slice selection assistance information (S-NSSAI) that is subject to NSSAA. For example, the remote WTRU may access the S-NSSAI via the L3 WTRU-to-network relay based on remote WTRU authentication by the network via the relay (as described herein). Additionally or alternatively, the remote WTRU may access the S-NSSAI, followed by the NSSAA procedure as part of PC5 link establishment.

[0076] The secondary authentication and / or NSSAA may be performed, for example, using the control plane. For example, certain embodiments support access to the DN. Access to the DN may require secondary authentication (e.g., to an S-NSSAI that is subject to NSSAA). The secondary authentication may be via an L3 WTRU-to-network relay. In some embodiments, the remote WTRU may provide a SUCI and / or a 5G Globally Unique Temporary ID (GUTI). These SUCI and / or GUTI may be provided via a DCR message. For example, the SUCI or 5G-GUTI WTRU may be used by a serving network associated with the relay WTRU. For example, the SUCI or 5G-GUTI WTRU may be used by a serving network associated with the relay WTRU to access subscription information associated with the remote WTRU (e.g., which may be used for secondary authentication and / or NSSAA procedures).

[0077] The remote WTRU may send the SUCI in the DCR. The remote WTRU may send the SCI in the DCR, for example, if the remote WTRU intends to connect for a relay service (RSC) (e.g., for the first time). In some scenarios, the remote WTRU may perform authentication with the network. The remote WTRU may be allowed to (re)connect to the relay service (e.g., to avoid potential signaling overhead associated with re-performing an authentication procedure with the network if the (re)connection is authorized from a previous connection).

[0078] In some scenarios, the 5G-GUTI can be used by the network (e.g., an AMF associated with the remote WTRU). For example, the 5G-GUTI may be used by the network to determine the remote WTRU context. The remote WTRU context may include a remote WTRU subscription persistent identifier (SUPI). The 5G-GUTI can be used when the remote WTRU is registered in the same Public Land Mobile Network (PLMN) as the relay WTRU (e.g., so that context information associated with the remote WTRU can be exchanged with the AMF associated with the relay WTRU).

[0079] A remote WTRU can (re)connect to a given relay service. For example, the remote WTRU may (re)connect to a given relay service without performing an authentication procedure. This connection may allow the network (e.g., AMF, SMF) to access subscription information associated with the remote WTRU (e.g., without sending the SUCI associated with the remote WTRU in a DCR). The techniques described herein may allow access (e.g., via a relay) to a DN that performs secondary authentication. The techniques may allow access (e.g., via a relay) to an S-NSSAI. Access to the S-NSSAI may, for example, be subject to an NSSAA for the remote WTRU (e.g., without the remote WTRU performing an authentication procedure with the network and / or a SUPI hiding / de-hiding process).

[0080] The secondary authentication and / or NSSAA may be performed using the user plane. The remote WTRU may be provided with access to the DN. The DN may perform the secondary authentication and / or S-NSSAI that are subject to NSSAA. For example, the performance of the secondary authentication and / or S-NSSAI may be subject to NSSAA via an L3 WTRU-network relay (e.g., when use of the user plane is not supported). Some security procedures on the user plane may rely on the remote WTRU obtaining a 5GPRUK / 5GPRUK ID from the PKMF (e.g., using a user plane connection). These security procedures may not use remote WTRU authentication by the network (e.g., as in a control plane-based approach). Additionally or alternatively, some security procedures may not define a mechanism that allows a serving network associated with the relay WTRU to access subscription information associated with the remote WTRU and / or perform remote WTRU PDU session secondary authentication and / or NSSAA via an L3 relay (e.g., without an N3IWF). The techniques described herein may enable access (e.g., via a relay) to a DN that performs secondary authentication. For example, the secondary authentication may be performed when using security procedures on the user plane. Some techniques described herein may enable access (e.g., via a relay) to an S-NSSAI. The access may be subject to NSSAA for a remote WTRU (e.g., when using security procedures on the user plane).

[0081] Layer 3 WTRU-network relay may be provided. One or more of the following may apply: The Layer 3 WTRU-network relay may enable access to a DN requiring secondary authentication and / or access to the S-NSSAI. For example, the secondary authentication and / or access to the S-NSSAI may be subject to NSSAA during PC5 link establishment. The Layer 3 WTRU-network relay may receive and / or store a 5GPRUUK ID associated with the remote WTRU and / or the network. For example, the Layer 3 WTRU-network relay may receive and / or store a 5GPRUUK ID associated with the remote WTRU and / or the network during PC5 link establishment. The relay WTRU may send the 5GPRUUK ID, for example, in a remote WTRU report message. The Layer 3 WTRU-network relay may exchange one or more authentication messages for the remote WTRU with the network. For example, the one or more authentication messages may include the 5GPRUUK ID associated with the remote WTRU. The relay WTRU may receive a remote WTRU report response message. For example, the report response may include a 5GPRUK ID. Additionally or alternatively, the report response may include the authentication and / or authorization results for the remote WTRU. The relay WTRU may provide access to a PDU session with the remote WTRU (e.g., based on the results in the response message).

[0082] A session management function (SMF) associated with the relay WTRU may perform secondary authentication of the remote WTRU. For example, the secondary authentication of the remote WTRU may be via the relay WTRU. One or more of the following may apply: The SMF may initiate the remote WTRU secondary authentication procedure (e.g., via a relay). For example, the remote WTRU secondary authentication procedure may be in response to receiving a remote WTRU report message. The remote WTRU report message may include the SUPI and / or the 5GPRUUK ID. The SMF may exchange one or more PDU session secondary authentication messages. The one or more PDU session secondary authentication messages may be associated with a remote WTRU connected to the relay WTRU. For example, the PDU session secondary authentication message associated with the remote WTRU may include the 5GPRUUK ID associated with the remote WTRU. The SMF may store the authentication result (e.g., the final authentication result) in a relay context / Unified Data Management (UDM). The SMF may send a remote WTRU report response message to the relay WTRU. The report response message may include the 5GPRUUK ID and / or the authentication result. Additionally or alternatively, the report response message may include one or more authorization results for the remote WTRU.

[0083] An Access and Mobility Function (AMF) associated with the NSSAA procedure may be provided. One or more of the following may apply: The AMF may initiate the NSSAA for the remote WTRU authentication procedure (e.g., via a relay). For example, the initiation of the NSSAA for the remote WTRU authentication procedure may be in response to receiving a remote WTRU report message. The remote WTRU report message may include a 5GPRUUK ID associated with the remote WTRU. The AMF may obtain the SUPI associated with the remote WTRU. For example, the obtainment of the SUPI associated with the remote WTRU may be based on the 5GPRUUK ID from a network function (e.g., ProSe Anchor Function (PAnF), UDM). The AMF may exchange slice-specific authentication messages with the relay WTRU. For example, the slice-specific authentication message may include the 5GPRUUK ID associated with the remote WTRU. The 5GPRUUK ID associated with the remote WTRU can be used for remote WTRU authentication. The AMF may store the authentication result (e.g., the final authentication result) in the relay context / UDM. The AMF may send (e.g., forward) a remote WTRU report message, for example, to a serving SMF. The remote WTRU report message may include an indication of an NSSAA associated with the remote WTRU result to the SMF.

[0084] The remote WTRU may send the 5GPRUUK ID in the DCR message. For example, the remote WTRU may send the 5GPRUUK ID in the DCR message when connecting and / or reconnecting via a Layer 3 WTRU-to-network relay. The relay WTRU and / or the relay WTRU's serving network may use the 5GPRUUK ID to identify the remote WTRU in the network. The relay WTRU's serving network may use the 5GPRUUK ID to access subscription information associated with the remote WTRU. The relay WTRU and / or the relay WTRU's serving network may use the 5GPRUUK ID to perform PDU session secondary authentication and / or authorization procedures. Additionally or alternatively, the relay WTRU and / or the serving network associated with the relay WTRU may use the 5GPRUUK ID to perform NSSAA procedures.

[0085] The remote WTRU may be identified by the relay WTRU's serving network. For example, the remote WTRU may be identified by the serving network associated with the relay WTRU based on the 5GPRUK ID. The remote WTRU (e.g., by the relay WTRU and / or the relay WTRU's serving network) may be identified based on the 5GPRUK ID. For example, the relay WTRU may receive the 5GPRUK ID from the remote WTRU in a DCR message. Additionally or alternatively, the relay WTRU may receive the 5GPRUK ID from the network during establishment of the PC5 link. The 5GPRUK ID may be generated by a network function. For example, if the relay WTRU receives the 5GPRUK ID from the network, the 5GPRUK ID may be generated by a network function (e.g., a network function in the remote WTRU's home network). The 5GPRUK ID may be stored by the network. For example, the 5GPRUK ID may be stored by the network together with one or more other parameters (e.g., 5GPRUK, RSC, SUPI) associated with the ProSe context associated with the remote WTRU. The 5GPRUK / 5GPRUK ID may be generated as part of a remote WTRU authentication procedure (e.g., by an authentication function (AUSF) associated with the remote WTRU) as described herein. For example, if security procedures are used on the control plane, the 5GPRUK / 5GPRUK ID may be generated as part of a remote WTRU authentication procedure (e.g., by an AUSF associated with the remote WTRU) as described herein. The 5GPRUK / 5GPRUK ID may be generated (e.g., by a PKMF associated with the remote WTRU) as part of a key request procedure on the user plane (e.g., before PC5 link establishment) and / or during PC5 link establishment (e.g., using a GBA push mechanism) as described herein.If security procedures are used on the user plane, the 5GPRUK / 5GPRUK ID may be generated (e.g., by a PKMF associated with the remote WTRU) as part of a key request procedure on the user plane (e.g., before PC5 link establishment) and / or during PC5 link establishment (e.g., using a GBA push mechanism) as described herein. The repeater may store the 5GPRUK ID. The repeater may associate the 5GPRUK ID with the established PC5 link with the remote WTRU. The repeater may then use the 5GPRUK ID (e.g., in conjunction with remote WTRU secondary authentication and / or NSSAA procedures).

[0086] One or more security procedures may be performed on the control plane. FIG. 2 shows an example 200 relating to a key identifier (e.g., 5GPRUK / 5GPRUK ID) exchange between a remote WTRU, a relay WTRU, and a network using the control plane (e.g., a control plane approach). As illustrated in FIG. 2, the remote WTRU and / or the relay WTRU may perform a discovery procedure 202. At 204, the remote WTRU may send a direct communication request (DCR) message to the relay WTRU. The DCR may include the SUCI and / or the 5GPRUK ID. For example, the DCR message sent by the remote WTRU to the relay WTRU may additionally or alternatively include other parameters (e.g., RSC, nonce). At 206, the relay WTRU may send a relay key request message to the AMF. The relay key request message may include information received from the remote WTRU (e.g., the SUCI, 5GPRUK ID, RSC, and / or nonce).

[0087] As shown in FIG. 2, the AMF may determine whether the relay WTRU is authorized to provide relay services. At 208, the AMF may initiate a remote WTRU authentication procedure with an AUSF associated with the remote WTRU. For example, if an SUCI is provided in the relay key request, the AMF may initiate the remote WTRU authentication procedure with an AUSF associated with the remote WTRU. Additionally or alternatively, at 210, the AMF may not initiate the remote WTRU authentication procedure with an AUSF associated with the remote WTRU. For example, if a 5GPRUK ID is provided in the relay key request, the AMF may not initiate the remote WTRU authentication procedure with an AUSF associated with the remote WTRU. A new 5GPRUK / 5GPRUK ID (e.g., new 5GPRUK / 5GPRUK ID) may be generated by the remote WTRU and / or the AUSF associated with the remote WTRU, for example, at 216. The AUSF associated with the remote WTRU may store the resulting 5GPRUK / 5GPRUK ID in a network function (e.g., PAnF, UDM) and / or send the 5GPRUK ID to the AMF. For example, after the authentication procedure is completed, the AUSF associated with the remote WTRU may store the resulting 5GPRUK / 5GPRUK ID in a network function (e.g., PAnF, UDM) and / or send the 5GPRUK ID to the AMF.

[0088] As illustrated in FIG. 2, at 212, the AMF may send a request message to a ProSe Anchor Network Function (PAnF). For example, the request message may include the 5GPRUK ID and / or other parameters included in the relay key request received from the relay WTRU. At 214, the AMF may receive a response to the request message (e.g., from the PAnF). The response request message may include ProSe key data (e.g., ProSe key, nonce). At 218, the relay WTRU may receive a relay key response message from the AMF. The relay key response message may follow the response request message. For example, the relay key response message may include the ProSe key data and / or a new 5GPRUK ID (e.g., previously generated). For example, the key may be generated by the remote WTRU, for example, at 222.

[0089] At 220, the WTRU-network relay may perform a security procedure. The security procedure may be a direct security mode command (DSMC). Alternatively, or additionally, the remote WTRU may use the ProSe key data received via the Relay Key Response message. The direct security procedure may be completed, for example, at 224. At 226, the WTRU-network relay may store the 5GPRUUK ID (e.g., received as described herein) and / or associate the 5GPRUUK ID with the PC5 link established with the remote WTRU. At 228, the WTRU-network relay may send a direct communication accept (DCA) message. An authentication message may be sent to the remote WTRU. The DCA message may be used to complete the PC5 link establishment. As described herein, the WTRU-network relay may use the 5GPRUUK ID when initiating subsequent procedures (e.g., secondary authentication and authorization procedures and / or NSAA), for example, at 230.

[0090] 3A-3B, 4A-4B, and 5A-5B illustrate example authentication procedures associated with a WTRU-network repeater and a remote WTRU. For example, FIGS. 3A-3B, 4A-4B, and 5A-5B may be used to perform PDU session secondary and slice-specific authentication and authorization for the WTRU-network repeater. While FIGS. 3A-3B, 4A-4B, and 5A-5B illustrate examples in which a 5GPRUUK ID is used as a key identifier, it should be understood that the techniques described herein are not limited to that example. For example, other suitable identifiers that can be used to verify and / or determine the identity of a remote WTRU may also or alternatively be used. Similarly, while the examples illustrated in FIGS. 3A-3B, 4A-4B, and 5A-5B contemplate specific network functions (e.g., SMF, AMF), any suitable network function may also or alternatively be used. Similarly, although the examples illustrated in Figures 3A-3B, 4A-4B, and 5A-5B show a WTRU-network repeater communicating with a single remote WTRU, it should be understood that these techniques apply equally when the WTRU-network repeater is communicating with multiple remote WTRUs and / or when a remote WTRU is communicating with multiple WTRU-network repeaters.

[0091] One or more security procedures may be performed on the user plane. Figures 3A and 3B illustrate an example 300 associated with a key identifier (e.g., 5GPRUK / 5GPRUK ID) exchange between a remote WTRU, a WTRU-network relay, and a network via a user plane approach. At 302, the remote WTRU may send a ProSe Remote User Key Request (e.g., on the user plane) to a ProSe Key Management Function (PKMF) associated with the remote WTRU. At 304, the remote WTRU may receive a response to the ProSe Remote User Key Request. For example, the response may include a 5GPRUK / 5GPRUK ID (e.g., a new 5GPRUK / 5GPRUK ID) from the PKMF associated with the remote WTRU on the user plane. At 306, the remote WTRU and the WTRU-network relay may perform a discovery procedure. At 308, the remote WTRU may send a DCR message (e.g., that includes information associated with the remote WTRU and / or that may be used to authenticate the remote WTRU) to the WTRU-network repeater. For example, the DCR message may include one or more of the SUCI (e.g., associated with the remote WTRU), a key identifier (e.g., a 5GPRUUK ID associated with the remote WTRU), and / or one or more other parameters (e.g., an RSC, a nonce associated with the remote WTRU).

[0092] At 310, the WTRU-network relay may send a relay key request message to a PKMF associated with the WTRU-network relay. The relay key request may include one or more of the SUCI, the 5GPRUK ID, and / or other parameters (e.g., the RSC, KNRP, etc. as described herein). At 312, the PKMF associated with the WTRU-network relay may forward the relay key request message to the PKMF associated with the remote WTRU. At 314, the GPI and / or AV for the WTRU may be sent from the UDM / BSF / HSS of the remote WTRU to the PKMF of the remote WTRU. At 316, the WTRU-network relay may receive a response message. The response message may include the new 5GPRUK ID. For example, if the SUCI was included in the relay key request message, the WTRU-network relay may receive the response message including the new 5GPRUK ID. The response message received by the WTRU-network relay may additionally or alternatively include ProSe key data from its PKMF (e.g., may be forwarded from a PKMF associated with the remote WTRU). At 318, the PKMF of the WTRU-network relay may send (e.g., forward) the response message to the WTRU-network relay.

[0093] As shown in FIG. 3B , at 320, the WTRU-network relay may send a Direct Security Mode Command (DSMC) procedure with the remote WTRU, e.g., using the received ProSe key data. At 322, the remote WTRU may verify authorization of the WTRU-network relay. Direct security mode may be completed at 324. Additionally or alternatively, the WTRU-network relay may verify authorization of the remote WTRU at 326. The WTRU-network relay may store the 5GPRUUK ID, e.g., at 328. The WTRU-to-network relay may associate the 5GPRUUK ID with the PC5 link established with the remote WTRU. At 330, the WTRU-network relay may send a Direct Connection Accept (DCA) message to the remote WTRU. The DCA message may be used to complete the PC5 link establishment. As described herein, for example, at 332, the WTRU-network relay may use the 5GPRUUK ID when initiating subsequent procedures 316 (eg, secondary authentication and authorization procedures and / or NSAA).

[0094] A secondary authentication and authorization (A&A) procedure associated with the PDU session may be performed. For example, the secondary A&A procedure associated with the PDU session may be performed via a WTRU-network repeater. Figures 4A and 4B illustrate an example 400 associated with a PDU session secondary A&A procedure performed via a WTRU-network repeater. One or more of the following may apply: As illustrated in Figures 4A and 4B, the session secondary A&A procedure may be performed for a remote WTRU during a remote WTRU reporting procedure. The example illustrated in Figures 4A and 4B supports both control plane security procedures and user plane security procedures.

[0095] 4A and 4B, the remote WTRU and / or WTRU-network relay may establish a PC5 link (e.g., using control plane security procedures and / or user plane security procedures 402 as described herein with respect to FIG. 2 and / or FIG. 3A and FIG. 3B) associated with a key identifier (e.g., 5GPRUK / 5GPRUK ID) exchange. The WTRU-network relay may store the remote WTRU's 5GPRUK ID as described herein. At 404, the remote WTRU and / or WTRU-network relay may perform IP configuration for communications over the PC5 link.

[0096] At 406, the WTRU-network relay may send a remote WTRU report message. The WTRU-network relay may send the remote WTRU report message to the SMF (e.g., via the AMF). For example, the remote WTRU report message may include one or more of a 5GPRUUK ID, a PDU session ID, and / or other parameters.

[0097] At 408, the AMF may send a request message to a network function (e.g., PAnF, UDM, PKMF). The request message may include the 5GPRUK ID. At 410, the AMF may receive a response message from the network function. The response message may include one or more of a key identifier (e.g., the 5GPRUK ID associated with the remote WTRU), a SUPI associated with the remote WTRU, and / or one or more other parameters (e.g., associated with the remote WTRU).

[0098] As illustrated in FIG. 4A , at 412, the AMF may forward the SUPI (e.g., associated with the remote WTRU), the 5GPRUK ID (e.g., associated with the remote WTRU), and / or a report message (e.g., associated with the remote WTRU) to the SMF. Additionally or alternatively, the AMF may identify a network function (NF). For example, the AMF may identify an NF from which to obtain information associated with the remote WTRU (e.g., the SUPI) and / or forward information associated with the WTRU (e.g., the 5GPRUK ID) to the SMF. The SMF may query the identified NF (e.g., providing the 5GPRUK ID of the remote WTRU). For example, in response to receiving this information from the AMF, the SMF may query the identified NF (e.g., providing the 5GPRUK ID associated with the remote WTRU). Querying the identified NF may be to obtain the SUPI associated with the remote WTRU. At 414, the SMF may check DN authentication for the remote WTRU. For example, the SMF may check DN authorization for the remote WTRU using a SUPI associated with the remote WTRU. Additionally or alternatively, the SMF may obtain DN subscription information for the remote WTRU from the UDM. The SMF may determine (e.g., based on information received from the UDM) one or more of whether the DN is authorized for the remote WTRU, whether the DN requests secondary authentication for the remote WTRU, and whether the remote WTRU has valid authentication and / or authorization results (e.g., from a previous authentication procedure). The SMF may initiate remote WTRU secondary authentication by the DN. Based on these determinations, for example, the SMF may initiate remote WTRU secondary authentication by the DN. The SMF may store the WTRU secondary authentication result in the WTRU-network relay context and / or in a UDM associated with the remote WTRU.

[0099] As shown in FIG. 4B , the SMF may send a PDU session authentication command at 416. The PDU session authentication command may be sent to a WTRU-network relay (e.g., a Layer 3 WTRU-network relay). For example, the PDU session authentication command may include a 5GPRUUK ID. The 5GPRUUK ID may be used to identify the remote WTRU to be authenticated. At 418, the Layer 3 WTRU-network relay may send a PC5-S message to the remote WTRU. At 420, the remote WTRU may send a PC5-S response message to the Layer 3 WTRU-network relay. The Layer 3 WTRU-network relay may determine that the PDU session authentication command is for the remote WTRU (e.g., send it via the associated PC5 link based on the 5GPRUUK ID). At 422, the Layer 3 WTRU-network relay may forward the authentication response (e.g., received from the remote WTRU). For example, the following information may be sent to the SMF: For example, the authentication response may include the 5GPRUK ID. At 424, the SMF may initiate remote WTRU authentication with the DN, for example, by sending an extensible authentication protocol (EAP) response / identification information to a data network-authentication authorization and accounting (DN-AAA). The DN-AAA and remote WTRU may exchange authentication messages (e.g., as defined by the associated authentication method). The SMF and Layer 3 WTRU-network relay may exchange authentication messages via NAS, for example, by including the 5GPRUK ID in the NAS message. At 428, the SMF may receive a final authentication result from the DN-AAA. At 426, the SMF may receive the final authentication result when the authentication procedure is completed. At 430, the SMF may store the authentication result in the WTRU-network relay context and / or in a UDM associated with the remote WTRU.

[0100] At 432, the SMF may send a remote WTRU report response message. The report response message may include the 5GPRUUK ID and / or the authentication and authorization result. Additionally or alternatively, the 5GPRUUK ID and / or the authentication and authorization result may be sent to the Layer 3 WTRU-network relay. The Layer 3 WTRU-network relay may provide the remote WTRU access to the PDU session (e.g., based on the authentication and authorization result in the remote WTRU report response message). At 434, the Layer 3 WTRU-network relay may store authorization information associated with the remote WTRU and / or forward the authentication and authorization result to the remote WTRU. The Layer 3 WTRU-network relay may proceed with the communication setup procedure. For example, if the PDU session secondary A&A for the remote WTRU is successful, the Layer 3 WTRU-network relay may proceed with the communication setup procedure. The Layer 3 WTRU-network relay may release the PC5 link with the remote WTRU. For example, if the PDU session secondary A&A for the remote WTRU is not successful, the layer 3 WTRU-network relay may release the PC5 link with the remote WTRU.

[0101] The NSSAA procedure may be performed via a Layer 3 WTRU-to-network relay. One or more of the following may apply: Figures 5A and 5B illustrate an example 500 associated with an NSSAA procedure performed via a Layer 3 WTRU-to-network relay. As illustrated in example 500, the NSSAA procedure may be associated with a remote WTRU and / or a remote WTRU reporting procedure. The remote WTRU may be associated with a remote WTRU key identifier (e.g., 5GPRUK / 5GPRUK ID), which may be used (e.g., exchanged) during the NSSAA procedure. The example illustrated in Figures 5A and 5B may be used with control plane security procedures and / or user plane security procedures.

[0102] As shown in FIG. 5A, the remote WTRU and / or WTRU-network relay may establish a PC5 link 500 (e.g., using control plane security procedures and / or user plane security procedures, e.g., as described herein with respect to FIGS. 2 and 3). As described herein, the Layer 3 WTRU-network relay may store a 5GPRUUK ID associated with the remote WTRU. At 504, the remote WTRU and / or WTRU-network relay may perform IP configuration for PC5 link communications.

[0103] At 506, the WTRU-network relay may send a remote WTRU report message to the SMF (e.g., via the AMF). For example, the remote WTRU report message may include one or more of a key identifier (e.g., a 5GPRUUK ID associated with the remote WTRU), a PDU session ID (e.g., associated with the remote WTRU), and / or other parameters (e.g., remote WTRU information, procedure transaction ID (PTI) associated with the remote WTRU).

[0104] At 508, the AMF may send a request (e.g., a Prose Acquisition Request) to an NF (e.g., a PAnF, a UDM, a PKMF). The request sent at 508 may include, for example, a key identifier (e.g., a 5GPRUK ID). At 510, the AMF may receive a response to the request message (e.g., a Prose Acquisition Response) from the NF. For example, the response received from the NF may include one or more of a key identifier (e.g., a 5GPRUK ID associated with the remote WTRU), a SUPI associated with the remote WTRU, and / or one or more other parameters (e.g., an RSC associated with the remote WTRU). At 512, the AMF may check S-NSSAI authorization for the remote WTRU (e.g., using the remote WTRU's SUPI and S-NSSAI information). For example, the AMF may obtain S-NSSAI information from the WTRU-network relay PDU session context (e.g., using the PDU session ID). The AMF may obtain the remote WTRU's S-NSSAI subscription information. The S-NSSAI subscription information of the remote WTRU may be obtained from the UDM. For example, the AMF may determine (e.g., based on the information received from the UDM) one or more of the following: whether the S-NSSAI is authorized, whether the S-NSSAI requires an NSSAA for the remote WTRU, and / or whether the remote WTRU has valid authentication and authorization results (e.g., from a previous NSSAA procedure). The AMF may initiate an NSSAA for the remote WTRU. For example, based on these determinations, the AMF may initiate an NSSAA for the remote WTRU. The AMF may forward a SUPI associated with the remote WTRU and / or a report message associated with the remote WTRU to the SMF.

[0105] As illustrated in FIG. 5B, at 514, the AMF may send a network slice-specific authentication command to the Layer 3 WTRU-network relay. The network slice-specific authentication command may include a key identifier (e.g., a 5GPRUK ID). For example, the key identifier (e.g., a 5GPRUK ID) may be used to identify / authenticate the remote WTRU to be authenticated. For example, because the Layer 3 WTRU-network relay (e.g., a relay WTRU) may be communicating with multiple remote WTRUs, the Layer 3 WTRU-network relay may determine that the request is associated with the remote WTRU based on the key identifier (e.g., a 5GPRUK ID). At 516, the Layer 3 WTRU-network relay may send the request over a PC5 link associated with the remote WTRU, for example, based on the key identifier. At 518, the remote WTRU may send an authentication response to the Layer 3 WTRU-network relay. At 520, the Layer 3 WTRU-network relay may send the authentication response from the remote WTRU. In some examples, the WTRU-network relay may forward an authentication response from the remote WTRU. The authentication response may be forwarded to the SMF. For example, the authentication response may include a 5GPRUUK ID associated with the remote WTRU. The SMF may initiate an NSSAA procedure for the remote WTRU, for example, by sending an EAP response / identity to an authentication, authorization, and accounting-server (AAA-S) at 522. The AAA-S and the remote WTRU may exchange authentication messages (e.g., as defined by the associated authentication method) at 524. The AMF and the Layer 3 WTRU-network relay may exchange authentication messages via the NAS. For example, the AMF and the Layer 3 WTRU-network relay may exchange authentication messages via the NAS by including the 5GPRUUK ID in the NAS message. At 526, the AMF may receive the authentication result from the AAA-S (e.g., when the authentication procedure is complete).At 528, the AMF may store the authentication result in a context associated with the WTRU-network relay (e.g., using an associated key identifier) ​​and / or in a UDM associated with the remote WTRU. At 530, the AMF may send an authentication result message to the Layer 3 WTRU-network relay. For example, the authentication result message may include the 5GPRUUK ID and / or authorization information (e.g., whether the S-NSSAI is authorized). The Layer 3 WTRU-network relay may forward the authentication and / or authorization result to the remote WTRU.

[0106] The AMF may proceed with the remote WTRU reporting procedure. At 534, for example, the AMF may proceed with the remote WTRU reporting procedure by forwarding a SUPI and / or a remote WTRU report message associated with the remote WTRU to the SMF. The AMF may include an indication of whether the remote WTRU has been successfully authenticated and / or authorized for the S-NSSAI associated with the PDU session. The indication of whether the remote WTRU has been successfully authenticated and / or authorized for the S-NSSAI associated with the PDU session may be included in the message forwarded to the SMF.

[0107] At 536, the SMF may send a remote WTRU report response message to the WTRU-network relay. For example, the remote WTRU report response message may include the 5GPRUUK ID and / or the authentication and authorization result.

[0108] At 538, the Layer 3 WTRU-network relay may provide the remote WTRU with access to the PDU session (e.g., based on the authentication and authorization result included in the remote WTRU report response message). The Layer 3 WTRU-network relay may store authorization information for the remote WTRU. For example, if the response message indicates that authentication and authorization were successful, the Layer 3 WTRU-network relay may store authorization information for the remote WTRU. The Layer 3 WTRU-network relay may release the PC5 link with the remote. For example, if the response message indicates that authentication and authorization were not successful, the Layer 3 WTRU-network relay may release the PC5 link with the remote.

Claims

1. a first wireless transmit / receive unit (WTRU), receiving, from a second WTRU, a key identifier associated with the second WTRU, the first WTRU being configured as a WTRU-to-network relay for the second WTRU, the key identifier being received during a key request procedure performed by the first WTRU on behalf of the second WTRU; storing the key identifier associated with the second WTRU; sending a remote WTRU report message to a session management function (SMF) to initiate a secondary authentication procedure on behalf of the second WTRU, the remote WTRU report message including the key identifier; receiving an authentication message including the key identifier; transmitting the authentication message to the second WTRU based on the authentication message including the key identifier; receiving an authentication response message from the second WTRU, the authentication response message including the key identifier; receiving a response to the remote WTRU report message from the SMF, the response including the key identifier and indicating a result of the secondary authentication procedure; a first WTRU comprising a processor configured to execute:

2. The first WTRU of claim 1 , wherein the key identifier comprises a 5G ProSe Remote User Key (5GPRUK) Identifier (ID).

3. The first WTRU of claim 1 , wherein the response to the remote WTRU report message comprises a remote WTRU report response message.

4. The first WTRU of claim 3 , wherein the processor is further configured to send an indication that the second WTRU is authorized to communicate over a link or release the link based on the remote WTRU report response message.

5. The first WTRU of claim 4 , wherein the link is a PC5 link.

6. The first WTRU of claim 1, wherein an Access and Mobility Function (AMF) sends the key identifier to the SMF.

7. 2. The first WTRU of claim 1, wherein data network (DN) information is obtained from the second WTRU, and the secondary authentication procedure is triggered based on one or more of the following determinations: that the DN is authorized, that the DN is requesting secondary authentication, and a previous authentication.

8. The first WTRU of claim 1 , wherein the processor is further configured to release a link with the second WTRU if the result of the secondary authentication procedure is not successful.

9. 1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: receiving, from a second WTRU, a key identifier associated with the second WTRU, the first WTRU being configured as a WTRU-to-network relay for the second WTRU, the key identifier being received during a key request procedure performed by the first WTRU on behalf of the second WTRU; storing the key identifier associated with the second WTRU; sending a remote WTRU report message to a session management function (SMF) to initiate a secondary authentication procedure on behalf of the second WTRU, the remote WTRU report message including the key identifier; receiving an authentication message including the key identifier; transmitting the authentication message to the second WTRU based on the authentication message including the key identifier; receiving an authentication response message from the second WTRU, the authentication response message including the key identifier; receiving a response to the remote WTRU report message from the SMF, the response including the key identifier and indicating a result of the secondary authentication procedure; A method comprising:

10. 10. The method of claim 9, wherein the key identifier comprises a 5G ProSe Remote User Key (5GPRUK) Identifier (ID).

11. The method of claim 9 , wherein the response to the remote WTRU report message comprises a remote WTRU report response message.

12. 12. The method of claim 11, further comprising either sending an indication that the second WTRU is authorized to communicate over a link based on the remote WTRU report response message, or releasing the link.

13. The method of claim 12 , wherein the link is a PC5 link.

14. The method of claim 10, wherein an Access and Mobility Function (AMF) sends the key identifier to the SMF.

15. 12. The method of claim 11, wherein data network (DN) information is obtained from the second WTRU, and the secondary authentication procedure is triggered based on one or more determinations of a DN being authorized, a DN requesting secondary authentication, and a previous authentication.

16. 1. A method performed by a base station, comprising: receiving a remote WTRU report message from a first wireless transmit / receive unit (WTRU), the remote WTRU report message indicating a key identifier associated with a second WTRU, the first WTRU being configured as a WTRU-network relay for the second WTRU, the key identifier being received during a key request procedure performed by the first WTRU on behalf of the second WTRU, the key identifier being received to initiate a secondary authentication procedure on behalf of the second WTRU; sending a request message to a ProSe Key Management Function (PKMF), the request message including the key identifier; and receiving a response message from the PKMF, the response message including a second identifier associated with the second WTRU; and sending a response to the remote WTRU report message to the first WTRU, the response including the key identifier and indicating a result of the secondary authentication procedure; A method comprising:

17. 17. The method of claim 16, wherein the key identifier comprises a 5G ProSe Remote User Key (5GPRUK) Identifier (ID).

18. The method of claim 16 , wherein the response to the remote WTRU report message comprises a remote WTRU report response message.

Images