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

Abstract

This provides secondary and slice-specific authentication and authorization methods for PDU sessions. [Solution] A wireless transceiver unit (WTRU) may be configured to receive a key identifier. The key identifier may be associated with a 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-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 a 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 a network function.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims the benefit of U.S. Patent Provisional Application No. 63 / 323,760, filed on March 25, 2022, which is hereby incorporated by reference in its entirety.

Background Art

[0002] Some security procedures on the control plane are specified for 5G proximity services (ProSe) related to the authentication of remote wireless transmit / receive units (WTRUs) and relay WTRUs and PC5 link security. For example, the authentication of remote WTRUs and relay WTRUs and PC5 link security can be based on remote WTRU authentication (e.g., by the network via a 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 - network repeater 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 executed on behalf of the second WTRU by the first 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 a second WTRU. The first WTRU may be configured to receive an authentication message (e.g., from a network function). The authentication message may include a key identifier that can be used to determine that the authentication message is associated with a second WTRU. Additionally or alternatively, the first WTRU may be configured to send an authentication message to a second WTRU. For example, the first WTRU may be configured to send an authentication message to a second WTRU based on an authentication message containing a key identifier. The network function can 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, SMF may send the key identifier to the ProSe Anchor Function (PAnF) or the 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 a network function. The response may include a key identifier. Additionally or alternatively, the response may indicate the result of a secondary authentication procedure. The key identifier may be sent to the network function in a remote WTRU reporting message. The response may include a remote WTRU reporting response message. The first WTRU may be configured to send an instruction that the second WTRU is authorized to communicate over the link or release the link. For example, the first WTRU may be configured to send an instruction that the second WTRU is authorized to communicate over the link or release the link based on a remote WTRU reporting response message. The link may be a PC5 link.

[0006] A 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. A base station may be configured to send an authentication message. For example, a base station may be configured to send an authentication message to a second WTRU. The authentication message may include a key identifier. The authentication message may be sent to the second WTRU via the first WTRU. For example, an authentication message may be sent to the second WTRU via the first WTRU based on an authentication message including a key identifier. A base station may be configured to send a response to the first WTRU. The response may include a key identifier. Additionally or alternatively, the response may indicate the result of a secondary authentication procedure. A WTRU may release its link to a second WTRU based on the results of a secondary authentication procedure. Data network (DN) information may be obtained from the second WTRU. For example, secondary authentication may be initiated based on the determination that the DN is authorized, that the DN is requesting secondary authentication, and one or more of the previous authentication determinations. [Brief explanation of the drawing]

[0007] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C]This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This paper illustrates 5GPRUK / 5GPRUK ID exchange and related examples between a remote WTRU, a relay WTRU, and a network using a control plane. [Figure 3A] This document illustrates the exchange of 5GPRUK / 5GPRUK IDs as key identifiers between a remote WTRU, a WTRU-network repeater, and a network using a user plane. [Figure 3B] This document illustrates the exchange of 5GPRUK / 5GPRUK IDs as key identifiers between a remote WTRU, a WTRU-network repeater, and a network using a user plane. [Figure 4A] This document illustrates the protocol data unit (PDU) session secondary authentication and authorization (A&A) procedures and related examples performed via a Layer 3 WTRU network relay. [Figure 4B] This document illustrates the protocol data unit (PDU) session secondary authentication and authorization (A&A) procedures and related examples performed via a Layer 3 WTRU network relay. [Figure 5A] This document illustrates network slice-specific authentication and / or authorization (NSSAA) procedures and related examples performed via Layer 3 WTRUs (Write-Time Units) network repeaters. [Figure 5B] This document illustrates network slice-specific authentication and / or authorization (NSSAA) procedures and related examples performed via Layer 3 WTRUs (Write-Time Units) network repeaters. [Modes for carrying out the invention]

[0008] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0009] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating on commercial radio networks and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as WTRU for compatibility purposes.

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

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

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

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

[0014] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish a radio 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, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which may establish a radio interface 116 using New Radio (NR).

[0016] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using a dual connectivity (DC) mechanism. Thus, the radio interface used by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to multiple types of base stations (e.g., eNB and gNB).

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

