Layer 3 authentication and authorization related to wireless transmit / receive units and networks

Abstract

A relay radio transmit / receive unit (WTRU) may receive a direct communication request (DCR) from a remote WTRU requesting a connection service (e.g., connection session parameters such as single network slice selection assistance (S-NSSAI), data network name (DNN), etc.). The relay may determine that the connection session for the service is subject to secondary authentication and authorization (A&A) based on an indication related to the connection session, if already established, and / or an indication related to the DN from a relay proximity service (ProSe) configuration. Based on the determination, the relay may trigger a network-controlled authorization for the remote WTRU. The relay WTRU may send a direct communication accept (DCA) message including the pending secondary A&A and configure a traffic filter associated with the connection (e.g., PC5 link) to discard data traffic from the remote WTRU until the secondary A&A is successfully completed.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 134,783, filed January 7, 2021. This application claims the benefit of U.S. Provisional Patent Application No. 63 / 150,130, filed February 17, 2021, and U.S. Provisional Patent Application No. 63 / 185,748, filed May 7, 2021, the disclosures of which are incorporated herein by reference in their entireties. [Background technology]

[0002] Mobile communications using radio communications continues to evolve. The fifth generation may be referred to as 5G. Previous (traditional) generations of mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Described herein are systems, methods, and means related to link setup (e.g., link release, deauthorization, and reauthentication) with a wireless transmit / receive unit (WTRU) to a network relay using a connection session that is subject to secondary authentication and authorization (A&A). Described herein are systems, methods, and means related to link setup (e.g., link release, deauthorization, and reauthentication) with a relay using single network slice selection assistance (S-NSSAI) that may be subject to network slice specific authentication and authorization (NSSAA).

[0004] A link setup with a relay using a connection session that is subject to secondary A&A may be performed. The relay WTRU may receive a direct communication request (DCR) from a remote WTRU requesting a connection service (e.g., connection session parameters such as S-NSSAI, data network name (DNN), etc.). The relay may determine that the connection session for the service may be subject to secondary A&A, for example, based on an indication related to the connection session if already established and / or an indication related to the DN from a relay proximity service (ProSe) configuration. Based on the determination, the relay may trigger a network-controlled admission for the remote WTRU. The relay WTRU may send a direct communication accept (DCA) message including a pending secondary A&A indication and may configure a traffic filter associated with the connection (e.g., PC5 link) to discard data traffic from the remote WTRU until completion (e.g., successful completion) of the secondary A&A. The relay WTRU may send a request message (e.g., an Access Stratum (NAS) Request message) to the Session Management Function (SMF) (e.g., including the remote WTRU ID) to initiate a connection session secondary A&A for the remote WTRU. The relay may transparently forward Extensible Authentication Protocol (EAP) authentication messages between the WTRU and the Access and Mobility Management Function (AMF) / SMF (e.g., the NAS message may include the remote WTRU ID to indicate that the EAP message can be used to authenticate the remote WTRU). The relay WTRU may receive a NAS Response message from the SMF containing a successful A&A indication, an EAP success message, and remote WTRU authorization information (e.g., the IP address to which the DN is assigned, the aggregate maximum bit rate (AMBR) for sessions to which the DN is allocated). If successful, the relay WTRU may configure a link traffic filter to allow data traffic between the remote WTRU and the network / DN and may notify the remote WTRU by including an EAP success message in a link modification procedure. The relay WTRU may relay data traffic between the remote WTRU and the network / DN.

[0005] A link setup with the relay using an S-NSSAI that is subject to NSSAA may be performed. The relay WTRU may receive a DCR from the remote WTRU. The DCR may include the remote WTRU's identity (e.g., SUCI), the S-NSSAI, the remote WTRU's NSSAA capabilities, etc. The relay WTRU may determine that the S-NSSAI requested by the remote WTRU for a ProSe (e.g., PC5) connection is subject to NSSAA based on the local ProSe configuration and / or a previous NSSAA performed by the relay for that S-NSSAI. The relay WTRU may initiate network-controlled authorization of the remote WTRU, for example, by sending a NAS request message to the AMF that includes the remote WTRU identity, the requested S-NSSAI, and the remote WTRU's NSSAA capabilities. The relay WTRU may send a primary authentication message between the AMF and the remote WTRU. The relay WTRU may receive a response message (e.g., a NAS response message) that may include the S-NSSAI, the remote WTRU ID, an NSSAA status indication (e.g., one of success, pending, or request), and keying material bound to one or more of the S-NSSAI. The relay WTRU may send a Direct Security Mode Command (DSMC) message to the remote WTRU, which may include the NSSAA status indication and the S-NSSAI. The relay WTRU may send an NSSAA authentication message between the AMF and the remote WTRU. The NSSAA procedure may be triggered by the relay WTRU (e.g., via a NAS request) or the AMF. The relay WTRU may receive a NAS message from the AMF, which may include the remote WTRU ID, the NSSAA result, and the S-NSSAI. The relay may store the S-NSSAI as authorized for the remote WTRU. The relay WTRU may send a ProSe (e.g., PC5) message (e.g., a Link Modify Request) that may include the successful NSSAA indication and the S-NSSAI. The relay WTRU may enable the remote WTRU to use the S-NSSAI (eg, in conjunction with a connection session that uses the S-NSSAI).

[0006] During a link establishment procedure, such as a PC5 link establishment procedure, the relay WTRU may enable the remote WTRU to perform a PDU session establishment with a secondary A&A following network-controlled authorization of the remote WTRU, where the PDU session may be shared among multiple remote WTRUs. Upon successful completion of the PDU session with the secondary A&A for the remote WTRU, the relay may provide the remote WTRU with access to the shared PDU session.

[0007] In PDU session secondary A&A via relay, the relay WTRU may perform an IP allocation procedure for the remote WTRU, for example, may perform IP prefix advertisement based on one or more IP addresses in the DN-AAA received from the SMF.

[0008] In a PDU session secondary A&A via a relay, the relay WTRU may derive a session AMBR for (eg, each) remote WTRU sharing the PDU session according to the DN authorized session AMBR received from the SMF.

[0009] During a link establishment procedure, such as a PC5 link establishment procedure, the relay WTRU may enable the remote WTRU to perform an NSSAA procedure using the remote WTRU's extended network controlled authorization. Upon completion (e.g., successful completion) of the NSSAA procedure by the remote WTRU, the relay may provide the remote WTRU access to the S-NSSAI that was the subject of the NSSAA.

[0010] During a link establishment procedure, such as a PC5 link establishment procedure, the relay may use the remote WTRU's security context, such as a 5G native security context, in the remote WTRU's enhanced network control authorization to enable the remote WTRU to gain access to the network via the relay.

[0011] During a link establishment procedure, such as a PC5 link establishment procedure, the relay is provisioned with a relay service code (RSC) that may request non-3GPP interworking function (N3IWF) access to provide connectivity to the remote WTRU and restrict the remote WTRU from establishing an IPsec connection with an N3IWF located in a visited public land mobile network (VPLMN) or home PLMN (HPLMN). The relay WTRU may receive the RSC and instructions to connect with a tunnel termination network function (e.g., a secure tunnel termination network function). As an example, the tunnel termination network function may be the N3IWF. The relay WTRU may identify the tunnel termination network function, allocate an IPv6 prefix or an IPv4 address for the remote WTRU, and configure traffic filters to allow traffic between the remote WTRU and the tunnel termination network function. [Brief explanation of the drawings]

[0012] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2]A diagram illustrating an example of a ProSe (e.g., PC5) link setup with a relay using a PDU session that may be subject to secondary A&A. [Figure 3] A figure illustrating an example of PDU session secondary A&A via a relay (e.g., PDU session secondary A&A via a relay procedure). [Figure 4] 10 illustrates an example PDU session release that may be triggered by a relay WTRU or the network. [Figure 5] A figure illustrating an example of release of a ProSe link (e.g., a PC5 link) associated with a shared PDU session subject to secondary A&A. [Figure 6] 10 illustrates an example of deauthorization by DN-AAA for a remote WTRU using a shared PDU session. [Figure 7] 10 illustrates an example of re-A&A by DN-AAA of a remote WTRU using a shared PDU session; [Figure 8] A diagram illustrating an example of PDU session secondary A&A via relay procedure with DN-AAA IP allocation. [Figure 9] A diagram illustrating an example of a ProSe (e.g., PC5) link setup using a relay using an S-NSSAI that is subject to NSSAA. [Figure 10] FIG. 1 illustrates an example of NSSAA via relay procedure. [Figure 11] 10 illustrates an example of a remote WTRU reconnection to a relay WTRU using an S-NSSAI subject to NSSAA with a previous authorization. [Figure 12] 10 illustrates an example of revocation of a remote WTRU using an S-NSSAI subject to NSSAA via a relay WTRU. [Figure 13] 10 illustrates an example of revocation of a relay WTRU using an S-NSSAI subject to NSSAA via a relay WTRU. [Figure 14] FIG. 10 illustrates an example of a ProSe (e.g., PC5) link setup with a relay using a remote WTRU 5G native security context. [Figure 15] 1 illustrates an example of a link setup with a relay using a connection session that is subject to secondary A&A. [Figure 16] 1 illustrates an example of a link setup with a relay using S-NSSAI, which is subject to NSSAA. [Figure 17] 1 illustrates an example in which a remote WTRU may determine whether to use a globally unique temporary identifier (GUTI) of the remote WTRU based on public land mobile network (PLMN) information received during a discovery procedure with a relay WTRU. [Figure 18] 1 illustrates an example in which a relay WTRU may determine whether to use an identifier (eg, GUTI) of a remote WTRU received during a link establishment procedure (eg, DCR). [Figure 19] 10 illustrates an example in which a relay WTRU may determine whether to use an identifier (eg, GUTI) of a remote WTRU received during a link establishment procedure (eg, an identity request). DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0036] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference through hardware (e.g., chokes) or processor-based signal processing (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053] 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0067] The PDU secondary authentication and authorization (A&A) procedure may be used, for example, to authenticate and / or authorize a WTRU. For example, a network (e.g., a Session Management Function (SMF)) based on subscription information and / or network policy may trigger an Extensible Authentication Protocol (EAP)-based secondary authentication of the WTRU with a Data Network Authentication, Authorization, and Accounting (DN-AAA) server, for example, as part of a connection establishment (e.g., PDU session establishment) procedure. The DN-AAA may perform A&A of the WTRU for a connection session (e.g., a PDU session) based, for example, on credentials (e.g., non-3GPP credentials). The DN-AAA may trigger re-authentication and / or revocation of the WTRU's authorization to use the connection session, for example, at a time (e.g., any time) following successful connection establishment with the secondary A&A.

[0068] A&A may be network slice-specific. Network slice-specific secondary authentication and authorization (NSSAA) may be performed by the WTRU. The WTRU may perform NSSAA (e.g., an NSSAA procedure) with a third-party AAA server through the AMF, e.g., using credentials (e.g., non-3GPP credentials), for requested single network slice selection assistance information (S-NSSAI) (e.g., each S-NSSAI) that may be subject to NSSAA, e.g., following a mandatory primary authentication. The network (e.g., AMF) may trigger an EAP-based authentication execution for applicable S-NSSAIs (e.g., based on the WTRU capability to perform NSSAA, subscription information, operator policies, and / or the like), e.g., following a registration procedure. The AMF may act as an authenticator for EAP authentication between the WTRU and the third-party AAA server. In an example, if the WTRU is successfully authenticated for a given S-NSSAI, the latter may be added to the allowed NSSAIs in the WTRU configuration via a WTRU configuration update (UCU) procedure. The third party AAA server may trigger a re-authentication of the WTRU or revocation of authorization to use the S-NSSAI at some time (eg, any time) following a successful NSSAA procedure.

[0069] A ProSe Layer 3 (L3) WTRU-to-network relay (e.g., a 5G ProSe L3 WTRU-to-network relay) may be provided and / or supported. An L2 and L3 WTRU-to-network (U2NW) relay may be provided and / or supported. The remote WTRU may connect via a Uu link (e.g., using a PC5 link) to an L3 U2NW relay that may establish a PDU session or reuse / modify a PDU session (e.g., an existing PDU session) to provide network connectivity for the remote WTRU.

[0070] ProSe security may include U2NW relay communication security. 5GS may support authorization of a WTRU as a remote WTRU in a WTRU-network relay scenario.

[0071] PDU session secondary authentication for a remote WTRU via a Layer 3 relay may be provided and / or supported. Network-controlled authorization of a remote WTRU for access via a Layer 3 WTRU-to-network relay may be provided and / or supported.

[0072] A remote WTRU may be permitted to access an N3IWF-specific network slice, which may be subject to an NSSAA or DN, which may require a secondary A&A, for example, via an IPsec connection, session, and / or tunnel. NAS procedures (e.g., registration and / or NSSAA) may be performed using the IPsec connection, session, and / or tunnel.

[0073] Network-controlled authorization of the remote WTRU to access the network via the L3 WTRU-to-network relay may be provided and / or enabled. The procedure may use a modified primary authentication performed via the relay (e.g., using the relay's AMF and the remote WTRU's Authentication Function (AUSF)). Following authorization (e.g., successful authorization), the remote WTRU may complete PC5 link establishment with the WTRU-to-network relay so that communications can occur via the relay.

