WTRU-to-network relay

Abstract

Systems and methods are described herein for enabling discovery and selection of WTRU to network relays by a remote WTRU and handling of WTRU to network relay configuration updates. The WTRU-to-network relay may broadcast a service type based on the WTRU-to-network relay slice configuration, indicating that the service type is available or conditionally available. The WTRU-to-network relay may update the broadcast of the service type or an indication that the service type is conditionally available based on an update of the WTRU-to-network relay slice configuration. The WTRU-to-network relay may relay communication traffic between one or more different remote WTRUs and a core network node via the WTRU-to-network relay. The WTRU-to-network relay may reutilize an existing PDU session for relaying communication traffic, or send a PDU session setup request to the network along with the requested PDU session parameters, depending on whether the session parameters associated with the existing PDU session match the PDU session requirements of the remote WTRU.

Description

[0001] This divisional application is a divisional application with application date of November 6, 2020, application number 202080083894.9, and invention name “WTRU to Network Relay”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 932,219, filed on November 7, 2019; U.S. Provisional Application No. 62 / 957,530, filed on January 6, 2020; U.S. Provisional Application No. 62 / 975,956, filed on February 13, 2020; and U.S. Provisional Application No. 63 / 086,436, filed on October 1, 2020, the contents of which are incorporated herein by reference. Background Art

[0004] A wireless transmit / receive unit (WTRU) to network relay may establish a protocol data unit (PDU) session based on a default configuration (e.g., a default data network name (DNN)) for relaying communication traffic between a remote WTRU and a core network. Various signaling mechanisms and resource usage on the remote WTRU and the WTRU to network relay in such communication networks may be insufficient or inefficient. Summary of the invention

[0005] A wireless transmit / receive unit to network (WTRU to network) relay may be configured to send a network registration request indicating its WTRU to network relay capabilities. In response to the network registration request, an indication of one or more authorized relay service types and communication parameters associated with the authorized relay service types may be received. Based on the communication parameters and the network resources granted to the WTRU to network relay, the WTRU to network relay may identify a relay service type from the authorized relay service type for broadcast. For example, the authorized relay service type may be identified for broadcast under the condition that the communication parameters associated with the relay service type are supported by the granted network resources associated with the WTRU to network relay. The granted network resources may be or may include PDU session parameters, such as 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 broadcast.

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

[0007] The relay service type of interest may be identified from the authorized relay service type, for example, based on network resource requirements and communication parameters associated with the authorized relay service type. For example, the authorized relay service type may be identified as the target relay service type under the condition that the network resource requirements associated with the relay access WTRU are supported by the communication parameters associated with the authorized relay service type. The WTRU to network relay may be selected under the condition that the relay service types broadcasted by the WTRU to the network include the target relay service type identified by the relay access WTRU. The communication parameters associated with the authorized relay service type may be or may include S-NSSAI, DNN and / or SSC mode. The network resource requirements associated with the relay access WTRU may be or may include S-NSSAI, DNN and / or SSC mode.

[0008] Systems and methods for enabling discovery and selection of a WTRU-to-network relay by a remote WTRU and processing of WTRU-to-network relay configuration updates are described herein. A WTRU-to-network relay may perform an initial registration with a core network. A WTRU-to-network relay may receive one or more WTRU-to-network relay configuration parameters from the core network. A WTRU-to-network relay may broadcast a service type indicating that a service type is conditionally available. When a configured service type becomes part of a set of allowed service types, the WTRU-to-network relay may update its broadcast information regarding the conditionally available service type to the service type available.

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

[0010] The remote WTRU may perform discovery and selection of a WTRU to a network relay based on: a relay broadcast of a service type associated with a Controlled Access Group (CAG) ID (e.g., during configuration) (e.g., selection based on an implicit CAG), or a relay broadcast of CAG information (e.g., selection based on an explicit CAG) including one or more of the following: CAG IDs supported by the current CAG cell, CAG IDs allowed by the relay, or a CAG indication only.

[0011] The WTRU-to-network relay may perform access control for a remote WTRU accessing a CAG cell. The relay WTRU may determine that the remote WTRU is authorized to access the CAG ID based on a successful per-application / service type authentication, for example, where an application may be associated with a CAG ID and the application layer keys may be used to establish / derive PC5 layer keys.

[0012] A WTRU-to-network relay may perform PC5 link maintenance based on a change in CAG ID (e.g., after mobility or configuration update). A relay WTRU may determine, for example, after a CAG change, whether a connected remote WTRU is authorized to access a serving cell (e.g., a new serving cell) via the relay based on the remote WTRU CAG information mapped with the PC5 link and the current serving cell CAG information. The relay WTRU may release the PC5 link, providing a cause that may indicate a CAG context, such as a new CAG context (e.g., no CAG ID available).

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

[0014] For example, when a remote WTRU re-enters network coverage, a stop monitoring procedure may be performed (eg, between a remote WTRU and a relay WTRU).

[0015] The remote WTRU and the WTRU-to-network relay may establish a secure PC5 link using credentials derived from the remote WTRU's primary authentication run performed via the WTRU-to-network relay. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.

[0017] Figure 1B is a diagram according to one embodiment which can be Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0018] Figure 1C is a diagram according to one embodiment which can be Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) for use within a communication system is shown.

[0019] Figure 1D is a diagram according to one embodiment which can be Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown.

[0020] Figure 2 is a diagram illustrating an exemplary reference model for proximity-based services.

[0021] Figure 3 is a diagram illustrating a ProSe architecture using WTRU to network relay.

[0022] Figure 4 is an exemplary message sequence chart illustrating establishment of communication traffic between a remote WTRU and a core network node (eg, session management function (SMF) / user plane function (UPF)).

[0023] Figure 5 An exemplary control plane protocol stack is shown.

[0024] Figure 6is an exemplary message sequence chart illustrating establishment of communication traffic between a remote WTRU and a core network node (eg, SMF / UPF).

[0025] Figure 7 is an exemplary message sequence chart illustrating establishment of communication traffic between a remote WTRU and a core network node (eg, SMF / UPF).

[0026] Figure 8 A process for WTRU-to-network relay discovery, selection, and communication via a layer 2 WTRU-to-network relay is shown.

[0027] Fig. 9 is an exemplary message sequence chart illustrating WTRU-network relay discovery and selection by a relay-access WTRU. DETAILED DESCRIPTION

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

[0029] like Figure 1AAs shown, the 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, but 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 may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

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

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

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

[0036] 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 dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0037] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio 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), GSM Enhanced Data Rates for Evolution (EDGE), GSM EDGE (GERAN), etc.

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

[0039] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the specification, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0040] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network 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) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0041] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

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

[0043] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0047] 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. In addition, the processor 118 may access information from and store data in any type of suitable 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).

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

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

[0050] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: 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.

[0051] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent 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., choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

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

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

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

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

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

[0060] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communications interface with a communications network.

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

[0062] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and directed to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and directed to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, where the source STA may send 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 point-to-point traffic. Point-to-point traffic may be sent between the source and destination STAs (e.g., directly between them) using direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0063] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit a beacon on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0064] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0065] Very high throughput (VHT) STAs may support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels may be formed by combining consecutive 20MHz channels. A 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-contiguous 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may divide the data into two streams. Each stream may be individually processed by an inverse fast Fourier transform (IFFT) and time domain processing. These streams may be mapped to two 80MHz channels, and data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to a medium access control (MAC).

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

[0067] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include 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 may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may 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) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

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

[0069] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to one embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

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

[0072] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or be connected with the gNBs 180a, 180b, 180c while also communicating or being connected with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0073] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. As shown in FIG. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0074] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

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

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

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

