WTRU-to-network relay

Abstract

To provide systems and methods for enabling discovery and selection of a WTRU-to-network relay by a remote WTRU and handling a WTRU-to-network relay configuration update.SOLUTION: A WTRU-to-network relay may broadcast a service type indicating that the service type is available or conditionally available based on a WTRU-to-network relay slicing configuration. The WTRU-to-network relay may update broadcasting the service type or an indication that the service type is conditionally available based on update of the WTRU-to-network relay slicing configuration. The WTRU-to-network relay may relay traffic between one or more separate remote WTRU and core network load via the WTRU-to-network relay.SELECTED DRAWING: Figure 9

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 932,219, filed on November 7, 2019; U.S. Provisional Patent Application No. 62 / 957,530, filed on January 6, 2020; U.S. Provisional Patent Application No. 62 / 975,956, filed on February 13, 2020; and U.S. Provisional Patent Application No. 63 / 086,436, filed on October 1, 2020, the contents of which are incorporated herein by reference.

Background Art

[0002] Relaying between a wireless transmit / receive unit (WTRU) and a network can establish a protocol data unit (PDU) session for relaying traffic between a remote WTRU and a core network based on a default configuration, e.g., a default data network name (DNN). Various signaling mechanisms and resource usage methods for remote WTRUs and WTRU - network relays in such communication networks can be inappropriate or inefficient.

Summary of the Invention

[0003] A wireless transmit / receive unit-network (WTRU-network) relay may be configured to send a network registration request indicating its WTRU-network relay capabilities. In response to the network registration request, an indicator may be received indicating one or more approved relay service types and associated communication parameters (if any) associated with the approved relay service type(s). Based on the communication parameters and the network resources (if any) allocated to the WTRU-network relay, the WTRU-network relay may identify a relay service type for broadcasting from the approved relay service type(s). For example, an approved relay service type may be identified for broadcasting, provided that the associated communication parameter(s) associated with the relay service type is / are supported by the allocated network resources associated with the WTRU-network relay. The allocated network resources may be or may include PDU session parameters such as a single network slice selection assistance information (S-NSSAI), a data network name (DNN), and / or a session and service continuity (SSC) mode. The identified relay service type may be broadcasted.

[0004] A relay access WTRU (which may be or include a remote WTRU) may be configured to send a network registration request that may include an indicator indicating WTRU-network relay access capabilities. In response to the network registration request, an indicator indicating one or more approved relay service types and communication parameters associated with the approved relay service types may be received. A relay service type of interest may be identified from the approved relay service type(s) based on, for example, network resource requirements(s) and communication parameters associated with the approved relay service type(s). The relay access WTRU may be configured to receive a broadcast message that may include one or more relay service types provided by the WTRU-network relay. Whether to select a WTRU-network relay may be determined based on the relay service type(s) provided by the WTRU-network relay and the identified service type(s) of interest.

[0005] The relay service type(s) of interest can be identified from the approved relay service type(s) based on, for example, network resource requirements (s) and communication parameters associated with the approved relay service type(s). For example, the approved relay service type can be identified as the relay service type of interest if the network resource requirements associated with the relay access WTRU are supported by the communication parameters associated with the approved relay service type. The WTRU-network relay can be selected on the condition that the relay service type broadcast by the WTRU-network includes the relay service type of interest identified by the relay access WTRU. The communication parameters associated with the approved relay service type can be or include S-NSSAI, DNN, and / or SSC mode. The network resource requirements associated with the relay access WTRU can be or include S-NSSAI, DNN, and / or SSC mode.

[0006] Systems and methods are described herein for enabling a remote WTRU to discover and select a WTRU-network relay and for handling updates to the WTRU-network relay configuration. The WTRU-network relay can perform an initial registration to the core network. The WTRU-network relay can receive, from the core network, one or more WTRU-network relay provisioning parameters. The WTRU-network relay can broadcast a service type to indicate that the service type is conditionally available. When the configured service type becomes part of the list of permitted service types, the WTRU-network relay can update its broadcast information regarding the service type that is conditionally available to be available.

[0007] Systems and methods are described herein for relaying traffic via a WTRU-network relay between one or more remote WTRUs (e.g., remote WTRUs having different service requirements) and a core network node. The WTRU-network relay can request PDU session parameters for each of the remote WTRUs associated with the WTRU-network relay from the core network. The WTRU-network relay can maintain a mapping between the remote WTRU and one or more PDU session parameters. The WTRU-network relay can establish a PDU session for traffic relaying. The WTRU-network relay can reuse an existing PDU session for relaying traffic if the session parameters associated with the existing PDU session match the PDU session requirements of the remote WTRU. The WTRU-network relay can provide PDU session parameters associated with the PC5 connection to the remote WTRU during PC5 connection establishment. If there is no existing PDU session that matches the session parameters requested by the remote WTRU, the WTRU-network relay can send a PDU session establishment request to the network along with the requested PDU session parameters. The WTRU-network relay can receive a PDU session establishment response from the core network. The WTRU-network relay can then begin relaying traffic between the remote WTRU and the core network.

[0008] The remote WTRU can perform the discovery and selection of WTRU - network relays, which can be performed, for example, during provisioning, based on the relay broadcast of service types associated with control access group (CAG) IDs (e.g., implicit CAG - based selection), or based on the relay broadcast of CAG information including one or more of the CAG ID supported by the current CAG cell, the CAG ID permitted for the relay, or the CAG - only indicator (e.g., explicit CAG - based selection).

[0009] The WTRU - network relay can perform access control for a remote WTRU accessing the CAG cell. The relay WTRU may determine that the remote WTRU is authorized to access the CAG ID based on successful authentication for each application / service type. For example, an application may be associated with the CAG ID, and a PC5 layer key may be established / derived using the application layer key.

[0010] The WTRU - network relay can perform PC5 link maintenance based on a changing CAG ID (e.g., after mobility or configuration updates). The relay WTRU can determine whether the connected remote WTRU is authorized to access a serving cell (e.g., a new serving cell) via the relay according to a CAG change based on, for example, the PC5 link and the remote WTRU CAG information mapped with the current serving cell CAG information. The relay WTRU can release the PC5 link that provides a reason for indicating a CAG context, e.g., a new CAG context (e.g., not including available CAG IDs).

[0011] The ProSe L2 relay can subscribe to paging messages of a remote WTRU, for example, when the ProSe L2 relay is in a connected state.

[0012] A monitoring stop procedure (e.g., between a remote WTRU and a relay WTRU) may be performed, for example, when the remote WTRU re-enters the network coverage.

[0013] The remote WTRU and the WTRU-network relay can establish a secure PC5 link using qualification information derived from the execution of the primary authentication of the remote WTRU, which is performed via the WTRU-network relay.

Brief Description of the Drawings

[0014]

Figure 1A

[0015]

Figure 1B

[0016]

Figure 1C

[0017]

Figure 1D

[0018]

Figure 2

[0019]

Figure 3

[0020]

Figure 4

[0021]

Figure 5

[0022]

Figure 6

[0023]

Figure 7

[0024]

Figure 8

[0025]

Figure 9

DETAILED DESCRIPTION OF THE INVENTION

[0026] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-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.

[0027] As shown in Figure 1A, communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to interchangeably as a "station" and / or "STA", may be configured to transmit and / or receive wireless signals and may be a user equipment (UE), mobile station, fixed or mobile subscriber unit, subscriber-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., telesurgery), industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), home appliance device, device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

[0029] Base station 114a may be part of RAN 104 / 113 and 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. 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 to a specific geographic area that may be relatively fixed or may change over time. A cell may further be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may be able to use multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

[0034] 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 implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies transmitted to / from multiple types of base stations (e.g., eNBs and gNBs) and / or transmissions.

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

[0036] The base station 114b in FIG. 1A may be, for example, a wireless router, a home node B, a home eNode B, or an access point, and may utilize any suitable radio access technology (RAT) to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, or other locations. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless 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 utilize a cellular-based radio access technology (RAT) (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. 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 via the CN 106 / 115 in some cases.

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

[0038] CN106 / 115 may also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a public switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) 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 that may employ the same radio access technology (RAT) as the RAN104 / 113 or a different RAT.

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

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

[0041] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0043] The transmit / receive element 122 is shown in FIG. 1B as a single element, but the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

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

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

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

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

[0048] Processor 118 may also be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, peripheral devices 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 an augmented reality (Virtual Reality / Augmented Reality, VR / AR) device, an activity tracker, etc. Peripheral devices 138 may include one or more sensors, where the sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0050] FIG. 1C is a system diagram showing the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 can communicate with the WTRU 102a, 102b, 102c via the air interface 116 using the E-UTRA radio technology. The RAN 104 can also communicate with the CN 106.

[0051] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, can transmit a wireless signal to the WTRU 102a and / or receive a wireless signal from the WTRU 102a using a plurality of antennas.

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

[0053] CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted in the figure as part of 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.

[0054] MME 162 can be connected to each of eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can function as a control node. For example, MME 162 can authenticate users of WTRUs 102a, 102b, and 102c, perform activation / deactivation of bearers, and play a role in selecting a specific serving gateway during the initial attach of WTRUs 102a, 102b, and 102c. MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0055] SGW 164 can be connected to each of eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. SGW 164 can generally route and transfer user data packets to / from WTRUs 102a, 102b, and 102c. SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNode Bs, the function of triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and the function of managing and storing the context of WTRUs 102a, 102b, and 102c.

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

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