[0074] A shared PDU session with secondary A&A via an L3 U2NW relay may be provided and / or supported. In an example, the PDU secondary A&A procedure may support A&A for a WTRU (e.g., only one WTRU) to use one PDU session (e.g., exclusively). In such a case, performing PDU session secondary A&A for multiple WTRUs (e.g., remote WTRUs) to share a PDU session (e.g., provided via a relay) may not be supported.

[0075] In an example, in the case of an L3 U2NW relay scenario, if a PDU session (e.g., an existing PDU session) satisfies the remote WTRU PC5 connection request, the relay WTRU may select (e.g., automatically select) it to be used by the remote WTRU (e.g., shared with another WTRU) without considering, for example, whether a secondary A&A may be required for the PDU session.

[0076] In an example, a PDU session secondary A&A over L3 relay scenario may not provide support for multiple remote WTRUs sharing a PDU session that is the subject of secondary A&A, and the scenario may not provide a means (e.g., an explicit means) for a remote WTRU to verify whether a relay can be authorized to use a PDU session that is the subject of secondary A&A.

[0077] The PDU Secondary A&A (e.g., a PDU Secondary A&A procedure) may require a previous primary authentication of the WTRU, for example, to enable the SMF to retrieve the WTRU's subscription information. The WTRU's subscription information may be requested by the SMF during the PDU Session Secondary A&A procedure to retrieve the WTRU's Generic Public Subscription Identifier (GPSI) to be provided to the DN-AAA to enforce PDU session authorization based on the subscription data, or to enable the PCF to make QoS decisions for the WTRU (e.g., using the WTRU's Subscribed Aggregate Maximum Bit Rate (AMBR)). In examples, it may not be specified how to perform primary authentication of the remote WTRU via a relay (e.g., using the procedures described herein) for the PDU Session Secondary A&A procedure. The serving AMF may need to select an SMF in the remote WTRU's HPLMN (H-SMF) during the PDU session establishment procedure, for example, to support home-routed roaming. Selection of the H-SMF by the AMF may require the AMF to have knowledge of the subscription identity (eg, Subscription Permanent Identifier (SUPI)) of the remote WTRU.

[0078] One or more examples described herein may provide a way in which a remote WTRU may be enabled to use a PDU session with a secondary A&A via an L3 U2NW relay. One or more examples described herein may provide a way in which PDU session secondary A&A may be performed by a DN-AAA for a remote WTRU connecting via an L3 U2NW relay (e.g., including providing SMF access to remote WTRU subscription data).

[0079] One or more examples described herein may provide a method by which secondary re-authentication and / or de-authorization of a PDU session may be performed by a DN-AAA for a remote WTRU connected via an L3 U2NW relay.

[0080] One or more examples described herein may provide a method by which sharing of a PDU session using secondary A&A between multiple remote WTRUs connected via an L3 U2NW relay is supported.

[0081] One or more examples described herein may provide a method by which a remote WTRU may be enabled to verify that the relay WTRU is authorized to use and / or provide access to a PDU session that is the subject of a secondary A&A (e.g., or vice versa).

[0082] One or more examples described herein may provide a method that may enable IP address / IPv6 prefix assignment and / or allocation by DN-AAA to one or more remote WTRUs that share the same PDU session.

[0083] One or more examples described herein may provide a method by which the DN allowed AMBR may be enforced, for example, when a PDU session is shared among multiple remote WTRUs.

[0084] NSSAA via an L3 U2NW relay may be provided and / or supported. In an example, access to a slice may be granted to a WTRU if the WTRU completes an NSSAA procedure. In such a case, a U2NW relay providing connectivity services using an S-NSSAI that is subject to NSSAA may not be able to verify whether a remote WTRU is authorized to use that S-NSSAI (e.g., or vice versa). In such a case, the AMF may perform a prior primary authentication of the WTRU to enable it to retrieve the WTRU's subscription data and / or enforce authorization related to slice access.

[0085] One or more examples described herein may provide a method by which a remote WTRU may be enabled to use an S-NSSAI that is subject to an NSSAA via an L3 U2NW relay.

[0086] One or more examples described herein may provide a method by which NSSAA may be performed for a remote WTRU connecting via an L3 U2NW relay (e.g., including providing AMF access to remote WTRU subscription data).

[0087] One or more examples described herein may provide a method by which slice-specific re-authentication and / or de-authorization may be performed by an AAA server for a remote WTRU connected via an L3 U2NW relay.

[0088] One or more examples described herein may provide a method by which a relay may be enabled to verify that a remote WTRU is authorized to use an S-NSSAI that is subject to the NSSAA (e.g., or vice versa).

[0089] Remote WTRU authentication and / or authorization via the L3 U2NW relay may be supported using a security context, which may be, for example, a 5G native security context, of the remote WTRU.

[0090] Network-controlled authorization of the remote WTRU may support the remote WTRU using a security context, such as its native 5G security context. In one example, the context may be established during a previous network registration procedure. Enabling the remote WTRU to use its security context (e.g., native 5G) may enable reconnection (e.g., faster reconnection) via the L3 WTRU-to-network (e.g., by avoiding primary authentication signaling via a relay).

[0091] One or more examples described herein may provide a method by which network-controlled authorization of a remote WTRU may be enabled to access via a Layer 3 WTRU-to-network relay using a remote WTRU security context, which may be, for example, a 5G native security context.

[0092] Support for NSSAA and / or PDU Secondary A&A via the L3 U2NW and / or N3IWF may be provided.

[0093] In an example, a remote WTRU may be authorized to access using an IPsec connection, session, and / or tunnel to an N3IWF, a particular network slice that may require NSSAA, and / or a DN that may require secondary A&A. The remote WTRU may be able to access a connection session and / or slice (e.g., a PDU session) to connect with the N3IWF and perform NSSAA and / or secondary authentication. In an example, if a connection service (e.g., a Relay Service Code (RSC)) provided by a relay is associated with an S-NSSAI that may require NSSAA and / or a DN that may require secondary authentication, the relay may authorize the remote WTRU to connect based on successful completion of the NSSAA or secondary authentication (e.g., the relay may authorize the remote WTRU and / or DN using the S-NSSAI until successful completion of the NSSAA or PDU secondary authentication, respectively). A remote WTRU may not be able to establish an IPsec connection, session, and / or tunnel with the N3IWF to perform NSSAA and / or secondary authentication, for example, if the remote WTRU is not authorized to connect to it (e.g., to reach the N3IWF). In an example, the remote WTRU may be authorized (e.g., only authorized) to access an S-NSSAI that requires an NSSAA, and may not be able to access a separate PDU session using another S-NSSAI (e.g., any other S-NSSAI) to establish an IPsec connection with the N3IWF, even if, for example, a relay provides the separate PDU session using a different S-NSSAI.

[0094] One or more examples described herein may provide a method for enabling a remote WTRU to access a slice and / or DN via an L3 U2NW relay and / or to use an N3IWF for the remote WTRU, for example, when the connectivity service provided by the relay is associated with an S-NSSAI that may require an NSSAA and / or a DN that may require secondary authentication.

[0095] Secondary A&A of a connection session (e.g., a PDU session) may be performed via a relay (e.g., an L3 U2NW relay).

[0096] The PC5 link may be set up with the relay using a connection session (e.g., a PDU session) that is subject to secondary A&A. Examples described herein that refer to a relay may be applicable to an entity that may perform the behavior of a relay (e.g., a WTRU-network relay).

[0097] During ProSe link establishment (e.g., PC5 link establishment), the relay may enable a WTRU (e.g., a remote WTRU) to perform connection establishment (e.g., PDU session establishment) with a secondary A&A, e.g., following network-controlled authorization of the remote WTRU, where the connection session may be shared among multiple remote WTRUs. The relay may provide the remote WTRU access to the shared connection session based, e.g., on successful completion of connection establishment with a secondary A&A for the remote WTRU. In examples, the terms "relay" and "relay WTRU" may be used interchangeably.

[0098] The relay may determine that a ProSe connection request (e.g., a PC5 connection request) from a remote WTRU is associated with a connection session (e.g., a PDU session) that is subject to the secondary A&A, e.g., based on an established relay WTRU PDU session establishment performed by the relay using the secondary A&A and / or a ProSe configuration that indicates the DN uses the secondary A&A. The relay may trigger a network-controlled authorization (e.g., an authorization procedure) of the remote WTRU, e.g., based on the determination that the connection request from the remote WTRU is associated with a connection session that is subject to the secondary A&A and / or the determination that the connection request uses a remote WTRU identity (e.g., an encrypted subscription identifier (SUCI) or a globally unique temporary identifier (GUTI)) received in the connection request. For example, the SUCI may be an encrypted SUPI. The SUCI may be used for WTRU initial registration / authentication with the network, e.g., for privacy reasons. The relay may establish security of a ProSe link (e.g., a PC5 link) with the remote WTRU, conditional on successful authorization of the remote WTRU by the network. The relay may notify the remote WTRU of a pending connection session (e.g., a PDU session) using secondary A&A using an indication via a ProSe (e.g., PC5) message (e.g., direct communication accept (DCA)). The relay may assign an IP address and / or an IPv6 prefix for the remote WTRU. The relay may configure a default filter (e.g., a default IP filter) for the ProSe link (e.g., PC5 link), for example, to discard data traffic until successful completion of the connection session (e.g., PDU session) secondary A&A. The indication may indicate a state. For example, the indication may be and / or may indicate a link state (e.g., extended link state or Uu link state). As an example, the link state may be set to pending A&A. A default value for the state (e.g., link state) may be set to ready, for example, if no state or state value is included in the DCA message.The relay may verify (e.g., use a filter on) the state (e.g., link state) when receiving data traffic from the remote WTRU. The relay may, for example, drop the data traffic if the state is not set to a ready state.

[0099] The relay may trigger a connection session secondary A&A (e.g., PDU session secondary A&A) for a remote WTRU in a network (e.g., SMF) via a non-access stratum (NAS) message (e.g., a NAS message including a remote WTRU ID and / or addressing information). The relay may forward EAP authentication messages between the WTRU and the AMF / SMF (e.g., transparently). The NAS messages exchanged between the relay and the SMF may include a remote WTRU identification (ID) (e.g., to indicate that the authentication message is for remote WTRU authentication). The relay may mark the remote WTRU as authorized by the DN for a connection session, for example, based on receiving a NAS message from the SMF indicating a successful connection session secondary A&A for the remote WTRU. For example, the relay WTRU may store a list of remote WTRUs authorized for a connection session (e.g., a PDU session) and / or set the associated ProSe link state (e.g., PC5 link state) to “ready.” The relay WTRU may send a ProSe (e.g., PC5) message (e.g., Link Modify Request message) informing the remote WTRU of the successful secondary A&A, for example, including an EAP success message from the SMF and / or a link state set to "ready." The relay may configure ProSe (e.g., PC5) link traffic filtering (e.g., IP and non-IP traffic) to allow relayed data traffic between the remote WTRU and the network / DN, for example, provided that the connection session secondary A&A is successful.

[0100] 2 is a diagram illustrating an example of a ProSe (e.g., PC5) link setup with a relay using a PDU session subject to secondary A&A. 0a, 0b, 1-13, 2a, 2b, 3b, 4a, 4b, 4c, 5b, 7a, and 7b used in one or more of FIGS. 2-14 are reference numerals. In 0a, a remote WTRU may be authorized and / or provisioned (e.g., with authorization parameters) to operate as a remote WTRU. In 0b, a relay WTRU may be provisioned (e.g., with authorization parameters such as registered and / or authorized) to operate as a relay WTRU.

[0101] In step 1, the relay may perform connection session secondary A&A (e.g., PDU session secondary A&A via DN-AAA). In an example, the relay may be provisioned with credentials used for the exemplary call flow as described with respect to FIG.

[0102] In 2, the remote WTRU and / or the relay WTRU may perform discovery (e.g., a discovery procedure). In an example, the remote WTRU and the relay WTRU may perform a discovery procedure, whereby the remote WTRU may discover connection services provided by the relay (e.g., based on broadcasted service types and / or codes).

