CN114747290A - WTRU to network relay - Google Patents

Abstract

Systems and methods for enabling discovery and selection of a WTRU-to-network relay by a remote WTRU and handling WTRU-to-network relay configuration updates are described herein. 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 the 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 a WTRU-to-network relay. The WTRU-to-network relay may reuse an existing PDU session for relaying communication traffic or send a PDU session setup request to the network 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

WTRU to network relay

Cross Reference to Related Applications

The present application claims the benefit of: U.S. provisional application No. 62/932,219 filed on 7/11/2019; U.S. provisional application No. 62/957,530, filed on 6/1/2020; U.S. provisional application No. 62/975,956 filed on 13/2/2020; and U.S. provisional application No. 63/086,436, filed on 1/10/2020, the contents of which are incorporated herein by reference.

Background

A wireless transmit/receive unit (WTRU) -to-network relay may establish a Protocol Data Unit (PDU) session for relaying communication traffic between a remote WTRU and a core network based on a default configuration (e.g., a default Data Network Name (DNN)). Various signaling mechanisms and resource usage on remote WTRUs and WTRU-to-network relays in such communication networks may be inefficient or inefficient.

Disclosure of Invention

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 capability. An indication of one or more authorized relay service types and communication parameters associated with the authorized relay service types may be received in response to the network registration request. Based on the communication parameters and 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 the broadcast. For example, a licensed relay service type may be identified for broadcast on a condition that communication parameters associated with the relay service type are supported by 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), Data Network Name (DNN), and/or Session and Service Continuity (SSC) patterns. The identified relay service type may be broadcast.

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 capability. An indication of one or more authorized relay service types and communication parameters associated with the authorized relay service types may be received in response to the network registration request. A target relay service type 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. The relay access WTRU may be configured to receive a broadcast message that may include one or more relay service types provided by the WTRU-to-network relay. Whether to select a WTRU-to-network relay may be determined based on a relay service type provided by the WTRU-to-network relay and an identified target service type.

The type of relay service 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 on a condition that network resources associated with the relay access WTRU require support by communication parameters associated with the authorized relay service type. The WTRU-to-network relay may be selected on the condition that the type of relay service broadcast by the WTRU to the network includes a 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 patterns. The network resource requirements associated with the relay access WTRU may be or may include S-NSSAI, DNN, and/or SSC patterns.

Systems and methods for enabling discovery and selection of a WTRU-to-network relay by a remote WTRU and handling WTRU-to-network relay configuration updates are described herein. The WTRU-to-network relay may perform initial registration with the core network. 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 broadcast a service type indicating that the service type is conditionally available. When the configured service type becomes part of a list of allowed service types, the WTRU-to-network relay may update its broadcast information conditionally available regarding the service type to be available.

Systems and methods for relaying communication traffic between one or more remote WTRUs (e.g., remote WTRUs having different service requirements) and a core network node via a WTRU-to-network relay are described herein. 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 relaying. The WTRU-to-network relay may reuse an existing PDU session for relaying communication traffic if session parameters associated with the existing PDU session match the PDU session requirements of the remote WTRU. The WTRU-to-network relay may provide PDU session parameters associated with the PC5 connection to the remote WTRU during PC5 connection establishment. The WTRU-to-network relay may send a PDU session setup request to the network with the requested PDU session parameters if no existing PDU session matches the requested session parameters of the remote WTRU. The WTRU-to-network relay may receive a PDU session setup response from the core network. The WTRU-to-network relay may then begin relaying communication traffic between the remote WTRU and the core network.

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

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

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

The ProSe L2 relay may subscribe to paging messages for remote WTRUs, e.g., if the ProSe L2 relay is in a connected state.

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

The remote WTRU and the WTRU-to-network relay may establish a secure PC5 link using credentials derived from a primary authentication run of the remote WTRU performed via the WTRU-to-network relay.

Drawings

Fig. 1A is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments may be implemented.

Figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A, according to one embodiment.

Fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to one embodiment.

Figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A, according to one embodiment.

Fig. 2 is a diagram illustrating an exemplary reference model for proximity-based services.

Fig. 3 is a diagram showing a ProSe architecture using WTRU-to-network relay.

Figure 4 is an exemplary message sequence chart illustrating establishing communication traffic between a remote WTRU and a core network node (e.g., Session Management Function (SMF)/User Plane Function (UPF)).

Fig. 5 illustrates an exemplary control plane protocol stack.

Figure 6 is an exemplary message sequence chart illustrating establishing communication traffic between a remote WTRU and a core network node (e.g., SMF/UPF).

Figure 7 is an exemplary message sequence chart illustrating establishing communication traffic between a remote WTRU and a core network node (e.g., SMF/UPF).

Figure 8 shows a process for WTRU-to-network relay discovery, selection and communication via a layer 2 WTRU-to-network relay.

Fig. 9 is an exemplary message sequence chart illustrating WTRU-network relay discovery and selection by a relay accessing WTRU.

Detailed Description

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, 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-tailed unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and so forth.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. 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 a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, 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., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain environments), consumer electronics devices and applications, Devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, gnbs, NR node bs, site controllers, Access Points (APs), wireless routers, and so forth. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of a RAN 104/113, which may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

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, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as indicated above, 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, and the like. 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).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a New Radio (NR) to establish the air interface 116.

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 together implement LTE radio access and NR radio access, e.g., using Dual Connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

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, CDMA 20001X, CDMA2000 EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by a drone), road, and so forth. 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-A, LTE-a Pro, NR, etc.) to establish the pico cell or the femto cell. As shown in fig. 1A, the base station 114b may have a direct connection to the internet 110. Thus, base station 114b may not need to access internet 110 via CN 106/115.

The RAN 104/113 may communicate with a CN 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. 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, and so forth. 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 shown in fig. 1A, it should be understood that RAN 104/113 and/or CN 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 104/113 or a different RAT. For example, in addition to connecting to the RAN 104/113, which may utilize NR radio technology, the CN 106/115 may communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

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), User Datagram Protocol (UDP), and/or the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

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 over different wireless links). For example, the WTRU102 c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU102 may include 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, among others. It should be understood that the WTRU102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a) over 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 optical signals. It should be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

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

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, 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 WTRU102, such as on a server or home computer (not shown).

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, 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, and the like.

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

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 peripheral devices 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 microphone, and/or the like,

Module, Frequency Modulation (FM) radio unitDigital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and so forth. 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, and a time sensor; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.

The WTRU102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. A full-duplex radio may include an interference management unit to reduce and/or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous.

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

RAN 104 may include enodebs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enodebs while remaining consistent with an embodiment. The enodebs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU102a and/or receive wireless signals from the WTRU102 a.

Each of the enodebs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in fig. 1C, enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C 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 are depicted as part of CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

MME 162 may be connected to each of enodebs 162a, 162B, 162c in 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 initial attachment of the WTRUs 102a, 102b, 102c, and the like. 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.

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

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

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN 106 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 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

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

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