[0058] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is also conceivable that such a terminal can use a wired communication interface (e.g., temporarily or permanently) with a communication network.

[0059] In an exemplary embodiment, the other network 112 described above may be a WLAN.

[0060] 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 to or an interface to another type of wired / wireless network that carries traffic entering and / or exiting the distribution system (DS) or the BSS. Traffic destined for an STA originating outside the BSS may reach the STA through the AP and may be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and may be sent to each destination. Traffic between STAs within the BSS may be sent, for example, via the AP, although the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent in a direct link setup (DLS) directly between the source STA and the destination STA (e.g., directly between the source STA and the destination STA). In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the "ad hoc" communication mode.

[0061] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The above-mentioned primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS, but can be used by the STA 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. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) may sense the primary channel. If the primary channel is sensed / detected as busy and / or determined to be busy by a particular STA, that particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

[0064] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro coverage area. The MTC device may have limited capabilities, including support (e.g., only support therefor) for a particular and / or limited bandwidth. The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0065] A WLAN system that supports a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may 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 set and / or restricted by the STA that supports the minimum bandwidth operating mode among all the STAs operating in the BSS. In the example of 802.11ah, for an STA (e.g., an MTC type device) that supports the 1MHz mode (e.g., supports only that), the primary channel can be 1MHz wide even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA transmitting to the AP (supporting only the 1MHz operating mode), the entire available frequency band may be considered busy even though most of the frequency band remains idle and available.

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

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

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

[0069] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with an extensible numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

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

[0071] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown), but can be configured to handle radio resource management decisions, handover decisions, user scheduling in 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, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0072] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted in the figure as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0073] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP (3GPP is a registered trademark) access technologies (such as WiFi).

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

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

[0076] CN115 can facilitate communication with other networks. For example, CN115 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and the PSTN 108. Further, CN115 can provide access to another network 112 to the WTRUs 102a, 102b, 102c, where this other network 112 can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can 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.

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

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

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

[0080] Proximity Services (ProSe) in a wireless communication system may enable direct communication between two WTRUs that are in proximity to each other. As used herein, the term ProSe may be used to refer to direct transmissions from WTRU to WTRU, whether or not network scheduler-based coordination is used. FIG. 2 shows an example of a reference model for proximity-based services. As shown in FIG. 2, the ProSe function may include one or more of a direct provisioning function (DPF) or a direct discovery name management function. Using the DPF, one or more parameters can be provided to the WTRU to enable the use of ProSe direct discovery and ProSe direct communication services. The direct discovery name management function may be used for open ProSe direct discovery, for example, to assign and process the mapping of ProSe application IDs and ProSe application codes used in ProSe direct discovery.

[0081] As shown in FIG. 2, ProSe-capable WTRUs in proximity (e.g., WTRU A and WTRU B) can support the exchange of ProSe control information between each of the WTRUs and the ProSe function via an interface (e.g., the PC3 interface). ProSe-capable WTRUs can also support procedures for open and restricted ProSe direct discovery of other ProSe-capable WTRUs over a wireless interface (e.g., the PC5 interface).

[0082] The ProSe application server may support one or more capabilities, such capabilities including, for example, storage of ProSe application layer information (e.g., mapping of application layer user IDs) and network layer ProSe user IDs.

[0083] Figure 3 shows an example of a ProSe architecture using a WTRU-network relay. A ProSe WTRU-network relay within the network may enable one or more remote WTRUs to connect to the core network. As shown in Figure 3, a remote WTRU that is outside the coverage of the NR network and cannot directly connect to the core network can communicate with the WTRU-network relay using its PC5 interface to connect to the core network. A remote WTRU as shown in Figure 3 can search for and select a WTRU-network relay. The WTRU-network relay can establish a PDU session (or a PDN connection in an evolved packet core (EPC)) for the remote WTRU. Traffic between the remote WTRU and the core network can be relayed through the WTRU-network relay, for example, as shown in Figure 4.

[0084] Figure 4 is an example of a message sequence diagram showing the establishment of a session between a remote WTRU and a core network node (e.g., a session management function (SMF) / user plane function (UPF)). As shown in Figure 4, at 401, the WTRU-network relay can send a registration request to the access and mobility management function within the core network. At 402, the WTRU-network relay can receive a registration acceptance message. At 403, the remote WTRU can execute a discovery procedure. At 404, the remote WTRU can establish a connection with the WTRU-network relay. At 405, the WTRU-network relay can send a PDU session establishment request to the SMF / UPF of the core network. At 406, the WTRU-network relay can receive an establishment response from the SMF / UPF. At 407, the IP address / prefix assigned to the remote WTRU and the traffic between the remote WTRU and the core network can be relayed through the WTRU-network relay.

[0085] The 5G system can support a Public Network Integrated Non-Public Network (PNI-NPN) using control access group (CAG) cell-based selection and access control. A CAG-enabled WTRU (configured, for example, with an appropriate CAG ID) may be authorized to access the network (e.g., via a CAG cell). The CAG-enabled WTRU can select a CAG cell that broadcasts a supported CAG ID, e.g., that matches at least one of its permitted CAG IDs (configured within the WTRU and / or included in the subscription). The WTRU may be authorized (e.g., by the AMF) to access the network via a CAG cell if at least one of the CAG IDs permitted from the WTRU subscription is included in the CAG ID supported by the CAG cell. A CAG-enabled WTRU configured with a “CAG-only identifier” may access the network (e.g., via a CAG cell). In the absence of such an indicator, the WTRU may access both CAG cells and non-CAG cells (e.g., public cells).

[0086] The remote WTRU may access the network (e.g., via a ProSe L2 relay). FIG. 5 shows an example of a control plane protocol stack. The remote WTRU may be made visible to the network (e.g., by a ProSe L2 relay). The RAN may terminate RRC signaling and / or NG-AP signaling (e.g., by a ProSe L2 relay). The behavior of the remote WTRU may be the same as that of a non-remote WTRU (e.g., from the perspective of the AMF). The remote WTRU can access the 5G-RAN via a ProSe L2 relay, and the behavior of the RRC layer may be the same as that of a non-remote WTRU.

[0087] 5G-RAN may release the RRC connection with the remote WTRU (which may be the same as a non-remote WTRU, e.g., to move the remote WTRU to the idle state). The ProSe L2 relay may intercept paging messages (e.g., instead of the remote WTRU) and forward them to the remote WTRU (e.g., if the remote WTRU is maintaining a PC5 session). 5G-RAN may send an RRC paging message (e.g., if the ProSe L2 relay is in the idle mode). 5G-RAN may send the RRC paging message of the remote WTRU to the ProSe L2 relay via the SRB and / or DRB of the ProSe L2 relay (e.g., if the ProSe L2 relay is in the connected mode).

[0088] The remote WTRU may be authorized to access the network via a WTRU-network relay, in which case it performs primary authentication via the relay and uses the AMF of the relay and the authentication function (AUSF) of the remote WTRU. The remote WTRU may complete the establishment of the PC5 link with the relay and perform communication via that relay (e.g., after successful primary authentication and authorization).

[0089] In a wireless communication network (e.g., a 4G wireless communication network), a WTRU-network relay can establish a PDU session for traffic relay based on a default configuration, e.g., a default data network name (DNN). Network slicing in a 5G communication network can introduce a set of communication service requirements that a WTRU-network relay can support. A 4G WTRU-network relay may not support one or more remote WTRU slice requirements, which can be due to, for example, existing limitations in network slice selection assistance information (NSSAI) storage (e.g., a maximum of 8 permitted NSSAI, 16 configured NSSAI), or other restrictions that the serving network may impose on the number of S-NSSAIs that a WTRU can use simultaneously. Thus, a WTRU-network relay can be restricted with respect to the types of services it can simultaneously provide to a remote WTRU, and also with respect to slicing (S-NSSAI) or other PDU session parameters (e.g., PDU session type, session and service continuity (SSC) mode, etc.). For example, a WTRU-network relay may be provisioned with an NSSAI configured such that it may not include S-NSSAIs that a remote WTRU can use. A remote WTRU can initiate (e.g., selectively initiate) communication using a WTRU-network relay that can support those communication service requirements instead of a WTRU-network relay that may not support the communication service requirements, thereby avoiding unnecessary signaling and resource usage at both the remote WTRU and the WTRU-network relay node, for example.

[0090] A remote WTRU may be provided with a mechanism for searching and / or selecting a WTRU-network relay that can meet the communication requirements of that remote WTRU (e.g., for a single NSSAI (S-NSSAI)). The WTRU-network relay may also be provided with a mechanism for handling relay discovery and updating the WTRU-network relay configuration (e.g., slicing configuration update) for one or more relay communications.

[0091] The WTRU-network relay may be searched for and selected based on slicing information and / or CAG ID. A WTRU-network relay (e.g., a 4G WTRU-network relay) may establish a PDU session for traffic relay based on a default configuration, e.g., a default DNN. One or more PDU sessions for relayed traffic from one or more remote WTRUs may share the same parameters, e.g., including DNN, NSSAI, and SSC mode. However, one or more remote WTRUs may have separate requirements for their relayed traffic. For example, some remote WTRUs may require service continuity, while other remote WTRUs may require a specific network slicing (e.g., NSSAI) for the traffic associated with those remote WTRUs. The configured PDU session parameters used for each remote WTRU may not meet the separate requirements associated with the remote WTRU. This may result in service disruption and / or a poor user experience. A dedicated PDU session may be provided for each remote WTRU.