[0079] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0080] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0081] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test lab and / or a test scenario in a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more simulation devices may be test devices. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0082] Proximity Services (ProSe) in wireless communication systems may enable direct communication between two WTRUs that are in close proximity to each other. As used herein, the term ProSe may be used to refer to direct WTRU-to-WTRU transmissions, regardless of whether network scheduler-based cooperation is used. Figure 2 An exemplary reference model for proximity-based services is shown. Figure 2 As shown, the ProSe function may include one or more of a direct configuration function (DPF) or a direct discovery name management function. The DPF may be used to configure one or more parameters for the WTRU to use the ProSe direct discovery service and the ProSe direct communication service. The direct discovery name management function may be used to open ProSe direct discovery, for example, to allocate and handle the mapping of the ProSe application ID and the ProSe application code used in the ProSe direct discovery.

[0083] like Figure 2 As shown, ProSe-enabled WTRUs in close proximity (e.g., WTRU A and WTRU B) may support the exchange of ProSe control information between each of the WTRUs and a ProSe function over an interface (e.g., PC3 interface). The ProSe-enabled WTRUs may also support procedures for open and restricted ProSe direct discovery of other ProSe-enabled WTRUs over a radio interface (e.g., PC5 interface).

[0084] The ProSe application server may support one or more capabilities including, for example, storing ProSe application layer information (mapping of application layer user IDs) and network layer ProSe user IDs.

[0085] Figure 3 An exemplary ProSe architecture using a WTRU-to-network relay is shown. A ProSe WTRU-to-network relay in the network can connect one or more remote WTRUs to the core network. Figure 3 As shown, a remote WTRU that is outside the NR network coverage and cannot directly connect to the core network can use its PC5 interface to communicate with the WTRU-to-network relay to connect to the core network. Figure 3 As shown, a remote WTRU may discover and select a WTRU-to-network relay. The WTRU-to-network relay may establish a PDU session (or a PDN connection in the Evolved Packet Core (EPC)) for the remote WTRU. Communication traffic between the remote WTRU and the core network may be relayed via the WTRU-to-network relay, for example, as Figure 4 shown.

[0086] Figure 4 is an exemplary message sequence diagram illustrating establishment of a session between a remote WTRU and a core network node (eg, session management function (SMF) / user plane function (UPF)). Figure 4 As shown, at 401, the WTRU to network relay may send a registration request to the access and mobility management function in the core network. At 402, the WTRU to network relay may receive a registration acceptance message. At 403, the remote WTRU may perform a discovery process. At 404, the remote WTRU may establish a connection with the WTRU to network relay. At 405, the WTRU to network relay may send a PDU session establishment request to the SMF / UPF of the core network. At 406, the WTRU to network relay may receive an establishment response from the SMF / UPF. At 407, the IP address / prefix assigned to the remote WTRU and the communication traffic between the remote WTRU and the core network may be relayed via the WTRU to network relay.

[0087] The 5G system may support public network integrated non-public networks (PNI-NPNs) using selection and access control based on controlled access group (CAG) cells. A CAG-enabled WTRU (e.g., configured with an appropriate CAG ID) may be authorized (e.g., via a CAG cell) to access the network. A CAG-enabled WTRU may select a CAG cell that broadcasts supported CAG IDs, such as those that match at least one of the allowed CAG IDs (e.g., configured in the WTRU and / or included in the subscription) of the WTRU. The WTRU may be granted access to the network via a CAG cell (e.g., by an AMF) (e.g., when at least one of the allowed CAG IDs from the WTRU subscription is included in the CAG IDs supported by the CAG cell). A CAG-enabled WTRU configured with a "CAG-only indication" may access the network (e.g., via a CAG cell). In the absence of such an indication, the WTRU may access both CAG cells and non-CAG cells (e.g., public cells).

[0088] A remote WTRU may access the network (eg, via a ProSe L2 relay). Figure 5 An exemplary control plane protocol stack is shown. The remote WTRU may be visible to the network (e.g., with a ProSe L2 relay). The RAN may terminate RRC signaling and / or NG-AP signaling (e.g., with a ProSe L2 relay). The behavior of the remote WTRU may be the same as a non-remote WTRU (e.g., from the perspective of the AMF). The remote WTRU may access the 5G-RAN via a ProSe L2 relay, and the RRC layer behavior may be the same as a non-remote WTRU.

[0089] The 5G-RAN may release the RRC connection with the remote WTRU (e.g., to move the remote WTRU to an idle state, which may be the same as a non-remote WTRU). The ProSe L2 relay may intercept a paging message (e.g., for the remote WTRU) and forward the paging message to the remote WTRU (e.g., if the remote WTRU maintains a PC5 session). The 5G-RAN may send an RRC paging message (e.g., when the ProSe L2 is finally in idle mode). The 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., when the ProSe L2 relay is in connected mode).

[0090] The remote WTRU may be authorized to access the network via the relay by performing a primary authentication run via the WTRU to the network relay and using the AMF of the relay and the authentication function (AUSF) of the remote WTRU. The remote WTRU may complete a PC5 link establishment with the relay to perform communications via the relay (e.g., after primary authentication and authorization).

[0091] In a wireless communication network (e.g., a 4G wireless communication network), a WTRU-to-network relay may establish a PDU session for communication traffic relay based on a default configuration (e.g., a default data network name (DNN)). Network slicing in a 5G communication network may introduce a set of communication service requirements that the WTRU-to-network relay may support. For example, a 4G WTRU-to-network relay may not support the slicing requirements of one or more remote WTRUs due to existing limits on network slice selection assistance information (NSSAI) storage (e.g., up to 8 allowed NSSAIs, 16 configured NSSAIs) or other restrictions that the serving network may impose on the number of simultaneous S-NSSAIs used by the WTRU. Therefore, with respect to the types of services that the WTRU-to-network relay may provide to the remote WTRU simultaneously, the relay may be limited in terms of slices (S-NSSAI) or other PDU session parameters (e.g., PDU session type, session and service continuity (SSC) mode, etc.). For example, a WTRU-to-network relay may be configured with a configured NSSAI that may not include an S-NSSAI that the remote WTRU may use. The remote WTRU may initiate (selectively initiate) communications with a WTRU-to-network relay that may support the communication service requirements, rather than with a WTRU-to-relay that may not support such requirements, for example to avoid unnecessary signaling and resource usage on both the remote WTRU and the WTRU-to-network relay node.

[0092] Mechanisms may be provided for a remote WTRU to discover and / or select a WTRU-to-network relay that may satisfy the communication requirements of the remote WTRU (e.g., for a single NSSAI (S-NSSAI)). Mechanisms may also be provided for a WTRU-to-network relay to handle WTRU-to-network relay configuration updates (e.g., slice configuration updates) related to relay discovery and one or more relay communications.

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

[0094] WTRU-to-network relay discovery and selection (e.g., based on CAG ID) may be performed. WTRU-to-network relays and remote WTRUs may be deployed (e.g., in industrial and / or vertical environments). The relay may provide extended range in a building (e.g., a factory) to remote WTRUs (e.g., machines, operator phones) that wish to access a private network provided by a PNI-NPN. Access to a PNI-NPN via a WTRU-to-network relay may be supported (e.g., in such use cases). One or more of the features described herein may relate to one or more of the following:

[0095] Discover and select a WTRU-to-network relay that can provide access (e.g., via a CAG cell); perform access control on a remote WTRU (e.g., a CAG-enabled or non-CAG-enabled remote WTRU) that accesses a network using a WTRU-to-network relay connected via a cell (e.g., a CAG or non-CAG cell); handle changes in available CAGs with respect to relay discovery and ongoing relay communications through the relay (e.g., CAG cell changes due to WTRU-to-network relay mobility); or WTRU-to-network relay CAG configuration updates (e.g., updates to allowed CAG IDs).