A WLAN in an 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 interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STAs and directed to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within a BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP and the AP may pass the traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Direct Link Setup (DLS) may be utilized to transmit point-to-point traffic between (e.g., directly between) a source and destination STA. In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (tdls). A WLAN using Independent Bss (IBSS) mode may not have an AP, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using an 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a20 MHz wide bandwidth) or a width that is 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 with collision avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. For CSMA/CA, an STA (e.g., each STA), including an AP, may listen to the primary channel. A particular STA may back off if the primary channel is sensed/detected and/or determined to be busy by the particular STA. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using a 40 MHz-wide channel, e.g., via a combination of a primary 20MHz channel and an adjacent or non-adjacent 20MHz channel to form a 40 MHz-wide channel.

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

802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/machine type communication, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) 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).

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 STAs from all STAs operating in the BSS (which support the minimum bandwidth operating mode). In the 802.11ah example, for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because STAs (supporting only 1MHz mode of operation) are transmitting to the AP, the entire available band may be considered busy even though most of the band remains idle and may be available.

In the united states, the available frequency band for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

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

RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that 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 to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 108b may utilize beamforming to transmit signals to the gnbs 180a, 180b, 180c and/or receive signals from the gnbs 180a, 180b, 180 c. Thus, the gNB180a may use multiple antennas to transmit wireless signals to the WTRU102a and/or receive wireless signals from the WTRU102a, for example. In one embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers to the WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive cooperative transmissions from gNB180a and gNB180 b (and/or gNB180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the set of scalable parameters. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of various or extendable lengths (e.g., including different numbers of OFDM symbols and/or varying absolute lengths of time).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not visiting other RANs (e.g., such as the enodebs 160a, 160B, 160 c). 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 frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c while also communicating or connecting with other RANs, such as the enodebs 160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may implement the DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enodebs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for the serving WTRUs 102a, 102B, 102 c.

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 User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

The CN 115 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185 b. While each of the foregoing elements are depicted as being 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 the CN operator.

The AMFs 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via an N2 interface in the RAN 113 and may serve as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, and so forth. The AMFs 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. The AMF 162 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi).

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

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

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. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the 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 connect to the UPFs 184a, 184b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the local Data Networks (DNs) 185a, 185 b.

In view of the corresponding descriptions of fig. 1A-1D and 1A-1D, 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 emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enodebs 160a-c, MME 162, SGW 164, PGW 166, gNB180 a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DNs 185a-B, and/or any other device described herein. The emulation device can be one or more devices configured to emulate one or more or all of the functionalities described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.

The simulated 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 simulated devices may perform one or more or all of the 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 emulation devices can perform one or more functions or all functions while 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 perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario in a test laboratory and/or 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 (which may include one or more antennas, for example) may be used by the emulation device to transmit and/or receive data.

Proximity services (ProSe) in a wireless communication system may enable direct communication between two WTRUs in proximity to each other. As used herein, the term ProSe may be used to refer to direct WTRU-to-WTRU transmissions, whether or not network scheduler based cooperation is used. Fig. 2 illustrates an exemplary reference model for proximity-based services. As shown in fig. 2, 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 ProSe direct discovery services and ProSe direct communication services. The direct discovery name management function may be used for open ProSe direct discovery, for example, to allocate and process a mapping of ProSe application IDs and ProSe application codes used in ProSe direct discovery.

As shown in fig. 2, proximate ProSe-enabled WTRUs (e.g., WTRU a and WTRU B) may support the exchange of ProSe control information between each of the WTRUs and the ProSe function via an interface (e.g., a PC3 interface). The ProSe-enabled WTRU may also support procedures for open and restricted ProSe direct discovery of other ProSe-enabled WTRUs over a radio interface (e.g., a PC5 interface).

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.