[0018] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

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

[0020] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices, and these networks and devices 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 can include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 can include another CN connected to one or more RANs that can use the same RAT as the RAN104 / 113 or a different RAT.

[0021] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include multimode functionality (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 1A can be configured to communicate with a base station 114a that can employ a cellular-based wireless technology and a base station 114b that can employ IEEE802 wireless technology.

[0022] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0023] The processor 118 could be a general-purpose processor, a dedicated 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 functions that enable WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B depicts the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit or receive signals to and from a base station (e.g., base station 114a) via the radio 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 optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0025] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, 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 radio signals via the radio interface 116.

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

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

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

[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 determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the radio interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0030] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, 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, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0031] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals associated with some or all of the signals (e.g., for specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception).

[0032] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via radio interface 116. RAN104 may also communicate with CN106.

[0033] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the radio interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0034] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0035] The CN106 shown in Figure 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 aforementioned elements is depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0036] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating transmission lines, and selecting a specific service-providing gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0037] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as mooring the user plane during e-node B handovers, initiating paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0038] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0039] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in some typical embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

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

[0042] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with other types of wired / wireless networks that carry traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA and destined for an outside BSS destination may be sent to the AP so that it is delivered to its respective destination. Traffic between STAs within the BSS may, for example, be sent via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) 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 Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

[0044] High-throughput (HT) STAs may use a 40 MHz wide channel 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] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining multiple adjacent 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. In the receiver of a receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to Medium Access Control (MAC).

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

[0047] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (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) settings may depend on the status of the primary channel. For example, if the primary channel is operational due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered operational, even though a large portion of the frequency band remains idle and could potentially be 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] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 employs NR radio technology and can communicate with WTRU102a, 102b, and 102c via radio interface 116. RAN113 can also communicate with CN115.

[0050] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via radio interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals to and from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple elemental carriers to WTRU102a (not shown). A subset of these elemental carriers may be on the unlicensed spectrum, while the remaining elemental carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0051] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0052] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bandwidth. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement a DC mechanism that communicates substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0054] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is depicted as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0055] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 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, and services for machine type communication (MTC) access. AMF162 may provide control plane functionality for exchange between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

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

[0059] In view of Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a and b, e-nodes-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a and b, SMF183a and b, DN185a and b, and / or any other devices described herein, may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or 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 network to test other devices in a communications 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 network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using radio communication.

[0061] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), 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 (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0062] Secondary and slice-specific authentication and authorization for Protocol Data Unit (PDU) sessions may be performed, for example, using a Layer 3 WTRU-Network Repeater. The remote WTRU and the 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 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, for example, from the network or from the remote WTRU during a security procedure. The relay WTRU may send a remote WTRU reporting message to a Layer 3 WTRU-Network Repeater (e.g., to an Access and Mobility Function (AMF) associated with the Layer 3 WTRU-Network Repeater). In some scenarios, the relay WTRU may send a remote WTRU reporting message to the network after the PC5 link with the remote WTRU has been established. For example, the remote WTRU reporting 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] A Layer 3 WTRU-network repeater may determine whether a remote WTRU is authorized and / or authenticated to communicate over an established PC5 link (e.g., over a network function). For example, an AMF associated with the repeater may obtain a second identifier associated with the remote WTRU (e.g., a subscription permanent identifier (SUPI)) based on the remote WTRU's key identifier. The AMF may transmit 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 repeater. Alternatively or additionally, an SMF associated with the repeater may obtain a second identifier associated with the remote WTRU (e.g., a subscription permanent identifier (SUPI)) based on the remote WTRU's key identifier. The SMF may send the security key identifier associated with the remote WTRU to a PAnF or PKMF and / or receive the second identifier associated with the remote WTRU in response. The SMF may determine whether a remote WTRU is authorized and / or authenticated to communicate over an established PC5 link. For example, the SMF may determine whether a remote WTRU is authorized and / or authenticated to communicate over an 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 the remote WTRU's key identifier to the WTRU-network repeater. The SMF may transmit the results of the authentication and authorization procedure to the WTRU-network repeater. Additionally or alternatively, the SMF may transmit the remote WTRU's security key identifier to the WTRU-network repeater.If a remote WTRU is authorized and / or certified to communicate over the PC5 link, the Layer 3 WTRU-network repeater may send an instruction to the repeater WTRU that the remote WTRU is authorized and / or certified to communicate over the established PC5 link. The remote WTRU may then communicate over the established PC5 link. In some scenarios, if the remote WTRU is not authorized or certified to communicate over the PC5 link, the Layer 3 WTRU-network repeater may release the established PC5 link.