[0096] The remote WTRU may be paged (e.g., via a ProSe L2 relay). The 5G-RAN may remove (e.g., when the remote WTRU enters an idle state) the stored remote WTRU context information (e.g., identity, mobility, security, etc.) associated with the connected WTRU. The 5G-RAN may not be aware of where the remote WTRU is located, such as whether the remote WTRU still accesses the ProSe L2 relay and / or which ProSe L2 relay the remote WTRU still accesses. The 5G-RAN may broadcast a paging message for the remote WTRU on a paging channel and send the paging message to all ProSe L2 relays in connected mode one by one via an SRB or a DRB (e.g., to ensure that the remote WTRU receives the paging message). In an example, it may be necessary to send a paging message for each remote WTRU to the ProSe L2 relay in connected mode via a unicast method. Sending a paging message for each remote WTRU to a ProSe L2 relay in connected mode through a unicast method may result in a large amount of radio resource consumption, for example, because there may be a large number of ProSe L2 relays in the paging area of ​​the remote WTRU (eg, in a Tracking Area (TA) list).

[0097] Redundant system information blocks (SIBs) and paging information may be received during idle mode. A remote WTRU in idle mode may receive (e.g., from an L2 WTRU to a network relay node) SIB information including, for example, cell ids and paging messages (e.g., in an L2 relay scenario). A remote WTRU (e.g., in an L2 relay scenario) may re-enter network coverage. A remote WTRU returning to network coverage may receive the same information from two different sources (e.g., a relay WTRU and a network (RAN)). One or more processes may notify a relay WTRU that broadcast information is no longer needed. In an example, the remote WTRU may notify the relay WTRU that the information being relayed is no longer needed.

[0098] A remote WTRU may establish a secure PC5 link with a WTRU-to-network relay. For example, when attempting to establish a PC5 link with a WTRU-to-network relay, the remote WTRU may perform a primary authentication run via the relay through the AMF of the relay and the AUSF of the remote WTRU. After successfully authenticating and authorizing the remote WTRU with the WTRU-to-network relay, the remote WTRU and the WTRU-to-network relay may proceed to establish a secure PC5 link. Security keys may be established for the PC5 link to protect communications conducted via the relay over the PC5 link. Additional authentication procedures between the remote WTRU and the WTRU-to-network relay may be avoided. Both unnecessary signaling and waste of resources at the remote WTRU and the WTRU-to-network relay (which may result in a denial of service (DOS) condition) may be avoided.

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

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

[0101] The WTRU-to-network relay may register with the core network to request an S-NSSAI based on the relay configuration information. The network may not currently allow S-NSSAI. The WTRU-to-network relay may pre-perform registration for one or more (e.g., all) S-NSSAIs corresponding to the configured service types, or the WTRU-to-network relay may trigger registration for an S-NSSAI corresponding to the configured service type, for example, upon receiving a request from a remote WTRU. The WTRU-to-network relay may trigger registration for an S-NSSAI corresponding to the service type based on one or more WTRU-to-network relay configuration parameters.

[0102] The WTRU-to-network relay may broadcast one or more messages via its PC5 interface announcing the types of services it can support. The broadcast message may include a WTRU-to-network relay indication (e.g., based on one or more WTRU-to-network relay configuration parameters). The WTRU-to-network relay may broadcast the service type, for example, if the corresponding S-NSSAI is included in a granted network resource (such as an allowed NSSAI). The WTRU-to-network relay may broadcast the service type, for example, if the corresponding S-NSSAI is included in a list of configured NSSAIs but not in an allowed NSSAI. In the case of broadcasting a service type corresponding to a configured NSSAI, the broadcast message may include an indication (explicit or implicit) that the service type is conditionally available. Once the configured S-NSSAI is part of the allowed NSSAI, the WTRU-to-network relay may stop broadcasting the indication that the service type is conditionally available.

[0103] A WTRU-to-network relay may not broadcast associated communication parameters for it (e.g., associated S-NSSAI), such as service types for which network resources are denied (e.g., for a registration area or public land mobile network (PLMN)). When a WTRU-to-network relay (e.g., for overload control purposes) reaches a maximum usage and / or load threshold, it does not broadcast one or more service types (e.g., stops all service broadcasts). For example, when a relay WTRU reaches a configured high usage and / or load threshold, the WTRU-to-network relay may include an explicit or implicit indication of high usage in its service broadcasts. The high usage value or load threshold may be configured as part of the WTRU-to-network relay configuration parameters. The high usage value or load threshold may be configured using overload control policy parameters. The usage or load level of the relay WTRU may be based on: the number of active PC5 links that the WTRU-to-network relay may have with one or more remote WTRUs, the number and type of PDU sessions, etc.

[0104] When the WTRU-to-network relay receives a request from a remote WTRU, for example, for a conditionally available service, it may trigger a registration process. The WTRU-to-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 allowed by the network, the WTRU-to-network relay may complete the establishment of a new link with the remote WTRU by sending a confirmation message (e.g., direct communication accepted) in response to the request from the remote WTRU. The WTRU-to-network relay may initiate a link modification for an existing link to add or remove a service, for example, in the event that the S-NSSAI is successfully allowed or rejected by the network. If the S-NSSAI is rejected, the WTRU-to-network relay may release the established link. The WTRU-to-network relay may provide the remote WTRU with the reason why the slice is unavailable.

[0105] A remote WTRU (which may be referred to herein as a relay-access WTRU) may perform an initial registration with a network as a WTRU that is capable of using (e.g., accessing) a WTRU-to-network relay. The remote WTRU may receive one or more relay-access WTRU configuration parameters during or after registration, including, for example, a set of service types authorized for use through the relay, associated communication parameters for each service type (e.g., S-NSSAI, DNN, SSC mode, etc.), and / or a WTRU-to-network relay selection policy. The S-NSSAI required for the service may be assumed to be part of the WTRU-configured NSSAI.

[0106] A remote WTRU may register with the core network to request S-NSSAI that may not currently be allowed and is associated with a service from the relay configuration information. A remote WTRU (e.g., an out of coverage WTRU) may detect a broadcast message, for example based on a relay access WTRU configuration parameter, announcing the service type of one or more relays that the remote WTRU may use (to meet network requirements, such as requirements of an application and / or service continuity).

[0107] The remote WTRU may select a WTRU-to-network relay based at least on a relay selection policy. The remote WTRU may select a WTRU-to-network relay, for example, based on the services provided by the WTRU-to-network relay. The remote WTRU may select a WTRU-to-network relay so as to minimize the number of PC5 links it may need to establish with multiple WTRU-to-network relays (e.g., with overlapping service offerings).

[0108] The remote WTRU may select one or more relays for similar service types for redundancy in the communication of the relays. The remote WTRU may select a WTRU-to-network relay that may be broadcasting a service available indication, and then try a different relay that may be broadcasting the same service as conditionally available.

[0109] A remote WTRU may select a WTRU-to-network relay that serves a WTRU without a high usage indication in the broadcast rather than a relay that broadcasts such an indication, or may not connect to a relay that broadcasts such an indication.

[0110] The WTRU to network relay may receive a slice configuration update. For example, the WTRU to network relay may receive a WTRU Configuration Update (UCU) message. The UCU message may contain slice information (e.g., new slice information). The slice information may be one or more of a configured NSSAI, an allowed NSSAI, a rejected S-NSSAI, etc. The WTRU to network relay may suspend its broadcast (advertising the types of services it can support) before completing the UCU procedure. The WTRU may complete the UCU procedure by updating its slice configuration based on the contents of the UCU message.

[0111] For one or more allowed S-NSSAIs that are not affected by the UCU procedure, the WTRU-to-network relay may resume broadcasting, announcing the types of services it supports. The WTRU-to-network relay may continue such services over any of the existing PC5 links established with one or more remote WTRUs that may be using the services.

[0112] The WTRU-to-network relay may register with the network to request S-NSSAI from an updated configured NSSAI that is not currently allowed and not required for the service type according to the relay configuration information. The WTRU-to-network relay may broadcast one or more broadcast messages over the PC5 interface announcing the service types that it can support and the associated S-NSSAI that is now allowed.

[0113] If the associated S-NSSAI in the relay configuration information is rejected by the network (e.g., the WTRU-to-network relay may receive an S-NSSAI from the network that includes a rejection of the associated S-NSSAI), the WTRU-to-network relay may perform a link modification procedure on the PC5 link with one or more remote WTRUs for the service type. The WTRU-to-network relay may provide the remote WTRU with the reason why the slice is unavailable. If the service is not allowed or adjusted on the PC5 link, the WTRU-to-network relay may release the link with the relay-access WTRU.