Fig. 3 shows an exemplary ProSe architecture using WTRU-to-network relay. A ProSe WTRU-to-network relay in the network may connect one or more remote WTRUs to the core network. As shown in fig. 3, a remote WTRU that is outside of NR network coverage and cannot connect directly to the core network may use its PC5 interface to relay communications with the WTRU to the network to connect to the core network. The remote WTRU as shown in figure 3 may discover and select a WTRU to network relay. The WTRU-to-network relay may establish a PDU session (or 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 a WTRU-to-network relay, for example, as shown in fig. 4.

Figure 4 is an exemplary message sequence diagram illustrating establishment of a session between a remote WTRU and a core network node (e.g., Session Management Function (SMF)/User Plane Function (UPF)). As shown in fig. 4, at 401, a WTRU-to-network relay may send a registration request to an access and mobility management function in a core network. At 402, the WTRU-to-network relay may receive a registration accept message. At 403, the remote WTRU may perform a discovery procedure. At 404, the remote WTRU may establish a connection with the WTRU to a network relay. At 405, the WTRU-to-network relay may send a PDU session setup 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 communication traffic between the remote WTRU and the core network may be relayed via WTRU-to-network relay.

The 5G system may use a public network integrated non-public network (PNI-NPN) based on selection and access control of Control Access Group (CAG) cells. A CAG-enabled WTRU (e.g., configured with an appropriate CAG ID) may be granted access to the network (e.g., via a CAG cell). A CAG-enabled WTRU may select a CAG cell that broadcasts supported CAG IDs, e.g., that match at least one of the WTRU's allowed CAG IDs (e.g., configured in the WTRU and/or included in a subscription). The WTRU may be granted access to the network via the CAG cell (e.g., through the AMF) (e.g., on a condition that 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). Without such an indication, the WTRU may access both CAG cells and non-CAG cells (e.g., common cells).

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

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 the paging message (e.g., for a remote WTRU) and forward the paging message to the remote WTRU (e.g., on the condition that the remote WTRU maintains a PC5 session). The 5G-RAN may send an RRC paging message (e.g., when ProSe L2 is eventually in idle mode). The 5G-RAN may send RRC paging messages of the remote WTRU to the ProSe L2 relay via ProSe L2 relayed SRBs and/or DRBs (e.g., when ProSe L2 relay is in connected mode).

The remote WTRU may be authorized to access the network via the relay by performing a primary authentication operation via the WTRU-to-network relay and using the relay's AMF and an authentication function (AUSF) of the remote WTRU. The remote WTRU may complete the PC5 link setup with the relay to perform communication via the relay (e.g., after primary authentication and authorization).

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 relaying 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 a WTRU-to-network relay may support. For example, the 4G WTRU-to-network relay may not support the slicing requirements of one or more remote WTRUs because of existing limits of 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. Thus, in terms of the type of services that a WTRU-to-network relay may provide to a remote WTRU simultaneously, the relay may be limited in slicing (S-NSSAI) or other PDU session parameters (e.g., PDU session type, Session and Service Continuity (SSC) mode, etc.). For example, the WTRU-network relay may be configured with a configured NSSAI, which may not include an S-NSSAI that the remote WTRU may use. A remote WTRU may initiate (selectively initiate) a WTRU-to-network relay with a request that may support communication services, rather than a WTRU-to-relay communication that may not support such a request, for example, to avoid unnecessary signaling and resource usage on both the remote WTRU and the WTRU-to-network relay node.

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

WTRU-to-network relay may be discovered and selected based on the slice information and/or CAG ID. The WTRU-to-network relay (e.g., 4G WTRU-to-network relay) may establish a PDU session for communication traffic relay based on a default configuration (e.g., 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 patterns. However, one or more remote WTRUs may have different requirements for their relayed communication traffic. For example, some remote WTRUs may require service continuity, while other remote WTRUs may require a particular network slice (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 different requirements associated with the remote WTRU. This may result in service interruption and/or poor user experience. A dedicated PDU session may be provided for each of the remote WTRUs.

WTRU-to-network relay discovery and selection (e.g., based on CAG ID) may be performed. WTRUs may be deployed to network relays and remote WTRUs (e.g., in industrial and/or vertical environments). The relay may provide extended range in a building (e.g., factory) to remote WTRUs (e.g., machines, operator phones) that wish to access the private network provided by the PNI-NPN. PNI-NPN access via 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:

discovering and selecting a WTRU-to-network relay that may provide access (e.g., via a CAG cell); access control for a remote WTRU (e.g., a CAG-enabled or non-CAG-enabled remote WTRU) accessing a network using a WTRU-to-network relay connected via a cell (e.g., a CAG or non-CAG cell); handling changes in available CAG over relay discovery and persistent relay communications through the relay (e.g., CAG cell change due to WTRU-to-network relay mobility); or WTRU-to-network relay CAG configuration updates (e.g., updates of allowed CAG IDs).

The remote WTRU may be paged (e.g., via ProSe L2 relay). The 5G-RAN may remove (e.g., when the remote WTRU enters an idle state) stored remote WTRU context information (e.g., identity, mobility, security, etc.) associated with the connected WTRU. The 5G-RAN may not know where the remote WTRU is located, e.g., whether the remote WTRU still has access to the ProSe L2 relay and/or which ProSe L2 relay the remote WTRU still has access to. The 5G-RAN may broadcast the remote WTRU's paging message on a paging channel and relay the paging message to all ProSe L2 in connected mode one by one via SRBs or DRBs (e.g., to ensure that the remote WTRU receives the paging message). In an example, it may be desirable to relay the paging message for each remote WTRU to the ProSe L2 in connected mode by a unicast method. Sending paging messages for each remote WTRU to ProSe L2 relays in connected mode by unicast methods may result in a large radio resource consumption, for example, because there may be a large number of ProSe L2 relays in the remote WTRU's paging area (e.g., in the Tracking Area (TA) list).

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, a cell id and a paging message (e.g., in an L2 relay scenario). The remote WTRU (e.g., in the 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 procedures may inform the relay WTRU that the broadcast information is no longer needed. In an example, the remote WTRU may inform the relay WTRU that the relay WTRU no longer needs the relayed information.

The remote WTRU may establish a secure PC5 link with the WTRU-to-network relay. For example, when attempting to establish a PC5 link with the WTRU to the 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 successful authentication and authorization of the remote WTRU using the WTRU-to-network relay, the remote WTRU and WTRU-to-network relay may continue to establish a secure PC5 link. A security key may be established for the PC5 link to protect communications over the PC5 link via the relay. Additional authentication procedures between the remote WTRU and the WTRU-to-network relay may be avoided. Unnecessary signaling and wasted resources, both at the remote WTRU and the WTRU-to-network relay, which may result in a denial of service (DOS) condition, may be avoided.

The terms relay WTRU, 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. The relay access WTRU may be or may include a remote WTRU as described herein.

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 registration (e.g., initial registration) with the core network as a WTRU that can become 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 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 for relaying by the WTRU to the network relay and/or one or more associated communication parameters (S-NSSAI, DNN, SSC pattern, etc.) associated with each service type. The S-NSSAI associated with the service may be part of a WTRU configured NSSAI.

The WTRU-to-network relay may register with the core network to request S-NSSAI based on 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 type, or the WTRU-to-network relay may trigger registration for S-NSSAIs 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.

The WTRU-to-network relay may broadcast one or more messages advertising the types of services it may support via its PC5 interface. 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 the granted network resources (such as allowed NSSAI). The WTRU-to-network relay may broadcast the service type, for example, on the condition that the corresponding S-NSSAI is included in the list of configured NSSAIs but not in the allowed NSSAIs. In the case of broadcasting a service type corresponding to the 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.

The WTRU-to-network relay may not broadcast the associated communication parameters (e.g., associated S-NSSAI) for it, e.g., a service type that is rejected as network resources (e.g., for a registration area or Public Land Mobile Network (PLMN)). When the 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 degree of usage and/or load threshold, the WTRU-to-network relay may include an explicit or implicit indication of high degree of usage in its service broadcast. The high usage value or load threshold may be configured as part of the WTRU-to-network relay configuration parameters. The high degree of usage or load threshold may be configured using overload control policy parameters. The usage level or load level of the relay WTRU may be based on: the WTRU-to-network relay may have a number of active PC5 links with one or more remote WTRUs, a number and type of PDU sessions, etc.

The WTRU-to-network relay may trigger a registration procedure when it receives a request from a remote WTRU, for example, for a conditionally available service. 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 new link setup with the remote WTRU by sending a confirmation message (e.g., direct communication accept) in response to the request from the remote WTRU. The WTRU-to-network relay may initiate link modification for existing links to add or remove services, e.g., on the condition that S-NSSAI is successfully allowed or rejected by the network. The WTRU-to-network relay may release the established link if the S-NSSAI is rejected. The WTRU-to-network relay may provide the remote WTRU with a reason that slicing is not available.

A remote WTRU (which may be referred to herein as a relay access WTRU) may perform an initial registration with the network as a WTRU that is capable of using (e.g., accessing) a WTRU to a 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 by the relay, associated communication parameters for each service type (e.g., S-NSSAI, DNN, SSC mode, etc.), and/or WTRU-to-network relay selection policies. The S-NSSAI required for service may be assumed to be part of the WTRU configured NSSAI.

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

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

The remote WTRU may select one or more relays for similar service types for redundancy in relayed communications. The remote WTRU may select a WTRU to network relay that may be broadcasting a service availability indication and then attempt to broadcast the same service as a different relay that may be conditionally available.

The remote WTRU may select a WTRU-to-network relay that does not have a high usage indication in the service broadcast without selecting a relay that broadcasts such indication, or without connecting to a relay that broadcasts such indication.

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 configured NSSAI, allowed NSSAI, rejected S-NSSAI, etc. The WTRU-to-network relay may suspend its broadcast (advertising the types of services it may 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.

For one or more allowed S-NSSAIs that are not affected by the UCU procedure, the WTRU-to-network relay may resume broadcasting advertising the type of service 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.

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 by the service type according to the relay configuration information. The WTRU-to-network relay may broadcast one or more broadcast messages via the PC5 interface advertising the types of services it may support and the associated S-NSSAI that is now allowed.

If the associated S-NSSAI in the relay configuration information is rejected by the network (e.g., the WTRU-to-network relay may receive from the network a rejected S-NSSAI including 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 type of service. The WTRU-to-network relay may provide the remote WTRU with a reason that slicing is not available. The WTRU-to-network relay may release the link with the relay access WTRU if service is not allowed or adjusted on the PC5 link.

The WTRU-to-network relay may create a dedicated PDU session for the remote WTRU. PDU session parameters (e.g., routing policies) 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 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 a remote WTRU establishes a connection for communicating with the WTRU-to-network relay, the WTRU-to-network relay may retrieve PDU session parameters for the remote WTRU. The WTRU-to-network relay may establish a PDU session for communication traffic relaying. If the 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 PDU session parameters for S-NSSAI, and a second remote WTRU may have the same PDU session parameters. Communication traffic for both WTRUs may be associated with the same PDU session. For example, if the WTRU-to-network relay uses the same PDU session for both WTRUs, the WTRU-to-network relay may modify the PDU session based on the QoS requirements received from the remote WTRU.

The WTRU-to-network relay may request PDU session parameters for the 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 the dedicated remote WTRU by including the remote WTRU ID and the ProSe service type/ID in the request message. For the same remote WTRU that may use different application/service types with different PDU session requirements (e.g., S-NSSAI, DNN), the WTRU-to-network relay may establish different dedicated PDU sessions.

The WTRU-to-network relay may send a PDU session parameter 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 PDU session parameters for the remote WTRU. The WTRU-to-network relay may verify whether the existing PDU session may be reused for the remote WTRU. The WTRU-to-network relay may determine whether the existing PDU session may meet the requirements of the PDU session parameters of the remote WTRU.

The WTRU-to-network relay may send a PDU session setup request to the network with the PDU session parameters for the remote WTRU if an existing PDU session is not found that meets the requirements of the PDU session parameters of the remote WTRU. The WTRU-to-network relay may include the remote WTRU ID in the PDU session setup 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.

Fig. 6 shows an example of a PDU session established between a remote WTRU and a core network via a ProSe WTRU-to-network relay. As shown in fig. 6, at 601, the WTRU sends a registration request message to a core network node (e.g., including an AMF) to a network relay. 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 WTRU and PDU session parameters, e.g., mapping between remote WTRU ID and NSSAI associated with PDU sessions.

At 603, the remote WTRU may perform its discovery procedure to discover the 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 does not request PDU session parameters during its registration with the core network), the WTRU-to-network relay may send a routing policy request message to the core network (e.g., the AMF of the core network) at 605. The routing policy request message may include one or more IDs associated with one or more of the remote WTRUs. The request may include a ProSe service type/service id.

At 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from an AMF of the core network). The routing policy response message received by the WTRU to the network relay may include one or more PDU session parameters for the remote WTRU.

At 607, the WTRU-to-network relay may search for an existing PDU session that may be reused for the remote WTRU, e.g., based on the remote WTRU's PDU session parameters and parameters associated with the existing PDU session. If a match between the PDU session parameters associated with the existing PDU session and the requirements of the remote WTRU is found, the WTRU-to-network relay may associate the existing PDU session with the remote WTRU and may not create a new PDU session.

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

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.

For example, when a remote WTRU establishes a connection for communicating with a 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 one or more PDU session parameters to the WTRU-to-network relay via a direct communication request message or other following messages (e.g., dedicated message for parameter configuration, IP address/prefix request message, etc.).

When (or after) a PC5 connection is established between the WTRU-to-network relay and the 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 the existing PDU session may be reused for requesting the remote WTRU. For example, the WTRU-to-network relay may determine whether an existing PDU session matches requested PDU session parameters received from a remote WTRU. The WTRU-to-network relay may send a PDU session setup request to the network if no existing PDU session is found that can be reused. The PDU session setup request may include PDU session parameters (e.g., new PDU session parameters) received from the remote WTRU. The WTRU-to-network relay may associate the remote WTRU with the matching PDU session if an existing PDU session is found that can be reused.

When (or after) the PC5 connection setup is requested, the remote WTRU may send one or more PDU session parameters to the WTRU-to-network relay. Figure 7 shows an example of a remote WTRU establishing a PDU session with a core network node via a WTRU-to-network relay. As shown in fig. 7, at 701, the WTRU-to-network relay may send a registration request message to a core network (e.g., an AMF of the core network). At 702, the WTRU-to-network relay may receive a registration accept message from an AMF in a core network. At 703, the remote WTRU may discover a 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 defer transmission of one or more of the PDU session parameters (e.g., S-NSSAI), which may be privacy sensitive, to a later step. For example, in fig. 7, the remote WTRU may transmit one or more PDU session parameters after 705 or 706. For example, in fig. 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 completion message with confidentiality and integrity protection including 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 IP address/prefix request message). The parameter configuration message may correspond to a protected DSM completion message as described above.

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

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

At 709, the WTRU-to-network relay may receive a PDU session setup response from the core network (e.g., SMF). 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.

The WTRU-to-network relay may include the remote WTRU ID and/or information about ProSe services 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 are acceptable. 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 accepted PDU session parameters such as accepted S-NSSAI, DDN, etc.

WTRU-to-network relay behavior receives remote WTRU ID and/or 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 service requested by the remote WTRU. The WTRU-to-network relay may receive a PDU session response message from the core network, which may include accepted PDU session parameters, such as S-NSSAI, DDN.

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

For example, after a WTRU-to-network relay establishes a PDU session for a remote WTRU, e.g., based on configuration, WTRU routing policy (URSP) rules, and/or PDU session parameters received from the remote WTRU, the WTRU-to-network relay may provide the PDU session parameters of the established PDU session to the remote WTRU. The remote WTRU may store the 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, e.g., PDU session type, SSC pattern, DNN, based on the local URSP rules.

For example, when or after establishing a PC5 connection with a remote WTRU, a WTRU-to-network relay may establish a PDU session for a 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 pattern.

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

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

In an example, the remote WTRU may need to be a CAG-enabled WTRU with a list of configured allowed CAG IDs and/or CAG-only indications. The WTRU may perform an initial registration with the network as a WTRU supporting the relay user. The WTRU may receive (e.g., during or after registration) relay access WTRU configuration parameters such as a set of service types authorized for use by relay with an optional associated CAG ID (e.g., the CAG ID may be part of the WTRU allowed CAG ID) and/or WTRU-to-network relay selection policy. The required CAG ID may be sent by the application layer (e.g., an industrial application may require a particular private network to be connected to). Parameters may be pre-configured in the relay access WTRU (e.g., to enable the WTRU to perform discovery and/or selection of a relay WTRU prior to the first initial registration).

The relay access WTRU may detect broadcast messages from the relay via the PC 5. The broadcast message 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 ID, a supported CAG ID (e.g., from a cell on which the relay is currently connected to or camped on), 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).

The relay access WTRU may select a WTRU to network relay according to a relay selection policy. The relay access WTRU may select to broadcast the WTRU to the network relay (e.g., based on the selection of the implicit CAG ID) for one or more service types associated with one of the relay access WTRU's allowed CAG IDs. The relay access WTRU may select a WTRU-to-network relay having the most compatible CAG configuration (e.g., one or more common CAG IDs between the relay access WTRU and the allowed CAG IDs of the WTRU-to-network relay, and/or the same CAG indication (e.g., same CAG only indication) configuration as the WTRU-to-network relay).

In an example, for a non-CAG remote WTRU, the remote WTRU may not select the relay unless the relay is not connected to/camped on a CAG cell (e.g., based on a CAG/non-CAG cell indication).

The remote WTRU may select a relay using one or more of the following features (e.g., if the broadcast message from the relay WTRU does not contain CAG specific information). The remote WTRU may select a relay WTRU based on the broadcast information (e.g., service type, universal 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 secured message (e.g., DSMC) from the relay WTRU, including one or more of: allowed CAG ID, CAG only indication, CAG ID supported by the current cell and/or CAG cell/non-CAG cell indication. The remote WTRU may select a relay using a selection policy as in the examples herein. The remote WTRU may send a PC5 unicast secured message to the relay WTRU including its CAG ID configuration and/or a subset of selected CAG IDs matching 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 with the PC5 link establishment or maintain the current PC5 link with the relay WTRU (e.g., if a PC5 link has been established). The remote WTRU may abort the PC5 link establishment and/or disconnect the established PC5 link (e.g., if the relay WTRU does not provide a suitable/compatible CAG ID for the remote WTRU).

The WTRU-to-network relay may enable 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 list of configured allowed CAG IDs and/or CAG indications (e.g., CAG-only indications). The relay access WTRU may select a CAG cell (e.g., which is part of a list of CAG IDs allowed for the relay access WTRU) and register with the network via the CAG cell. The WTRU may perform initial registration with the network. To act 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 for use by the relay, wherein the configuration parameters may have associated CAG IDs (e.g., the CAG IDs may be part of WTRU allowed CAG IDs); and/or relay operation strategies. The relay WTRU may broadcast one or more messages announcing the service type and/or CAG information via the PC5 interface. The relay WTRU may decide to broadcast a service type associated with one or more CAG IDs available in the CAG cell to which the relay WTRU is connected (e.g., broadcast a supported CAG ID through the CAG cell).

The WTRU-to-network relay may perform access control for a remote WTRU accessing the network via a CAG cell based on a configured type of service associated with one or more CAG IDs (e.g., allowed CAG IDs). In an example, a WTRU-to-network relay may be discovered and selected by a remote WTRU (e.g., based on service type/CAG ID information). The WTRU may perform mutual authentication with a remote WTRU. The PC5 layer key (e.g., KD) may be established/derived using the application layer key. 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 continue with PDU session establishment/modification.

The WTRU-to-network relay may be a layer 2(L2) relay. One or more of the following may be applied. 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 reject message (e.g., registration reject) 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 on the condition that a reject message is detected.

The available CAG may change (e.g., due to WTRU-to-network relay mobility). CAG-a and CAG-B may be available (e.g., when the WTRU camps on cell a to the network relay). A remote WTRU with CAG-a (e.g., instead of CAG-B) included in its allowed CAG ID may establish a PC5 session (e.g., to access CAG-a via 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 moves to cell B through the network relay, this may be limited to support CAG-B).

The WTRU-to-network CAG configuration (e.g., allowed CAG ID and/or CAG indication) 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 reselect a new cell to the network. Remote WTRU connectivity to the network via the WTRU may be affected. The remote WTRU may need to reselect and reconnect to the WTRU-to-network relay after such CAG configuration update or select a different WTRU-to-network relay (e.g., if the first WTRU-to-network relay does not meet the CAG-based access requirements of the remote WTRU).

The remote WTRU CAG configuration (e.g., allowed CAG ID and/or CAG indication, e.g., CAG only indication) 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., that supports the remote WTRU's newly allowed CAG ID).

The relay WTRU may notify the remote WTRU of the CAG change (e.g., sending updated available CAG information via a PC5 broadcast and/or unicast message). 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 reason code indicating that the CAG context has changed). The reason code may indicate: the available CAG ID has changed and/or the type of cell to which the relay WTRU is connected to or camped on has changed (e.g., from a CAG cell to a non-CAG cell or vice versa); no CAG ID is available; and/or current CAG access (e.g., via a 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.

The relay WTRU may notify the remote WTRU of the CAG change and disconnect the PC5 chain with the remote WTRU (e.g., on the condition that 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 a mapping of the searched CAG ID from the remote WTRU to the PC5 link (e.g., exchanged during PC5 link establishment). The relay WTRU may maintain the PC5 link (e.g., on a condition that a remote WTRU associated with the PC5 link searches for a CAG ID, an allowed or selected CAG ID, may still be available via the relay after a CAG change). The relay may switch off the PC5 link (e.g., on a condition that a remote WTRU associated with the PC5 link searches for a CAG ID, an allowed or selected CAG ID, may still not be available via the relay after a CAG change). The relay WTRU may obtain the CAG indication of the WTRU (e.g., CAG only indication) and switch off the PC5 link (e.g., if it has moved to a non-CAG cell).

The relay access WTRU may receive updated broadcast or unicast CAG information (e.g., from the relay WTRU) via the PC 5. The relay access WTRU may switch off the PC5 link (e.g., if the WTRU determines that access to the network via the relay and/or the new serving cell is not allowed).

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

Figure 8 illustrates WTRU-to-network relay discovery, selection and communication via layer 2 WTRU-to-network relay. As shown in fig. 8, at 800, a remote WTRU (WTRU1) may be configured (e.g., pre-configured and/or after initial registration with the network) with the parameters necessary to enable relay discovery/selection and connection to the network via the WTRU. The WTRU-to-network relay may be configured to provide L2 relay service. The WTRU-to-network relay WTRU may camp on the CAG cell.

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, etc.).

At 802, the remote WTRU may receive a PC5 broadcast message from the WTRU-to-network relay WTRU and select a relay based on an application ID, a relay service code or 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 with integrity protection and cell CAG information).

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., in case of an integrity check failure). The remote WTRU may check that the received relay CAG information contains at least one CAG ID that matches the remote WTRU's allowed CAG ID. The remote WTRU may proceed with link establishment (e.g., if a match is found). The remote WTRU may abort the link establishment (e.g., if no match is found).

At 807, the remote WTRU may send a DSMC complete message (e.g., including the remote WTRU's CAG information with integrity and confidentiality protection, such as allowed CAG ID and/or CAG indication) to the WTRU-to-network relay WTRU. At 808, the WTRU-to-network relay WTRU may store a mapping of the CAG information of the remote WTRU to 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, e.g., to complete the PC5 link establishment.

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 PDU session establishment. At 813, the remote WTRU may transmit/receive data via WTRU-to-network relay/RAN/remote WTRU UPF (e.g., where the WTRU-to-network relay may perform normal forwarding at L2).

The ProSe L2 relay may subscribe to paging notifications from the 5G-RAN (e.g., when the ProSe L2 relay is in 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 Occasion (PO) of the remote WTRU). After receiving the paging message from the remote WTRU of 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 ProSe L2 relay's subscribed ID and/or PO of the remote WTRU).

The ProSe L2 relay may establish a PC5 connection with a remote WTRU and receive paging parameters for the remote WTRU from the remote WTRU. The remote WTRU may send the paging parameters during or after PC5 connection establishment. The remote WTRU may send the updated paging parameters to the ProSe L2 relay (e.g., upon a change in paging parameters, such as in the case of a change in remote WTRU paging identity and/or PO).

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

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

The 5G-RAN may receive a paging subscription request from the ProSe L2 relay (e.g., which includes the ProSe L2 relay ID, the ID of the remote WTRU, and/or the PO of the remote WTRU). The 5G-RAN may receive a paging message from the AMF. The 5G-RAN may forward the paging message to the relevant ProSe L2 relay (e.g., on the condition that 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 the 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).

The stop monitoring procedure may be performed such that transmission and/or reception of redundant information may be reduced or avoided. For example, when a remote WTRU (re) enters 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 (e.g., through the relay node) for other information broadcast in the SIB. 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 two TAIs are the same or the TAI received from the RAN belongs to a TAI list that may be received from the core network during a previous registration procedure, the remote WTRU may know (or learn) that it may receive paging messages and other information from the RAN. The remote WTRU (e.g., where paging messages and other information from the RAN may be received) may decide to inform the relay node (e.g., relay WTRU) that the relayed information is no longer needed.

The remote WTRU may initiate a stop monitoring procedure. In an example, a PC5-S stop monitoring request or similar PC5 message may be sent to the 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., SIBs and cell ids) 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) be relayed by the relay WTRU. The stop-monitoring request message may be integrity, replay, and/or privacy protected, for example, to prevent sending a malicious request to the relay WTRU, such as a request intended to cause loss of service for the remote WTRU (e.g., a denial-of-service (DoS) attack).

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 includes a paging message in the stop monitoring request, the relay WTRU may (e.g., also) stop reading the Uu paging channel with the ID of the remote WTRU and the Paging Occasion (PO) of the remote WTRU. The relay WTRU may send a response or confirmation message back to the remote WTRU (e.g., to confirm receipt of the request).