[0064] A first radio 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 point to a key and / or be generated as random bits. For example, the key identifier may be used to determine an identifier associated with a remote WTRU, such as the SUPI of a remote WTRU (e.g., by a lookup table maintained by the network and / or repeaters). The key identifier may be used and / or transmitted over the network in place of the SUPI of a remote WTRU, for example, to maintain security across the network 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-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 a 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 a key identifier. 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 an authentication message to the second WTRU based on an authentication message containing a key identifier. Network functions can 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 a network function. The response may include a key identifier. Additionally or alternatively, the response may indicate the result of a secondary authentication procedure. The key identifier may be sent to the network function in a remote WTRU reporting message. The response may include a remote WTRU reporting response message. The first WTRU may be configured to send an instruction that the second WTRU is authorized to communicate over the link or release the link. For example, the first WTRU may be configured to send an instruction that the second WTRU is authorized to communicate over the link or release the link based on a remote WTRU reporting response message. The link may be a PC5 link.

[0067] A 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. A base station may be configured to send an authentication message. For example, a base station may be configured to send an authentication message to a second WTRU. The authentication message may include a key identifier. The authentication message may be sent to the second WTRU via the first WTRU. For example, an authentication message may be sent to the second WTRU via the first WTRU based on an authentication message including a key identifier. A base station may be configured to send a response to the first WTRU. The response may include a key identifier. Additionally or alternatively, the response may indicate the result of a secondary authentication procedure. A WTRU may release its link to a second WTRU based on the results of a secondary authentication procedure. Distinguished name (DN) information may be retrieved from the second WTRU. For example, secondary authentication may be initiated based on the determination that the DN is authorized, that the DN is requesting secondary authentication, and one or more of the previous authentication determinations.

[0068] Security procedures associated with 5G Prose communications may be implemented. For example, security procedures associated with 5G Prose communications may be implemented via 5G Prose (e.g., a 5G Prose Layer 3 WTRU-network repeater). Security procedures may also be implemented, 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 the following: authorization of remote WTRUs (e.g., WTRUs outside coverage), authorization of transit WTRUs (e.g., WRUs within coverage), and PC5 link security. For example, authorization of remote WTRUs and transit WTRUs and / or PC5 link security may be based on remote WTRU authentication (e.g., via the transit WTRU during PC5 link establishment by the network).

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

[0071] A remote WTRU may provide a key identifier (e.g., a 5GPRUK ID) via a DCR. In certain embodiments, a remote WTRU may provide a 5GPRUK ID via a DCR (e.g., if available) instead of a SUCI (e.g., to avoid performing a remote WTRU authentication procedure, as a possible optimization). For example, 5GPRUK may locate and / or retrieve based on the provided 5GPRUK ID.

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