[0114] The WTRU-to-network relay may create a dedicated PDU session for a remote WTRU. The PDU session parameters (e.g., routing strategy) may include one or more of the following parameters: S-NSSAI, DNN, PDU session type, SSC mode, etc. In an example, the WTRU-to-network relay may request the PDU session parameters from the core network for each of the remote WTRUs associated with the WTRU-to-network relay. The WTRU-to-network relay may maintain a mapping between the remote WTRU and one or more PDU session parameters. For example, when the remote WTRU establishes a connection for communicating with the WTRU-to-network relay, the WTRU-to-network relay may retrieve the PDU session parameters for the remote WTRU. The WTRU-to-network relay may establish a PDU session for communication traffic relaying. If an existing PDU session meets the PDU session requirements of the remote WTRU, the WTRU-to-network relay may reuse the existing PDU session for relaying communication traffic instead of establishing a new session. For example, a first remote WTRU may be associated with a PDU session parameter for an S-NSSAI, and a second remote WTRU may have the same PDU session parameter. The communication traffic of the two WTRUs may be associated with the same PDU Session. For example, if the WTRU-to-network relay uses the same PDU Session for the two WTRUs, the WTRU-to-network relay may modify the PDU Session based on the QoS requirements received from the remote WTRU.

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

[0116] The WTRU to Network Relay may send a PDU Session Parameters Request to the Core Network. The PDU Session Parameters Request may include a Remote WTRU ID. The WTRU to Network Relay may receive and / or store PDU Session Parameters for one or more Remote WTRU IDs. For example, when establishing a PC5 connection with a remote WTRU, the WTRU to Network Relay may retrieve the PDU Session Parameters for the remote WTRU. The WTRU to Network Relay may verify whether an existing PDU Session may be reused for the remote WTRU. The WTRU to Network Relay may determine whether an existing PDU Session may satisfy the PDU Session Parameters requirements of the remote WTRU.

[0117] If no existing PDU Session is found that meets the requirements of the remote WTRU's PDU Session parameters, the WTRU-to-network relay may send a PDU Session Establishment Request to the network along with the PDU Session parameters for the remote WTRU. The WTRU-to-network relay may include the remote WTRU ID in the PDU Session Establishment Request. The AMF may perform SMF selection using the remote WTRU ID. If an existing PDU Session is found, the WTRU-to-network relay may associate the remote WTRU with the existing PDU Session.

[0118] Figure 6 An example of a PDU session established between a remote WTRU and a core network via a ProSe WTRU to network relay is shown. Figure 6 As shown, at 601, the WTRU to network relay sends a registration request message to a core network node (e.g., including an AMF). The registration request message may include a WTRU to network relay indication. At 602, the WTRU to network relay may receive a registration accept message from the core network (e.g., from an AMF in the core network). The registration accept message may include one or more PDU session parameters for one or more remote WTRUs associated with the WTRU to network relay. The WTRU to network relay may store mapping information between remote WTRUs and PDU session parameters, for example, a mapping between a remote WTRU ID and an NSSAI associated with a PDU session.