[0092] Search and selection of WTRU-network relays (e.g., CAG ID-based) can be performed. The WTRU-network relays and remote WTRUs can be deployed (e.g., in an industry and / or vertical environment). If a remote WTRU (e.g., a machine, an operator phone) desires to access a private network provided by a PNI-NPN, the relay can provide an extended range within a building (e.g., a factory) for such a remote WTRU. Access to the PNI-NPN via the WTRU-network relay can be supported (e.g., in such use cases). One or more of the features described herein can be related to one or more of the following: Search and selection of a WTRU-network relay that can provide access (e.g., via a CAG cell), access control of a remote WTRU (e.g., a CAG or non-CAG enabled remote WTRU) that desires to access the network using a WTRU-network relay connected via a cell (e.g., a CAG or non-CAG cell), handling of a change in an available CAG (e.g., a CAG cell change due to WTRU-network relay mobility) with respect to relay search and ongoing relay communication via that relay, or updating of the CAG configuration of the WTRU-network relay (e.g., updating of permitted CAG IDs).

[0093] A remote WTRU may be paged (e.g., via a ProSe L2 relay). (For example, when the remote WTRU enters the idle state,) the 5G-RAN may remove the stored remote WTRU context information (e.g., identity, mobility, security, and / or the like) associated with the connected WTRU. The 5G-RAN may not need to know where the remote WTRU is. For example, the 5G-RAN may not need to know whether the remote WTRU still accesses a ProSe L2 relay that exists and / or to which ProSe L2 the remote WTRU still has access. The 5G-RAN may broadcast the paging message of the remote WTRU on the paging channel (e.g., to ensure that the remote WTRU receives the paging message), and may send the paging message one by one via the SRB or DRB to all ProSe L2 relays in the connected mode. In multiple examples, the paging message for each remote WTRU may need to be sent to the ProSe L2 relay in the connected mode by the unicast method. Sending the paging message for each remote WTRU to the ProSe L2 relay in the connected mode by the unicast method may cause a large amount of radio resource consumption. This is because, for example, a large number of ProSe L2 relays may exist in the paging area (e.g., within the tracking area (TA) list) of the remote WTRU.

[0094] Redundant system information blocks (SIBs) and paging information can be received during idle mode. A remote WTRU in idle mode can receive SIB information, such as cell ID and paging messages, (e.g., in an L2 relay scenario) from, for example, an L2 WTRU to a network relay node. The remote WTRU can re-enter network coverage (e.g., in an L2 relay scenario). A remote WTRU returning to network coverage may receive the same information from two different sources, e.g., from a relay WTRU and from the network (RAN). The relay WTRU can be notified by one or more procedures that broadcast information is no longer needed. In one example, the remote WTRU can notify the relay WTRU that relayed information is no longer needed.

[0095] The remote WTRU can establish a secure PC5 link with a WTRU-network relay. For example, when attempting to establish a PC5 link with a WTRU-network relay, the remote WTRU can perform primary authentication that is executed via that relay through the relay's AMF and the remote WTRU's AUSF. After successful authentication and authorization of the remote WTRU for using the WTRU-network relay, the remote WTRU and the WTRU-network relay can proceed to establish a secure PC5 link. A security key can be established for the PC5 link to protect communications over the PC5 link via the relay. Additional authentication procedures between the remote WTRU and the WTRU-network relay can be avoided. Unnecessary signaling and resource waste at both the remote WTRU and the WTRU-network relay, which can cause a denial of service (DOS) condition, can be avoided.

[0096] The terms relay WTRU, WTRU-network relay, WTRU-network relay WTRU, and WTRU-NW relay may be used interchangeably herein. The terms remote WTRU, relay user, and relay user WTRU may be used interchangeably herein. A relay access WTRU may be or may include a remote WTRU as described herein.

[0097] A WTRU-network relay may be configured to provide a discovery mechanism for one or more remote WTRUs. The WTRU-network relay may perform registration (e.g., initial registration) with the core network as a WTRU that can be a WTRU-network relay node. The WTRU-network relay may receive one or more WTRU-network relay provisioning parameters from the core network. The WTRU-network relay may receive the WTRU-network relay provisioning parameters during or after registration with the core network. The WTRU-network relay provisioning parameters may include one or more of a set of service types approved to be relayed by the WTRU-network relay and / or one or more associated communication parameters (S-NSSAI, DNN, SSC mode, etc.) associated with each service type. The S-NSSAI associated with a service may be part of the NSSAI configured for the WTRU.

[0098] The WTRU-network relay may be registered with the core network and request an S-NSSAI based on the relay's provisioning information. The S-NSSAI may not be permitted at the current time by some networks. The WTRU-network relay may perform the registration of one or more (e.g., all) S-NSSAIs corresponding to the pre-provisioned service types, or the WTRU-network relay may trigger the registration of the S-NSSAI corresponding to the provisioned service type, e.g., when receiving a request from a remote WTRU. The WTRU-network relay may trigger the registration of the S-NSSAI corresponding to the service type based on one or more WTRU-network relay provisioning parameters.

[0099] The WTRU-network relay may broadcast one or more messages on its PC5 interface that notify the service type(s) it can support. The broadcast message(s) may include WTRU-network relay metrics, e.g., based on one or more WTRU-network relay provisioning parameters. The WTRU-network relay may broadcast the service type if, for example, the corresponding S-NSSAI is included in the granted network resources such as the permitted NSSAI. The WTRU-network relay may broadcast the service type even if, for example, the corresponding S-NSSAI is included in the configured list of NSSAIs but not in the permitted NSSAIs. When broadcasting the service type corresponding to the configured NSSAI, the broadcast message may include an indication (either explicit or implicit) that the service type is conditionally available. If the configured S-NSSAI becomes part of the permitted NSSAI, the WTRU-network relay may stop broadcasting the indication that the service type is conditionally available.

[0100] The WTRU-network relay can refrain from broadcasting, for example, as a network resource, a service type for which an associated communication parameter (e.g., an associated S-NSSAI) is rejected (e.g., for a certain registration area or a public land mobile network (PLMN)). When the WTRU-network relay reaches a maximum usage amount and / or a load threshold, it may not broadcast one or more service types (e.g., it may stop all service broadcasts) for overload control purposes. The WTRU-network relay may include, for example, an indicator that explicitly or implicitly indicates that the usage in its service broadcast is at a high level when the relay WTRU reaches a high-level usage and / or load threshold. The value indicating high-level usage or the load threshold may be provisioned as part of the WTRU-network relay provisioning parameters. The value indicating high-level usage or the load threshold may be provisioned using overload control policy parameters. The usage level or load level of the relay WTRU can be based on, for example, the number of active PC5 links, the number and type of PDU sessions, etc., that the WTRU-network relay may have for one or more remote WTRUs.

[0101] When a WTRU-network relay receives a request for a conditionally available service, for example, from a certain remote WTRU, it can trigger a registration procedure. The WTRU-network relay may send a registration request message to the network. The registration request message may include an S-NSSAI corresponding to the service requested by the remote WTRU. If the S-NSSAI is successfully permitted by the network, the WTRU-network relay may complete the setup of a new set of links with the remote WTRU by sending a confirmation message (e.g., direct communication acceptance) in response to the request from the remote WTRU. The WTRU-network relay may initiate a link modification for adding or deleting services to / from an existing link, for example, when the S-NSSAI is normally permitted or rejected by the network. If the S-NSSAI is rejected, the WTRU-network relay can release the established link. The WTRU-network relay may provide the remote WTRU with the reason why the slice is not available.

[0102] A remote WTRU (which may be referred to herein as a relay access WTRU) may perform an initial registration with the network as a WTRU that can use (e.g., access) a WTRU-network relay. The remote WTRU may receive one or more relay access WTRU provisioning parameters during or after registration. Such parameters may include, for example, a set of service types approved for use via the relay, communication parameters (e.g., S-NSSAI, DNN, SSC mode, etc.) associated with each service type, and / or a WTRU-network relay selection policy. The S-NSSAI required by a service may be assumed to be part of the NSSAI configured in the WTRU.

[0103] When registered with the core network, a remote WTRU can request an S-NSSAI that is not currently permitted and may be associated with a service from relay provisioning information. A remote WTRU (e.g., a WTRU outside of coverage) can detect a broadcast message that notifies of one or more relayed service type(s) that the remote WTRU can use (e.g., to meet network requirements such as application requirements and / or service continuity) based on, for example, relay access WTRU provisioning parameters.

[0104] A remote WTRU can select a WTRU-network relay based at least on a relay selection policy. A remote WTRU can select a WTRU-network relay based on, for example, the services provided by the WTRU-network relay. A remote WTRU can select a WTRU-network relay to minimize the number of PC5 links that may need to be configured with multiple WTRU-network relays (e.g., by providing overlapping services).

[0105] A remote WTRU can select one or more relays for the same service type to ensure redundancy in relayed communications. A remote WTRU can select a WTRU-network relay that can broadcast a service availability indicator before attempting different relays that may broadcast the same service as available conditionally.

[0106] A remote WTRU can select a WTRU-network relay that does not broadcast a high usage indicator in the services broadcast on the relay or refrain from connecting to a relay that broadcasts such an indicator.