For example, if the remote WTRU decides to rely on broadcast information (e.g., paging messages, SIBs, cell-id, MBMS, etc.) from the relay WTRU, the remote WTRU may initiate a normal "information monitoring request" procedure (e.g., at any time). 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).

A secure link may be established between the remote WTRU and the WTRU-to-network relay (which may be referred to herein as a "relay"). For example, the security of the PC5 link between the remote WTRU and the WTRU-to-network relay may be established (e.g., bootstrapped) by utilizing the primary authentication operation of the remote WTRU and 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., subscription hidden identity (SUCI)). The remote WTRU may perform a primary authentication procedure with the relayed AMF and the remote WTRU's master AUSF via a PC5 link with the relay. The remote WTRU may derive and store the 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 (e.g., after the remote WTRU successfully authenticates the network). The remote WTRU may receive a request message (e.g., direct security mode command) from the relay via the PC 5. 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 proceed with the security establishment procedure by deriving a session key from Krelay (e.g., Krelay-sess) 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 accept) indicating a successful establishment of the PC5 link.

For example, the 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 serving AMF of the relay. 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., associate them with the PC5 link context). The relay may use Krelay received from the AMF to derive the session key and the 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 serving AMF of the relay. 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 protection (e.g., confidentiality and/or integrity) of the message. Upon successful establishment of the 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 successful establishment of the PC5 link.