[0103] In 3, the remote WTRU may determine (e.g., from the configuration in 0) that the service code is associated with a DN that uses a secondary A&A. The remote WTRU may send a Direct Communication Request (DCR) message (e.g., including the remote WTRU's subscription identity and / or network identity information such as a SUPI or GUTI) based on, for example, the determination that the service code is associated with a DN that uses a secondary A&A.

[0104] In 4, the relay may determine, for example, based on receiving a DCR message, that a connection session subject to secondary A&A should be used to satisfy the request of the remote WTRU. In an example, the relay may determine that a PDU session using secondary A&A may be needed to satisfy the remote WTRU request. The determination that a connection session subject to secondary A&A should be used to satisfy the request of the remote WTRU may be based on one or more of: an established PDU session (e.g., an existing PDU session) that satisfies the remote WTRU connection requirements (e.g., established in 1) may be marked with an indication that secondary A&A may be required; and, from the configuration in 0, a service code may be associated with a DN that may be marked with a parameter indicating that the DN requires secondary A&A.

[0105] In 5, the relay may trigger network-controlled authorization of the remote WTRU (e.g., as described with respect to FIG. 9 or FIG. 14), for example, on the condition that the DCR message includes a SUPI or GUTI. Referring to FIG. 2, in an example, the relay may send an identity request message to the remote WTRU to obtain a remote WTRU ID to perform network-controlled authorization (e.g., an authorization procedure) of the remote WTRU. The relay may reject the remote WTRU request, for example, if the remote WTRU fails to provide the remote WTRU ID used for network-controlled authorization. The relay may provide a cause via the reject message indicating that the identity parameter (e.g., SUPI or GUTI) may be missing.

[0106] At 6, the relay may initiate a Direct Security Mode Command (DSMC) procedure with the remote WTRU to establish security of the ProSe link (e.g., PC5 link), for example, based on the success of the remote WTRU's network-controlled authorization (e.g., authorization procedure).

[0107] In 7, the relay may send a successful DCA message, for example, based on the security establishment. The DCA message may include an indication that a PDU session with the secondary A&A may be pending. The relay may assign an IP address and / or an IPv6 prefix to the remote WTRU. The relay may configure a traffic filter (e.g., as a default filter for IP traffic or non-IP traffic) for the ProSe link (e.g., PC5 link) to prevent data traffic (e.g., any data traffic) until the subsequent PDU session secondary A&A is successfully completed (e.g., as described with respect to 8). The remote WTRU may refrain from sending data traffic (e.g., any data traffic) over the ProSe link (e.g., PC5 link) until the subsequent PDU session secondary A&A is successfully completed, for example, based on the instruction via the DCA message. In an example, the instruction may be a link state set to “pending A&A.” The relay may use the link state to set a filter and / or verify the link state to prevent forwarding data traffic on and / or from the ProSe link. In an example, a remote WTRU may transmit data over a PC5 unicast link with a relay. The PC5 unicast link may be identified by a src / dst L2 ID. The relay may set a filter on the value of the src / dst L2 ID that identifies the PC5 link. The relay may associate an action on the PC5 link set with, for example, "check link state" (e.g., if in pending A&A state) instead of "forward data" (e.g., if in ready state). The link state may be stored in the relay's PC5 link table. The remote WTRU may refrain from transmitting data traffic until the link state can be set to "ready."

[0108] At 8, the relay may trigger a PDU session secondary A&A via a relay procedure, for example, as described with respect to FIG.

[0109] In 9, the relay may send a ProSe message (e.g., a PC5 message) based on a successful (e.g., PDU session with the secondary A&A over relay procedure). The ProSe message (e.g., PC5 link modification request) may include a success indication (e.g., and / or a link state set to “ready”). The ProSe message and / or success indication may include an EAP success message (e.g., an EAP success message may be received from the SMF in 8) and / or QoS parameters (e.g., AMBR for the remote WTRU as described herein). The relay may configure the ProSe link to allow data traffic between the remote WTRU and the network / DN (e.g., remove the filters configured in 7) and set the link state to “ready.” The relay may assign an IP address and / or IPv6 prefix (e.g., if none was assigned in 7) for the remote WTRU to be used with the established connection session (e.g., the established PDU session). In an example, if the PDU session with the secondary A&A fails, the relay may release the ProSe link (e.g., PC5 link) indicating the cause of the failure. The rejection message may include an EAP failure message (e.g., the EAP failure message may be received from the SMF at 8).

[0110] In an example, the relay may trigger a PDU session secondary A&A over relay procedure during the link establishment procedure, for example, after 6 in FIG. 2 (e.g., perform 8 in FIG. 2 before 7 in FIG. 2). In such a case, a message (e.g., a PC5 signaling (S) message) may be used to carry an authentication message for the PDU session secondary A&A to and / or from the remote WTRU, or the access stratum (AS) layer may be configured with ProSe (e.g., PC5) link information (e.g., L2 ID and / or QoS parameters). The ProSe link information may be used for bearer configuration. The relay may send a DCA message including a successful secondary A&A indication based on the successful secondary A&A over relay procedure (e.g., a PDU session with it). The DCA message may include an EAP success message (e.g., an EAP success message may have been received from the SMF). In an example, if the PDU session with the secondary A&A fails, the relay may send a ProSe reject message (e.g., a PC5 reject message) indicating the cause of the failure. The rejection message may include an EAP failure message (e.g., the EAP failure message may have been received from an SMF).

[0111] FIG. 3 is a diagram illustrating an example of PDU session secondary A&A via a relay (e.g., PDU session secondary A&A via a relay procedure).

[0112] At 1, the relay WTRU may decide to trigger a PDU session secondary A&A for the remote WTRU based on the condition determined in FIG.

[0113] In 2, the relay may send an NAS message (e.g., a PDU session modification, an establishment request, and / or a remote WTRU report) to, for example, the SMF. The NAS message may include one or more of a remote WTRU user ID, a remote WTRU addressing information, or other connection session (e.g., PDU session) parameters (e.g., S-NSSAI, DNN, and / or the like). The SMF may receive an NAS message including a remote WTRU subscription identity (e.g., SUPI) from the AMF. The remote WTRU subscription identity may be obtained by the AMF during controlled authorization of the remote WTRU (e.g., as described with respect to Figure 9 or Figure 14).

[0114] In 3, the SMF may determine, for example based on subscription information, that the requested DN may be subject to secondary A&A and / or may trigger PDU session secondary A&A of the remote WTRU via the relay.

[0115] In 4, the remote WTRU may perform PDU session secondary A&A via the relay. The authentication message may be forwarded between the SMF and the relay using one or more NAS messages. The one or more NAS messages may include the remote WTRU's identification information (e.g., GPSI, remote user ID, and / or the like) to indicate to the relay that the authentication message is for the remote WTRU. The relay may forward the message (e.g., transparently) between the remote WTRU and the SMF. The DN-AAA may assign and / or allocate an IP address and / or IPv6 prefix for the remote WTRU during a procedure as described herein (e.g., as described with respect to FIG. 8). The DN-AAA may grant QoS parameters (e.g., session AMBR) for the remote WTRU using the shared PDU session as described herein. The SMF may maintain an N4 session with the DN-AAA for WTRUs (e.g., all WTRUs) that share the PDU session, for example, as long as the PDU session is not released.

[0116] In 5, the SMF may store the remote WTRU information in a relay session management (SM) context, for example, based on a successful PDU session secondary A&A via a relay procedure. The remote WTRU information and / or the relay session management context may include one or more of the remote WTRU identity information (e.g., SUPI and / or GPSI), individual authorization status, and / or information received from the DN-AAA (e.g., allocated IP, QoS parameters, and / or the like).

[0117] In 6, the SMF may send a NAS message (e.g., PDU Session Modification, Establishment Response, and / or Remote WTRU Report Acknowledgement) to the relay indicating the result of the PDU session Secondary A&A. The NAS message may include the identity of the remote WTRU (e.g., GPSI and / or Remote User ID) and / or an EAP success or failure message. The NAS message may include addressing and / or QoS information associated with the remote WTRU, for example, in the case of a successful Secondary A&A. The relay may use (e.g., enforce) the addressing and / or QoS information associated with the remote WTRU based on one or more examples described herein, such as the example described with respect to FIG. 8.

[0118] At 7, the relay may mark the remote WTRU as authorized by the DN and / or store the received authorization information associated with the remote WTRU upon successful PDU session secondary A&A. The relay WTRU may proceed with the remainder of the ProSe link setup (e.g., PC5 link setup with the relay), e.g., using the PDU session that is the subject of secondary A&A, as described with respect to FIG.

[0119] A connection session (e.g., a PDU session) with the secondary A&A may be released. During connection session (e.g., a PDU session) release, the SMF may enable removal of a remote WTRU from a WTRU that is authorized to use a shared connection session (e.g., a PDU session that is subject to the secondary A&A and is provided via a relay).

[0120] During a connection session release (e.g., a PDU session release procedure), the SMF may determine, for example, based on the relay WTRU SM context information, that the connection session (e.g., a PDU session) may be subject to secondary A&A and / or may be used for relay communication by multiple remote WTRUs. The SMF may send a notification of address release to the DN-AAA for one or more of the remote WTRUs (e.g., each of the one or more remote WTRUs) that share the connection session based on the relay WTRU SM context. An example procedure may be described with reference to FIG. 4. FIG. 4 is a diagram illustrating an example of a PDU session release triggered by a relay WTRU or a network.

[0121] In 0a and 0b, the remote WTRU may be connected to the relay WTRU using, for example, a shared PDU session that is subject to secondary A&A.

[0122] In 1, the relay may trigger a PDU session release procedure with the SMF by sending a PDU session release request to the SMF. In an example, the SMF may trigger the PDU session release procedure, in which case this may not be performed.

[0123] In 2, the SMF may notify the DN of the release of IP addresses and / or IPv6 prefixes for one or more of the WTRUs (e.g., each of the one or more WTRUs) that share a PDU session stored in the relay SM context (e.g., as described with respect to FIG. 3). The SMF may release user plane (UP) resources used by the PDU session that includes the PDU session context.

[0124] At 3, the SMF may send a PDU session release indication (e.g., command) to the relay.

[0125] At 4, the relay may release a ProSe link (eg, a PC5 link) with one or more remote WTRUs (eg, each of the one or more remote WTRUs) that share the PDU session.

[0126] At 5, the relay may acknowledge the release command message by sending an acknowledgement to the SMF.

[0127] FIG. 5 is a diagram illustrating an example of a ProSe link (e.g., PC5 link) release associated with a shared PDU session subject to secondary A&A.

[0128] During a ProSe link (e.g., PC5 link) release procedure, the relay may enable removal of a remote WTRU from a WTRU that is authorized to use a shared connection session (e.g., a PDU session that is the subject of secondary A&A and is provided via the relay).

[0129] During a ProSe release (e.g., PC5 release) procedure, the relay may determine that a connection session (e.g., a PDU session) used by a remote WTRU is subject to secondary A&A. The relay may send a message (e.g., an NAS message) to the serving SMF, for example, including a remote WTRU ID, addressing information, and / or a release indication for the remote WTRU. The relay may complete the ProSe link (e.g., PC5 link) release procedure based on receiving an NAS message from the SMF confirming the removal of the remote WTRU from the connection session. In an example, the relay may complete the ProSe (e.g., PC5) release procedure before initiating or completing the removal of the remote WTRU from a WTRU that shares the PDU session. FIG. 5 is a diagram illustrating an example of a ProSe link (e.g., PC5 link) release associated with a shared PDU session that is subject to secondary A&A.

[0130] In 0a and 0b, the remote WTRU may be connected to the relay WTRU using a shared PDU session covered by secondary A&A 1.

[0131] In 1, the remote WTRU and / or relay WTRU may initiate a direct link release procedure, for example, by sending a release request. Release may be triggered if a time (e.g., a keep-alive timer) expires. For example, release may be triggered by expiration of a time, after a certain duration, and / or the like.

[0132] At 2, the relay WTRU may determine that a ProSe link (eg, a PC5 link) with the remote WTRU may be associated with a shared PDU session.

[0133] In 3, the relay may initiate removal of the remote WTRU from the WTRUs that share the PDU session, for example, based on the determination in 2. The relay may send a NAS request message to the SMF indicating release of resources associated with the remote WTRU, including remote WTRU identification information (e.g., remote user ID, GPSI, and / or the like), remote WTRU addressing information, and / or a release indication.

[0134] At 4, the SMF may retrieve and / or remove the remote WTRU information from the relay WTRU SM context and / or release the address (e.g., any address) assigned to the remote WTRU. The SMF may, for example, configure the User Plane Function (UPF) to drop any remaining packets (e.g., any remaining) associated with the remote WTRU while maintaining the N4 session with the DN-AAA and continue to serve other WTRUs that share the PDU session.

[0135] At 5, the SMF may notify the DN-AAA of the release of information associated with the remote WTRU (e.g., IP addresses and / or IPv6 prefixes allocated and / or used by the remote WTRU and / or MAC).

[0136] At 6, the SMF may send a response message (eg, a NAS response message) to the relay indicating the remote WTRU identity information and / or the remote WTRU information. The NAS response message may include a remote WTRU report acknowledgement.

[0137] At 7, the relay may complete the ProSe link release procedure, for example, by sending a release response to the remote WTRU.

[0138] Authorization, re-authentication, and / or revocation by the DN-AAA of a remote WTRU using a PDU session with a secondary A&A (eg, a shared PDU session) may be performed.

[0139] During deauthorization by DN-AAA, the SMF may enable removal of a remote WTRU from the WTRUs authorized to use a shared connection session (e.g., a PDU session that is subject to secondary A&A and is provided via a relay).

[0140] Based on receiving a revocation request message from the DN (e.g., including relay and / or remote WTRU GPSI and / or addressing information), the SMF may locate the relay WTRU SM context based on the provided information and remove the remote WTRU ID and information from the relay SM context (e.g., as one of the WTRUs authorized for the connection session). The SMF may send a message (e.g., a NAS command message) that may include the remote WTRU ID and / or information to revoke the remote WTRU's authorization to use the relay with the PDU session that is the subject of the secondary A&A. Figure 6 is a diagram illustrating an example of authorization revocation by the DN-AAA for a remote WTRU using a shared PDU session.

[0141] In 0a and 0b, the remote WTRU may be connected to the relay WTRU using a shared PDU session that is subject to secondary A&A.

[0142] In 1, the DN may initiate revocation of authorization for a WTRU using a shared PDU session, for example, by sending a message (e.g., a revocation request) to the SMF. The message may include the WTRU's identification information (e.g., GPSI) and / or addressing information (e.g., IP and / or Mac address). The SMF may identify the shared PDU session and the WTRU based on the provided information.

[0143] In 2, depending on whether the message (e.g., a request) is for a relay or a remote WTRU, one of the following may be performed: If the WTRU identified for revocation is a relay WTRU, the SMF (e.g., shown in FIG. 2a) may initiate a network-triggered PDU session release (e.g., as described in one or more examples herein, such as the example shown in FIG. 4) that may complete the authorization revocation (e.g., procedure). If the WTRU identified for revocation is a remote WTRU, the SMF (e.g., shown in 2b) may retrieve and / or remove the remote WTRU information from the relay WTRU SM context and / or release an address (e.g., any address) assigned to the remote WTRU. The SMF may, for example, configure the UPF to drop remaining (e.g., any remaining) packets associated with the remote WTRU while maintaining the N4 session with the DN-AAA, and continue serving other WTRUs sharing the PDU session.

[0144] In 3b, the SMF may send a message (e.g., a NAS command message) to release the connection with the remote WTRU whose authorization has been revoked. The message may include one or more of the remote WTRU identification information (e.g., remote user ID, GPSI, and / or the like), remote WTRU addressing information, and / or an indication of the reason for the release.

[0145] At 4b, the relay WTRU may initiate a ProSe link (eg, PC5 link) release procedure with the remote WTRU.

[0146] At 5b, the relay may acknowledge the message to release the connection (e.g., a NAS command message), for example, by sending a message to the SMF indicating release completion. The message may include remote WTRU identification information (e.g., remote user ID, GPSI, and / or the like) and / or remote WTRU information.

[0147] A procedure for re-authentication and / or re-authorization by the DN-AAA of a remote WTRU using a shared PDU session may be described with respect to Figure 7. Figure 7 is a diagram illustrating an example of re-A&A by the DN-AAA of a remote WTRU using a shared PDU session.

[0148] In 0a and 0b, the remote WTRU may be connected to the relay WTRU using a shared PDU session that is subject to secondary A&A.

[0149] In 1, the DN may initiate a re-authentication procedure for the remote WTRU using a shared PDU session, for example, by sending a message (e.g., a re-authorization request) to the SMF. The message may include the remote WTRU's identification information (e.g., GPSI) and / or addressing information (e.g., IP and / or Mac address).

[0150] At 2, the SMF may identify the shared PDU session and / or the remote WTRU based on the provided information (e.g., from 1).

[0151] At 3, the SMF may initiate a PDU session secondary A&A (eg, EAP authentication) for the remote WTRU via a relay (eg, a procedure), for example, as described with respect to FIG.

[0152] At 4, the SMF may update the remote WTRU information in the relay WTRU SM context, for example, if different authorization information (eg, new authorization information) may be provided by the DN-AAA during the procedure.

[0153] In 5, the SMF may send a NAS command message (e.g., a PDU Session Modify Command) to the relay indicating the result of the PDU session secondary re-authentication and / or re-authorization. The message may include one or more of the remote WTRU's identification information (e.g., GPSI, remote user ID, and / or the like) and / or an EAP success or failure message. In the case of a successful secondary re-A&A, the message may include different authorization information (e.g., new authorization information) associated with the remote WTRU connection.

[0154] In 6, if the secondary re-A&A of the remote WTRU is successful, the relay WTRU may update the authorization information (e.g., any authorization information) associated with the remote WTRU with different information (e.g., new information) received from the SMF. If the re-A&A procedure fails, the relay may initiate a ProSe link (e.g., PC5 link) release procedure with the remote WTRU.

[0155] In 7, the relay may acknowledge the NAS command message by sending a message indicating an acknowledgement (e.g., a PDU Session Modify Command Acknowledgement) to the SMF. The message may include the remote user ID.

[0156] The remote WTRU IP address may be assigned by the DN-AAA during the PDU session secondary A&A.

[0157] The PDU session secondary A&A function may include IP address allocation for the PDU session by DN-AAA.

[0158] In an example, the DN-AAA may provide the IP address of the remote WTRU to the SMF. The SMF may provide the IP address of the remote WTRU along with the ID of the remote WTRU to the relay WTRU. The relay WTRU may perform IP allocation (e.g., IP allocation procedure) for the remote WTRU (e.g., IP prefix advertisement).

[0159] 8 is a diagram illustrating an example of PDU session secondary A&A via relay procedure with DN-AAA IP allocation, which may include the behaviors and / or features described with respect to FIG. 3 and / or one or more of the following relay WTRU and SMF behaviors:

[0160] The behavior of the relay WTRU may include one or more of the following: The relay WTRU may receive a connection establishment request (e.g., a PC5 connection establishment request) from the remote WTRU. In an example, the connection establishment request may include a direct communication request message. The relay WTRU may determine that the connection establishment request from the remote WTRU uses a connection session (e.g., a PDU session) that is subject to the secondary A&A, for example, based on the relay WTRU PDU session establishment performed by the relay using the secondary A&A. The relay WTRU may send a pending IP allocation for the remote WTRU (e.g., a pending IP allocation for the remote WTRU until the secondary A&A is successful). The pending IP address allocation and / or an indication may be sent to the remote WTRU via an acceptance message (e.g., a direct communication accept message). The relay WTRU may provide the remote user identity to the SMF (e.g., provide the remote user identity to the SMF without an IP address). The relay WTRU may receive the IP address of the remote WTRU from the SMF (e.g., via a PDU session modification response and / or a remote WTRU report acknowledgement). The relay WTRU may assign an IP address to the remote WTRU, which may be sent to the remote WTRU via a message (eg, a link modification request message or a new PC5 message such as IP address assignment).

[0161] The behavior of the SMF may include one or more of the following: The SMF may receive the IP address of the remote WTRU from the DN-AAA (e.g., via an authentication and / or authorization response). The SMF may store the IP address of the remote WTRU, for example, in a connection session (e.g., PDU session) context. The SMF may send the IP address of the remote WTRU to the network (NW) relay via a PDU session modification response and / or a remote WTRU report acknowledgement.

[0162] The DN authorization AMBR provided by the DN-AAA via a shared PDU session can be enforced.

[0163] The SMF may receive a DN Authorized AMBR from the DN-AAA for a non-guaranteed bit rate (GBR) flow in a connection session (e.g., a PDU session), for example, as part of a general secondary A&A procedure. The SMF may use the received DN Authorized AMBR (e.g., as input) to retrieve an authorized session AMBR from a Policy Control Function (PCF). In an example, the SMF may receive a DN Authorized Profile Index (DAPI) (e.g., instead of the DN Authorized AMBR), and the SMF may use the DAPI to retrieve local configuration for QoS and / or provide the DAPI (e.g., as input) to the PCF to retrieve the QoS configuration.

[0164] When a relay WTRU and one or more remote WTRUs share a connection session (e.g., a PDU session) that may be subject to secondary A&A, one or more of the following may be used to enforce a session AMBR for the relay WTRU and the remote WTRU: The SMF may receive an initial DN authorized AMBR and / or DAPI when the relay WTRU establishes a connection session (e.g., a PDU session) and performs secondary A&A (e.g., as described at 1 in FIG. 2). The relay WTRU may receive an initial session AMBR authorized by the PCF (e.g., taking the DN authorized AMBR and / or DAPI as input) or may derive the initial session AMBR from a local configuration (e.g., if a DAPI may be received). When a remote WTRU is going to share a PDU session and secondary A&A is performed for the remote WTRU (e.g., at 4 in FIG. 3), the SMF may receive an updated DN authorized AMBR and / or an updated DAPI. The DN-AAA may take into account the presence of multiple WTRUs sharing a PDU session (e.g., the same PDU session) and may increment the DN Authorization AMBR or select a different DAPI accordingly. In an example, the DN-AAA may determine an updated DN Authorization AMBR or DAPI (e.g., a new DN Authorization AMBR or DAPI). The SMF may provide the updated DN Authorization AMBR or DAPI to the PCF, for example, as a result of receiving an SMF for the updated DN Authorization AMBR or updated DAPI. The SMF may retrieve an updated session AMBR (e.g., a new session AMBR) from a local configuration as a result of receiving an SMF for the DN Authorization AMBR or updated DAPI. The SMF may provide remote WTRU information (e.g., the number of remote WTRUs sharing the PDU session, a WTRU identifier of the remote WTRU, etc.) to the PCF to retrieve the updated session AMBR. The updated session AMBR may be sent to the relay WTRU. The DN Authorization AMBR and session AMBR update may be performed when (e.g., every time) a remote WTRU is added to share a PDU session.The relay WTRU may obtain (e.g., derive) a session AMBR for participating remote WTRUs (e.g., each participating remote WTRU), for example, based on a received session AMBR (e.g., from an SMF) and / or an algorithm. In an example, if the received session AMBR is incremented by an amount X (Mbps) after a remote WTRU is added to a PDU session, the relay WTRU may consider the amount X as the session AMBR for that remote WTRU. The relay WTRU may employ a more advanced algorithm (e.g., an algorithm that takes into account the priority of the remote WTRU and / or an algorithm that derives a session AMBR for a remote WTRU based on a statistical model for remote WTRU and / or relay WTRU traffic). In an example, the relay WTRU may have a statistical model for remote WTRU traffic and its own traffic and may distribute an aggregate AMBR among itself based on the model. For example, considering that remote WTRUs may not transmit or receive traffic at the same time, the aggregate of the derived AMBRs per remote WTRU (e.g., all derived AMBRs per remote WTRU) may exceed the received session AMBR. The relay WTRU may send the derived per-remote WTRU session AMBR to the remote WTRU via a ProSe connection (e.g., a PC5 connection). The relay WTRU may enforce the session AMBR among the participating remote WTRUs (e.g., all participating remote WTRUs) for UL traffic of the connection session (e.g., a PDU session). In an example, if the observed aggregate bit rate of the remote WTRUs exceeds the session AMBR, the relay WTRU may choose to buffer some traffic from a particular remote WTRU. The relay WTRU may dynamically update (e.g., reduce) the per-remote WTRU AMBR via the ProSe connection (e.g., a PC5 connection) to throttle traffic from the remote WTRU.When a remote WTRU is removed from a connected session (e.g., as a result of authorization revocation) or after a re-authentication procedure, the SMF may receive an updated DN authorization AMBR and / or DAPI and may retrieve an updated session AMBR (e.g., from the PCF or locally). The relay WTRU may receive the updated session AMBR and / or recalculate the derived AMBR for each remote WTRU.

[0165] The secondary A&A of the remote WTRU may be performed using the L3 U2NW and / or the N3IWF.

[0166] During the PC5 link establishment procedure with the relay, the remote WTRU may determine to access the network. For example, the remote WTRU may determine to access the 5GC via the N3IWF based on a provisioned ProSe / WTRU Route Selection Policy (URSP) policy. The connectivity service provided by the relay may be associated with the DN that is the subject of the secondary authentication.

[0167] The remote WTRU and relay may perform network controlled authorization to perform secondary A&A as described herein (eg, as described with respect to FIGS. 2 and 3).

[0168] In an example, if the remote WTRU receives a DCA message from the relay indicating that a secondary A&A is pending, the remote WTRU may refrain from establishing an IPsec connection with the N3IWF through the relay until the secondary A&A procedure is successfully completed.

[0169] In an example, if the remote WTRU receives an indication of successful Secondary A&A (e.g., a PC5 message including a successful Secondary A&A indication such as EAP success as described herein), the remote WTRU may establish an IPsec connection, session, and / or tunnel with the N3IWF via the relay based on a determination that the Secondary A&A procedure completed successfully.

[0170] NSSAA may be performed via an L3 U2NW relay. A link (e.g., a ProSe link or a PC5 link) may be set up with the relay using an S-NSSAI that is subject to NSSAA. During the link (e.g., a ProSe link or a PC5 link) establishment procedure between the remote WTRU and the relay, the relay may perform network-controlled authorization (e.g., extended network-controlled authorization) of the remote WTRU procedure to enable the remote WTRU to perform NSSAA for the S-NSSAI. The S-NSSAI that is subject to NSSAA may be associated with a connectivity service requested by the remote WTRU. The relay may provide the remote WTRU with access to the S-NSSAI, for example, based on completion of an NSSAA procedure by the remote WTRU.

[0171] The relay behavior may include one or more of the following: The relay may receive a connection request (e.g., a PC5 connection request) from a remote WTRU, which may include one or more of the remote WTRU's identity (e.g., SUCI), S-NSSAI, and / or the remote WTRU's NSSAA capabilities. The relay may determine that the S-NSSAI used by the ProSe connection (e.g., PC5 connection) may be subject to NSSAA based on local configuration and / or previous NSSAA performed by the relay for that S-NSSAI. The relay may request authorization (e.g., from the AMF) for relayed communication for the remote WTRU via a request message (e.g., a NAS request message). The message may include one or more of the remote WTRU identity, the requested S-NSSAI, and / or the remote WTRU's NSSAA capabilities. The relay may send a primary authentication message between the AMF and the remote WTRU. The relay may receive a response message (e.g., a NAS response message) confirming successful authorization of relayed communication for the remote WTRU. The response message may include one or more of the keying material bound to the S-NSSAI, the remote WTRU ID, an NSSAA status indication (e.g., successful, pending, or required), and / or the S-NSSAI. The relay may forward the NSSAA status indication and / or the S-NSSAI subject to the NSSAA to the remote WTRU via a ProSe (e.g., PC5) message (e.g., Direct Security Mode Command (DSMC)). The relay may trigger an NSSAA with the serving AMF for the remote WTRU via a request message (e.g., an NAS request message) including the remote WTRU ID and / or the S-NSSAI. The relay may send an NSSAA authentication message between the AMF and the remote WTRU. Based on receiving a NAS message from the AMF indicating a successful NSSAA for the remote WTRU, the relay may mark the S-NSSAI as authorized for the remote WTRU and / or send a ProSe message (e.g., PC5 message) informing the remote WTRU of the successful NSSAA.The relay may facilitate the establishment, modification of connection sessions (eg, PDU sessions) and / or may relay data traffic between the remote WTRU and the network.

[0172] FIG. 9 is a diagram illustrating an example of a ProSe (e.g., PC5) link setup with a relay using an S-NSSAI subject to NSSAA.

[0173] In 0a, a remote WTRU may be provisioned (e.g., with authorization parameters) to operate as a remote WTRU. In 0b, a relay WTRU may be provisioned (e.g., with authorization parameters) to operate as a relay WTRU. A relay may be registered for an S-NSSAI related to a service provided (e.g., broadcasted) by the relay, including, for example, for an S-NSSAI that is subject to an NSSAA.

[0174] At 1, the remote WTRU and the relay may perform discovery (eg, a discovery procedure).

[0175] In 2, the remote WTRU may determine (e.g., from the configuration provided in 0) that the relay service code and / or type discovered in 1 may be associated with an S-NSSAI that may be subject to NSSAA (e.g., based on the indication parameters for S-NSSAI). The remote WTRU may, for example, based on this determination, send a DCR message including one or more of the remote WTRU's subscription or network identity information (e.g., SUPI or GUTI) and / or an indication of WTRU support for NSSAA. The remote WTRU may include the requested S-NSSAI. For privacy reasons, the remote WTRU may decide whether to include the S-NSSAI in the DCR message based, for example, on configuration parameters (e.g., that may have been provided by the public land mobile network (PLMN) during a previous registration procedure). The configuration parameters may include the access stratum connection establishment NSSAI inclusion mode.

[0176] In 3, the relay may determine, based on receipt of the DCR message and / or the contents of the DCR message, that network-controlled authorization of the remote WTRU with NSSAA may be used to provide the remote WTRU access to the slice. The operation mode may be determined based on one or more of the following: The relay may be performing NSSAA for the S-NSSAI (e.g., as performed in 0). For example, during the NSSAA procedure, the S-NSSAI may be marked with an indication that it may be subject to NSSAA. Based on the configuration from 0, the provided service may be associated with the S-NSSAI that may be subject to NSSAA (e.g., based on the indication parameters for the S-NSSAI). The network-controlled authorization (e.g., with slice access permission) of the remote WTRU may include 3 through 8.

[0177] In 4, the relay may decide to trigger network-controlled authorization of the remote WTRU on the condition that the DCR message includes a SUCI or a GUTI. In an example, the relay may send an Identity Request message to the remote WTRU to obtain remote WTRU identity information to be used for performing network-controlled authorization (e.g., an authorization procedure) of the remote WTRU. The relay may send a request message (e.g., a NAS Relay Authorization Request message) to the AMF / Security Anchor Function (SEAF) including one or more of the remote WTRU ID (e.g., SUCI), S-NSSAI, and / or NSSAA capabilities of the remote WTRU.

[0178] In 5, the AMF may determine (e.g., check to determine) that the relay may be authorized to act as a relay and may be authorized to access or provide access to the S-NSSAI (e.g., the S-NSSAI may be part of the relay's WTRU authorization NSSAI). The AMF may decide to trigger a primary authentication procedure via the relay for the remote WTRU based on the determination (e.g., upon successful check).

[0179] At 6, the remote WTRU may perform a primary authentication procedure via the relay. The authentication message may be forwarded between the AMF and the relay on a NAS message. The NAS message may include an indication that the authentication message is for the remote WTRU (e.g., the remote WTRU's GPSI, a remote user ID, or any ID provided by the remote WTRU in the message at 2 to identify the remote WTRU). The relay may forward the message (e.g., transparently between the remote WTRU and the AMF).

[0180] In 7b, the AMF may determine (e.g., by checking with the remote WTRU's Unified Data Management (UDM)) based on the successful authentication procedure that the remote WTRU may be authorized to use the relay and / or has an S-NSSAI as part of its subscription. The AMF may verify (e.g., from capabilities received from the relay) that the remote WTRU supports NSSAA, for example, if the S-NSSAI is subject to NSSAA. The AMF may subscribe to the remote WTRU's UDM (e.g., including information about the serving relay), process UDM subscription notifications (e.g., further UDM subscription notifications), and / or process revocation and / or re-authentication requests for the remote WTRU from the AAA-S. Following a successful subscription-based authorization check, the AMF may generate material (e.g., keying material) for authorizing and / or enabling secure communication between the relay and the remote WTRU. The generated keying material may be obtained (e.g., derived) from keying material generated during primary authentication with the remote WTRU. The generated keying material may be bound to the S-NSSAI, for example, to enable strict enforcement of network slice access permissions (e.g., restricting relay communication between the remote WTRU and the relay to a particular slice). In 7a, the remote WTRU may generate keying material for securing communication with the relay (e.g., using a method similar to or the same as AMF), for example, based on a successful authentication procedure.

[0181] The remote WTRU may have successfully performed or initiated an NSSAA for S-NSSAI from a previous registration with the relay WTRU's AMF or another AMF, In such a case, the relay WTRU's AMF may retrieve the current NSSAA status from the remote WTRU context (e.g., from its local storage or from the remote WTRU's serving AMF as described in one or more examples herein, such as the example shown in FIG. 14).

[0182] In 8, the AMF may send a response message (e.g., a NAS response message) including one or more of the remote WTRU ID (e.g., GPSI or SUPI), the generated keying material, the S-NSSAI, and / or an indication of the NSSAA status (e.g., the current NSSAA status) based on the successful authentication procedure. The indication may indicate that the NSSAA should be performed, is in progress, or is successful (e.g., if initiated from a previous registration or is successfully performed) for the given S-NSSAI. If the primary authentication and / or subscription-based authorization check fails, the response message may indicate the cause of the failure (e.g., the S-NSSAI is not authorized for the remote WTRU).

[0183] At 9, the relay may establish ProSe link (e.g., PC5 link) security with the remote WTRU, for example, using the keying material generated from 7. In an example, in case of a failure indication via the message at 8, 9 may be skipped.

[0184] At 10, the relay may send an acknowledgement message (e.g., to the AMF) to confirm the ProSe link (e.g., PC5 link) security establishment. The AMF may trigger an NSSAA procedure based on receipt of the message, as described with respect to FIG. 10.

[0185] At 11, the relay may send a DCA message to the remote WTRU, including one or more of an NSSAA status (e.g., pending status, requested status, success status, etc.) and / or an indication about the S-NSSAI. In the case of a failure indication via the message at 8, the relay may send a rejection message to the remote WTRU (e.g., including the cause of the failure). The relay may assign an IP address and / or an IPv6 prefix to the remote WTRU. The relay may configure a traffic filter (e.g., as a default filter for IP traffic or non-IP traffic) of the PC5 link to prevent data traffic (e.g., any data traffic) until the subsequent NSSAA procedure is successfully completed (e.g., as shown at 12) and until PDU session establishment by the relay using the given S-NSSAI (e.g., which may be indicated by a message at 13) is successful (e.g., if not already established). Based on the indication in the DCA message, the remote WTRU may refrain from sending data traffic (e.g., any data traffic) over the PC5 link until the subsequent NSSAA procedure is successfully completed (e.g., after 13). For example, the remote WTRU may determine that the subsequent NSSAA is complete and may transmit data traffic over the PC5 link based on the determination of successful completion of the subsequent NSSAA.

[0186] At 12, if an NSSAA is performed (eg, requested), an NSSAA procedure for the remote WTRU via the relay may be triggered by the relay (eg, as described with respect to FIG. 10).

[0187] At 13, the relay may send a ProSe message (e.g., PC5 Link Modify Request) including a successful NSSAA Indication and / or S-NSSAI, e.g., based on successful completion of the NSSAA (e.g., NSSAA procedure). The relay may allocate an IP address and / or IPv6 prefix (e.g., if none was allocated in 11) for the remote WTRU to be used with the established connection session (e.g., established PDU session). If the NSSAA fails, the relay may release the ProSe (e.g., PC5) link, e.g., indicating the cause of the failure.

[0188] In an example, an NSSAA (e.g., 12 in FIG. 9) over relay procedure may be performed before 11 in FIG. 9. Based on a successful NSSAA (e.g., NSSAA procedure), the relay may send a DCA message including a successful NSSAA indication and / or S-NSSAI. In an example, if the NSSAA fails, the relay may send a reject message (e.g., a PC5 reject message) indicating the cause of the failure.

[0189] FIG. 10 is a diagram illustrating an example of NSSAA via relay procedure.

[0190] In 1a or 1b, the relay WTRU and / or the AMF may decide to trigger an NSSAA (e.g., an NSSAA procedure) for the remote WTRU based on one or more conditions, for example, as determined in Figure 11 or Figure 9. In an example, if the NSSAA is triggered by the AMF, 2 and 3 in Figure 10 may be skipped. In an example, if the NSSAA is triggered by the relay, 8 in Figure 10 may be skipped.

[0191] At 2, the relay may send a request message (eg, a NAS request message to the AMF) including the remote WTRU ID (eg, SUPI and / or GPSI) and / or S-NSSAI.

[0192] In 3, the AMF may determine (check and determine) that the relay is authorized to act as a relay, may allow or provide access for the S-NSSAI (e.g., the S-NSSAI may be part of the authorized NSSAI of the relay WTRU), and / or may perform an NSSAI for the remote WTRU to use the S-NSSAI (e.g., based on the S-NSSAI stored in the relay WTRU context / NSSAA status associated with the remote WTRU). The AMF may, for example, decide to trigger a primary authentication procedure via the relay for the remote WTRU based on the determination (e.g., based on the success of the check).

[0193] In 4, the remote WTRU may perform NSSAA (e.g., NSSAA procedure) via the relay. The authentication message may be forwarded on a NAS message between the AMF and the relay. The NAS message may, for example, include an indication (e.g., the GPSI and / or SUPI of the remote WTRU) to indicate to the relay that the authentication message is for the remote WTRU. The relay may forward the message (e.g., transparently) between the remote WTRU and the AMF. The AMF may receive authorization information (e.g., a time limit) from the AAA-S for the remote WTRU to use the S-NSSAI.

[0194] At 5, the AMF may update the S-NSSAI state associated with the remote WTRU in the relay WTRU context based on the successful NSSAA procedure (e.g., mark the S-NSSAI as allowed for the remote WTRU).

[0195] In 6, the AMF may send a message (e.g., a NAS message) to the relay indicating the result of the NSSAA (e.g., procedure), for example, including the identity of the remote WTRU and / or the S-NSSAI. The AMF may provide authorization information for the remote WTRU's use of the S-NSSAI as provided by the AAA-S. The message may include a NAS Relay Authorization Response and / or a NAS Relay Authorization Update Command.

[0196] At 7, the relay may, subject to a successful NSSAA, mark the remote WTRU as S-NSSAI authorized and / or store authorization information (e.g., any authorization information) for the remote WTRU's use of S-NSSAI.

[0197] At 8, the relay may send a message (e.g., a NAS message) to acknowledge the message received at 6 from the AMF. The message at 8 may be a NAS Relay Authorization Update Command Complete message. The message may include the remote WTRU ID and / or the S-NSSAI.

[0198] The relay WTRU may proceed with the remainder of the ProSe link (e.g., PC5 link) setup with the relay using the S-NSSAI subject to the NSSAA, for example, as described with respect to FIG. 11 or FIG. 9.

[0199] A reconnection to the relay using the S-NSSAI that is the subject of the NSSAA may be performed.

[0200] During a ProSe link (e.g., PC5 link) reconnection procedure between a remote WTRU and a relay using network-controlled authorization, the relay may enable the remote WTRU to obtain access to an authorized S-NSSAI from a previous successful completion of the NSSAA (e.g., procedure) and / or to perform the NSSAA via the relay.

[0201] During a PC5 link reconnection procedure with network-controlled authorization, the relay may determine whether the remote WTRU can be authorized to use the S-NSSAI that is subject to the NSSAA, for example, based on locally stored slicing information associated with the remote WTRU (e.g., retrieved based on a Krelay ID provided by the remote WTRU). In an example, if the remote WTRU is not authorized for the S-NSSAI, the relay may trigger an NSSAA with the serving AMF for the remote WTRU via a request message (e.g., a NAS request message including the remote WTRU ID and / or S-NSSAI). If the S-NSSAI is marked as rejected, the relay may reject the link establishment request. If the relay decides to trigger an NSSAA with the AMF, the relay may perform a procedure based on one or more examples described herein, such as the examples described with respect to FIG. 9 or FIG. 10.

[0202] FIG. 11 is a diagram illustrating an example of a remote WTRU reconnecting to a relay WTRU using an S-NSSAI subject to NSSAA with a previous authorization.

[0203] In 0a and 0b, the remote WTRU and the relay may have established a previous connection using an S-NSSAI that is subject to NSSAA. Following the link release, the relay may have notified the AMF about the link release. The relay WTRU may retain one or more of the Krelay ID and / or associated S-NSSAI authorization information, for example, based on the AMF response.

[0204] At 1, the remote WTRU and the relay may perform discovery (eg, a discovery procedure).

[0205] At 2, the remote WTRU may send a DCR message that includes one or more of the remote WTRU's subscription or network identification information (e.g., SUPI or GUTI), an indication of WTRU support for NSSAI, and a Krelay ID. The remote WTRU may include the requested S-NSSAI.

[0206] In 3, the relay may retrieve the Krelay using the Krelay ID. In an example, if associated valid S-NSSAI authorization information for the remote WTRU is available, the relay may skip 4 and 6 in FIG.

[0207] At 4, the relay may initiate network-controlled authorization (eg, via the relay) of the remote WTRU (eg, as described with respect to FIG. 9 or FIG. 14).

[0208] At 5, the relay may establish ProSe link (eg, PC5 link) security using the Krelay from the previous connection or a different Krelay (eg, a new Krelay if received during 4).

[0209] At 6, an NSSAA (eg, procedure) for the remote WTRU via the relay may be performed (eg, as described with respect to FIG. 10).

[0210] At 7, the relay may send a DCA message containing a successful NSSAA indication, S-NSSAI, or a reject message indicating the cause of the failure (e.g., a PC5 reject message).

[0211] Revocation of authorization to use an S-NSSAI subject to NSSAA through a relay may be performed by the AAA.

[0212] During the procedure for S-NSSAI revocation of authorization by the AAA, the relay may enable revocation of authorization for the remote WTRU to use the S-NSSAI that was authorized from a previous successful completion of the NSSAA procedure via the relay using network-controlled authorization.

[0213] During S-NSSAI authorization revocation by the AAA, the relay may, for example, receive a message (e.g., a NAS Command message) from the AMF including a remote WTRU ID and S-NSSAI indicating the revocation of authorization for the remote WTRU to use the S-NSSAI. The relay may perform one or more of the following: discard locally stored S-NSSAI information associated with the remote WTRU; mark / store the S-NSSAI as denied for the remote WTRU; and discard information (e.g., all information) associated with the remote WTRU, including key material from a previous network-controlled authorization procedure (e.g., if key material is bound to the S-NSSAI). The relay may perform a direct link release procedure with the remote WTRU and / or notify the remote WTRU via a ProSe message (e.g., a PC5 message) that authorization for the S-NSSAI has been revoked. The relay may send a NAS Command Acknowledge message to the AMF to confirm the S-NSSAI revocation at the relay.

[0214] FIG. 12 is a diagram illustrating an example of revocation of a remote WTRU using an S-NSSAI subject to an NSSAA via a relay WTRU.

[0215] In 0a and 0b, the remote WTRU may connect to the relay WTRU using an S-NSSAI that is subject to NSSAA.

[0216] In 1, the AMF may receive a revocation request from the AAA-S, for example, via a network slice specific authentication and authorization function (NSSAAF). The request may include the GPSI of the remote WTRU. The NSSAAF may request the UDM to obtain the AMF ID of the AMF serving the remote WTRU. The NSSAAF may obtain the relay's identity when querying the UDM. In such a case, the NSSAAF may provide the AMF with the relay WTRU's identity (e.g., SUPI and / or GPSI).

[0217] In 2, the AMF may locate the relay WTRU context based on the identification information provided by the NSSAAF. The AMF may remove the association between the remote WTRU and the S-NSSAI (e.g., NSSAA status) in the relay WTRU context. In an example, if no other S-NSSAI is used for the remote WTRU, the AMF may remove the remote WTRU information from the relay WTRU context. The AMF may, for example, deregister from the UDM of the remote WTRU if the remote WTRU information is removed from the relay WTRU context.

[0218] In 3, the AMF may send a message (e.g., a NAS command message) including the remote WTRU ID (e.g., GPSI and / or SUPI) and / or S-NSSAI to the relay to revoke the remote WTRU's permission to use the S-NSSAI.

[0219] In 4, the relay WTRU may discard the S-NSSAI authorization information associated with the remote WTRU and / or mark the S-NSSAI authorization information as denied for the remote WTRU. If Krelay and / or ID are bound to the S-NSSAI, the relay may discard Krelay and / or ID.

[0220] At 5, the relay may initiate a link release procedure, for example, if a remote WTRU is connected to the relay.

[0221] In 6, the relay may send a message (e.g., a NAS message) to the AMF to acknowledge receipt of the message in 3. The message may be a NAS Relay Release Complete message. The message may include the remote WTRU ID and / or the S-NSSAI.

[0222] The re-authentication and / or authorization procedure may use one or more of 0a, 0b, and 1-6 in Figure 12. In an example, the re-authentication and / or authorization procedure may be similar to the de-authorization procedure, except for one or more of the following differences: the AMF may trigger an NSSAA of the remote WTRU via a relay procedure (e.g., as described with respect to Figure 10) based on, for example, receiving a re-authentication request from the AAA-S, and if the re-authentication fails, it may perform 3, 4, 5, and / or 6 in Figure 12.

[0223] FIG. 13 is a diagram illustrating an example of revocation of a relay WTRU using an S-NSSAI subject to NSSAA via a relay WTRU.

[0224] In 0a and 0b, the remote WTRU may connect to the relay WTRU using an S-NSSAI that is subject to NSSAA.

[0225] In 1, the AMF may receive a revocation request from the AAA-S via the NSSAAF. The request may include the GPSI and / or S-NSSAI of the relay WTRU. The NSSAAF may request the UDM to obtain (e.g., retrieve) the identity of the AMF serving the relay WTRU.

[0226] In 2, the AMF may locate the relay WTRU context based on the identification information provided by the NSSAAF. For a remote WTRU (e.g., each remote WTRU) associated with the revoked S-NSSAI, the AMF may remove the association of the remote WTRU with the S-NSSAI (e.g., NSSA status) from the relay WTRU context, and if no other S-NSSAI can be used for the remote WTRU, the AMF may remove the remote WTRU information from the relay WTRU context. Or, the AMF may deregister from the UDM of the remote WTRU if the remote WTRU information can be removed from the relay WTRU context.

[0227] At 3, the AMF may initiate a UCU procedure with the relay to revoke permission for the relay to use the S-NSSAI.

[0228] In 4, for a remote WTRU (e.g., each remote WTRU) associated with the revoked S-NSSAI, one or more of the following may be performed: the relay WTRU may discard the S-NSSAI authorization information associated with the remote WTRU; and, if Krelay is bound to the S-NSSAI, the relay may discard the S-NSSAI.

[0229] At 5, for a remote WTRU (eg, each remote WTRU) connected to the relay and associated with the revoked S-NSSAI, the relay may initiate a link release procedure.

[0230] At 6, the relay may send a message (e.g., a NAS message such as UCU Complete) to acknowledge the message received at 3.

[0231] The NSSAA of the remote WTRU may be performed using the L3 U2NW and / or the N3IWF.

[0232] During the PC5 link establishment procedure with the relay, the remote WTRU may determine to access the network. For example, the remote WTRU may determine to access the 5GC via the N3IWF, for example, based on a provisioned ProSe / URSP policy. The connectivity service provided by the relay may be associated with an S-NSSAI that is subject to the NSSAA.

[0233] The remote WTRU and / or relay may perform an enhanced network controlled authorization procedure to perform the NSSAA as described herein (eg, as described with respect to FIGS. 9 and 10).

[0234] In an example, if the remote WTRU receives a DCA message from the relay indicating that an NSSAA is pending, the remote WTRU may refrain from establishing an IPsec connection with the N3IWF through the relay until successful completion of the NSSAA procedure.

[0235] In an example, if the remote WTRU receives a successful NSSAA indication (e.g., a PC5 message including a successful NSSAA indication as described herein), the remote WTRU may establish an IPsec connection, session, and / or tunnel with the N3IWF via the relay based on a determination of successful completion of the NSSAA procedure.

[0236] The connection via the L3 WTRU2NW relay may be established using a security context, which may be a 5G native security context.

[0237] During a ProSe link (e.g., PC5 link) connection procedure between a remote WTRU and a relay using network-controlled authorization, the relay may allow the remote WTRU to gain access to the network via the relay according to a previous successful registration procedure by using its security context, which may be a 5G native security context.

[0238] The remote WTRU may have registered with the network and established a security context, such as a 5G native security context. The remote WTRU may perform discovery (e.g., a discovery procedure) with the relay WTRU and decide to connect with the relay using that security context, which may be a 5G native security context. The remote WTRU may send a DCR message to the relay, including one or more of the following parameters: a core network identity (e.g., a GUTI, which may be a 5G-GUTI) of the remote WTRU; a keyset identifier (e.g., in 5G) (ngKSI) that identifies the key being used (e.g., a key shared with the AMF), and / or the NAS security capabilities of the remote WTRU. The parameters may be included, for example, in an integrity protection message (IPM) protected using the security context of the remote WTRU (e.g., key K NASintIn an example, the remote WTRU may provide its core network identity in response to an identity request message from the relay and / or network. The remote WTRU may receive a message (e.g., a DSMC message) from the relay, which may include a Krelay ID and / or a set of security parameters forwarded from the network (e.g., AMF), which may include one or more of a KAMF key change flag, an ngKSI identifying the KAMF to be used, or the remote WTRU's security capabilities (e.g., sent via a DCR). If the KAMF change flag is set, the remote WTRU may obtain (e.g., derive) a second KAMF from the first KAMF indicated by the value of the ngKSI. In an example, the second KAMF may be a new KAMF. The remote WTRU may obtain (e.g., derive) a Krelay and a Krelay ID based on the first KAMF (e.g., an existing KAMF) or the obtained KAMF (e.g., a newly derived and / or second KAMF). The remote WTRU may verify the DSMC message security, which may include determining (e.g., checking) that the received remote WTRU NAS security capabilities match those sent to the relay via the connection request message. The remote WTRU may verify the integrity protection of the DSMC message, for example, using an integrity key obtained based on the Krelay indicated by the Krelay ID. If the security verification is successful, the remote WTRU may send a direct security mode complete message to the relay with security protection (integrity and / or confidentiality using the security key obtained based on the Krelay). The remote WTRU may receive a DCA message successfully completing the ProSe link (e.g., PC5 link) establishment.

[0239] FIG. 14 is a diagram illustrating an example of a ProSe link (e.g., PC5 link) setup with a relay using a remote WTRU security context, which may be a 5G native security context.

[0240] In step 0, the remote WTRU may be registered with the network and may establish a security context, which may be a 5G native security context, with an AMF (e.g., a source AMF). The relay WTRU may be registered and / or authorized to operate as a relay.

[0241] In 1, the remote WTRU may perform discovery (eg, a discovery procedure) with the relay WTRU and determine to connect with the relay using its security context, which may be a 5G native security context.

[0242] In 2, the remote WTRU may send a DCR message to the relay that includes one or more of the following parameters: the remote WTRU's core network identity (e.g., GUTI, which may be 5G-GUTI), an ngKSI that identifies the KAMF being used, or the remote WTRU's NAS security capabilities. The parameters may be included in an IPM protected using the remote WTRU's security context, which may include a key K NASint In an example, the remote WTRU may provide its identity in response to an identity request message from the relay.

[0243] In 3, the relay may send the remote WTRU GUTI, which may be 5G-GUTI, and / or the remote WTRU's IPM to the serving AMF (e.g., target AMF) of the relay WTRU, for example, via a request message (e.g., a NAS request message) for relay authorization.

[0244] At 4, the target AMF may determine (e.g., check to determine) that the relay may be allowed to operate as a relay.

[0245] In 5, the target AMF may identify the source AMF serving the remote WTRU using the provided GUTI, which may be, for example, 5G-GUTI. In an example, if the source and target AMF are different, the target AMF may send a request message to the source AMF to obtain security parameters for the remote WTRU from the source AMF. The target AMF may include the IPM of the remote WTRU received from the relay and / or the remote WTRU's identification information. The target AMF may indicate that the access type and / or the reason for the request is for relay access. If the source and target AMF are the same (e.g., the remote WTRU is registered with the target AMF), the target AMF may retrieve the remote WTRU context directly from its local storage (e.g., skip 5 and 6 in FIG. 14).

[0246] In 6, the source AMF may use the received remote WTRU's GUTI, which may be 5G-GUTI, to locate the remote WTRU's security context. The source AMF may use the remote WTRU's security context to evaluate (e.g., check) the integrity protection of the remote WTRU's IPM. In an example, if the security check is successful, the source AMF may obtain (e.g., derive) a Krelay and a Krelay ID from the KAMF identified by the ngKSI. If the security check is not successful, the source AMF may create a different security context (e.g., a new 5G security context). The source AMF may send a response message including the remote WTRU SUPI to the target. The message may include, for example, a Krelay and a Krelay ID, a different security context to be used for the remote WTRU, which may be a different 5G security context (e.g., a new 5G security context), or the current remote WTRU's security context, which may be a 5G security context, along with a KAMF change instruction.

[0247] In 7, the target AMF may check using the remote WTRU's context (e.g., if provided by the source AMF) or the remote WTRU's UDM (e.g., using the provided SUPI) for permission to use the relay. If not provided by the source AMF, the target AMF may obtain (e.g., derive) the Krelay and Krelay ID using the remote WTRU's security context.

[0248] In 8, the target AMF may send a response message (e.g., NAS response message) to the relay including the remote WTRU ID (e.g., GPSI and / or SUPI) and / or the Krelay and Krelay ID. If a different security context (e.g., a new security context) was previously created by the source AMF, the message may include a KAM change flag and / or a different ngKSI (e.g., a new ngKSI).

[0249] In 9, the relay may send a DSMC message to the remote WTRU including one or more of a Krelay ID, a KAMF change flag, and / or a different ngKSI, if provided by the target AMF. The message may be integrity protected, for example, using a security key derived based on Krelay.

[0250] At 10, if the KAMF change flag is set, the remote WTRU may obtain a different KAMF (e.g., derive a new KAMF) from the KAMF indicated by the value of ngKSI. The remote WTRU may obtain (e.g., derive) a Krelay and a Krelay ID from the first KAMF (e.g., an existing KAMF) or from a obtained (e.g., newly derived and / or second KAMF). The remote WTRU may verify DSMC message security using, for example, the security key obtained based on the Krelay.

[0251] At 11, if the security verification is successful, the remote WTRU may send a direct security mode complete message to the relay with security protection (e.g., integrity and / or confidentiality) using the security key obtained based on Krelay.

[0252] At 12, the remote WTRU may receive a DCA message completing the ProSe link (eg, PC5 link) establishment.

[0253] The procedures described herein may be combined with NSSAA via a relay procedure as described with respect to Figure 9. In an example, if the service provided by the relay is associated with an S-NSSAI that is subject to NSSAA, the target AMF may retrieve slicing authorization information (e.g., the allowed NSSAI and / or the NSSAA status) from the source AMF that holds the remote WTRU context (e.g., as shown in Figure 14, 5 and 6). The NSSAA procedure described with respect to Figure 10 may be skipped based on whether the S-NSSAI is authorized pending NSSAA, etc. For example, if the S-NSSAI that is subject to NSSAA is authorized (e.g., already authorized) for the remote WTRU or if the NSSAA is pending (e.g., in progress), the AMF may determine not to initiate the NSSAA procedure for the remote WTRU as described in Figure 10. The AMF may grant the remote WTRU access to the slice as part of the ProSe link setup or may wait until the NSSAA procedure is successfully completed, respectively.

[0254] 15 illustrates an example 1500 of a link setup with a relay using a connection session that is subject to secondary A&A. At 1502, a relay WTRU may receive a direct communication request (DCR) from a remote WTRU requesting a connection service (e.g., connection session parameters such as an S-NSSAI, a data network name (DNN), and / or the like). At 1504, the relay may determine that the connection session for the service is subject to secondary A&A, e.g., based on an indication related to the connection session if already established and / or an indication related to the DN from a relay proximity services (ProSe) configuration. At 1506, for example, based on the determination, the relay may trigger a network-controlled admission to the remote WTRU. At 1508, the relay WTRU may send a direct communication accept (DCA) message (e.g., including a pending secondary A&A indication) and configure a traffic filter associated with the connection (e.g., a PC5 link) to discard data traffic from the remote WTRU until the secondary A&A is successfully completed. At 1510, the relay WTRU may send a request message (e.g., an Access Stratum (NAS) Request message) to a Session Management Function (SMF) (e.g., including the remote WTRU ID) to initiate a connection session secondary A&A for the remote WTRU. The relay may transparently forward EAP authentication messages between the WTRU and the AMF and / or SMF (e.g., the NAS message may include the remote WTRU ID to indicate that the EAP message authenticates the remote WTRU). At 1512, the relay WTRU may send a secondary AA authentication message between the SMF and the remote WTRU. At 1514, the relay WTRU may receive a NAS Response message from the SMF including a successful A&A indication, an EAP success message, and / or remote WTRU authorization information (e.g., an IP address to which the DN is assigned and / or an aggregate maximum bit rate (AMBR) for the session to which the DN is allocated).At 1516, the relay WTRU may configure a link traffic filter to allow data traffic between the remote WTRU and the network / DN, e.g., based on the success, and may notify the remote WTRU by including an EAP success message in a link modification procedure. At 1518, the relay WTRU may relay data traffic between the remote WTRU and the network and / or DN. FIG. 16 illustrates an example 1600 of a link setup with a relay using an S-NSSAI that is subject to NSSAA. At 1602, the relay WTRU may receive a DCR from the remote WTRU, e.g., including the remote WTRU's identity (e.g., SUCI), S-NSSAI, and / or the remote WTRU's NSSAA capabilities. At 1604, the relay WTRU may determine that the S-NSSAI used by the ProSe connection (e.g., PC5 connection) is subject to NSSAA, e.g., based on local ProSe configuration and / or a previous NSSAA performed by the relay for that S-NSSAI. At 1606, the relay WTRU may send a NAS request message to the AMF including the remote WTRU identity, the requested S-NSSAI, and / or the remote WTRU's NSSAA capabilities to initiate network-controlled authorization of the remote WTRU. The relay WTRU may send a primary authentication message between the AMF and the remote WTRU. At 1608, the relay WTRU may receive a response message (e.g., a NAS response message) including keying material, the remote WTRU ID, an NSSAA status indication (e.g., one of success, pending, or request), and / or the S-NSSAI, which may be bound to the S-NSSAI. At 1610, the relay WTRU may send a Direct Security Mode Command (DSMC) message to the remote WTRU including the NSSAA status indication and / or the S-NSSAI. The NSSAA procedure may be triggered by the relay WTRU (e.g., via the NAS request) or by the AMF. At 1612, the relay WTRU may send an NSSAA authentication message between the AMF and the remote WTRU.At 1614, the relay WTRU may receive a NAS message from the AMF including the remote WTRU ID, NSSAA result, and / or S-NSSAI. The relay may store the S-NSSAI as authorized for the remote WTRU. At 1616, the relay WTRU may send a ProSe (e.g., PC5) message (e.g., Link Modify Request) including the successful NSSAA indication and / or S-NSSAI. At 1618, the relay WTRU may enable the remote WTRU to use the S-NSSAI (e.g., with a connection session using the S-NSSAI). The connection may be established via the relay WTRU using the remote WTRU's identity (e.g., the GUTI, which may be 5G-GUTI).

[0255] In the examples described herein, the remote WTRU and / or relay WTRU may determine whether the remote WTRU's security context (e.g., the remote WTRU's security context, which may be a 5G native security context) can be used with the relay WTRU's serving PLMN.

[0256] FIG. 17 illustrates an example in which a remote WTRU may determine whether to use its identity (e.g., a GUTI, which may be a 5G-GUTI) based on PLMN information received during a discovery procedure (e.g., a discovery procedure using a relay WTRU).

[0257] In the example described with respect to FIG. 17, the remote WTRU may determine whether it can use the remote WTRU's identification information (e.g., the remote WTRU's GUTI, which may be 5G-GUTI) to connect via the relay WTRU.

[0258] At 1702, the remote WTRU may receive the relay WTRU's serving network ID (e.g., PLMN ID) via a discovery message from the relay WTRU during a discovery procedure. The discovery message may include information indicating the relay WTRU's serving PLMN ID. The relay WTRU may broadcast its PLMN ID along with a service code provided by the relay WTRU (e.g., using ProSe Discovery Model A). The relay WTRU may send a response message including the relay WTRU's PLMN ID in response to a message (e.g., a solicitation message and / or a request message) from the remote WTRU (e.g., using ProSe Discovery Model B).

[0259] At 1704, the remote WTRU may determine whether the remote WTRU has a security context, which may be a 5G native context, established with the relay's WTRU serving PLMN, for example, by matching the PLMN ID portion of the GUTI (e.g., 5G-GUTI) with the PLMN ID received from the relay WTRU. The remote WTRU may evaluate or determine (e.g., check to determine) whether the received relay WTRU's serving PLMN ID matches the PLMN ID portion of the remote WTRU's GUTI (e.g., 5G-GUTI). In an example, the GUTI may include a PLMN ID (e.g., PLMN ID portion), an AMF ID (e.g., AMF ID portion), and / or an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., S-TMSI portion). If the received relay WTRU's serving PLMN ID is equal to a PLMN ID that is part of the GUTI, the received relay WTRU's serving PLMN ID may match the PLMN ID portion of the remote WTRU's GUTI (e.g., 5G-GUTI).

[0260] At 1706, if a match is found for the received relay WTRU's serving PLMN ID, the remote WTRU may send a message (e.g., a DCR message) to the relay WTRU. The message may include the remote WTRU's identifier (e.g., 5G-GUTI) associated with the received relay WTRU's serving PLMN ID, e.g., the remote WTRU's corresponding 5G-GUTI. The remote WTRU may connect (e.g., proceed with connection through the relay) via the relay WTRU using a security context, which may be a 5G native security context associated with the remote WTRU's identifier (e.g., 5G-GUTI) as illustrated in one or more examples herein. If no match is found, the remote WTRU may send a different remote WTRU's identifier (e.g., the remote WTRU's SUCI) via the DCR message and / or the remote WTRU may not send the remote WTRU's GUTI (e.g., 5G-GUTI).

[0261] FIG. 18 illustrates an example in which a relay WTRU may determine whether to use a remote WTRU identifier (e.g., 5G-GUTI) received during a link establishment procedure (e.g., a remote WTRU identifier received in a DCR).

[0262] In the example described with respect to FIG. 18, the relay WTRU may determine whether the identifier of the remote WTRU (e.g., 5G-GUTI) provided by the remote WTRU via the DCR message can be used to connect via the relay WTRU.

[0263] At 1802, the relay WTRU may receive a message (e.g., a first DCR message) from a remote WTRU. The message may include an identifier (e.g., 5G-GUTI) of the remote WTRU.

[0264] At 1804, the relay WTRU may evaluate and / or determine (e.g., check and determine) whether the relay WTRU's serving network ID (e.g., the relay WTRU's own serving PLMN ID) matches the PLMN ID portion of the remote WTRU's identifier (e.g., 5G-GUTI).

[0265] At 1806, if a match is found for the relay WTRU's serving network ID (e.g., PLMN ID), the relay WTRU may perform (e.g., proceed to perform) an attachment procedure (e.g., a network-controlled authorization procedure with the network (e.g., AMF)) using the remote WTRU's security context, which may be, for example, a 5G native security context as described herein. If a match is not found for the relay WTRU's serving network ID (e.g., PLMN ID), the relay WTRU may reject the remote WTRU's attachment request and / or the relay WTRU may indicate the cause of the rejection (e.g., that the provided 5G-GUTI is not valid for the relay's serving PLMN). If the relay WTRU rejects the remote WTRU's attachment request, the remote WTRU may send a second DCR (e.g., new DCR) message. The second DCR message may include a different remote WTRU identifier (eg, a SUCI of the remote WTRU) and / or may not include a remote WTRU identifier, which may be a GUTI, such as a 5G-GUTI.

[0266] FIG. 19 illustrates an example in which a relay WTRU may determine whether to use a remote WTRU identifier (e.g., 5G-GUTI) received during a link establishment procedure (e.g., a remote WTRU identifier received in association with an identification information request).

[0267] In the example described with respect to FIG. 19, the relay WTRU may determine whether the remote WTRU's identifier (e.g., 5G-GUTI) provided by the remote WTRU in the identity response message can be used to connect via the relay WTRU.

[0268] At 1902, the relay WTRU may receive a DCR message from a remote WTRU for a connectivity service (e.g., a connectivity service that requires network-controlled authorization). The DCR message may not include (e.g., any) remote WTRU identity (e.g., the remote WTRU's network identity, such as SUCI or 5G-GUTI). The relay WTRU may determine that the remote WTRU's identity (e.g., the remote WTRU's network identity) should be used and / or required to connect via the relay WTRU (e.g., if network-controlled authorization is required for the connectivity service provided as illustrated in one or more examples herein).

[0269] At 1904, the relay WTRU may send an identity request message to the remote WTRU. The identity request message may include the relay WTRU's serving network ID (e.g., PLMN ID) and / or an instruction for the remote WTRU to provide the remote WTRU's identity (e.g., the remote WTRU's network identity).

[0270] The remote WTRU may evaluate and / or determine (e.g., check to determine) whether the received relay WTRU's serving PLMN ID matches the PLMN ID portion of the remote WTRU's identifier (e.g., the remote WTRU's 5G-GUTI). If a match is found, the remote WTRU may transmit the remote WTRU's identifier (e.g., a GUTI, such as 5G-GUTI). If a match is not found, the remote WTRU may transmit the remote WTRU's SUCI.

[0271] At 1906, the relay WTRU may receive an identity response message. The identity response message may include an identifier of the remote WTRU (e.g., 5G-GUTI).

[0272] At 1908, the relay WTRU may evaluate and / or determine (e.g., check to determine) whether the PLMN ID portion (e.g., 5G-GUTI) of the remote WTRU's identity matches the relay WTRU's serving PLMN ID. At 1910, if a match is found, the relay WTRU may perform (e.g., proceed with) an attachment procedure with the network (e.g., AMF) using the remote WTRU's 5G native security context, e.g., as illustrated in one or more examples herein. For example, the attachment procedure may include a network-controlled authorization procedure. If no match is found for the PLMN ID, the relay WTRU may reject the remote WTRU's attachment request and / or indicate the cause of the rejection (e.g., that the provided 5G-GUTI is not valid for the relay's serving PLMN). If the identity response message includes the remote WTRU's SUCI, the relay WTRU may perform (e.g., proceed with) the attachment procedure using the remote WTRU's SUCI, e.g., as illustrated in one or more examples herein.

[0273] Relay traffic filtering to the N3IWF may be performed for remote WTRU authentication and authorization to access network resources (eg, PDU sessions / slices).

[0274] A relay provisioned with an RSC using N3IWF access may determine, during a PC5 link establishment procedure with a remote WTRU requesting RSC, to enforce restricted connectivity to enable the remote WTRU to establish an IPsec connection with the N3IWF. The remote WTRU may determine to select an N3IWF in the relay's serving PLMN based on the N3IWF selection procedure (e.g., based on PLMN ID, tracking area identification information). In an example, the remote WTRU may determine to select an N3IWF in the remote WTRU's HPLMN based on the remote WTRU's N3IWF identifier configuration (e.g., the FQDN or IP address of the N3IWF in the HPLMN).

[0275] The behavior of a relay WTRU (eg, using an N3IWF in the relay's serving PLMN) may include one or more of the following:

[0276] The relay WTRU may receive a connection request (e.g., a PC5 connection request message) including an RSC requesting N3IWF access and an instruction to use the local N3IWF (e.g., an instruction that the remote WTRU wants to use the local N3IWF).

[0277] The relay WTRU may determine the IP address of the local N3IWF in the relay's serving PLMN using an N3IWF selection procedure similar to that used by a remote WTRU, which may use, for example, the serving PLMN ID and / or the TAI corresponding to the serving cell.

[0278] The relay WTRU may establish a connection session (eg, a PDU session) (eg, if not already established) to enable communication between the remote WTRU and the local N3IWF.

[0279] The relay WTRU may, for example, provide the PLMN ID and TAI to the remote WTRU in a connection response (e.g., a PC5 connection response message) to assist the remote WTRU in the N3IWF selection procedure. In some examples, the relay WTRU may provide the remote WTRU with an IP address or FQDN for the local N3IWF selected by the relay WTRU above.

[0280] The relay WTRU may allocate an IPv6 prefix or an IPv4 address to the remote WTRU and / or configure a traffic filter (eg, a traffic filter for the PC5 link that only allows traffic between the remote WTRU and the local N3IWF).

[0281] The behavior of a relay WTRU (eg, using an N3IWF in the HPLMN of the remote WTRU) may include one or more of the following.

[0282] The relay WTRU may receive a connection request (e.g., a PC5 connection request message) including an RSC requesting an N3IWF and an indication that the remote WTRU wishes to use the remote WTRU's HPLMN N3IWF (e.g., including the FQDN or IP address of the N3IWF in the remote WTRU's HPLMN) and the remote WTRU's HPLMN ID.

[0283] The relay WTRU shall verify that the provided N3IWF address is a valid operator-identifier-based N3IWF FQDN (e.g., n3iwf.5gc.mnc <mnc>.mcc <mcc>.pub.3gppnetwork.org), where the MNC and / or MCC matches the remote WTRU's HPLMN ID. The relay WTRU may verify that the remote WTRU is authorized to use the N3IWF in the remote WTRU's HPLMN if the HPLMN ID is part of a configured list of PLMNs (e.g., associated with the requested RSC).

[0284] The relay WTRU may establish a connection session (eg, a PDU session) (eg, if not already established) to enable communication between the remote WTRU and the N3IWF.

[0285] The relay WTRU may allocate an IPv6 prefix or an IPv4 address to the remote WTRU and / or configure a traffic filter (e.g., a traffic filter for the PC5 link that only allows traffic between the remote WTRU and the N3IWF in the remote WTRU's HPLMN).

[0286] A relay wireless transmit / receive unit (WTRU) may be provided. The WTRU may include a processor. The processor may be configured to perform several actions. A request for a connection session associated with a network may be received from a remote WTRU. It may be determined that the connection session associated with the network is subject to network-controlled authorization. A request message may be sent to the network to trigger network-controlled authorization. An authentication message may be received from the network. The authentication message may be sent to the remote WTRU.

[0287] In one example, a response message may be received from the network indicating the status of the network-controlled authorization. An indication of the status of the network-controlled authorization may be sent to the remote WTRU. A traffic filter may be determined to allow / not allow data traffic from the remote WTRU. The traffic filter may be applied to the data traffic.

[0288] In one example, it may be determined that a Single Network Slice Selection Assistance Information (S-NSSAI) associated with the connection session may be subject to Network Slice Specific Authentication and Authorization (NSSAA). A response message may be received from the network. The response message may comprise an indication of the S-NSSAI and / or NSSAA status. A Direct Communication Accept (DCA) message may be sent to the remote WTRU. The DCA message may comprise the S-NSSAI and an indication of the NSSAA status.

[0289] In one example, a non-access stratum (NAS) message may be received from the network. The NAS message may comprise an S-NSSAI and / or an indication of the outcome of the NSSAA. Provided the outcome of the NSSAA is successful, the S-NSSAI may be stored and a message may be sent to the network. The message sent to the network may comprise the S-NSSAI and an identifier of the remote WTRU.

[0290] In one example, the request for the connection session may include a globally unique temporary identifier (GUTI) associated with the remote WTRU. It may be determined whether a serving public land mobile network (PLMN) ID associated with the relay WTRU matches the PLMN ID portion of the GUTI. Network-controlled authorization for the remote WTRU may be triggered using the GUTI associated with the remote WTRU if the serving PLMN ID associated with the relay WTRU matches the PLMN ID portion of the GUTI.

[0291] In one example, an identity request message may be sent. The identity request message may comprise a serving PLMN ID associated with the relay WTRU and / or an instruction to request the identity of the remote WTRU. An identity response message may be received from the remote WTRU. The identity response message may include the GUTI of the remote WTRU.

[0292] In one example, a relay service code (RSC) and instructions to connect with a non-3GPP interworking function (N3IWF) may be received. The N3IWF may be identified. An IPv6 prefix or an IPv4 address may be allocated to the remote WTRU. A traffic filter may be configured to allow traffic between the remote WTRU and the N3IWF.

[0293] In one example, an indication of a type of N3IWF may be received, which may include a local N3IWF of the remote WTRU and / or a visited public land mobile network (HPLMN) N3IWF.

[0294] In one example, the traffic filter may allow traffic between the remote WTRU and the N3IWF.

[0295] When a ProSe connection (e.g., a PC5 connection) is established, the relay WTRU may enable traffic between the remote WTRU and the N3IWF to establish an IPsec connection, and may enable the remote WTRU to perform NAS registration (e.g., including NSSAA) and connection session establishment (e.g., PDU session establishment including secondary authentication) via the relay / N3IWF.

[0296] In an example, a first WTRU may receive a first message from a second WTRU. The first message may indicate a request for a data session associated with a data network. The first WTRU may send a second message to the second WTRU, for example, if a primary authentication associated with the second WTRU is successful. The second message may indicate that a secondary authentication associated with the second WTRU is pending. The first WTRU may receive a third message from the data network. The third message may indicate that a secondary authentication associated with the second WTRU is successful and that the second WTRU is authorized to access the data session. The first WTRU may send a fourth message to the second WTRU, for example, if the secondary authentication is successful. The first message may be associated with the data session.

[0297] In an example, the first message may indicate one or more of an identity of the first WTRU or capabilities associated with an authentication service. The second message may indicate one or more of an authentication service, an identity associated with the authentication service, or an identity of a server providing the authentication service. The third message may indicate one or more of a user identity, data associated with an authentication protocol, authorization information for a data session, or data associated with a link modification procedure. The fourth message may indicate a service identity. The first WTRU may determine that the second WTRU is subject to primary authentication and that access to the data session is subject to secondary authentication. The first WTRU may send a fifth message to the second WTRU. The fifth message may indicate a request for the second WTRU to perform procedures associated with primary authentication. In an example, the first WTRU may send a sixth message to the second WTRU. The sixth message may indicate a request for the second WTRU to perform procedures associated with secondary authentication. The first WTRU may transmit the authentication data to the network. The authentication data may be received from the second WTRU in response to the sixth message.

[0298] Although the above-described features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without the other features and elements.

[0299] While the implementations described herein may consider 3GPP-specific protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, new radio (NR), or 5G-specific protocols, it is understood that the solutions described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0300] The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.< / mcc> < / mnc>

Claims

1. In a first wireless transmit / receive unit (WTRU), a processor, the processor comprising: receiving a first message from a second WTRU, the first message indicating a request for a protocol data unit (PDU) session associated with a data network; determining, based on the request for the PDU session, that the second WTRU is subject to network authentication and secondary authentication; If the network authentication associated with the second WTRU is successful, sending a second message to the second WTRU, the second message indicating that a secondary authentication associated with the second WTRU is pending; receiving a third message from a network node, the third message including an indication that the secondary authentication was successful; and determining, based on the indication that the secondary authentication was successful, that the second WTRU is authorized to access the PDU session; If the second WTRU is allowed to access the PDU session, transmitting a fourth message to the second WTRU, the fourth message being associated with the PDU session.

2. The WTRU of claim 1 , wherein the first message further indicates at least one of an identity of the first WTRU or a capability associated with an authentication service.

3. The WTRU of claim 1 , wherein the second message indicates at least one of an authentication service or identification information associated with the authentication service.

4. The WTRU of claim 1 , wherein the third message further indicates at least one of a user identity, data associated with an authentication protocol, or authentication information for the PDU session.

5. The WTRU of claim 1 , wherein the fourth message further indicates a service identification.

6. 10. The WTRU of claim 1, wherein the processor is further configured to send a fifth message to the second WTRU, the fifth message indicating a request for the second WTRU to perform a procedure associated with the network authentication.

7. 10. The WTRU of claim 1, wherein the processor is further configured to transmit a sixth message to the second WTRU, the sixth message indicating a request for the second WTRU to perform a procedure associated with the secondary authentication.

8. The WTRU of claim 7 , wherein the processor is further configured to transmit authentication data to the network node, the authentication data being received from the second WTRU in response to the sixth message.

9. 1. A method performed by a first wireless transmit / receive unit (WTRU) for authenticating a second WTRU, comprising: receiving a first message from a second WTRU, the first message indicating a request for a protocol data unit (PDU) session associated with a data network; determining, based on the request for the PDU session, that the second WTRU is subject to network authentication and secondary authentication; If the network authentication associated with the second WTRU is successful, sending a second message to the second WTRU, the second message indicating that the secondary authentication associated with the second WTRU is pending; receiving a third message from a network node, the third message including an indication that the secondary authentication was successful; and determining, based on the indication that the secondary authentication was successful, that the second WTRU is authorized to access the PDU session; If the second WTRU is authorized to access the PDU session, transmitting a fourth message to the second WTRU, the fourth message being associated with the PDU session.

10. 10. The method of claim 9, wherein the first message further indicates at least one of an identity of the first WTRU or capabilities associated with an authentication service.

11. The method of claim 9 , wherein the second message indicates at least one of an authentication service or identification information associated with the authentication service.

12. 10. The method of claim 9, wherein the third message further indicates at least one of a user identification, data associated with an authentication protocol, or authentication information for the PDU session.

13. The method of claim 9 , wherein the fourth message further indicates a service identification.

14. 10. The method of claim 9, further comprising: transmitting a fifth message to the second WTRU, the fifth message indicating a request for the second WTRU to perform a procedure associated with the network authentication.

15. 10. The method of claim 9, further comprising: transmitting a sixth message to the second WTRU, the sixth message indicating a request for the second WTRU to perform a procedure associated with the secondary authentication.

16. 16. The method of claim 15, further comprising transmitting authentication data to the network node, the authentication data received from the second WTRU in response to the sixth message.

Images