[0107] A WTRU-network relay can receive an update to a slicing configuration. For example, a WTRU-network relay can receive a WTRU Configuration Update (UCU) message. The UCU message can include slicing information (e.g., new slicing information). The slicing information can be one or more of a configured NSSAI, a permitted NSSAI, a rejected S-NSSAI, etc. The WTRU-network relay can interrupt, for example, a broadcast that notifies of the service type(s) it can support, prior to completion of the UCU procedure. The WTRU can complete the UCU procedure by updating its slicing configuration based on the content of the UCU message.

[0108] The WTRU-network relay may resume a broadcast that notifies of the service type(s) it supports, for one or more permitted S-NSSAIs not affected by the UCU procedure. The WTRU-network relay can continue the service on any of the existing PC5 links established to one or more remote WTRUs that can use such service.

[0109] The WTRU-network relay can be registered with the network and request an S-NSSAI for an updated configured NSSAI that is not currently permitted and not required by the service type, according to relay provisioning information. The WTRU-network relay can broadcast one or more broadcast messages that announce, via the PC5 interface, the service type(s) it can support, along with the currently permitted associated S-NSSAIs.

[0110] When the associated S-NSSAI in the relay provisioning information is rejected by the network (e.g., when the WTRU-network relay can receive the rejected S-NSSAI including the associated S-NSSAI from the network), the WTRU-network relay can perform link modification procedures for one or more PC5 links (if any) with one or more remote WTRUs for the service type(s). The WTRU-network relay may provide the remote WTRU with the reason that the slice is not available. If the service is not permitted or is conditional on the PC5 link, the WTRU-network relay may release the link with the relay access WTRU.

[0111] A WTRU-network relay may create a dedicated PDU session for a certain remote WTRU. The PDU session parameters (e.g., routing policy) may include one or more of the parameters such as S-NSSAI, DNN, PDU session type, SSC mode, etc. In one example, the WTRU-network relay may request the core network for PDU session parameters for each of the remote WTRUs associated with that WTRU-network relay. The WTRU-network relay may maintain a mapping between the remote WTRU and one or more PDU session parameters. The WTRU-network relay may obtain the PDU session parameters of a certain remote WTRU, which may be done, for example, when that remote WTRU establishes a connection for communication with the WTRU-network relay. The WTRU-network relay may establish a PDU session for traffic relaying. The WTRU-network relay may reuse an existing PDU session instead of establishing a new one if the existing PDU session for traffic relaying meets the PDU session requirements of the remote WTRU. For example, a first remote WTRU may be associated with PDU session parameters for an S-NSSAI, and a second remote WTRU may have the same PDU session parameters. The traffic of both WTRUs may be associated with the same PDU session. The WTRU-network relay may modify the PDU session based on the QoS requirements received from the remote WTRU, for example, if the WTRU-network relay uses the same PDU session for both WTRUs.

[0112] A WTRU-network relay may request PDU session parameters for a remote WTRU during initial registration of the remote WTRU to the core network or when the remote WTRU establishes a PC5 connection with the WTRU-network relay. The WTRU-network relay may request one or more PDU session parameters by including the remote WTRU ID(s) and ProSe service type / ID in the request message for each possible remote WTRU or for dedicated remote WTRU(s). Different dedicated PDU sessions may be established by the WTRU-network relay for the same remote WTRU using different application / service types having different PDU session requirements (e.g., S-NSSAI, DNN).

[0113] The WTRU-network relay can send the PDU session parameter request to the core network. The PDU session parameter request may include the remote WTRU ID(s). The WTRU-network relay can receive and / or store the PDU session parameters for one or more remote WTRU ID(s). The WTRU-network relay can obtain the PDU session parameters for the remote WTRU, for example, when a PC5 connection is established with the remote WTRU. The WTRU-network relay can check whether an existing PDU session can be reused by the remote WTRU. The WTRU-network relay can determine whether an existing PDU session can meet the requirements of the remote WTRU's PDU session parameters.

[0114] If no existing PDU session that meets the requirements of the PDU session parameters of the remote WTRU is found, the WTRU-network relay can send a PDU session establishment request, along with the PDU session parameters of the remote WTRU, to the network. The WTRU-network relay can include the remote WTRU ID in the PDU session establishment request. The remote WTRU ID can be utilized by the AMF to perform SMF selection. If an existing PDU session is found, the WTRU-network relay can associate the remote WTRU with that existing PDU session.

[0115] Figure 6 shows an example of PDU session establishment between a remote WTRU and a core network via a ProSe WTRU-network relay. As shown in Figure 6, at 601, the WTRU-network relay sends a registration request message to a core network node (e.g., having an AMF). The registration request message may include WTRU-network relay indicators. At 602, the WTRU-network relay can receive a registration acceptance message from the core network (e.g., from the AMF within the core network). The registration acceptance message may include one or more PDU session parameters for one or more remote WTRUs associated with the WTRU-network relay. The WTRU-network relay can store mapping information between the remote WTRU and the PDU session parameters, e.g., mapping information between the remote WTRU ID and the NSSAI associated with the PDU session.

[0116] At 603, the remote WTRU can execute its discovery procedure to discover a WTRU-network relay. At 604, the remote WTRU and the discovered WTRU-network relay can establish a PC5 connection. If none of the PDU session parameters associated with the remote WTRU are known to the WTRU-network relay (for example, if the WTRU-network relay did not request PDU session parameters during registration with the core network), at 605, the WTRU-network relay can send a routing policy request message to the core network (for example, the AMF of the core network). The routing policy request message may include one or more IDs associated with one or more of the remote WTRUs. The request may include a ProSe service type / service ID.

[0117] At 606, the WTRU-network relay can receive a routing policy response message from the core network (for example, the AMF of the core network). The routing policy response message received by the WTRU-network relay may include one or more PDU session parameters for the remote WTRU.

[0118] At 607, the WTRU-network relay can search for an existing PDU session that can be reused for the remote WTRU, for example, based on the PDU session parameters of the remote WTRU and the parameters associated with the existing PDU session. If a match is found between the PDU session parameters associated with the existing PDU session and the requirements of the remote WTRU, the WTRU-network relay can associate the existing PDU session with the remote WTRU and does not have to create a new PDU session.

[0119] At 608, the WTRU-network relay can send a PDU session establishment request message, for example, when an existing PDU session is not discovered for this remote WTRU. The PDU session establishment request message may include PDU session parameters associated with the remote WTRU. At 609, the WTRU-network relay can receive a PDU session establishment response message from the core network (e.g., the SMF of the core network).

[0120] At 610, the remote WTRU can obtain an IP address / prefix, and the WTRU-network relay can start relaying traffic between the remote WTRU and the core network.

[0121] The remote WTRU can provide one or more PDU session parameters to the WTRU-network relay, for example, when the remote WTRU establishes a connection for communicating with the WTRU-network relay. The WTRU-network relay can establish a PDU session for the remote WTRU based on the received PDU session parameters. The remote WTRU can provide one or more PDU session parameters to the WTRU-network relay via a direct communication request message, or other messages, such as a dedicated message for parameter provisioning, an IP address / prefix request message, etc.

[0122] When (or after) a PC5 connection is established between the WTRU-network relay and a remote WTRU, the WTRU-network relay can receive and / or store PDU session parameters associated with one or more remote WTRU IDs. The WTRU-network relay can determine whether an existing PDU session can be reused for the request of the remote WTRU. For example, the WTRU-network relay can determine whether an existing PDU session matches the requested PDU session parameters received from the remote WTRU. If no existing PDU session that can be reused is found, the WTRU-network relay can send a PDU session establishment request to the network. The PDU session establishment request may include the PDU session parameters received from the remote WTRU (e.g., new PDU session parameters). If an existing PDU session that can be reused is found, the WTRU-network relay can associate the remote WTRU with its matching PDU session.

[0123] When the remote WTRU requests (or subsequently) the establishment of a PC5 connection, it can send one or more PDU session parameters to the WTRU-network relay. FIG. 7 shows an example of a remote WTRU that establishes a PDU session with a core network node via the WTRU-network relay. As shown in FIG. 7, at 701, the WTRU-network relay can send a registration request message to the core network (e.g., the AMF of the core network). At 702, the WTRU-network relay can receive a registration acceptance message from the AMF within the core network. At 703, the remote WTRU can discover the WTRU-network relay. At 704, the remote WTRU can send a direct communication request message to the WTRU-network relay. The direct communication request message may include one or more PDU session parameters. The remote WTRU can defer the transmission of one or more of the PDU session parameters (e.g., S-NSSAI), which may be privacy-sensitive, to a later step, e.g., when the security association between the remote WTRU and the WTRU-network relay is established. For example, in FIG. 7, the remote WTRU can transmit one or more PDU session parameters after 705 or 706. For example, in FIG. 7, after 705 (mutual authentication), the WTRU-network relay may request one or more PDU session parameters by including an indicator in the direct security mode (DSM) command message sent to the remote WTRU. The WTRU can reply with a DSM completion message with secrecy and integrity protection that includes the PDU session parameters. At 705, mutual authentication between the remote WTRU and the WTRU-network relay can be performed. At 705, a security association can be established between the remote WTRU and the WTRU-network relay. At 705, the WTRU-network relay can send a direct communication acceptance (DCA) message to complete the establishment of the PC5 unicast link with the remote WTRU.In 706, the remote WTRU can provide one or more PDU session parameters to the WTRU-network relay, for example, using a parameter provisioning message (or an IP address / prefix request message). The parameter provisioning message may correspond to a protected DSM completion message as described above.