For example, the serving AMF of the WTRU-to-network relay may receive a request message from the relay to authorize the remote WTRU. The message may include a remote WTRU identity (e.g., SUCI). The AMF may trigger a remote WTRU identity verification procedure with a master 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., a 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 the 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 for the relay. The AMF may allocate and store core network remote WTRU identities (e.g., GUTI, GPSI) as part of the WTRU context for the relay. The AMF may register with the UDM of the remote WTRU as a relayed AMF serving the remote WTRU by providing an AMF identity and/or a relayed identity (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 a core network remote WTRU identity (e.g., GPSI).

For example, re-authentication/authorization of a remote WTRU to use a WTRU to a network relay may be performed at the AMF serving the relay, and the remote WTRU. For example, the serving AMF may initiate re-authentication/authorization of the remote WTRU at any time after successfully authorizing the remote WTRU to use the relay. In an exemplary scenario, the authorized range may be limited in time or location. During mobility for the relay, the AMF serving the relay may change, and the new AMF may obtain the WTRU context for the relay from the old AMF, including remote WTRU information (e.g., new Krelay and Krelay ID and identity) as described herein. The new AMF may update the serving AMF registration information with the UDM of the remote WTRU. The new AMF may initiate re-authentication/authorization of the remote WTRU in the procedures 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 new Krelay and Krelay ID from the new serving AMF as described herein. The relay may perform a rekeying process over the PC5 link with the remote WTRU using the new PC5 root key/key id. The remote WTRU may initiate the rekeying process by including the new Krelay ID in the direct rekeying request message to the relay. The relay may check that the received Krelay ID matches a new Krelay ID derived after the remote WTRU re-authentication process. Upon successful match checking, the relay may trigger a direct security command procedure to establish a new session and use Krelay as the integrity and confidentiality key for the PC5 link root key. The roles of the relay and remote WTRU may be reversed when performing the above described re-keying procedure. For example, the relay may initiate a key update procedure.

For example, revoking authorization for a remote WTRU to use a WTRU-to-network relay may be performed at the AMF serving the relay, and the remote WTRU. For example, the AMF may receive a request message from the UDM of the remote WTRU including an indication to revoke 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 a relay serving the remote WTRU including an indication to revoke 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 a PC5 link context based on receiving the Krelay id and/or the core network remote WTRU identity and initiate a link release procedure with the remote WTRU's associated PC5 link. 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 used for the remote WTRU). The relay may send a response message to the AMF indicating a successful release of the remote WTRU connection. The AMF may send a response message to the UDM of the remote WTRU indicating a successful grant retraction. The AMF may send a request to revoke remote WTRU authorization (e.g., for overload control purposes) as above but based on serving network policies.

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 a 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 the previous connection as described herein. The relay may continue to establish a secure PC5 link as described herein using Krelay. Upon successful establishment of the secure PC5 link, the relay may proceed with connection signaling with the network and complete the PC5 link establishment as described herein.

Figure 9 shows an exemplary message sequence for WTRU-to-network relay discovery and selection. The WTRU-to-network relay may be or may include the WTRU102 as described herein with respect to fig. 1A-1D. As shown in fig. 9, at 901, a relay may send a network registration request (e.g., in a registration request message) to a core network (e.g., an AMF of the core network). The network registration request may include an indication that the relay is capable of being a WTRU-to-network relay. The AMF may receive the network registration request and perform an Access and Mobility (AM) policy association setup 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. In response, at 902, the relay can receive (e.g., in a registration accept message) one or more relay service types and associated communication parameters as part of relay configuration parameters authorized by a core network (e.g., an AMF/PCF of the core network). The associated communication parameters may include PDU session parameters such as S-NSSAI, DNN, and/or SSC patterns.

At 903, the relay access WTRU (e.g., remote WTRU) may send a network registration request to a core network (e.g., an AMF of the core network) (e.g., in a registration request message). The relay access WTRU may be or may include the WTRU102 as described herein with respect to fig. 1A-1D. The network registration request may include an indication that the relay access WTRU is capable of supporting relay access (e.g., visiting the relay WTRU). The AMF may perform Access and Mobility (AM) policy association establishment with the PCF at 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.

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 relay access WTRU configuration parameters authorized by a 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 patterns.

At 905, the WTRU-to-network relay may broadcast a relay service type (e.g., a relay service type identified from the one or more authorized relay service types received at 902). The WTRU-to-network relay may identify a relay service type for broadcast, for example, based on communication parameters associated with one or more authorized relay service types and granted network resources associated with the WTRU-to-network relay. For example, a relay service type may be identified for broadcast on a condition that at least one communication parameter associated with the relay service type is supported by granted network resources. For example, the grant 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 from a core network (e.g., an AMF of the core network), for example, in a registration accept message. The relay service type may be identified for broadcasting on a condition that the allowed NSSAI received from the core network includes an S-NSSAI associated with the relay service type.

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 on a condition that the authorized relay service type is associated with communication parameters (e.g., S-NSSAI) included in one or more rejected network resources (e.g., rejected S-NSSAI).

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

The relay access WTRU may identify a target relay service type based on network requirements and communication parameters associated with an authorized relay service type that the relay access WTRU is authorized to use. For example, an authorized relay service type may be identified as a target relay service type on condition that the associated communication parameters meet network requirements. The network requirement may be a requirement of an application, such as S-NSSAI based on a relay access WTRU' S local URSP. The network requirement may be a requirement for service continuity, e.g., a particular SSC pattern. The authorized relay service type received from the core network may be identified as the target relay service type if the S-NSSAI associated with the authorized relay service type matches the S-NSSAI required by the application.

The relay access WTRU may also determine to select the WTRU to 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 to provide the maximum number of relay service type WTRUs to network relays in order to minimize the number of PC5 links that need to be established. The relay selection policy may prefer to have redundancy in relayed communications 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, but not another WTRU to network relay that broadcasts an indication that the same relay service type is conditionally available. The relay selection policy may prefer WTRU-to-network relays that do not broadcast an indication of high usage. The relay selection policy may not select WTRUs that broadcast an indication of high usage to network relays.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the 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 over 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (34)

1. A wireless transmit/receive unit to network (WTRU to network) relay, comprising:

a processor configured to:

sending a network registration request indicating a WTRU-to-network relay capability;

receiving, in response to the network registration request, an indication of at least one authorized relay service type and a plurality of communication parameters associated with the at least one authorized relay service type;

identifying a relay service type from the at least one authorized relay service type for broadcasting based on the plurality of communication parameters and granted network resources associated with the WTRU-to-network relay; and

the identified relay service type is broadcast.

2. The WTRU-to-network relay of claim 1, wherein the indication of the at least one authorized relay service type and the plurality of communication parameters associated with the at least one authorized relay service type are received as part of relay configuration parameters.

3. The WTRU-to-network relay of claim 1, wherein the processor is further configured to:

for a first authorized relay service type of the at least one authorized relay service type, identifying at least one communication parameter associated with the first authorized relay service type based on the plurality of communication parameters; and

determining whether the at least one communication parameter is supported by the granted network resources associated with the WTRU-to-network relay, wherein the first authorized relay service type is identified for broadcasting on a condition that the at least one communication parameter is supported by the granted network resources.

4. The WTRU-to-network relay of claim 1, wherein the granted network resources comprise allowed Network Slice Selection Assistance Information (NSSAI) associated with the WTRU-to-network relay.

5. The WTRU-to-network relay of claim 1, wherein the granted network resources comprise an allowed NSSAI associated with the WTRU-to-network relay, and the plurality of communication parameters associated with the at least one authorized relay service type comprise at least one single network slice selection assistance information (S-NSSAI), and the processor is further configured to:

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters; and

determining whether the S-NSSAI associated with the first authorized relay service type is included in the allowed NSSAI, wherein the first authorized relay service type is identified for broadcasting on a condition that the S-NSSAI associated with the first authorized relay service type is included in the allowed NSSAI.

6. The WTRU-to-network relay of claim 1, wherein the processor is further configured to:

receiving, in response to the network registration request, rejected network resources associated with the WTRU-to-network relay, and the rejected network resources include at least one rejected S-NSSAI;

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the S-NSSAI associated with the first authorized relay service type is included in the at least one rejected S-NSSAI; and

determining not to broadcast the first authorized relay service type on a condition that the S-NSSAI associated with the first authorized relay service type is included in the at least one rejected S-NSSAI.

7. The WTRU-to-network relay of claim 1, wherein the plurality of communication parameters includes at least one of:

S-NSSAI；

a Data Network Name (DNN); or

Session and Service Continuity (SSC) mode.

8. The WTRU-to-network relay of claim 1, wherein the plurality of communication parameters includes a plurality of Protocol Data Unit (PDU) session parameters.

9. A relay access wireless transmit/receive unit to network (WTRU), comprising:

a processor configured to:

sending a network registration request including an indication of a WTRU-to-network relay access capability;

receiving, in response to the network registration request, an indication of at least one authorized relay service type and a plurality of communication parameters associated with the at least one authorized relay service type;

identifying a target relay service type from the at least one authorized relay service type based on network resource requirements associated with the relay access WTRU and the plurality of communication parameters;

receiving a broadcast message including at least one relay service type provided by a WTRU to a network relay; and

determining to select the WTRU-to-network relay based on the at least one relay service type provided by the WTRU-to-network relay and the identified target service type.

10. The relay access WTRU of claim 9, wherein the indication of the at least one authorized relay service type and the plurality of communication parameters associated with the at least one authorized relay service type are received as part of a relay access WTRU configuration parameter.

11. The relay access WTRU of claim 9, wherein the processor is further configured to:

for a first authorized relay service type of the at least one authorized relay service type, identifying at least one communication parameter associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the network resource requirement associated with the relay-access WTRU is supported by the at least one communication parameter associated with the first authorized relay service type; and

identifying the first authorized relay service type as the target relay service on a condition that the network resources associated with the relay access WTRU require support by the at least one communication parameter associated with the first authorized relay service type.

12. The relay access WTRU of claim 9, wherein the processor is further configured to:

determining to select the WTRU-to-network relay on at least a condition that the at least one relay service type provided by the WTRU-to-network relay includes an identified target relay service type.

13. The relay access WTRU of claim 9, wherein the plurality of communication parameters includes at least one of a single network slice selection assistance information (S-NSSAI), a Data Network Name (DNN), or a Session and Service Continuity (SSC) pattern.

14. The relay access WTRU of claim 9, wherein the network resource requirements associated with the relay access WTRU include at least one of an S-NSSAI, DNN, or SSC pattern.

15. The relay access WTRU of claim 9, wherein the plurality of communication parameters includes at least one S-NSSAI associated with the at least one authorized relay service type, the network resource requirements associated with the relay access WTRU include the S-NSSAI associated with the relay access WTRU, and the processor is further configured to:

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the S-NSSAI associated with the relay-accessing WTRU is included in the S-NSSAI associated with the first authorized relay service type; and

identifying the first authorized relay service type as the target relay service type on a condition that at least the S-NSSAI associated with the first authorized relay service type includes the S-NSSAI associated with the relay access WTRU.

16. The relay access WTRU of claim 9, wherein the processor is further configured to:

receiving WTRU-to-network relay selection policy information in response to the network registration request, wherein the WTRU-to-network relay is selected further based on the WTRU-to-network relay selection policy information, and the WTRU-to-network relay selection policy information includes at least one of:

information related to selecting a WTRU to network relay that provides a maximum number of target relay service types;

information related to selecting one or more WTRU-to-network relays for similar target relay service types;

information related to selecting a WTRU-to-network relay that broadcasts an indication that a target relay service type is available without selecting a second WTRU-to-network relay that broadcasts an indication that a target relay service type is conditionally available;

information related to selecting a WTRU to network relay that does not broadcast an indication of high usage; or

Information related to WTRU-to-network relay not selecting to broadcast an indication of high usage.

17. The relay access WTRU of claim 9 wherein the plurality of communication parameters includes a plurality of Protocol Data Unit (PDU) session parameters.

18. A method implemented by a wireless transmit/receive unit to network (WTRU to network) relay, the method comprising:

sending a network registration request indicating a WTRU-to-network relay capability;

receiving, in response to the network registration request, an indication of at least one authorized relay service type and a plurality of communication parameters associated with the at least one authorized relay service type;

identifying a relay service type from the at least one authorized relay service type for broadcasting based on the plurality of communication parameters and granted network resources associated with the WTRU-to-network relay; and

the identified relay service type is broadcast.

19. The method of claim 18, wherein the indication of at least one authorized relay service type and the plurality of communication parameters associated with the at least one authorized relay service type are received as part of a relay configuration parameter.

20. The method of claim 18, further comprising:

for a first authorized relay service type of the at least one authorized relay service type, identifying at least one communication parameter associated with the first authorized relay service type based on the plurality of communication parameters; and

determining whether the at least one communication parameter is supported by the granted network resources associated with the WTRU-to-network relay, wherein the first authorized relay service type is identified for broadcasting on a condition that the at least one communication parameter is supported by the granted network resources.

21. The method of claim 18 wherein the granted network resources comprise allowed Network Slice Selection Assistance Information (NSSAI) associated with the WTRU-to-network relay.

22. The method of claim 18, wherein the granted network resources comprise an allowed NSSAI associated with the WTRU-to-network relay, and the plurality of communication parameters associated with the at least one authorized relay service type comprise at least one single network slice selection assistance information (S-NSSAI), and the method of claim 18 further comprising:

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters; and

determining whether the S-NSSAI associated with the first authorized relay service type is included in the allowed NSSAI, wherein the first authorized relay service type is identified for broadcasting on a condition that the S-NSSAI associated with the first authorized relay service type is included in the allowed NSSAI.

23. The method of claim 18, further comprising:

receiving, in response to the network registration request, rejected network resources associated with the WTRU-to-network relay, and the rejected network resources include at least one rejected S-NSSAI;

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the S-NSSAI associated with the first authorized relay service type is included in the at least one rejected S-NSSAI; and

determining not to broadcast the first authorized relay service type on a condition that the S-NSSAI associated with the first authorized relay service type is included in the at least one rejected S-NSSAI.

24. The method of claim 18, wherein the plurality of communication parameters comprise at least one of:

S-NSSAI；

a Data Network Name (DNN); or

Session and Service Continuity (SSC) mode.

25. The method of claim 18, wherein the plurality of communication parameters comprise a plurality of Protocol Data Unit (PDU) session parameters.

26. A method implemented by a relay access wireless transmit/receive unit to network (WTRU), the method comprising:

sending a network registration request including an indication of a WTRU-to-network relay access capability;

receiving, in response to the network registration request, an indication of at least one authorized relay service type and a plurality of communication parameters associated with the at least one authorized relay service type;

identifying a target relay service type from the at least one authorized relay service type based on network resource requirements associated with the relay access WTRU and the plurality of communication parameters;

receiving a broadcast message including at least one relay service type provided by a WTRU to a network relay; and

determining to select the WTRU-to-network relay based on the at least one relay service type provided by the WTRU-to-network relay and the identified target service type.

27. The method of claim 26, wherein the indication of at least one authorized relay service type and the plurality of communication parameters associated with the at least one authorized relay service type are received as part of a relay access WTRU configuration parameter.

28. The method of claim 26, further comprising:

for a first authorized relay service type of the at least one authorized relay service type, identifying at least one communication parameter associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the network resource requirement associated with the relay-access WTRU is supported by the at least one communication parameter associated with the first authorized relay service type; and

identifying the first authorized relay service type as the target relay service on a condition that the network resources associated with the relay access WTRU require support by the at least one communication parameter associated with the first authorized relay service type.

29. The method of claim 26, the method further comprising:

determining to select the WTRU-to-network relay on at least a condition that the at least one relay service type provided by the WTRU-to-network relay includes an identified target relay service type.

30. The method of claim 26, wherein the plurality of communication parameters comprise at least one of single network slice selection assistance information (S-NSSAI), Data Network Name (DNN), or Session and Service Continuity (SSC) mode.

31. The method of claim 26, wherein the network resource requirements associated with the relay access WTRU include at least one of an S-NSSAI, DNN, or SSC pattern.

32. The method of claim 26, wherein the plurality of communication parameters includes at least one S-NSSAI associated with the at least one authorized relay service type, the network resource requirements associated with the relay-accessing WTRU include the S-NSSAI associated with the relay-accessing WTRU, and the method of claim 26 further comprises:

for a first authorized relay service type of the at least one authorized relay service type, identifying an S-NSSAI associated with the first authorized relay service type based on the plurality of communication parameters;

determining whether the S-NSSAI associated with the relay access WTRU is included in the S-NSSAI associated with the first authorized relay service type; and

identifying the first authorized relay service type as the target relay service type on a condition that at least the S-NSSAI associated with the first authorized relay service type includes the S-NSSAI associated with the relay access WTRU.

33. The method of claim 26, further comprising:

receiving WTRU-to-network relay selection policy information in response to the network registration request, wherein determining to select the WTRU-to-network relay is further based on the WTRU-to-network relay selection policy information, and the WTRU-to-network relay selection policy information includes at least one of:

information related to selecting a WTRU to network relay that provides a maximum number of target relay service types;

information related to selecting one or more WTRU-to-network relays for similar target relay service types;

information related to selecting a WTRU-to-network relay that broadcasts an indication that a target relay service type is available without selecting a second WTRU-to-network relay that broadcasts an indication that a target relay service type is conditionally available;

information related to selecting a WTRU to network relay that does not broadcast an indication of high usage; or

Information related to WTRU-to-network relays not electing to broadcast indications of high usage.

34. The method of claim 26, wherein the plurality of communication parameters comprise a plurality of Protocol Data Unit (PDU) session parameters.

Images