[0119] At 603, the remote WTRU may perform its discovery procedure to discover a WTRU-to-network relay. At 604, the remote WTRU and the discovered WTRU-to-network relay may establish a PC5 connection. If there are no known PDU session parameters associated with the remote WTRU for the WTRU-to-network relay (e.g., if the WTRU-to-network relay did not request the PDU session parameters during its registration with the core network), then at 605, the WTRU-to-network relay may send a routing policy request message to the core network (e.g., 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 the ProSe service type / service id.

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

[0121] At 607, the WTRU-to-network relay may search for an existing PDU session that may be reused for the remote WTRU, for example based on the remote WTRU's PDU session parameters and 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 remote WTRU's requirements, the WTRU-to-network relay may associate the existing PDU session with the remote WTRU and may not create a new PDU session.

[0122] At 608, the WTRU-to-network relay may send a PDU session establishment request message, for example, if no existing PDU session is found for the remote WTRU. The PDU session establishment request message may include PDU session parameters associated with the remote WTRU. At 609, the WTRU-to-network relay may receive a PDU session establishment response message from the core network (e.g., from the SMF of the core network).

[0123] At 610, the remote WTRU may obtain an IP address / prefix and the WTRU-to-network relay may begin relaying communication traffic between the remote WTRU and the core network.

[0124] For example, when the remote WTRU establishes a connection for communicating with the WTRU-to-network relay, the remote WTRU may provide one or more PDU session parameters to the WTRU-to-network relay. The WTRU-to-network relay may establish a PDU session for the remote WTRU based on the received PDU session parameters. The remote WTRU may provide the one or more PDU session parameters to the WTRU-to-network relay via a direct communication request message or other following messages (e.g., a dedicated message for parameter configuration, an IP address / prefix request message, etc.).

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

[0126] When (or after) a PC5 connection establishment is requested, the remote WTRU may send one or more PDU session parameters to the WTRU-to-network relay. Figure 7 An example of a remote WTRU establishing a PDU session with a core network node via a WTRU-to-network relay is shown. Figure 7 As shown, at 701, the WTRU to network relay may send a registration request message to the core network (e.g., the AMF of the core network). At 702, the WTRU to network relay may receive a registration acceptance message from the AMF in the core network. At 703, the remote WTRU may discover the WTRU to network relay. At 704, the remote WTRU may send a direct communication request message to the WTRU to network relay. The direct communication request message may include one or more PDU session parameters. For example, when a security association between the remote WTRU and the WTRU to network relay has been established, the remote WTRU may postpone the transmission of one or more of the PDU session parameters (e.g., S-NSSAI) that may be privacy-sensitive to a later step. For example, in Figure 7 In , the remote WTRU may transmit one or more PDU session parameters after 705 or 706. For example, in Figure 7, after 705 (mutual authentication), the WTRU to network relay may request one or more PDU session parameters by including an indication in a direct security mode (DSM) command message sent to the remote WTRU. The WTRU may reply with a DSM complete message with confidentiality and integrity protection including the PDU session parameters. At 705, mutual authentication between the remote WTRU and the WTRU to network relay may be performed. At 705, a security association between the remote WTRU and the WTRU to network relay may be established. At 705, the WTRU to network relay may send a direct communication accept (DCA) message to complete the PC5 unicast link establishment with the remote WTRU. At 706, the remote WTRU may provide one or more PDU session parameters to the WTRU to network relay, for example, using a parameter configuration message (or an IP address / prefix request message). The parameter configuration message may correspond to a protected DSM complete message as described above.

[0127] At 707, the WTRU-to-network relay may search for an existing PDU session that may be reused for the remote WTRU. The WTRU-to-network relay may perform the search based on the remote WTRU's requested PDU session parameters and parameters associated with the existing PDU session. If the WTRU-to-network relay determines that the existing PDU session matches the remote WTRU's requested PDU session parameters, the WTRU-to-network relay may associate the PDU session with the remote WTRU and may not create a new PDU session.

[0128] At 708, if the WTRU-to-network relay determines that none of the existing PDU sessions satisfies the requested PDU session parameters of the remote WTRU, the WTRU-to-network relay may send a PDU session establishment request to the core network. The PDU session establishment may include the PDU session parameters received from the remote WTRU. The WTRU-to-network relay may include the remote WTRU ID associated with the requesting WTRU in the PDU session establishment request. The core network (e.g., AMF) may use the remote WTRU ID to perform SMF selection.

[0129] The WTRU-to-network relay may receive a PDU session establishment response from the core network (eg, SMF) at 709. At 710, the remote WTRU may obtain an IP address / prefix and the WTRU-to-network relay may begin relaying communication traffic between the remote WTRU and the core network.

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

[0131] The WTRU to Network Relay Behavior receives the remote WTRU ID and / or the ProSe services requested by the remote WTRU during discovery or authorization and configuration or during PC5 connection establishment. The WTRU to Network Relay may send a PDU Session Request to the core network, which may include the remote WTRU ID and / or the ProSe services requested by the remote WTRU. The WTRU to Network Relay may receive a PDU Session Response message from the core network, which may include the accepted PDU Session parameters, such as S-NSSAI, DDN.

[0132] The AMF / SMF in the core network may receive a remote WTRU ID and / or ProSe service from the WTRU to the network relay. The AMF / SMF may receive the remote WTRU ID and / or ProSe service in a PDU session establishment request message. The AMF / SMF may retrieve one or more PDU session parameters associated with the remote WTRU or ProSe service, for example, by querying a policy control function (PCF). The AMF / SMF may send a PDU session establishment response to the WTRU to the network relay. The PDU session establishment response may include one or more accepted PDU session parameters.

[0133] For example, after the WTRU-to-network relay establishes a PDU session for a remote WTRU, for example based on a configuration, a WTRU routing policy (URSP) rule, and / or PDU session parameters received from the remote WTRU, the WTRU-to-network relay may provide the remote WTRU with the PDU session parameters of the established PDU session. The remote WTRU may store an association between the PDU session parameters and the PC5 connection. For each newly detected application, the remote WTRU may evaluate whether the PDU session parameters associated with the existing PC5 connection may meet the requirements of the application. Based on the evaluation, the remote WTRU may reuse the existing PC5 connection or establish a new PC5 connection. The remote WTRU may retrieve the requirements of the application, such as PDU session type, SSC mode, DNN, based on local URSP rules.

[0134] For example, when establishing or after establishing a PC5 connection with a remote WTRU, the WTRU-to-network relay may establish a PDU session for the PC5 connection. The WTRU-to-network relay may provide the remote WTRU with PDU session parameters associated with the PC5 connection, such as PDU session type, SSC mode.

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

[0136] WTRU-to-network relay discovery and selection (e.g., based on CAG ID) may be performed. The remote WTRU may perform WTRU-to-network relay discovery and selection based on: the relay broadcast service type associated with one or more CAG IDs (e.g., permitted CAG IDs) provided during configuration; and / or the CAG information broadcast from the relay and / or the CAG cell to which the relay is connected.

[0137] In an example, the remote WTRU may need to be a CAG-enabled WTRU with a configured list of permitted CAG IDs and / or only a CAG indication. The WTRU may perform an initial registration with the network as a WTRU supporting relay users. The WTRU may receive (e.g., during or after registration) relay access WTRU configuration parameters (such as a set of service types authorized to be used through the relay with an optional associated CAG ID (e.g., the CAG ID may be part of the CAG IDs permitted for the WTRU)) and / or a WTRU-to-network relay selection strategy. The required CAG ID may be sent by the application layer (e.g., an industrial application may require a specific private network to be connected to). The parameters may be pre-configured in the relay access WTRU (e.g., to enable the WTRU to perform discovery and / or selection of the relay WTRU before the first initial registration).

[0138] The relay access WTRU may detect broadcast messages from the relay via PC5. The broadcast messages may include: a WTRU to network relay capability indication, one or more service types supported by the relay, a WTRU to network relay allowed CAG IDs, supported CAG IDs (e.g., from a cell to which the relay is currently connected or camped), a WTRU to network relay CAG-only indication (e.g., specifying whether the relay is allowed to access the network via a CAG cell), and / or a CAG / non-CAG cell indication for the cell to which the relay is currently connected (e.g., indicating whether the cell is a CAG cell or a non-CAG cell).

[0139] The relay-access WTRU may select a WTRU-to-network relay based on a relay selection policy. The relay-access WTRU may select a WTRU-to-network relay that broadcasts one or more service types associated with one of the allowed CAG IDs of the relay-access WTRU (e.g., selection based on an implicit CAG ID). The relay-access WTRU may select a WTRU-to-network relay that has the most compatible CAG configuration (e.g., one or more common CAG IDs between the allowed CAG IDs of the relay-access WTRU and the WTRU-to-network relay, and / or the same CAG indication as the WTRU-to-network relay (e.g., the same CAG indication only) configuration).

[0140] In an example, for a non-CAG remote WTRU, the remote WTRU will not select the relay unless the relay is not connected / camped on a CAG cell (eg, based on a CAG / non-CAG cell indication).

[0141] The remote WTRU may select a relay using one or more of the following features (e.g., in the case where the broadcast message from the relay WTRU does not contain CAG-specific information). The remote WTRU may select the relay WTRU based on broadcast information (e.g., service type, general relay service code, and / or relay capability indication). The remote WTRU may continue to establish a PC5 link with the relay WTRU. The remote WTRU may receive a PC5 unicast security-protected message (e.g., DSMC) from the relay WTRU, including one or more of the following: allowed CAG IDs, CAG-only indication, CAG IDs supported by the current cell, and / or CAG cell / non-CAG cell indication. The remote WTRU may select a relay using a selection strategy as in the examples herein. The remote WTRU may send a PC5 unicast security-protected message to the relay WTRU, including its CAG ID configuration and / or a subset of selected CAG IDs that match the available CAG IDs from the relay WTRU, (e.g., when the remote WTRU determines that the CAG IDs supported by the relay WTRU are appropriate). The remote WTRU may continue the PC5 link establishment or maintain the current PC5 link with the relay WTRU (e.g., if a PC5 link has already been established). The remote WTRU may abort the PC5 link establishment and / or cut off the established PC5 link (e.g., if the relay WTRU does not provide a suitable / compatible CAG ID for the remote WTRU).

[0142] A WTRU to network relay may achieve its discovery by a remote WTRU accessing the network via a CAG cell. In an example, the remote WTRU may be a CAG-enabled WTRU with a configured list of allowed CAG IDs and / or CAG indication (e.g., CAG indication only). The relay access WTRU may select a CAG cell (e.g., which is part of the list of CAG IDs allowed by the relay access WTRU) and register with the network via the CAG cell. The WTRU may perform an initial registration with the network. In order to function as a WTRU to network relay, the relay access WTRU may receive (e.g., during or after registration) configuration parameters such as: a set of service types authorized to be used by the relay, where the configuration parameters may have an associated CAG ID (e.g., the CAG ID may be part of the CAG IDs allowed by the WTRU); and / or a relay operation policy. The relay WTRU may broadcast one or more messages via the PC5 interface, announcing the service type and / or CAG information. The relay WTRU may decide 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., supported CAG IDs broadcast by the CAG cell).

[0143] The WTRU to network relay may perform access control for a remote WTRU accessing the network via a CAG cell based on a configured service type associated with one or more CAG IDs (e.g., allowed CAG IDs). In an example, the WTRU to network relay may be discovered and selected by the remote WTRU (e.g., based on service type / CAG ID information). The WTRU may perform mutual authentication with the remote WTRU. PC5 layer keys (e.g., KD) may be established / derived using application layer keys. The WTRU may determine (e.g., based on successful per-application / service authentication) that the remote WTRU is authorized to access the CAG ID associated with the application / service type. The WTRU may complete the PC5 link establishment and may proceed with PDU session establishment / modification.

[0144] The WTRU to network relay may be a layer 2 (L2) relay. One or more of the following may apply. The relay WTRU may 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 may perform conventional CAG-based access control. The relay WTRU may detect a rejection message (e.g., registration rejection) from the AMF to the remote WTRU (e.g., when the remote WTRU is not allowed to access the current (CAG) cell serving the relay WTRU). The relay may disconnect the PC5 link with the remote WTRU upon detection of the rejection message.

[0145] The available CAGs may change (e.g. due to mobility of the WTRU to network relay). CAG-A and CAG-B may be available (e.g. when the WTRU to network relay is camped on cell A). A remote WTRU with CAG-A included in its allowed CAG IDs (e.g. instead of CAG-B) may establish a PC5 session (e.g. to access CAG-A via the WTRU to network relay). The remote WTRU may no longer be allowed to access the network through the WTRU to network relay / cell B (e.g. when the WTRU to network relay moves to cell B, which may be limited to supporting CAG-B).