[0124] In 707, the WTRU-network relay can search for an existing PDU session that can be reused by the remote WTRU. The WTRU-network relay can perform the search based on the requested PDU session parameters of the remote WTRU and the parameters associated with the existing PDU session. If the existing PDU session matches the requested PDU session parameters of the remote WTRU as determined by the WTRU-network relay, the WTRU-network relay can associate the PDU session with the remote WTRU and does not have to create a new PDU session.

[0125] In 708, if the WTRU-network relay determines that none of the existing PDU sessions meet the requested PDU session parameters of the remote WTRU, the WTRU-network relay can send a PDU session establishment request to the core network. The PDU session establishment request may include the PDU session parameters received from the remote WTRU. The WTRU-network relay can include the remote WTRU ID associated with the requesting WTRU in the PDU session establishment request. The core network, for example, the AMF, can use the remote WTRU ID to perform SMF selection.

[0126] At 709, the WTRU-network relay can receive a PDU session establishment response from the core network (e.g., SMF). At 710, the remote WTRU can obtain an IP address / prefix, and the WTRU-network relay can initiate traffic relaying between the remote WTRU and the core network.

[0127] The WTRU-network relay can include information regarding the remote WTRU ID and / or ProSe services requested by the remote WTRU within the PDU session request message. The core network (e.g., the AMF and / or SMF of the core network) can determine PDU session parameters that can be accepted. For example, the PDU session parameters can be accepted based on the ID of the remote WTRU and / or ProSe services requested by the remote WTRU. The core network can send a PDU session response message to the WTRU-network relay. The PDU session response message can include the accepted PDU session parameters, such as the accepted S-NSSAI, DDN, etc.

[0128] The behavior of the WTRU-network relay receives the remote WTRU ID and / or ProSe services requested by the remote WTRU during discovery or authentication and provisioning, or PC5 connection establishment. The WTRU-network relay can send a PDU session request that can include the remote WTRU ID(s) and / or ProSe services requested by the remote WTRU to the core network. The WTRU-network relay can receive a PDU session response message that can include the accepted PDU session parameters, such as S-NSSAI, DDN, from the core network.

[0129] The AMF / SMF within the core network can receive the remote WTRU ID and / or ProSe service from the WTRU-network relay. The AMF / SMF can receive the remote WTRU ID and / or ProSe service within the PDU session establishment request message. The AMF / SMF can obtain one or more PDU session parameters associated with the remote WTRU or ProSe service, for example, by querying the Policy Control Function (PCF). The AMF / SMF can send a PDU session establishment response to the WTRU-network relay. The PDU session establishment response may include one or more accepted PDU session parameters.

[0130] The WTRU-network relay can provide the PDU session parameters of the established PDU session to the remote WTRU, for example, after the WTRU-network relay has established a PDU session for the remote WTRU based on, for example, configuration, the WTRU Routing Selection Policy (URSP) rules, and / or the PDU session parameters received from the remote WTRU. The remote WTRU can store the association between the PDU session parameters and the PC5 connection. For all newly detected applications, the remote WTRU can evaluate whether the PDU session parameters associated with the existing PC5 connection can meet the requirements of the application. Based on the evaluation, the remote WTRU can reuse the existing PC5 connection or establish a new PC5 connection. The remote WTRU can obtain the requirements of its application, such as the PDU session type, SSC mode, and DNN, based on the local URSP rules.

[0131] For example, a WTRU-network relay can establish a PDU session for the PC5 connection when and / or after the PC5 connection with a remote WTRU is established. The WTRU-network relay can provide the PDU session parameters associated with the PC5 connection, such as the PDU session type, SSC mode, to the remote WTRU.

[0132] For example, a remote WTRU can receive PDU session parameters that can be associated with the PC5 connection. The remote WTRU can memorize the association between the PDU session parameters and the PC5 connection. The remote WTRU can obtain the requirements of a newly launched application, such as the PDU session type, SSC mode, S-NSSAI and / or DNN, based on the local URSP of the remote WTRU. The remote WTRU can determine whether the existing PC5 connection can be used for the newly launched application. The remote WTRU can reuse the existing PC5 connection or establish a new PC5 connection for the newly launched application.

[0133] The search and selection of a WTRU-network relay can be performed (e.g., based on the CAG ID). The remote WTRU can perform the search and selection of a WTRU-network relay based on the service type (e.g., permitted CAG ID) broadcast by the relay associated with one or more CAG IDs provided during provisioning, and / or the CAG information broadcast from the relay and / or the CAG cell to which the relay is connected.

[0134] In an example, the remote WTRU may need to be a CAG-enabled WTRU with a configured permitted CAG ID list and / or a CAG-only indicator. The WTRU can perform an initial registration with the network as a WTRU with the ability as a relay user. The WTRU can receive relay access WTRU provisioning parameters (e.g., during or after registration), such parameters including a set of service types approved for use by a relay with an optional associated CAG ID (e.g., the CAG ID may be part of the WTRU permitted CAG ID), and / or a WTRU-network relay selection policy. The required CAG ID can be communicated by the application layer (e.g., an industrial application may require a certain private network to connect). The parameters can be pre-configured within the relay access WTRU (e.g., to enable the WTRU to perform relay discovery and / or selection of a relay WTRU prior to the first initial registration).

[0135] The relay access WTRU can detect a message broadcast from the relay via PC5. The broadcast message can include a WTRU-network relay capability indicator, one or more service types (s) supported by the relay, a WTRU-network relay permitted CAG ID, a supported CAG ID (e.g., from the cell to which the relay is currently connected or present), a CAG-only indicator of the WTRU-network relay (e.g., an indicator specifying whether the relay is permitted to access the network via a CAG cell), and / or a CAG / non-CAG cell indicator regarding the cell to which the relay is currently connected (e.g., an indicator indicating whether it is a CAG or non-CAG cell).

[0136] The relay access WTRU can select a WTRU-network relay according to a relay selection policy. The relay access WTRU can select a WTRU-network relay that broadcasts one or more service types (plural) associated with one of the permitted CAG IDs of the relay access WTRU (e.g., an implicit CAG ID-based selection). The relay access WTRU can select a WTRU-network relay having the most compatible CAG configuration (e.g., one or more common CAG IDs common between the relay access WTRU and the permitted CAG ID of the WTRU-network relay, and / or the same CAG indicator (e.g., CAG-only indicator) configuration as the WTRU-network relay).

[0137] In an example, in the case of a non-CAG remote WTRU, there may be a case where a relay is not selected (e.g., based on CAG / non-CAG cell indicators) unless the relay is connected to / resident in a CAG cell.

[0138] A remote WTRU can select a relay using one or more of the following features (e.g., if the broadcast message from the relay WTRU does not contain CAG-specific information for each CAG). The remote WTRU can select a relay WTRU based on broadcast information (e.g., service type(s), general relay service code, and / or relay capability indicator). The remote WTRU can proceed to establish a PC5 link with the relay WTRU. The remote WTRU can receive a PC5 unicast security protection message (e.g., DSMC) from the relay WTRU that includes one or more of a permitted CAG ID, CAG-only indicator, CAG ID supported by the current cell, and / or CAG cell / non-CAG cell indicator. The remote WTRU can select a relay using a selection policy as in the examples herein. The remote WTRU can send a PC5 unicast security protection message to the relay WTRU that includes a CAG ID configuration that matches the CAG ID available from the relay WTRU and / or a subset of the selected CAG ID (e.g., if the remote WTRU determines that the CAG ID supported by the relay WTRU is suitable). The remote WTRU can proceed to establish a PC5 link or, if a PC5 link is already established, maintain the current PC5 link with the relay WTRU. The remote WTRU can abort the establishment of a PC5 link and / or tear down an established PC5 link (e.g., if the relay WTRU does not provide a CAG ID that is suitable / compliant for the remote WTRU).

[0139] A WTRU-network relay may enable its discovery by a remote WTRU accessing the network via a CAG cell. In an example, the WTRU-network relay may be a CAG-enabled WTRU with a configured list of permitted CAG IDs and a CAG indicator (e.g., a CAG-only indicator). The relay access WTRU may select a CAG cell (e.g., which is part of its permitted CAG ID list) and may register with the network via that CAG cell. The WTRU may perform an initial registration to the network. To function as a WTRU-network relay, the relay access WTRU may receive provisioning parameters (e.g., during or after registration). Examples of such may include a set of service types approved for use via the relay, having associated CAG IDs (e.g., the CAG ID may be part of the WTRU permitted CAG ID), and / or a relay operation policy. The relay WTRU may broadcast one or more messages on the PC5 interface notifying of service type(s) and / or CAG information. The relay WTRU may determine to broadcast service types associated with one or more CAG IDs available in the CAG cell to which the relay WTRU is connected (e.g., broadcast CAG IDs supported by the CAG cell).

[0140] A WTRU-network relay can perform access control for a remote WTRU accessing the network via a CAG cell based on one or more provisioned service types (e.g., permitted CAG IDs) associated with CAG IDs. In an example, the WTRU-network relay can be discovered and selected by a remote WTRU (e.g., based on service type / CAG ID information). The WTRU can perform mutual authentication with the remote WTRU. The PC5 layer key (e.g., KD) can be established / derived using the application layer key. The WTRU can determine that the remote WTRU is authorized to access the CAG ID(s) associated with the application / service type (e.g., based on the success of application / service type authentication). The WTRU can complete the PC5 link establishment and proceed with the establishment / modification of the PDU session.