[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, for example, in a key request message, to the PKMF associated with the remote WTRU (for example, via the relay WTRU's PKMF on the user plane). The relay WTRU may receive a shared key. The shared key may be derived from the 5GPRUK received from the remote WTRU's PKMF (for example, via the PKMF associated with the relay WTRU). Based on the shared key, the relay WTRU may establish security for the PC5 link with the remote WTRU.

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

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

[0076] Secondary authentication and / or NSSAA may be performed, for example, using the control plane. For example, certain embodiments support access to DNs. Access to DNs may require secondary authentication (e.g., to S-NSSAI subject to NSSAA). Secondary authentication may be performed via an L3 WTRU-network repeater. In some embodiments, a remote WTRU may provide a SUCI and / or a 5G Globally Unique Temporary ID (GUTI). These SUCIs and / or GUTIs may be provided via DCR messages. For example, a SUCI or 5G-GUTI WTRU may be used by a service delivery network associated with a relay WTRU. For example, a SUCI or 5G-GUTI WTRU may be used by a service delivery network associated with a 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] A remote WTRU may send a SUCI in the DCR. A remote WTRU may send an SCI in the DCR, for example, if the remote WTRU intends to connect for a relay service (RSC) (for example, for the first time). In some scenarios, a remote WTRU may perform authentication with the network. A remote WTRU may be enabled to (re)connect to a relay service (for example, to avoid the potential signaling overhead associated with re-performing the authentication procedure with the network if the (re)connection is authorized from the previous connection).

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

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

[0080] Secondary authentication and / or NSSAA may be performed using the user plane. A remote WTRU may provide access to the DN. The DN may perform secondary authentication and / or S-NSSAI subject to NSSAA. For example, the performance of secondary authentication and / or S-NSSAI may be subject to NSSAA via an L3 WTRU-network repeater (e.g., when the 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 PKMF (e.g., using a user plane connection). These security procedures do not require the use of network-based remote WTRU authentication (e.g., as in the case of control plane-based methods). Additionally or alternatively, some security procedures may not define a mechanism that allows a service delivery network associated with a relay WTRU to access subscription information associated with the remote WTRU, and / or a mechanism that performs remote WTRU PDU session secondary authentication and / or NSSAA via an L3 repeater (e.g., without an N3IWF). The techniques described herein may enable access to a DN that performs secondary authentication (e.g., via a relay). For example, secondary authentication may be performed when using security procedures on the user plane. Some of the techniques described herein may enable access to an S-NSSAI (e.g., via a relay). Access may be subject to NSSAA against 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 DNs requiring secondary authentication and / or access to S-NSSAI. For example, secondary authentication and / or access to S-NSSAI may be subject to NSSAA during PC5 link establishment. The Layer 3 WTRU-network relay may receive and / or store 5GPRUK IDs associated with remote WTRUs and / or networks. For example, the Layer 3 WTRU-network relay may receive and / or store 5GPRUK IDs associated with remote WTRUs and / or networks during PC5 link establishment. The relay WTRU may transmit 5GPRUK IDs, for example, in remote WTRU reporting messages. The Layer 3 WTRU-network relay may exchange one or more authentication messages with the network for the remote WTRU. For example, one or more authentication messages may include 5GPRUK IDs associated with the remote WTRU. The relay WTRU may receive remote WTRU reporting response messages. For example, the report response may include a 5GPRUK ID. Additionally or alternatively, the report response may include the results of authentication and / or authorization for the remote WTRU. The relay WTRU may provide access to the PDU session with the remote WTRU (for example, based on the results in the response message).

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

[0083] NSSAA procedures and associated Access and Mobility Functions (AMF) may be provided. One or more of the following may apply: The AMF may initiate an NSSAA for a remote WTRU authentication procedure (e.g., via a relay). For example, initiating an NSSAA for a remote WTRU authentication procedure may be in response to receiving a remote WTRU reporting message. The remote WTRU reporting message may include a 5GPRUK ID associated with the remote WTRU. The AMF may retrieve a SUPI associated with the remote WTRU. For example, retrieving a SUPI associated with a remote WTRU may be based on a 5GPRUK 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, a slice-specific authentication message may include a 5GPRUK ID associated with the remote WTRU. The 5GPRUK ID associated with the remote WTRU can be used for remote WTRU authentication. The AMF may store authentication results (e.g., final authentication results) within the relay context / UDM. The AMF may send (e.g., forward) remote WTRU reporting messages to, for example, the service-providing SMF. The remote WTRU reporting messages may include instructions from the NSSAA to the SMF associated with the remote WTRU results.

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

[0085] A remote WTRU may be identified by the service-providing network of the relay WTRU. For example, a remote WTRU may be identified by the service-providing network associated with the relay WTRU based on its 5GPRUK ID. A remote WTRU (e.g., by the relay WTRU and / or the service-providing network of the relay WTRU) may be identified based on its 5GPRUK ID. For example, a relay WTRU may receive a 5GPRUK ID from a remote WTRU in a DCR message. Additionally or alternatively, a relay WTRU may receive a 5GPRUK ID from the network while establishing a PC5 link. A 5GPRUK ID may be generated by a network function. For example, if a relay WTRU receives a 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). A 5GPRUK ID may be stored by the network. For example, a 5GPRUK ID may be stored by the network along 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 the remote WTRU authentication procedure (e.g., by the Authentication Function (AUSF) associated with the remote WTRU) as described herein. For example, if a security procedure is used on the control plane, the 5GPRUK / 5GPRUK ID may be generated as part of the remote WTRU authentication procedure (e.g., by the AUSF associated with the remote WTRU) as described herein. The 5GPRUK / 5GPRUK ID may be generated on the user plane as part of the key request procedure (e.g., before PC5 link establishment) and / or during PC5 link establishment (e.g., using the GBA push mechanism) (e.g., by the PKMF associated with the remote WTRU) as described herein.When security procedures are used on the user plane, the 5GPRUK / 5GPRUK ID may be generated as part of the key request procedure on the user plane (e.g., before PC5 link establishment) and / or during PC5 link establishment (e.g., using the GBA push mechanism) (e.g., by PKMF associated with the remote WTRU), as described herein. The relay may store the 5GPRUK ID. The relay may associate the 5GPRUK ID with the PC5 link established with the remote WTRU. The relay may then use the 5GPRUK ID (e.g., with remote WTRU secondary authentication and / or NSSAA procedures).

[0086] One or more security procedures may be performed on the control plane. Figure 2 shows an example 200 involving the exchange of key identifiers (e.g., 5GPRUK / 5GPRUK ID) between a remote WTRU, a relay WTRU, and the network, using the control plane (e.g., a control plane technique). As illustrated in Figure 2, the remote WTRU and / or relay WTRU may perform a discovery procedure 202. In 204, the remote WTRU may send a Direct Communication Request (DCR) message to the relay WTRU. The DCR may include the SUCI and / or 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). In 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., SUCI, 5GPRUK ID, RSC, and / or nonce).