[0146] The WTRU-to-network CAG configuration (e.g., allowed CAG IDs and / or CAG indications) may be updated by the network, for example, at any time (e.g., via the UCU). A configuration update (e.g., a WTRU-to-network CAG configuration update) may trigger the WTRU-to-network to reselect a new cell. A remote WTRU connection via the WTRU-to-network may be affected. The remote WTRU may need to reselect and reconnect to a WTRU-to-network relay or select a different WTRU-to-network relay after such a CAG configuration update (e.g., in the event that the first WTRU-to-network relay does not meet the remote WTRU's CAG-based access requirements).

[0147] The remote WTRU CAG configuration (e.g., allowed CAG IDs and / or CAG indications, e.g., only CAG indications) may be updated by the network, e.g., at any time (e.g., via the UCU). The remote WTRU CAG configuration update may 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., which supports the remote WTRU's newly allowed CAG ID).

[0148] The relay WTRU may notify the remote WTRU of the CAG change (e.g., sending updated available CAG information via PC5 broadcast and / or unicast messages). The relay WTRU may disconnect the PC5 link with the remote WTRU (e.g., while releasing the link, the relay may provide the remote WTRU with a cause code indicating that the CAG context has changed). The cause code may indicate: the available CAG ID has changed and / or the type of cell to which the relay WTRU is connected or camped has changed (e.g., from a CAG cell to a non-CAG cell or vice versa); no CAG ID is available; and / or the current CAG access (e.g., via the relay) is not authorized. If the relay WTRU needs to perform a new cell selection or if no suitable cell is found, it may need to disconnect the PC5 link (e.g., all PC5 links) with the remote WTRU.

[0149] The relay WTRU may notify the remote WTRU of the CAG change and cut off the PC5 link with the remote WTRU (for example, if the relay WTRU determines that the remote WTRU is affected and / or the remote WTRU does not support the new CAG ID). The relay WTRU may maintain the mapping of the searched CAG ID from the remote WTRU to the PC5 link (for example, exchanged during PC5 link establishment). The relay WTRU may maintain the PC5 link (for example, if the CAG ID searched by the remote WTRU, the allowed or selected CAG ID associated with the PC5 link is still available via the relay after the CAG change). The relay may cut off the PC5 link (for example, if the CAG ID searched by the remote WTRU, the allowed or selected CAG ID associated with the PC5 link is still not available via the relay after the CAG change). The relay WTRU may obtain the WTRU's CAG indication (for example, only the CAG indication) and cut off the PC5 link (for example, if it has moved to a non-CAG cell).

[0150] A relay-access WTRU may receive (eg, from a relay WTRU) updated broadcast or unicast CAG information via PC5. A relay-access WTRU may disconnect the PC5 link (eg, if the WTRU determines that access to the network via a relay and / or a new serving cell is not allowed).

[0151] The relay-access WTRU may receive a link release message with a cause code indicating that the specified 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 allowed to select a new CAG ID), or the relay-access WTRU may select another more suitable / compatible relay.

[0152] Figure 8 WTRU to network relay discovery, selection and communication via layer 2 WTRU to network relay are shown. Figure 8 As shown, at 800, a remote WTRU (WTRU1) may be configured (e.g., pre-configured and / or after initial registration with the network) with the necessary parameters to be able to discover / select and connect via a WTRU-to-network relay. The WTRU-to-network relay may be configured to provide L2 relay services. The WTRU-to-network relay WTRU may be camped on a CAG cell.

[0153] At 801, the WTRU to network relay WTRU may send a PC5 broadcast message (e.g., including relay service related information, such as application ID, relay service code, relay capability indication, current cell CAG information, cell supported CAG ID and / or allowed CAG ID, CAG only indication, and other relay CAG information).

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

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

[0156] At 807, the remote WTRU may send a DSMC complete message to the WTRU-to-network relay WTRU (e.g., including the remote WTRU's CAG information with integrity and confidentiality protection, such as an allowed CAG ID and / or CAG indication). At 808, the WTRU-to-network relay WTRU may store a mapping of the remote WTRU's CAG information with the PC5 link. At 809, the WTRU-to-network relay WTRU may trigger a service request procedure (e.g., if it is in a CM_IDLE state). At 810, the WTRU-to-network relay WTRU may send a PC5 unicast response message, for example, to complete the PC5 link establishment.

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

[0158] The ProSe L2 relay may subscribe to paging notifications from the 5G-RAN (e.g., when the ProSe L2 relay is in a CM connected state). 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 time (PO) of the remote WTRU). After receiving the paging message of the remote WTRU from the core network, the 5G-RAN may send the paging message of the remote WTRU to the ProSe L2 relay (e.g., based on the ID and / or PO of the remote WTRU to which the ProSe L2 relay subscribes).

[0159] The ProSe L2 relay may establish a PC5 connection with the remote WTRU and receive the remote WTRU's paging parameters from the remote WTRU. The remote WTRU may send the paging parameters during or after the PC5 connection establishment. The remote WTRU may send updated paging parameters to the ProSe L2 relay (e.g., once the paging parameters change, such as in the case where the remote WTRU paging identity and / or PO changes).

[0160] The ProSe L2 relay may send a paging subscription request (e.g., including the ProSe L2 relay ID, the remote WTRU's ID, and / or the remote WTRU's PO) to the 5G-RAN (e.g., when the ProSe L2 relay is in a CM connected state). The remote WTRU's ID or PO may be retrieved from the paging parameters.

[0161] The ProSe L2 relay may suspend paging subscription requests (e.g., when the ProSe L2 relay is in an idle state). The ProSe L2 relay may send (e.g., when the ProSe L2 relay enters a CM connected state) a paging subscription request (e.g., for a remote WTRU to be subscribed, such as a remote WTRU having a PC5 connection with the relay WTRU). The ProSe L2 relay may send a request to the 5g-RAN to unsubscribe from paging notifications (e.g., when the PC5 connection with the remote WTRU is released). The ProSe L2 relay may receive a paging message for the remote WTRU from the 5G-RAN (e.g., via a PC5 interface) and forward the paging message to the remote WTRU.