[0141] The WTRU-network relay can be a layer 2 (L2) relay. One or more of the following can apply. The relay WTRU can establish a PC5 link with the remote WTRU and forward NAS messages (e.g., encapsulated in RRC messages) from the remote WTRU to the network. The serving AMF of the remote WTRU can perform conventional CAG-based access control. The relay WTRU can detect a rejection message (e.g., registration rejection) from the AMF to the remote WTRU (e.g., if the remote WTRU is not permitted to access the current (CAG) cell that provides services to that relay WTRU). The relay can break the PC5 link with the remote WTRU under the condition that it detects a rejection message.

[0142] The available CAGs can change (e.g., due to the mobility of the WTRU-network relay). For example, CAG-A and CAG-B may be available if the WTRU-network relay is camped on cell A. A remote WTRU having CAG-A included in its permitted CAG ID (e.g., but not having CAG-B) can establish a PC5 session (e.g., to access CAG-A via the WTRU-network relay). For example, if the WTRU-network relay moves to cell B which may be restricted to support CAG-B, the remote WTRU may no longer be permitted to access the network via the WTRU-network relay / cell B.

[0143] The WTRU-network CAG configuration (e.g., permitted CAG ID and / or CAG indicator) can be updated by the network (e.g., via the UCU) at any time, for example. The configuration update (e.g., WTRU-network CAG configuration update) can trigger the WTRU-network to reselect a new cell. The connectivity of the remote WTRU via the WTRU-network may be affected. Subsequently to such a CAG configuration update, the remote WTRU may need to reselect and reconnect to the WTRU-network relay again or select a different WTRU-network relay (e.g., if the first WTRU-network relay does not meet the CAG-based access requirements of the remote WTRU).

[0144] The CAG configuration of the remote WTRU (e.g., permitted CAG ID and / or CAG indicator, e.g., CAG-only indicator) can be updated by the network (e.g., via the UCU) at any time, for example. The update of the CAG configuration of the remote WTRU can trigger the remote WTRU to release the PC5 link with the currently used relay WTRU and search for another more suitable relay WTRU (e.g., one that supports the new permitted CAG ID of the remote WTRU).

[0145] The relay WTRU can notify the remote WTRU about the CAG change. (For example, it can send updated available CAG information via a PC5 broadcast and / or unicast message). The relay WTRU can break the PC5 link with the remote WTRU (for example, while releasing the link, the relay can provide a cause code indicating that the CAG context has changed to the remote WTRU). The cause code can indicate that the available CAG ID has changed, and / or that the cell type to which the relay WTRU is connected or in which it is camped has changed (e.g., from a CAG cell to a non-CAG cell or vice versa), that there is no available CAG ID, and / or that the current CAG access (e.g., via the relay) is not authorized. The relay WTRU may need to break the PC5 link with the remote WTRU (e.g., all PC5 links) if, for example, it needs to perform a new cell selection or if no suitable cell is found.

[0146] The relay WTRU may notify the remote WTRU about the CAG change and break the PC5 link with the remote WTRU (e.g., if the relay WTRU determines that the remote WTRU is affected and / or does not support the new CAG ID). The relay WTRU can maintain the mapping of the CAG ID requested from the remote WTRU together with the PC5 link (e.g., exchanged during PC5 link establishment). The relay WTRU can maintain the PC5 link (e.g., if the remote WTRU requests a CAG ID and the permitted or selected CAG ID associated with the PC5 link is still available via the relay after the CAG change). The relay can break the PC5 link (e.g., if the remote WTRU requests a CAG ID and the permitted or selected CAG ID associated with the PC5 link is no longer available via the relay after the CAG change). The relay WTRU may obtain the CAG indicator of the WTRU (e.g., CAG-only indicator) (e.g., when moving to a non-CAG cell) and break the PC5 link.

[0147] The relay access WTRU may receive updated CAG information on PC5 broadcast or unicast (e.g., from the relay WTRU). The relay access WTRU may break the PC5 link (e.g., if the WTRU determines that it is not permitted to access the network via the relay and / or the new serving cell).

[0148] The relay access WTRU can receive a link release message indicating a cause code specifying that the CAG ID has changed. The relay access WTRU may repeat the relay selection and reselect the same relay (e.g., if the WTRU is still permitted to select the new CAG ID), or the relay access WTRU may select another more appropriate / compatible relay.

[0149] Figure 8 shows the discovery, selection, and communication by the WTRU-network relay of layer 2 via the WTRU-network relay. As shown in Figure 8, at 800, the remote WTRU (WTRU1) can perform provisioning (e.g., pre-configuration and / or subsequent initial registration with the network) using the necessary parameters so that it can discover / select and connect via the WTRU-network relay. The WTRU-network relay can be provisioned to provide L2 relay services. The WTRU-network relay WTRU can camp on a CAG cell.

[0150] At 801, the WTRU-network relay WTRU can send a PC5 broadcast message (e.g., including relay service-related information such as application ID, relay service code, relay capability indicator, current cell CAG information, cell support CAG ID, and / or permitted CAG ID, CAG-only indicator, etc., such as relay CAG information).

[0151] At 802, the remote WTRU can receive the PC5 broadcast message from the WTRU-network relay WTRU and select a relay based on the application ID, relay service code or relay capability indicator, current cell CAG information, and / or relay CAG information. At 803, the remote WTRU can send a PC5 unicast request message (e.g., to request link establishment with the WTRU-network relay WTRU). At 804, the remote WTRU and the WTRU-network relay WTRU can perform mutual authentication. At 805, the WTRU-network relay WTRU can send a DSMC message (e.g., including cell CAG information with relay WTRU CAG information and integrity protection).

[0152] In 806, the remote WTRU may check the integrity protection of the DSMC and / or compare the previous relay / cell CAG information received via a broadcast message with the relay / cell CAG information. The remote WTRU may abort link establishment (e.g., if the integrity check fails). The remote WTRU may verify that the received relay CAG information contains at least one CAG ID that matches the remote WTRU permitted CAG ID. The remote WTRU may proceed with link establishment (e.g., if a match is found). The remote WTRU may abort link establishment (e.g., if no match is found).

[0153] In 807, the remote WTRU may send a DSMC complete message (e.g., containing the CAG information of the remote WTRU such as the permitted CAG ID and / or CAG indicator, with integrity and confidentiality protection) to the WTRU-network relay WTRU. In 808, the WTRU-network relay WTRU may store the mapping of the CAG information of the remote WTRU together with the PC5 link. In 809, the WTRU-network relay WTRU may trigger a service request procedure (e.g., if in the CM_IDLE state). In 810, the WTRU-network relay WTRU may send a PC5 unicast response message, for example, to complete the PC5 link establishment.

[0154] In 811, the remote WTRU may send NAS messages to the network via the WTRU-network relay WTRU as described herein. The WTRU-network relay WTRU and the remote WTRU may be served by the same AMF or different AMFs. In 812, the remote WTRU may perform PDU session establishment. In 813, the remote WTRU may send / receive data via the WTRU-network relay / RAN / remote WTRU UPF (e.g., the WTRU-network relay may perform conventional forwarding at L2).

[0155] (For example, when the ProSe L2 relay is in the CM connection state) The ProSe L2 relay can subscribe to paging notifications from the 5G-RAN. The ProSe L2 relay may send a paging subscription request to the 5G-RAN, which may include the ProSe L2 relay ID, the ID of the remote WTRU (e.g., or the paging occasion (PO) of the remote WTRU). After receiving a paging message for the remote WTRU from the core network, the 5G-RAN can send the paging message for the remote WTRU to the ProSe L2 relay (e.g., based on the ID of the remote WTRU and / or the PO subscribed by the ProSe L2 relay).

[0156] The ProSe L2 relay can establish a PC5 connection with the remote WTRU and receive paging parameters of the remote WTRU from the remote WTRU. The remote WTRU can send paging parameters during or after the establishment of the PC5 connection. The remote WTRU can send updated paging parameters to the ProSe L2 relay (e.g., when the paging parameters change, such as when the remote WTRU paging identification information and / or the PO are changed).

[0157] The ProSe L2 relay may send a paging subscription request to the 5G-RAN (e.g., when the ProSe L2 relay is in the CM connection state, and this may include the ProSe L2 relay ID, the ID of the remote WTRU, and / or the PO of the remote WTRU). The ID or PO of the remote WTRU may be obtained from the paging parameters.

[0158] (For example, when the ProSe L2 relay is in an idle state,) the ProSe L2 relay can interrupt the paging subscription request. The ProSe L2 relay can send a paging subscription request (for example, a request for a remote WTRU to be subscribed, such as a remote WTRU with a PC5 connection to the relay WTRU) (for example, when the ProSe L2 relay enters the CM connection state). The ProSe L2 relay can send a request to the 5G-RAN to cancel the subscription to paging notifications (for example, when the PC5 connection with the remote WTRU is released). The ProSe L2 relay can receive a paging message for the remote WTRU from the 5G-RAN and transfer the paging message to the remote WTRU (for example, via the PC5 interface).

[0159] The 5G-RAN can receive a paging subscription request from the ProSe L2 relay (for example, which includes the ProSe L2 relay ID, the ID of the remote WTRU, and / or the PO of the remote WTRU). The 5G-RAN can receive a paging message from the AMF. The 5G-RAN can transfer the paging message to the relevant ProSe L2 relay (for example, when the ID of the WTRU in the paging message matches the ID of the remote WTRU received in the paging subscription request). The 5G-RAN can receive a paging message from the AMF. The 5G-RAN can transfer the paging message to the relevant ProSe L2 relay (for example, when the PO for the paging message matches the PO received in the paging subscription request).