[0087] As shown in Figure 2, the AMF may determine whether the relay WTRU is authorized to provide relay services. In 208, the AMF may initiate the remote WTRU authentication procedure using the AUSF associated with the remote WTRU. For example, if a SUCI is provided in the relay key request, the AMF may initiate the remote WTRU authentication procedure using the AUSF associated with the remote WTRU. Additionally or alternatively, in 210, the AMF does not have to initiate the remote WTRU authentication procedure using the AUSF associated with the remote WTRU. For example, if a 5GPRUK ID is provided in the relay key request, the AMF does not have to initiate the remote WTRU authentication procedure using the 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, in 216. The AUSF associated with the remote WTRU may store the resulting 5GPRUK / 5GPRUK ID within its network functions (e.g., PAnF, UDM) and / or transmit 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 within its network functions (e.g., PAnF, UDM) and / or transmit the 5GPRUK ID to the AMF.

[0088] As illustrated in Figure 2, at 212, the AMF may send a request message to the 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] In 220, the WTRU-network repeater may perform a security procedure. The security procedure may be a direct security mode command (DSMC). Alternatively or additionally, the remote WTRU may use ProSe key data received via a relay key response message. The direct security procedure may be completed, for example, in 224. In 226, the WTRU-network repeater may store the 5GPRUK ID (received, for example, as described herein) and / or associate the 5GPRUK ID with the PC5 link established with the remote WTRU. In 228, the WTRU-network repeater 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 repeater may use the 5GPRUK ID when initiating subsequent procedures (e.g., secondary authentication and authorization procedures and / or NSAA), for example, in 230.