[0162] The 5G-RAN may receive a paging subscription request from a ProSe L2 relay (e.g., including a ProSe L2 relay ID, an ID of a remote WTRU, and / or a PO of a remote WTRU). The 5G-RAN may receive a paging message from an AMF. The 5G-RAN may forward the paging message to the relevant ProSe L2 relay (e.g., if 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 may receive a paging message from an AMF. The 5G-RAN may forward the paging message to the relevant ProSe L2 relay (e.g., if the PO for the paging message matches the PO received in the paging subscription request).

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

[0164] The remote WTRU may initiate a stop monitoring procedure. In an example, a PC5-S stop monitoring request or a similar PC5 message may be sent to a relay WTRU. The stop monitoring request message may include, for example, an indication that 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 may be configured to include information that the relay WTRU should stop transmitting. For example, the remote WTRU may indicate to the relay WTRU to stop transmitting (e.g., only stop transmitting) the remote WTRU paging message. Other information (e.g., SIB and cell id) excluded from the stop monitoring request message may (e.g., implicitly) indicate that other information may still be needed and that it may (e.g., continue to be) relayed by the relay WTRU. The stop monitoring request message may be integrity protected, replay protected, and / or confidentiality protected, for example, to prevent malicious requests from being sent to the relay WTRU, such as requests intended to cause a loss of service to the remote WTRU (e.g., a denial of service (DoS) attack).

[0165] For example, when the relay WTRU receives the message, the relay WTRU may stop relaying the information indicated in the message (e.g., explicitly and / or implicitly). For example, if the remote WTRU included a paging message in the stop monitoring request, the relay WTRU may (e.g., also) stop reading the Uu paging channel with the remote WTRU's ID and the remote WTRU's paging time (PO). The relay WTRU may send a response or confirmation message back to the remote WTRU (e.g., to confirm receipt of the request).

[0166] For example, if the remote WTRU decides to rely on broadcast information (e.g., paging messages, SIBs, cell ids, MBMS, etc.) from the relay WTRU, the remote WTRU may (e.g., at any time) initiate a normal "information monitoring request" procedure. For example, the remote WTRU may send an information monitoring request message to the relay WTRU. The relay WTRU may start (e.g., resume) monitoring the requested information, may start reading the Uu paging channel and / or may reply to the remote WTRU (e.g., with an information monitoring response message).

[0167] A secure link may be established between a remote WTRU and a WTRU-to-network relay (which may be referred to herein as a "relay"). For example, the security of a PC5 link between a remote WTRU and a WTRU-to-network relay may be established (e.g., bootstrapped) by utilizing a primary authentication run of the remote WTRU with the network. For example, the remote WTRU may send a request message (e.g., a direct communication request) to the relay to establish the PC5 link. The message may include a remote WTRU identity (e.g., a subscription hidden identity (SUCI)). The remote WTRU may perform a primary authentication process using the relay's AMF and the remote WTRU's primary AUSF via the PC5 link with the relay. The remote WTRU may (e.g., after the remote WTRU successfully authenticates the network) derive and store a PC5 root key and ID (e.g., Krelay and Krelay ID) based on a master key (e.g., KAMF) derived from the primary authentication run. The remote WTRU may receive a request message (e.g., a direct security mode command) from the relay via PC5. The remote WTRU may check that the request message includes a Krelay ID that matches a Krelay ID previously derived from the primary authentication. The remote WTRU may continue the security establishment procedure by deriving a session key (e.g., Krelay-sess) from Krelay and deriving ciphering and integrity keys from the session key and sending a protected PC5 response message (e.g., Direct Security Mode Complete). The remote WTRU may receive a response message (e.g., Direct Communication Accepted) indicating successful establishment of the PC5 link.

[0168] For example, a WTRU-to-network relay may receive a request message (e.g., DCR) from a remote WTRU to establish a PC5 link. The request message from the remote WTRU may include a remote WTRU identity (e.g., SUCI). The relay may send a request message to its serving AMF to authorize the remote WTRU. The request message from the relay may include a remote WTRU identity (e.g., SUCI). The relay may forward authentication messages back and forth between the remote WTRU and the relay's serving AMF. The relay may receive a response message from its serving AMF including a PC5 root key and ID (e.g., Krelay and Krelay ID) indicating successful authentication and authorization of the remote WTRU. The response message may include a core network remote WTRU identity (e.g., Globally Unique Temporary Identity (GUTI), General Public Subscription Identity (GPSI)). The relay may store the root key, key id, and core network remote WTRU identity (e.g., associating them with the PC5 link context). The relay may use the Krelay received from the AMF to derive session keys and encryption and integrity keys. The relay may send a PC5 request message (e.g., Direct Security Mode Command) to the remote WTRU, including the Krelay ID received from the relay's serving AMF. The integrity of the message is protected using the integrity key described above. The relay may receive a PC5 response message (e.g., Direct Security Mode Complete) from the remote WTRU. The relay may check the security protections (e.g., confidentiality and / or integrity) of the message. Upon successful establishment of a secure PC5 link, the relay may proceed with connection signaling with the network (e.g., by establishing a new PDU session or reusing an existing PDU session), as described herein. The relay may send a response message (e.g., DCA) to the remote WTRU, indicating the successful establishment of the PC5 link.

[0169] For example, a serving AMF of a WTRU to a network relay may receive a request message from the relay to authorize a remote WTRU. The message may include a remote WTRU identity (e.g., SUCI). The AMF may trigger a remote WTRU authentication procedure with a primary AUSF of the remote WTRU. The AMF may perform a primary authentication procedure for the remote WTRU via the relay. The AMF may receive a response message from the AUSF of the remote WTRU including an identity of the remote WTRU (e.g., User Permanent Identity (SUPI)) and an anchor key (e.g., KAUSF / KSEAF), indicating successful authentication and authorization of the remote WTRU. The AMF may derive a PC5 root key and ID (e.g., Krelay and Krelay ID) based on a master key (e.g., KAMF) derived from the anchor key. The AMF may store the received remote WTRU identity (e.g., SUPI) as part of the WTRU context of the relay. The AMF may allocate and store a core network remote WTRU identity (e.g., GUTI, GPSI) as part of the WTRU context of the relay. The AMF may register the AMF as a relay serving the remote WTRU with the UDM of the remote WTRU by providing the AMF identity and / or the identity of the relay (e.g., SUPI or GPSI). The AMF may send a response message to the relay including the PC5 root key and ID (e.g., Krelay and Krelay ID). The AMF response message may include the core network remote WTRU identity (e.g., GPSI).

[0170] For example, re-authentication / authorization of a remote WTRU to use a WTRU to network relay may be performed at the AMF serving the relay, the relay, and the remote WTRU. For example, after successfully authorizing the remote WTRU to use the relay, the serving AMF may initiate re-authentication / authorization of the remote WTRU at any time. In an exemplary scenario, the scope of authorization may be limited in time or location. During the mobility of the relay, the AMF serving the relay may change, and the new AMF may obtain the WTRU context of the relay from the old AMF, which WTRU context includes remote WTRU information as described herein (e.g., new Krelay and Krelay ID and identity). The new AMF may update the serving AMF registration information using the UDM of the remote WTRU. The new AMF may initiate re-authentication / authorization of the remote WTRU in the process as described herein. When performing such re-authentication / authorization, the remote WTRU may generate a new PC5 root key / key id, and the relay may obtain a new Krelay and Krelay ID from the new serving AMF as described herein. The relay may perform a key update procedure using the new PC5 root key / key id via the PC5 link with the remote WTRU. The remote WTRU may initiate the key update procedure by including the new Krelay ID in a direct key update request message to the relay. The relay may check that the received Krelay ID matches the new Krelay ID derived after the remote WTRU re-authentication procedure. Upon a successful match check, the relay may trigger a direct security command procedure to establish a new session and integrity and confidentiality key using Krelay as the PC5 link root key. The roles of the relay and the remote WTRU may be reversed when performing the above-described key update procedure. For example, the relay may initiate the key update procedure.

[0171] For example, revoking authorization for a remote WTRU to use a WTRU-to-network relay may be performed at the AMF, the relay, and the remote WTRU serving the relay. For example, the AMF may receive a request message from the UDM of the remote WTRU, including an indication of revoking authorization for the remote WTRU to use the relay (e.g., due to a remote WTRU subscription change) and an identity of the relay serving the remote WTRU. The AMF may send a request message to the relay serving the remote WTRU, including an indication of revoking authorization for the remote WTRU to use the relay, a Krelay id associated with the remote WTRU, and / or a core network remote WTRU identity (e.g., GPSI). The relay may locate the PC5 link context based on the received Krelay id and / or the core network remote WTRU identity, and initiate a link release procedure for the associated PC5 link with the remote WTRU. The relay may delete the PC5 link context with the associated Krelay and remote WTRU information. The relay may initiate a WTRU-triggered PDU session release procedure (e.g., when a dedicated PDU session is for a remote WTRU). The relay may send a response message to the AMF indicating the successful release of the remote WTRU connection. The AMF may send a response message to the UDM of the remote WTRU indicating the successful authorization revocation. The AMF may send a request to revoke the remote WTRU authorization as above but based on the serving network policy (e.g., for overload control purposes).

[0172] After reconnection between the remote WTRU and the WTRU-to-network relay, a secure link may be established between the two. For example, the WTRU-to-network relay may receive a request message (e.g., DCR) from the remote WTRU to establish a PC5 link. The request message may include a Krelay ID. The relay may 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 may use Krelay to continue to establish a secure PC5 link as described herein. Upon successful establishment of the secure PC5 link, the relay may continue with connection signaling with the network and complete the PC5 link establishment as described herein.

[0173] Fig. 9 An exemplary message sequence for WTRU-to-network relay discovery and selection is shown. The WTRU-to-network relay may be or may include a Figures 1A to 1D The WTRU 102 described above. Fig. 9As shown, at 901, the relay may send a network registration request to the core network (e.g., the AMF of the core network) (e.g., in a registration request message). The network registration request may include an indication that the relay is capable of becoming a WTRU-to-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 authorized relay configuration parameters for the WTRU-to-network relay and may send the authorized relay configuration parameters in response to the network registration request. At 902, in response, the relay may receive (e.g., in a registration accept message) one or more relay service types and associated communication parameters as part of the relay configuration parameters authorized 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.

[0174] At 903, the relay access WTRU (eg, the remote WTRU) may send a network registration request (eg, in a registration request message) to the core network (eg, the AMF of the core network). The relay access WTRU may be or may include a method as described herein with respect to Figures 1A to 1D The WTRU 102 may include an indication that the relay access WTRU is capable of supporting relay access (e.g., access relay WTRU). The AMF may perform access and mobility (AM) policy association establishment with the PCF in the core network. The AMF / PCF may determine an authorized relay access WTRU configuration parameter for the relay access WTRU and may send the authorized relay access WTRU configuration parameter in response to the network registration request.

[0175] In response, the relay-access WTRU may receive (e.g., in a registration accept message) one or more relay service types and associated communication parameters as part of the relay-access WTRU configuration parameters authorized by the core network (e.g., the AMF / PCF of the core network) at 904. The associated communication parameters may include PDU session parameters such as S-NSSAI, DNN, and / or SSC mode.

[0176] At 905, the WTRU-to-network relay may broadcast a relay service type (e.g., a relay service type identified from one or more authorized relay service types received at 902). The WTRU-to-network relay may identify the relay service type for broadcast, for example, based on communication parameters associated with the one or more authorized relay service types and granted network resources associated with the WTRU-to-network relay. For example, the relay service type may be identified for broadcast under the condition 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-to-network relay may be or may include allowed network slice selection assistance information (NSSAI). The allowed NSSAI may be received, for example, from the core network (e.g., the AMF of the core network) in a registration accept message. The relay service type may be identified for broadcast under the condition that the allowed NSSAI received from the core network includes the S-NSSAI associated with the relay service type.

[0177] The WTRU-to-network relay may receive (e.g., in a REGISTRATION ACCEPT message) one or more rejected network resources, such as a rejected S-NSSAI. The WTRU-to-network relay may not broadcast the authorized relay service type, provided that the authorized relay service type is associated with a communication parameter (e.g., S-NSSAI) included in the one or more rejected network resources (e.g., rejected S-NSSAI).

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

[0179] The relay access WTRU may identify a target relay service type based on network requirements and communication parameters associated with the authorized relay service type that the relay access WTRU is authorized to use. For example, the authorized relay service type may be identified as the target relay service type, provided that the associated communication parameters meet the network requirements. The network requirements may be requirements of the application, such as an S-NSSAI based on the local URSP of the relay access WTRU. The network requirements may be requirements for service continuity, such as a specific SSC mode. If the S-NSSAI associated with the authorized relay service type matches the S-NSSAI required by the application, the authorized relay service type received from the core network may be identified as the target relay service type.

[0180] The relay access WTRU may also determine the selection of a WTRU to a network relay based on a WTRU to network relay selection policy received from the core network (e.g., in a registration accept message). The relay selection policy may prefer a WTRU to network relay that provides the greatest number of relay service types in order to minimize the number of PC5 links that need to be established. The relay selection policy may prefer to have redundancy in the communications of the relays for similar relay service types. The relay selection policy may prefer a WTRU to network relay that broadcasts an indication that a relay service type is available, and not prefer another WTRU to network relay that broadcasts an indication that the same relay service type is conditionally available. The relay selection policy may prefer a WTRU to network relay that does not broadcast an indication of high usage. The relay selection policy may not select a WTRU to network relay that broadcasts an indication of high usage.

[0181] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in 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 may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A first wireless transmit / receive unit (WTRU), include: A processor and a transceiver, wherein the processor and the transceiver are configured to: authenticating the first WTRU with a network via a second WTRU, determining a PC5 root key based on a master key obtained from the identity authentication of the first WTRU, receiving, from the second WTRU, a first PC5 message protected based on the PC5 root key, wherein the first PC5 message is a Direct Security Mode Command message, determining, based on the PC5 root key, at least one of: (i) an encryption key and (ii) an integrity key, and A second PC5 message is sent to the second WTRU, wherein the second PC5 message is a direct security mode complete message protected using at least one of the cipher key and the integrity key.

2. The first WTRU of claim 1, in, Any of the following: (1) the master key is derived from the identity authentication of the WTRU, (2) the PC5 root key is derived based on the master key, and / or (3) the encryption key and the integrity key are derived based on the PC5 root key.

3. The first WTRU of claim 1 , in, The processor is further configured to: determining an identity (ID) of the PC5 root key based on the master key obtained from the identity authentication of the first WTRU, Wherein said determination of said one or more third keys is based on said PC5 root key and said ID of said PC5 root key.

4. The first WTRU of claim 1 , in, The processor and the transceiver are configured to: Prior to the authentication of the first WTRU with the network, a direct communication request message is sent to the second WTRU to establish a PC5 link with the second WTRU.

5. The first WTRU of claim 4, in, The processor and the transceiver are configured to: After sending the direct security mode complete message, a direct communication accept message is received from the second WTRU indicating establishment of the PC5 link with the second WTRU.

6. The first WTRU of claim 5, in, The processor and the transceiver are configured to: After receiving the direct communication accept message, one or more transmissions are sent to the network via the second WTRU using the PC5 link.

7. The first WTRU of claim 5, in, The processor and the transceiver are configured to: After receiving the direct communication accept message, one or more transmissions are sent to the network via the second WTRU using the PC5 link.

8. A first wireless transmit / receive unit (WTRU), comprising: A processor and a transceiver, wherein the processor and the transceiver are configured to: performing a registration with a network, wherein the first WTRU indicates a capability of the first WTRU to act as a WTRU-to-network relay, receiving one or more WTRU-to-network relay configuration parameters from the network, wherein the one or more WTRU-to-network relay configuration parameters include any service type from a set of service types authorized to be relayed by the first WTRU and one or more communication parameters associated with each service type, A message is broadcast via a PC5 interface including information indicating a service type supported by the first WTRU, wherein the communication parameters associated with the indicated service type correspond to allowed network slice selection assistance information (NSSAI) of the WTRU to a network relay.

9. The first WTRU of claim 8, in, The registration is an initial registration.

10. The first WTRU of claim 8, in, The one or more WTRU-to-network relay configuration parameters include a first service type and a second service type authorized to be relayed by the first WTRU.

11. The first WTRU of claim 10, in, The one or more communication parameters associated with the first service type include any one of a first single network slice selection assistance information (S-NSSAI), a first data network name (DNN), and a first session and service continuity (SSC) mode.

12. The first WTRU of claim 11, in, The message includes information indicating that the first service type is supported by the first WTRU as a WTRU-to-network relay, and the first S-NSSAI is included in the allowed NSSAI.

13. The first WTRU of claim 10, in, The one or more communication parameters associated with the second service type include any one of a second single network slice selection assistance information (S-NSSAI), a second data network name (DNN), and a second session and service continuity (SSC) mode.

14. The first WTRU of claim 10, in, The registration is an initial registration with the network, and the one or more WTRU-to-network relay configuration parameters are received during the initial registration.

15. The first WTRU of claim 14, in, Information indicating the allowed NSSAIs for the WTRU to relay to a network is received during the initial registration.

16. The first WTRU of claim 10, in, The one or more WTRU-to-network relay configuration parameters are received subsequent to registration with the network.

17. The first WTRU of claim 16, in, The information indicating the allowed NSSAIs for the WTRU to relay to the network is received during initial registration.

Images