[0160] The stop monitoring procedure may be performed such that the transmission and / or reception of redundant information can be reduced or avoided. The remote WTRU can check, for example, the cell ID, gNB ID, and / or tracking area ID (TAI) broadcast by the RAN when the remote WTRU (re)enters the coverage of the RAN (e.g., gNB) in idle mode. The remote WTRU may also check other information broadcast within the SIB (e.g., by a relay node). The remote WTRU can compare the information received from the RAN with the broadcast information received from the relay node. For example, the remote WTRU can compare the TAI received from the RAN with the TAI received from the relay node. For example, if both TAIs are the same or the TAI received from the RAN belongs to a list of TAIs that could have been received from the core network during a previous registration procedure, the remote WTRU can know (or recognize) that it can receive paging messages and other information from the RAN. The remote WTRU can decide to notify the relay node (e.g., relay WTRU) that the relayed information is no longer needed (e.g., if it can receive paging messages and other information from the RAN).

[0161] The remote WTRU can initiate a stop monitoring procedure. In one example, a PC5-S stop monitoring request or a similar PC5 message can be sent to the relay WTRU. The stop monitoring request message can include an indication that, for example, the relay WTRU should stop transmitting broadcast information (e.g., SIB, cell ID, paging message, Multimedia Broadcast / Multicast Service (MBMS) information / content). The stop monitoring request message can be configured to include information that the relay WTRU should abort transmissions. For example, the remote WTRU may indicate to the relay WTRU to stop transmitting (e.g., only) the remote WTRU paging message. Other information excluded from the stop monitoring request message (e.g., SIB and cell ID) may (e.g., implicitly) indicate that the other information may still be needed but can be relayed by the relay WTRU (e.g., continuously). The stop monitoring request message can be integrity protected, replay protected, and / or confidentiality protected to prevent malicious requests (e.g., denial of service (DoS) attacks) sent towards the relay WTRU, such as requests intended to cause a loss of service to the remote WTRU.

[0162] The relay WTRU can, for example, stop relaying information indicated (e.g., explicitly and / or implicitly) in a message when the relay WTRU receives the message. The relay WTRU can also, for example, stop reading the Uu paging channel at the remote WTRU's ID and the remote WTRU's paging opportunity (PO) if paging message information is included by the remote WTRU within the stop monitoring request. The relay WTRU can send a response or acknowledgment message back to the remote WTRU (e.g., to confirm receipt of the request).

[0163] For example, when the remote WTRU determines that it depends on broadcast information (e.g., paging message, SIB, cell ID, MBMS, etc.) from the relay WTRU, the remote WTRU can use the relay WTRU to initiate (e.g., at any time) the normal "information monitoring request" procedure. The remote WTRU can, for example, send an information monitoring request message to the relay WTRU. The relay WTRU can start (e.g., resume) monitoring the requested information, start reading the Uu paging channel, and / or reply to the remote WTRU (e.g., with an information monitoring response message).

[0164] A secure link can be established between a remote WTRU and a WTRU-network relay (which may be referred to as a "relay" in this specification). For example, the security of the PC5 link between the remote WTRU and the WTRU-network relay can be established (e.g., initiated) by performing a primary authentication with the network of the remote WTRU. For example, the remote WTRU can send a request message (e.g., a direct communication request) to the relay to establish the PC5 link. The message may include the identification information of the remote WTRU (e.g., a Subscription Concealed Identifier (SUCI)). The remote WTRU can perform a primary authentication procedure on the PC5 link with the relay using the AMF of the relay and the home AUSF of the remote WTRU with the relay. The remote WTRU can derive and store a PC5 root key and an ID (e.g., Krelay and Krelay ID) based on a master key (e.g., KAMF) derived from the execution of the primary authentication (e.g., after the successful authentication of the network by the remote WTRU). The remote WTRU can receive a request message (e.g., a direct security mode command) on PC5 from the relay. The remote WTRU can check that the request message includes a Krelay ID that matches the Krelay ID previously derived from the primary authentication. The remote WTRU can derive a session key (e.g., Krelaysess) from Krelay, derive an encryption key and an integrity key from the session key, and proceed with the security establishment procedure by sending a protected PC5 response message (e.g., a direct security mode complete). The remote WTRU can receive a response message (e.g., a direct communication acceptance) indicating the success of the establishment of the PC5 link.

[0165] For example, a WTRU-network relay can receive a request message (e.g., DCR) from a remote WTRU and establish a PC5 link. The request message from the remote WTRU may include identification information of the remote WTRU (e.g., SUCI). The relay can send the request message to its serving AMF for approval of the remote WTRU. The request message from the relay may include identification information of the remote WTRU (e.g., SUCI). The relay can transfer authentication messages bi-directionally between the remote WTRU and its serving AMF. The relay can receive a response message including a PC5 root key and ID (e.g., Krelay and Krelay ID) from its serving AMF, indicating that the authentication and approval of the remote WTRU were successful. The response message may include identification information of the core network remote WTRU (e.g., a primary Globally Unique Temporary Identifier (GUTI), a Generic Public Subscription Identifier (GPSI)). The relay can store (e.g., associate them with the PC5 link context) the root key, key ID, and identification information of the core network remote WTRU. The relay can derive a session key, an encryption key, and an integrity key using the Krelay received from the AMF. The relay can send a PC5 request message (e.g., a direct security mode command) including the Krelay ID received from its serving AMF to the remote WTRU. The message is protected for integrity using the above integrity key. The relay can receive a PC5 response message (e.g., a direct security mode complete) from the remote WTRU. The relay can check the security protection (e.g., confidentiality and / or integrity) of the message. Once the secure PC5 link is successfully established, the relay can proceed to connectivity signaling with the network (e.g., by establishing a new PDU session or reusing an existing one) as described herein.The relay may send a response message (e.g., DCA) indicating the success of establishing the PC5 link to the remote WTRU.

[0166] For example, the serving AMF of the WTRU-network relay can receive a request message from the relay to approve the remote WTRU. The message may include the identification information of the remote WTRU (e.g., SUCI). The AMF can trigger the remote WTRU authentication procedure using the home AUSF of the remote WTRU. The AMF can execute the primary authentication procedure of the remote WTRU via the relay. The AMF can receive a response message from the AUSF of the remote WTRU indicating the success of the authentication and approval of the remote WTRU, including the identification information of the remote WTRU (e.g., Subscriber Permanent Identity, SUPI) and the anchor key (e.g., KAUSF / KSEAF). The AMF can derive the PC5 root key and ID (e.g., Krelay and Krelay ID) based on the master key (e.g., KAMF) derived from the anchor key. The AMF can store the received identification information of the remote WTRU (e.g., SUPI) as part of the WTRU context of the relay. The AMF can allocate and store the identification information of the remote WTRU in the core network (e.g., GUTI, GPSI) as part of the WTRU context of the relay. The AMF can register with the UDM of the remote WTRU as the AMF of the relay serving the remote WTRU by providing the AMF identification information and / or the identification information of the relay (e.g., SUPI or GPSI). The AMF can send a response message including the PC5 root key and ID (e.g., Krelay and Krelay ID) to the relay. The AMF response message can include the identification information of the remote WTRU (e.g., GPSI) in the core network.

[0167] For example, re - authentication / authorization of a remote WTRU for using a WTRU - network relay can be performed at the AMF serving the relay, the relay, and the remote WTRU. For example, after successful authorization of a remote WTRU for using a relay, the serving AMF can initiate re - authentication / authorization of the remote WTRU at any time. In one example of a scenario, the authorization scope can be limited with respect to time or location. During the movement of the relay, a change in the AMF serving the relay can occur, but the new AMF can obtain the WTRU context of the relay, including remote WTRU information (e.g., new Krelay and KrelayID and identification information) from the old AMF as described herein. The new AMF can update the registration information of the serving AMF with the UDM of the remote WTRU. The new AMF can initiate re - authentication / authorization of the remote WTRU in the process described herein. When such re - authentication / authorization is performed, the remote WTRU can generate a new PC5 root key / key ID, and the relay can obtain a new Krelay and Krelay ID from the new serving AMF as described herein. The relay can execute a key update procedure via the PC5 link with the remote WTRU using the new PC5 root key / key ID. The remote WTRU can initiate the key update procedure by including the new Krelay ID in a direct re - key request message to the relay. The relay can check that the received Krelay ID matches the new Krelay ID derived according to the remote WTRU re - authentication procedure. Upon successful check of the match, the relay can trigger a direct security command procedure to establish a new session, as well as integrity and confidentiality keys using Krelay as the PC5 link root key. The roles of the relay and the remote WTRU can be reversed when performing the above - mentioned key update procedure. For example, the relay may initiate the key update procedure.

[0168] For example, the cancellation of authorization for a remote WTRU to use a WTRU-network relay can be performed at the AMF serving the relay, the relay, and the remote WTRU. For example, the AMF can receive a request message from the UDM of the remote WTRU, which includes an indicator indicating the cancellation of authorization for the remote WTRU to use the relay (e.g., by a remote WTRU subscription change) and identification information of the relay serving the remote WTRU. The AMF can send a request message, which includes an indicator indicating the cancellation of authorization for the remote WTRU to use the relay, the Krelay ID associated with the remote WTRU, and / or the identification information of the core network remote WTRU (e.g., GPSI), to the relay serving the remote WTRU. The relay can locate the PC5 link context based on the received Krelay ID and / or the identification information of the core network remote WTRU and initiate the link release procedure for the PC5 link associated with the remote WTRU. The relay may delete the PC5 link context together with the associated Krelay and remote WTRU information. (For example, if a dedicated PDU session is being used by the remote WTRU,) the relay can initiate the PDU session release procedure triggered to the WTRU. The relay can send a response message indicating the success of releasing the connection of the remote WTRU to the AMF. The AMF can send a response message indicating the success of the cancellation of authorization to the UDM of the remote WTRU. The AMF can send a request to cancel the remote WTRU authorization as described above (e.g., for overload control purposes), but it may also be based on the serving network policy.