[0090] Figures 3A–3B, 4A–4B, and 5A–5B illustrate exemplary authentication procedures associated with WTRU-network repeaters and remote WTRUs. For example, PDU session secondary and slice-specific authentication and authorization for a WTRU-network repeater may be performed using Figures 3A–3B, 4A–4B, and 5A–5B. Figures 3A–3B, 4A–4B, and 5A–5B illustrate an example where 5GPRUK ID is used as the key identifier, but it should be understood that the techniques described herein are not limited to this example. For example, other suitable identifiers that can be used to verify and / or determine the identity of a remote WTRU may be used similarly or alternatively. Similarly, the examples illustrated in Figures 3A–3B, 4A–4B, and 5A–5B envision specific network functions (e.g., SMF, AMF), but any suitable network function may be used similarly or alternatively. Similarly, while the examples illustrated in Figures 3A-3B, 4A-4B, and 5A-5B illustrate a WTRU-network repeater communicating with a single remote WTRU, it should be understood that these techniques are equally applicable when a WTRU-network repeater communicates with multiple remote WTRUs, and / or when a remote WTRU communicates with multiple WTRU-network repeaters.

[0091] One or more security procedures may be performed on the user plane. Figures 3A and 3B illustrate Example 300 associated with the exchange of key identifiers (e.g., 5GPRUK / 5GPRUK ID) between a remote WTRU, a WTRU-network repeater, and the network via the user plane method. In 302, the remote WTRU may send a ProSe remote user key request (e.g., on the user plane) to the ProSe key management function (PKMF) associated with the remote WTRU. In 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. In 306, the remote WTRU and the WTRU-network repeater may perform a discovery procedure. In 308, a remote WTRU may send a DCR message to a WTRU-network relay (which may include, for example, information associated with the remote WTRU and / or be used to authenticate the remote WTRU). For example, the DCR message may include one or more of the following: (for example, associated with the remote WTRU) SUCI, key identifier (for example, a 5GPRUK ID associated with the remote WTRU), and / or one or more other parameters (for example, an RSC, nonce associated with the remote WTRU).

[0092] In 310, the WTRU-network repeater may send a relay key request message to the PKMF associated with the WTRU-network repeater. The relay key request may include one or more of the following parameters: SUCI, 5GPRUK ID, and / or other parameters (e.g., RSC, KNRP, etc., as described herein). In 312, the PKMF associated with the WTRU-network repeater may forward the relay key request message to the PKMF associated with the remote WTRU. In 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. In 316, the WTRU-network repeater may receive a response message. The response message may include a new 5GPRUK ID. For example, if the relay key request message included SUCI, the WTRU-network repeater may receive a response message including a new 5GPRUK ID. The response message received by the WTRU-network relay may additionally or alternatively include ProSe key data from its PKMF (for example, it may be forwarded from the PKMF associated with the remote WTRU). In 318, the WTRU-network relay's PKMF may send (for example, forward) the response message to the WTRU-network relay.

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

[0094] Secondary authentication and authorization (A&A) procedures may be performed in association with a PDU session. For example, a secondary A&A procedure associated with a PDU session may be performed via a WTRU-network relay. Figures 4A and 4B illustrate Example 400 associated with a PDU session secondary A&A procedure performed via a WTRU-network relay. One or more of the following may apply: As illustrated in Figures 4A and 4B, a session secondary A&A procedure may be performed against 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] As shown in Figures 4A and 4B, a remote WTRU and / or WTRU-network repeater may establish a PC5 link associated with key identifier (e.g., 5GPRUK / 5GPRUK ID) exchange (for example, using control plane security procedures and / or user plane security procedures 402 as described herein with respect to Figure 2 and / or Figures 3A and 3B). The WTRU-network repeater may store the 5GPRUK ID of the remote WTRU as described herein. In 404, the remote WTRU and / or WTRU-network repeater may perform IP configuration for communication over the PC5 link.

[0096] In 406, the WTRU-network repeater may transmit a remote WTRU report message. The WTRU-network repeater may transmit a remote WTRU report message to the SMF (for example, via the AMF). For example, the remote WTRU report message may include one or more of the 5GPRUK ID, PDU session ID, and / or other parameters.

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