[0169] A secure link can be established after reconnection between a remote WTRU and a WTRU-network relay. For example, the WTRU-network relay can receive a request message (e.g., DCR) from the remote WTRU and establish a PC5 link. The request message can include a Krelay ID. The relay can check that the received Krelay ID matches a valid existing Krelay ID that may have been established during a previous connection, as described herein. The relay can proceed to establish a secure PC5 link using the Krelay, as described herein. Once the secure PC5 link is successfully established, the relay can proceed to connection signaling with the network and completion of the PC5 link establishment, as described herein.

[0170] Figure 9 shows an example of a message sequence for WTRU-network relay discovery and selection. The WTRU-network relay may be, or may include, a WTRU 102 as described herein with respect to FIGS. 1A-1D. As shown in FIG. 9, at 901, the relay may send a network registration request (e.g., within a registration request message) to the core network (e.g., the AMF of the core network). The network registration request may include an indicator indicating that the relay may be a WTRU-network relay. The AMF may receive the network registration request and perform access and mobility (AM) policy association establishment with the PCF on the core network. The AMF / PCF may determine the approved relay provisioning parameters for the WTRU-network relay and send the approved relay provisioning parameters in response to the network registration request. At 902, the relay may receive one or more relay service types as part of the approved relay provisioning parameters and associated communication parameters (e.g., those in the registration acceptance message) approved by the core network (e.g., the AMF / PCF of the core network). The associated communication parameters may include PDU session parameters such as S-NSSAI, DNN, and / or SSC mode.

[0171] In 903, a relay access WTRU (e.g., a remote WTRU) can send a network registration request (e.g., in a registration request message) to a core network (e.g., the AMF of the core network). The relay access WTRU may be, or may include, a WTRU 102 as described herein with respect to FIGS. 1A-1D. The network registration request may include an indicator indicating that the relay access WTRU is able to relay access (e.g., access a relay WTRU). The AMF can perform access and mobility (AM) policy association establishment with a PCF on the core network. The AMF / PCF can determine the approved relay access WTRU provisioning parameters for the relay access WTRU and send the approved relay access WTRU provisioning parameters in response to the network registration request.

[0172] In 904, the relay access WTRU can then receive, as part of the provisioning parameters of the relay access WTRU approved by the core network (e.g., the AMF / PCF of the core network) and the associated communication parameters (e.g., those in a registration acceptance message), one or more relay service types. The associated communication parameters may include PDU session parameters such as S-NSSAI, DNN, and / or SSC mode.

[0173] At 905, the WTRU-network relay can broadcast a relay service type (e.g., identified from one or more approved relay service types received at 902). The WTRU-network relay can identify a relay service type for broadcasting based on, for example, communication parameters associated with one or more approved relay service types and the granted network resources associated with the WTRU-network relay. For example, the relay service type can be identified for broadcasting provided that at least one communication parameter associated with the relay service type is supported by the granted network resources. For example, the granted network associated with the WTRU-network relay can be or can include a permitted network slice selection assistance information (NSSAI). The permitted NSSAI can be received, for example, from the core network (e.g., the AMF of the core network) in a registration acceptance message. The relay service type can be identified for broadcasting provided that the permitted NSSAI received from the core network includes the S-NSSAI associated with the relay service type.

[0174] The WTRU-network relay can receive one or more rejected network resources, such as a rejected S-NSSAI (e.g., in a registration acceptance message). The WTRU-network relay may refrain from broadcasting an approved relay service type, provided that the approved relay service type is associated with communication parameters (e.g., S-NSSAI) included in one or more rejected network resources (e.g., rejected S-NSSAI).

[0175] At 906, the relay access WTRU may determine whether to select a WTRU-network relay (e.g., based on whether the relay service type the relay access WTRU is interested in using is the relay service type broadcast by the WTRU-network relay). For example, the relay access WTRU may determine to select a WTRU-network relay under the condition that the relay service type broadcast by the WTRU-network relay matches the relay service type the relay access WTRU is interested in using.

[0176] The relay access WTRU can identify the relay service type of interest based on the network requirements and communication parameters associated with the approved relay service type that the relay access WTRU is approved to use. For example, the approved relay service type can be identified as the relay service type of interest under the condition that the associated communication parameters meet the network requirements. The network requirements can be applications based on the local URSP of the relay access WTRU, such as the requirements of the S-NSSAI. The network requirements can be service continuity, such as the requirements of a specific SSC mode. When the S-NSSAI associated with the approved relay service type matches the S-NSSAI required by the application, the approved relay service type received from the core network can be identified as the relay service type of interest.

[0177] The relay access WTRU can determine to select a WTRU-network relay, further based on the WTRU-network relay selection policy received from the core network (e.g., in an admission acceptance message). The relay selection policy may prioritize a WTRU-network relay that provides the maximum number of relay service types in order to minimize the number of PC5 links that need to be configured. The relay selection policy may prioritize having redundancy of relayed communications of similar relay service types. The relay selection policy may prioritize a WTRU-network relay that broadcasts an indication of an available relay service type over another WTRU-network relay that broadcasts an indication of the same relay service type that is conditionally available. The relay selection policy may prioritize a WTRU-network relay that does not broadcast an indication of high-level usage. The relay selection policy can refrain from selecting a WTRU-network relay that broadcasts an indication of high-level usage.

[0178] Although features and elements are described above in certain combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Further, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: authenticating the first WTRU by a network via a second WTRU; determining a PC5 root key based on a master key obtained from the authentication of the first WTRU; receiving, from the second WTRU, a first PC5 message, wherein the first PC5 message is a direct security mode command message; determining an encryption key and / or an integrity key based on the PC5 root key; transmitting, to the second WTRU, a second PC5 message, wherein the second PC5 message is a direct security mode completion message protected using at least one of the encryption key and the integrity key.

2. The method of claim 1, wherein the master key is derived from the authentication of the first WTRU.

3. The method of claim 1, further comprising determining an identifier (ID) of the PC5 root key based on the master key obtained from the authentication of the first WTRU, wherein the determining of at least one of the encryption key and the integrity key is based on the PC5 root key and the ID of the PC5 root key.

4. The method of claim 1, further comprising transmitting, to the second WTRU, a direct communication request message for establishing a PC5 link with the second WTRU prior to the authentication of the first WTRU by the network.

5. The method of claim 4, wherein the direct communication request message includes a subscription concealment identifier (SUCI) of the WTRU.

6. The method of claim 4, further comprising receiving, from the second WTRU, a direct communication acceptance message indicating establishment of the PC5 link with the second WTRU after transmitting the direct security mode completion message.

7. The method of claim 6, further comprising communicating with the network via the second WTRU using the PC5 link after receiving the direct communication acceptance message.

8. The method of claim 1, wherein the PC5 root key is derived based on the master key.

9. ​ The method according to claim 1, wherein the encryption key and the integrity key are derived based on the PC5 root key. **Claim 10** The method according to claim 1, wherein the first PC5 message is protected based on the PC5 root key. **Claim 11** A first wireless transmit / receive unit (WTRU), comprising: authenticating, via a second WTRU, the first WTRU by a network; determining a PC5 root key based on a master key obtained from the authentication of the first WTRU; receiving, from the second WTRU, a first PC5 message, wherein the first PC5 message is a direct security mode command message; determining an encryption key and / or an integrity key based on the PC5 root key; transmitting, to the second WTRU, a second PC5 message, wherein the second PC5 message is a direct security mode completion message protected using at least one of the encryption key and the integrity key. **Claim 12** The first WTRU according to claim 11, wherein the master key is derived from the authentication of the WTRU. **Claim 13** The processor is further configured to: determine an identifier (ID) of the PC5 root key based on the master key obtained from the authentication of the first WTRU; The first WTRU according to claim 11, wherein at least one of the encryption key and / or the integrity key is determined based on the PC5 root key and the ID of the PC5 root key. **Claim 14** The processor is further configured to: transmit, to the second WTRU prior to the authentication of the first WTRU by the network, a direct communication request message for establishing a PC5 link with the second WTRU. **Claim 15** The first WTRU according to claim 14, wherein the direct communication request message includes a subscription concealment identifier (SUCI) of the WTRU. **Claim 16** The processor is further configured to: The first WTRU according to claim 14, configured to receive, from the second WTRU, a direct communication acceptance message indicating establishment of the PC5 link with the second WTRU after the direct security mode completion message has been transmitted. **Claim 17** The processor and the transceiver are The first WTRU according to claim 16, configured to communicate with the network via the second WTRU using the PC5 link after the direct communication acceptance message has been received. **Claim 18** The first WTRU according to claim 11, wherein the PC5 root key is derived based on the master key. **Claim 19** The first WTRU according to claim 11, wherein the encryption key and the integrity key are derived based on the PC5 root key. **Claim 20** The first WTRU according to claim 11, wherein the first PC5 message is protected based on the PC5 root key.

Images