[0098] As illustrated in Figure 4A, in 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 reporting 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 that retrieves information associated with the remote WTRU (e.g., the SUPI) and / or forward the information associated with the WTRU (e.g., the 5GPRUK ID) to the SMF. The SMF may query the identified NF (e.g., by providing the GPRUK ID of the remote WTRU 5). For example, in response to receiving this information from the AMF, the SMF may query the identified NF (e.g., by providing the 5GPRUK ID associated with the remote WTRU). Querying the identified NF may be to obtain the SUPI associated with the remote WTRU. In 414, the SMF may check DN authentication for the remote WTRU. For example, the SMF may use the SUPI associated with the remote WTRU to check for DN authorization for the remote WTRU. Additionally or alternatively, the SMF may obtain DN enrollment information for the remote WTRU from the UDM. The SMF may determine (for example, based on the information received from the UDM) 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 a valid authentication and / or authorization result (for example, from a previous authentication procedure). The SMF may initiate secondary authentication of the remote WTRU by the DN. Based on these determinations, for example, the SMF may initiate secondary authentication of the remote WTRU by the DN. The SMF may store the WTRU secondary authentication result in the WTRU-network relay context and / or in the UDM associated with the remote WTRU.

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

[0100] In 432, the SMF may send a remote WTRU report response message. The report response message may include the 5GPRUK ID and / or the authentication and authorization results. Additionally or alternatively, the 5GPRUK ID and / or the authentication and authorization results may be sent to a Layer 3 WTRU-network repeater. The Layer 3 WTRU-network repeater may provide the remote WTRU with access to the PDU session (for example, based on the authentication and authorization results in the remote WTRU report response message). In 434, the Layer 3 WTRU-network repeater may store authorization information associated with the remote WTRU and / or forward the authentication and authorization results to the remote WTRU. The Layer 3 WTRU-network repeater 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 repeater may proceed with the communication setup procedure. The Layer 3 WTRU-network repeater may release the PC5 link with the remote WTRU. For example, if secondary A&A for a remote WTRU session fails, the Layer 3 WTRU-network repeater may release the PC5 link with the remote WTRU.

[0101] NSSAA procedures can be performed via a Layer 3 WTRU-network repeater. One or more of the following may apply. Figures 5A and 5B illustrate Example 500, which involves an NSSAA procedure performed via a Layer 3 WTRU-network repeater. As illustrated in Example 500, an NSSAA procedure may be associated with a remote WTRU and / or a remote WTRU reporting procedure. A 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 examples illustrated in Figures 5A and 5B may be used in conjunction with control plane security procedures and / or user plane security procedures.

[0102] As shown in Figure 5A, the remote WTRU and / or WTRU-network repeater can establish a PC5 link (for example, using control plane security procedures and / or user plane security procedures, as described herein with respect to Figures 2 and 3). As described herein, the Layer 3 WTRU-network repeater can store the 5GPRUK ID associated with the remote WTRU. In 504, the remote WTRU and / or WTRU-network repeater can perform IP configuration for PC5 link communication.

[0103] In 506, the WTRU-network relay may send a remote WTRU reporting message to the SMF (e.g., via the AMF). For example, the remote WTRU reporting message may include one or more of the following: a key identifier (e.g., a 5GPRUK 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, a procedure transaction ID (PTI) associated with the remote WTRU).

[0104] In 508, the AMF may send a request (e.g., a Prose retrieval request) to the NF (e.g., PAnF, UDM, PKMF). The request sent in 508 may include, for example, a key identifier (e.g., a 5GPRUK ID). In 510, the AMF may receive a response from the NF to the request message (e.g., a Prose retrieval response). For example, the response received from the NF may include one or more of the following: 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). In 512, the AMF may check for S-NSSAI authorization for the remote WTRU (e.g., using the SUPI and S-NSSAI information of the remote WTRU). For example, the AMF may obtain S-NSSAI information from the PDU session context of the WTRU-network repeater (e.g., using the PDU session ID). The AMF may obtain S-NSSAI join information for the remote WTRU. S-NSSAI enrollment information for a remote WTRU can be obtained from the UDM. For example, the AMF may determine (based on information received from the UDM, for example) one or more of the following: whether the S-NSSAI is authorized, whether the S-NSSAI requests an NSSAA from the remote WTRU, and / or whether the remote WTRU has valid authentication and authorization results (from a previous NSSAA procedure, for example). The AMF may initiate an NSSAA against the remote WTRU. For example, based on these determinations, the AMF may initiate an NSSAA against the remote WTRU. The AMF may forward the SUPI associated with the remote WTRU and / or the reporting messages associated with the remote WTRU to the SMF.

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

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

[0107] In 536, the SMF may send a remote WTRU report response message to a WTRU-network repeater. For example, the remote WTRU report response message may include the 5GPRUK ID and / or the results of authentication and authorization.

[0108] In 538, the Layer 3 WTRU-network repeater may provide access to the PDU session for a remote WTRU (for example, based on the authentication and authorization results contained in the remote WTRU report response message). The Layer 3 WTRU-network repeater 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 repeater may store authorization information for the remote WTRU. The Layer 3 WTRU-network repeater may release the PC5 link to the remote. For example, if the response message indicates that authentication and authorization were unsuccessful, the Layer 3 WTRU-network repeater may release the PC5 link to the remote.

Claims

1. Network node, Receiving a remote WTRU report message from the relay WTRU that includes the ProSe remote user key (PRUK) identifier (ID) of the remote WTRU, Sending a request message to the network function to obtain the subscription persistence identifier (SUPI) of the remote WTRU, wherein the request message includes the PRUK ID of the remote WTRU. The network function receives a response message including the SUPI of the remote WTRU, wherein the SUPI of the remote WTRU is determined using the PRUK ID of the remote WTRU. A network node with a processor configured to run [the specified program].

2. The network node according to claim 1, wherein the processor is further configured to store the PRUK ID and SUPI of the remote WTRU in the context of the relay WTRU.

3. The network node according to claim 1, wherein the PRUK ID includes a 5G PRUK ID.

4. The network node according to claim 1, wherein the network node is a session management function (SMF), and the network function is a ProSe key management function (PKMF) or a ProSe anchor function (PAnF).

5. The network node according to claim 1, wherein the processor is further configured to send a remote WTRU report response message including the PRUK ID to the relay WTRU.

6. The network node according to claim 5, wherein the remote WTRU report response message indicates one or more authentication results and authorization results.

7. The network node according to claim 1, wherein the processor is configured to check data network authorization for the remote WTRU using the SUPI of the remote WTRU.

8. The network node according to claim 7, wherein the processor is further configured to trigger secondary authentication by the data network of the remote WTRU.

9. The network node according to claim 8, wherein the secondary authentication is triggered based on the determination that the DN is authorized, that the DN is requesting secondary authentication, and one or more of the previous authentication determinations.

10. The network node according to claim 8, wherein the processor is configured to receive authentication response messages associated with the remote WTRU from the relay WTRU.

11. A method performed by network nodes, Receiving a remote WTRU report message from the relay WTRU that includes the ProSe remote user key (PRUK) identifier (ID) of the remote WTRU, Sending a request message to the network function associated with the remote WTRU to obtain the subscription persistence identifier (SUPI) of the remote WTRU, wherein the request message includes the PRUK ID of the remote WTRU. The network function receives a response message including the SUPI of the remote WTRU, wherein the SUPI of the remote WTRU is determined using the PRUK ID of the remote WTRU. A method that includes this.

12. The method according to claim 11, further comprising storing the PRUK ID and SUPI of the remote WTRU in the context of the relay WTRU.

13. The method according to claim 11, wherein the PRUK ID includes a 5G PRUK ID.

14. The method according to claim 11, wherein the network node is a session management function (SMF), and the network function is a ProSe key management function (PKMF) or a ProSe anchor function (PAnF).

15. The method according to claim 11, further comprising sending a remote WTRU report response message including the PRUK ID to the relay WTRU.

16. The method according to claim 15, wherein the remote WTRU report response message indicates one or more authentication results and authorization results.

17. The method according to claim 11, further comprising checking the data network authorization of the remote WTRU using the SUPI of the remote WTRU.

18. The method according to claim 17, further comprising triggering secondary authentication by the data network of the remote WTRU.

19. The method according to claim 18, wherein the secondary authentication is triggered based on the fact that the DN is authorized, that the DN is requesting secondary authentication, and one or more decisions from the previous authentication.

20. The method according to claim 18, further comprising receiving an authentication response message associated with the remote WTRU from the relay WTRU.

Images