Device discovery via relay device

Abstract

Mobile device-to-mobile device discovery may be performed via a relay device (e.g., a wireless transmit / receive unit (WTRU)), which may send a discovery request (e.g., including a service ID, a relay capability indication, and a relay WTRU ID) to a ProSe server. The discovery response may include a (e.g., ProSe) relay service broadcast code and a discovery filter (e.g., corresponding to the service ID of the service broadcast by the service provider WTRU). The relay WTRU may use the discovery filter to listen to the ProSe code broadcast by the service provider WTRU. The relay WTRU may determine that the received ProSe code matches the discovery filter. The relay WTRU may broadcast the relay service broadcast code based on the match. The service broadcast code broadcast may be intended for reception by the serving WTRU, which may utilize the relay WTRU to join / receive the service from the service provider WTRU.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Application No. 62 / 910,067, filed Oct. 3, 2019, the content of which is incorporated herein by reference.

Background Art

[0002] A wireless communication device can establish communication with other devices and data networks via an access network. For example, a wireless communication device can establish communication via a 3GPP radio access network (RAN). A wireless communication device can access a 3GPP network to communicate with other wireless devices and access a data network.

[0003] A wireless communication device can execute applications that utilize various services. These applications and services may be intended for simultaneous use by multiple users. A wireless communication device can benefit from being able to discover other communication devices in relation to the execution of a particular application or service.

Summary of the Invention

[0004] This specification discloses systems, methods, and means related to mobile device service discovery via a relay device. A wireless transmit and receive unit (WTRU) can communicate a discovery request. The discovery request can indicate that the WTRU is configured to operate as a relay for the discovery of at least one service. The WTRU can receive a discovery response. The discovery response can include at least one discovery filter and at least one relay service broadcast code. The WTRU monitors the service broadcast code. When the WTRU detects a service broadcast code that meets at least one discovery filter, the WTRU broadcasts at least one relay service broadcast code.

[0005] For example, a relay device that may be a relay WTRU can send a discovery request to a network entity such as a proximity service (ProSe) server. The discovery request can include, for example, a service identifier (ID), a WTRU-WTRU relay indication (e.g., an information element indicating that the relay WTRU is configured to operate as a relay for discovery of at least one service), and / or a relay WTRU ID. The relay WTRU can receive a discovery response (e.g., from the ProSe server). The discovery response can include, for example, at least one service (e.g., ProSe service) broadcast code that may be referred to as a relay service broadcast code, and at least one discovery filter (e.g., corresponding to the service ID). The relay WTRU can use the at least one discovery filter to listen for at least one ProSe code broadcast (e.g., on the PC5 interface) by at least one service provider WTRU, and this ProSe code may be referred to as a service broadcast code. The relay WTRU can determine whether the received broadcast code (service broadcast code) matches or otherwise satisfies at least one discovery filter (e.g., received in the discovery response and used to monitor the broadcast code). The relay WTRU can broadcast, for example, a relay service (e.g., ProSe service) broadcast code (e.g., received in the discovery response from the ProSe server) based on a match (e.g., the received broadcast ProSe service code corresponds to the service ID of the service provided by the service provider WTRU as may be indicated by the discovery filter match). The (e.g., ProSe) relay service broadcast code broadcast by the relay WTRU may be for reception by a service utilization WTRU, and this service can use the relay WTRU to receive a service from the service provider WTRU.

[0006] The relay WTRU can request and broadcast a ProSe relay code (relay service broadcast code) for ProSe relay services. The relay WTRU can monitor the ProSe services being relayed and report the available ProSe services being relayed to the ProSe function. The service-using WTRU can determine to discover ProSe services. The service-using WTRU can query the ProSe function about the ProSe relay code of a relay WTRU configured to relay ProSe services. The relay WTRU may be configured to relay ProSe services. The relay WTRU can discover ProSe services. The service-using WTRU can discover the relay WTRU, for example, by listening for the ProSe relay code.

[0007] The relay WTRU may be configured to perform a discovery operation (e.g., an open direct discovery procedure). The relay WTRU can receive a discovery response, which can include a relay ProSe application code, a relay discovery key, a ProSe application code, and / or a discovery key from the ProSe function. The relay WTRU can perform a security check on a message that may include the ProSe application code (e.g., using the discovery key). The relay WTRU can transmit the relay ProSe application using a second message protected with the relay discovery key, for example, if the first message passes the security check.

[0008] The monitoring WTRU can discover (e.g., determine to discover) the notification WTRU when, for example, the monitoring WTRU is within the range of the notification WTRU and the relay WTRU. The monitoring WTRU can send a relay preference indication in a discovery request. The monitoring WTRU can receive a relay match report (RMR) transmission timer (e.g., timer value) in a discovery response. The monitoring WTRU can delay the transmission of a match report (e.g., by the timer value) (e.g., using the RMR transmission timer) when, for example, the monitoring WTRU detects that the relay ProSe application code is from the relay WTRU. The monitoring WTRU can send a match report (e.g., including the relay ProSe application code from the relay WTRU) when, for example, the RMR transmission timer expires. The monitoring WTRU can send a match report (e.g., immediately or without delay) when, for example, the monitoring WTRU detects a ProSe application code from the notification WTRU, and the monitoring WTRU can stop the RMR transmission timer (e.g., when the timer is running).

[0009] This "Summary of the Invention" is provided to introduce, in a simplified form, a selection of concepts that are further described herein in the "Detailed Description of the Invention". This "Summary of the Invention" is not intended to limit the scope of the claimed subject matter. Other features are described herein.

Brief Description of the Drawings

[0010]

Figure 1A

[0011]

Figure 1B

[0012]

Figure 1C

[0013]

Figure 1D

[0014]

Figure 2

[0015]

Figure 3

[0016]

Figure 4

[0017]

Figure 5

[0018]

Figure 6

[0019]

Figure 7

[0020]

Figure 8

[0021]

Figure 9

Best Mode for Carrying Out the Invention

[0022] Systems, methods, and means related to WTRU - to - WTRU discovery via a relay WTRU are disclosed (e.g., via exemplary implementations). The relay WTRU can send a discovery request to a network entity, such as a ProSe server (which may be used as an example in this specification), or a similar network node, such as a PCF, DDNMF, etc. This request can include, for example, a service ID, a relay function indication, and / or a relay WTRU ID. The relay WTRU can receive a response, which can include a discovery filter corresponding to a broadcast code and a service ID. The relay WTRU can use the discovery filter to listen for ProSe codes broadcast by a service provider WTRU. The relay WTRU can detect a ProSe code corresponding to the service provider WTRU. The relay WTRU can broadcast the ProSe code received from the ProSe server. A service - using WTRU listening to the relay WTRU can receive the ProSe code and can use the relay WTRU to request to use a service from the service provider WTRU.

[0023] FIG. 1A is a diagram showing 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. The communication system 100 can enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filter type co-OFDM, filter bank multicarrier (FBMC).

[0024] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may all be referred to as "stations" and / or "STAs," may be configured to transmit and / or receive wireless signals and may also be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), home electronics, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may also be referred to synonymously as a UE.

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

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

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

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

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

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

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

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

[0033] The base station 114b in FIG. 1A may be, for example, a wireless router, a home node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connections in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by, e.g., a drone), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115 in some cases.

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

[0035] CN106 / 115 can also function as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can 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 Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 can include another CN connected to one or more RANs, which can use the same or a different RAT as the RAN104 / 113.

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

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

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

[0039] The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmitting / receiving 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 transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0041] The transceiver 120 may be configured to modulate signals transmitted by the transmitting / receiving element 122 and demodulate signals received by the transmitting / receiving element 122. As noted above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

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

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

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

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

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

[0048] RAN 104 can include eNode-Bs 160a, 160b, 160c, but it will be understood that RAN 104 can include any number of eNode-Bs while maintaining consistency with one embodiment. Each of eNode-Bs 160a, 160b, 160c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, eNode-B 160a, for example, can transmit wireless signals to and / or receive wireless signals from WTRU 102a using multiple antennas.

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

[0050] CN106 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. Although each of the foregoing elements is illustrated as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0051] MME 162 may be connected to each of eNode-Bs 162a, 162b, 162c in RAN 104 via an S1 interface and may function as a control node. For example, MME 162 may serve roles such as authenticating users of WTRUs 102a, 102b, 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial connection of WTRUs 102a, 102b, 102c. MME 162 may provide control plane functions for switching between RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

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

[0053] SGW 164 may be connected to PGW 166, and PGW 166 can provide WTRU 102a, 102b, 102c with access to a packet switched network such as the Internet 110 in order to facilitate communication between WTRU 102a, 102b, 102c and an IP-enabled device.

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

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

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

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

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

[0059] A High Throughput (HT) STA can form a 40 MHz wide channel for communication, for example, via a combination of an adjacent or non - adjacent 20 MHz channel with the primary 20 MHz channel.

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

[0061] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah can support meter type control / machine type communication, such as MTC devices within a macro coverage area. The MTC device may have limited capabilities including specific capabilities, such as support for a specific bandwidth and / or support for a limited bandwidth (e.g., only support). The MTC device can include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0062] A WLAN system that supports multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs within the BSS. The bandwidth of the primary channel may be set and / or restricted by a certain STA among all STAs operating within a BSS that supports the minimum bandwidth operation mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that) even when the AP and other STAs within the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. For example, if the primary channel is busy for an STA (supporting only the 1 MHz operation mode) to transmit to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain available and idle.

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

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

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

[0066] The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using transmissions related to scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using different or scalable length sub-frames or transmission time intervals (TTIs) (e.g., containing various numbers of OFDM symbols and / or having various lengths of absolute time durations).

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

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

[0069] 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 optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is shown as part of CN 115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

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

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

[0072] UPF184a and 184b may be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, and one or more of gNB180a, 180b, and 180c can provide access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding of packets, implementation of user plane policies, support for multi-home PDU sessions, processing of user plane QoS, buffering of downlink packets, and provision of a mobility anchor.

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

[0074] Considering FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein with respect to one or more of WTRU102a-d, base stations 114a-b, eNode-Bs 160a-c, MME162, SGW164, PGW166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functionality.

[0075] An emulation 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, one or more emulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform tests using terrestrial wireless communication.

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

[0077] This specification discloses systems, methods, and means related to WTRU - to - WTRU discovery via a relay WTRU. The relay WTRU can send a discovery request to a network entity, such as a Proximity Services (ProSe) server that can be used as an example in this specification. The discovery request can include, for example, a service identifier (ID), a relay function indication, and / or a relay WTRU ID. The relay WTRU can receive a response that may include a discovery filter corresponding to a broadcast code and / or a service ID. The broadcast code can be a relay service broadcast code. The relay WTRU can use the discovery filter to listen for ProSe codes that can be broadcast by a service provider WTRU. The relay WTRU can, for example, broadcast the ProSe code received from the ProSe server if the relay WTRU detects (e.g., by using the received discovery filter) that the ProSe code corresponding to the service provider WTRU matches the ProSe code received from the ProSe server. A service - using WTRU can listen for the relay WTRU and receive the ProSe code. The service - using WTRU can, for example, request a service from the WTRU providing the service by using the relay WTRU based on, for example, receiving (and using) the ProSe code.

[0078] There may be multiple types or models for service discovery. (For example, prior to the introduction of relays) Two exemplary models will be described. Some features in this specification may be described with respect to a given model, but these features may be used in an implementation, as needed, regardless of the model. (For example, directly) The first model for service discovery may be referred to as "Model A" or "Open Discovery" and may be based on an announcement (for example, a declaration such as "I am here"). A service-capable (e.g., ProSe-capable) WTRU may include, for example, an announcing WTRU and a monitoring WTRU. A ProSe-capable WTRU participating in ProSe direct discovery may have one or more roles. The first role of the WTRU may be to act as an announcing WTRU, which may include announcing specific information that can be used by a neighboring WTRU, such as a WTRU having permission to discover other devices. The second role of the WTRU may be to act as a monitoring WTRU, which may include monitoring for specific information of interest (e.g., while in proximity to one or more announcing WTRUs). The announcing WTRU can broadcast discovery messages at a predefined discovery interval. A monitoring WTRU interested in the broadcast message can read and process the received broadcast message. The announcement / declaration in Model A may be equivalent to the "I am here" paradigm, for example, when the announcing WTRU broadcasts information about itself (e.g., ProSe application identity and / or ProSe WTRU identity) in a discovery message.

[0079] (For example, directly) The second model for services may be referred to as "Model B" and discovery occurs when there is a request (e.g., seeking a response to a question such as "who is there?" or "are you there?"). A service-capable (e.g., ProSe-capable) WTRU (e.g., capable of participating in ProSe direct discovery) may have one or more (e.g., two) roles. The first role of the WTRU may be to act as a discoverer WTRU that can send a request. The request can include information that the discoverer WTRU (e.g., an application running therein) may be interested in discovering from one or more nearby WTRUs or is attempting to discover. The second role of the WTRU may be to act as a discovered WTRU that can receive a request message from one or more discoverer WTRUs and can respond, for example, with information related to the discoverer's request.

[0080] Figure 2 shows an exemplary implementation for direct service discovery. The example shown in Figure 2 may conform to Model A. Referring to Figure 2, at 1, the WTRU can obtain permission from the ProSe function to announce and / or monitor in a particular public land mobile network (PLMN) (e.g., via a device management (DM) procedure).

[0081] At 2a, the WTRU can send a discovery announcement request (e.g., via a PC3 reference point) to the ProSe function, for example, if the WTRU is permitted to announce. This request can identify the service that the WTRU has determined to announce. Identification of the service can be provided, for example, by a ProSe application ID. The ProSe function can provide a ProSe application code for the WTRU to announce, for example, if the ProSe function determines that the WTRU is permitted to announce.

[0082] In 2b, the WTRU can send a discovery monitoring request (e.g., via a PC3 reference point) to the ProSe function if, for example, the WTRU is permitted to monitor in a specific PLMN. This request can include, for example, the service that the WTRU is requesting to discover / monitor (e.g., using a ProSe application ID). The ProSe function can provide the WTRU with a ProSe application code for monitoring if, for example, the ProSe function determines that monitoring is permitted.

[0083] The WTRU can communicate with another WTRU via a relay WTRU. For example, proximity services (ProSe) can include WTRU-to-WTRU communication via a relay WTRU (e.g., in a 5G network). The WTRU can discover another WTRU using, for example, model A, model B, or another discovery procedure or mechanism. The WTRU can communicate with the discovered other WTRU via a relay WTRU that is arranged to be communicable between the WTRUs.

[0084] Figure 3 shows an example of WTRU-to-WTRU communication via a relay WTRU. Figure 3 shows three types of WTRUs. A service provider WTRU (WTRU1) can provide services that can be discoverable by other WTRUs (e.g., by searching for one or more available services). Examples of services that can be provided by the service provider WTRU can include, for example, restaurant services, taxi services, game consoles, game controllers, etc. The service provider WTRU can announce the services it provides and can be referred to as the announcing WTRU or A-WTRU.

[0085] A service-using WTRU (WTRU2) can search for one or more available services, and the one or more available services can include services provided by a service provider WTRU. There may be two or more service-using WTRUs, and one or more of the two or more service-using WTRUs can attempt to discover available services that can include services provided by one or more (e.g., specific) service provider WTRUs. Examples of service-using WTRUs can include, for example, a WTRU that provides one or more applications (apps) that can be used by a restaurant customer or a taxi passenger, a WTRU that provides a game controller to a user, an augmented reality (AR) and / or virtual reality (VR) headset that can be used by a user, etc. The service-using WTRU can monitor service announcements from other WTRUs and can be referred to as a monitoring WTRU or an M-WTRU.

[0086] A relay WTRU can assist or relay discovery messages and PC5 data communications between a service provider WTRU and a service-using WTRU. The relay WTRU can, for example, function as a proxy between the service-providing WTRU and the service-using WTRU for discovery and communication, and / or the relay WTRU can transparently relay messages between the service-providing WTRU and the service-using WTRU. The relay WTRU can participate in the discovery process between the service provider WTRU and the service-using WTRU. The relay WTRU can be referred to as a WTRU-to-WTRU relay or an R-WTRU.

[0087] Figure 4 shows an exemplary implementation of the discovery procedure. Figure 4 shows an example of providing integrity protection for the transmitted code. For example, the security procedure for ProSe open discovery (e.g., Model A) can be transmitted by the informing WTRU (e.g., via the PC5 interface) and can provide integrity and replay protection for the discovery message that can be received by the monitoring WTRU. The informing WTRU can be provided with, for example, ProSe application (app) code, a discovery key, and / or time-related parameters. The informing WTRU can be provided with, for example, the ProSe function of the informing WTRU's home PLMN (HPLMN) (e.g., via the PC3 interface) through the discovery transaction. The discovery transaction can include, for example, a discovery request and a discovery response. The informing WTRU can inform the ProSe app code (e.g., to one or more monitoring WTRUs) in the PC5 message. The informing WTRU can calculate a message integrity check (MIC) for the message using, for example, the discovery key and a time (e.g., coordinated universal time (UTC))-based counter. The informing WTRU can transmit the MIC together with the message. The monitoring WTRU can detect the ProSe app code broadcast by the informing WTRU using, for example, a filter that can be provided by the HPLMN ProSe function of the monitoring WTRU. The monitoring WTRU can transmit the code and / or MIC (e.g., received in the detected broadcast) for verification to the HPLMN ProSe function of the monitoring WTRU (e.g., via the PC3 interface) in, for example, a match report message. The monitoring WTRU can receive an acknowledgement (Ack) of the report match, which can confirm that the discovery message from the informing WTRU has passed one or more integrity checks by the ProSe function.

[0088] In the discovery procedure in the evolved packet core (EPC) ProSe, a ProSe application ID can be used (e.g., in Model A discovery). For example, a WTRU can use the ProSe application ID to discover each other for each service. The discovery procedure (e.g., the same or similar discovery procedure that can be used in Model A) can be applied to ProSe WTRU - to - WTRU discovery via a relay WTRU (e.g., in 5G). A first WTRU (e.g., a service - provider WTRU) and a second WTRU (e.g., a service - user WTRU) can determine to discover each other (e.g., before service data can be exchanged). The first WTRU and the second WTRU, which may not be within each other's communication range, can utilize the assistance from a relay WTRU (e.g., to be able to discover each other). The first WTRU and the second WTRU can execute the discovery procedure using the relay WTRU (e.g., in addition to discovering each other). Disclosed herein are a system, method, and means for the first WTRU, the second WTRU, and the relay WTRU to discover each other (e.g., for the purpose of accessing a particular service) via a plurality of exemplary implementations.

[0089] For WTRU - to - WTRU relay discovery, security can be provided. A relay WTRU (R - WTRU) participating in the discovery procedure with an announcing WTRU (A - WTRU) and a monitoring WTRU (M - WTRU) can determine (e.g., ensure compliance) whether a discovery message (e.g., a PC5) from the announcing WTRU (A - WTRU) passes a integrity check and / or a freshness check (e.g., for replay protection) before the relay WTRU can operate as a relay for the corresponding ProSe application. The relay WTRU (R - WTRU) can verify that the announcing WTRU (A - WTRU) is permitted to send a discovery code for the service before the R - WTRU starts relaying the discovery of the service.

[0090] The relay WTRU can, for example, protect (e.g., determine to protect) a message (e.g., via the PC5 interface) for integrity and freshness before transmission such that a monitoring WTRU can verify that the relay WTRU is permitted to send a discovery code and function as a relay for services. Systems, methods, and means for performing integrity / replay protection and verification of a code transmitted during a discovery procedure by a relay WTRU are disclosed herein (e.g., via exemplary implementations).

[0091] The monitoring WTRU may be in proximity to both the announcing WTRU and the relay WTRU. Discovery of the announcing WTRU by the monitoring WTRU (e.g., directly) without using the relay WTRU may be available. The monitoring WTRU (M-WTRU) can (e.g., directly) discover the services provided by the announcing WTRU and establish (e.g., via PC5) (e.g., direct) communication with the announcing WTRU without going through the relay WTRU. Using the relay WTRU within the range of the announcing WTRU may result in unnecessary signaling, delays in communication, and resource usage. The monitoring WTRU may prefer direct communication over relayed communication with the announcing WTRU. Systems, methods, and means for service discovery are disclosed herein (e.g., via exemplary implementations), and the monitoring WRTU may, for example, prefer (e.g., deterministically prefer) direct discovery of the announcing WTRU over (e.g., indirect) discovery of the announcing WTRU via the relay WTRU when the monitoring WTRU is within the range of both the announcing WTRU and the relay WTRU.

[0092] The discovery implementation can use operations such as operations performed by an entity / function with an entity, and the operations can be described in this specification using the ProSe function or the ProSe server. The ProSe function can be a node that is part of a network function or a network (e.g., a 5G core network). The ProSe function can be a separate or distinct network function or ProSe function, and in an example, the operations can be split or distributed across different network functions (e.g., in a core network). In some examples, the policy control function (PCF) can play a role (e.g., provide) in ProSe configuration provisioning, and the access and mobility management function (AMF) or the session management function (SMF) can play a role in the ProSe discovery procedure. In the interaction between the WTRU and the ProSe function (e.g., the network), a control plane path can be used. The WTRU can interact with the ProSe function via the user plane (e.g., additionally and / or alternatively).

[0093] FIG. 5 shows an example related to WTRU - to - WTRU discovery via a relay WTRU. The exemplary implementation shown in FIG. 5 has a discovery when it conforms to Model A. FIG. 5 shows an exemplary process in which a service - using WTRU (WTRU2) can discover a service - provider WTRU (WTRU1) via a relay WTRU (WTRU3).

[0094] Referring to FIG. 5, at 1, the relay WTRU (WTRU3) can communicate a discovery request to a network function / entity (e.g., the ProSe function). The discovery request can include the service ID of the service, for which the relay can act / operate as a relay. For example, the discovery request can include the service ID of the ProSe application, for which the relay WTRU can act as a relay. The service ID of the ProSe application can be the ProSe application ID. The discovery request can include a relay WTRU ID (relay identifier) (e.g., subscription permanent identifier (SUPI), ProSe relay ID, international mobile subscriber identifier (IMSI), etc.) that identifies the relay WTRU. The discovery request can include an indication (e.g., information element) that the relay WTRU is configured and / or operating as a relay for a (e.g., specific or identified) service. This indication (e.g., information element) can indicate the WTRU-WTRU relay function. The relay WTRU can operate as a relay for multiple services (e.g., simultaneously or in parallel). The discovery request (e.g., message) can include multiple service IDs (e.g., multiple ProSe application IDs). The indication of the function acting as a relay can notify the network that the relay WTRU can operate / function as a relay for multiple services (e.g., simultaneously) and / or is operating / functioning.

[0095] In 2, the ProSe function can, for example, after processing a discovery request message from a relay WTRU, respond to the relay WTRU (e.g., in a discovery response). The discovery response message can include a ProSe broadcast code and / or a discovery filter for a service that may be identified in the discovery request. The broadcast code may be a ProSe relay code and may also be referred to as a relay service broadcast code. The discovery response can include multiple ProSe broadcast codes (relay service broadcast codes) and discovery filters, for example, when the discovery request identifies multiple services for which the relay WTRU can operate as a relay. The discovery response can include one or more broadcast rules and / or one or more discovery filters for each service identified in the discovery request. The ProSe function may not (e.g., determine not to) assign a broadcast code (relay service broadcast code) and / or a discovery filter to one or more services that were requested (e.g., by the relay WTRU) but were rejected (e.g., by the ProSe function). The discovery response can include an indication (e.g., a rejection code, a cause code, or an information element) for a service for which the ProSe function did not assign a broadcast code (relay service broadcast code) and / or a discovery filter. The discovery response can associate a rejection code or a similar code with the service ID of the service for which the broadcast code and / or the discovery filter were not assigned.

[0096] In 3, the relay WTRU can store one or more discovery filters, one or more corresponding broadcast codes (e.g., a ProSe relay code (relay service broadcast code)), and / or related service IDs from the discovery response (e.g., based on / responding to receiving a discovery response message from the ProSe function). The relay WTRU can start discovery (e.g., on PC5) by monitoring, for example, using the received discovery filters.

[0097] The service - using WTRU (WTRU2) and the service - provider WTRU (WTRU1) can execute a discovery procedure using the ProSe function. In 4, the service - using WTRU (WTRU2) can communicate a discovery request to the ProSe function. The service - using WTRU (WTRU2) can receive a response that may include a discovery filter. In 5, the service - using WTRU can start a monitoring process and use the received discovery filter to listen for the codes broadcast.

[0098] In 6, the service - provider WTRU (WTRU1) can communicate a discovery request to the ProSe function and can receive a response that can include a ProSe broadcast code, which may be called a service broadcast code. The received ProSe broadcast code (service broadcast code) may be a ProSe application code. In 7, the service - provider WTRU (WTRU1) can broadcast (e.g., start a broadcast) the received ProSe broadcast code, for example, a ProSe application code (service broadcast code). The service - using WTRU can monitor and listen for the broadcast code (service broadcast code) using the received discovery filter.

[0099] The relay WTRU can monitor the ProSe broadcast code (service broadcast code) broadcast by the service provider WTRU using a discovery filter (e.g., received from the ProSe function during the discovery procedure of the relay WTRU). Referring to FIG. 5, at 8, the relay WTRU can monitor and detect / discover the ProSe broadcast code (service broadcast code) broadcast by the service provider WTRU if, for example, the received ProSe broadcast code (service broadcast code) meets or matches one or more discovery filters. The relay WTRU can detect the ProSe broadcast code (service broadcast code) from the service provider WTRU (WTRU1). The relay WTRU can, for example, based on the detection of the ProSe broadcast code (service broadcast code), initiate the broadcast of a ProSe relay code (relay service broadcast code) (e.g., received from the ProSe function during discovery). The discovery of the broadcast code (service broadcast code) from the service provider WTRU can function as a trigger for the relay WTRU to inform about the ProSe relay code (relay service broadcast code).

[0100] At 9, the service usage WTRU can discover or detect the ProSe relay code (relay service broadcast code) broadcast by the relay WTRU using a discovery filter (e.g., received from the ProSe function during discovery by the service usage WTRU). The service usage WTRU can, for example, communicate a match report to the ProSe function in response to the detection of the ProSe relay code (relay service broadcast code) of the relay WTRU.

[0101] In some examples, the ProSe code (service broadcast code) (e.g., ProSe application code) received / broadcast by a service provider WTRU may be different from the ProSe code (e.g., ProSe relay code (relay service broadcast code)) received / broadcast by a relay WTRU. In some examples, the ProSe function may assign the same code to the relay WTRU and the service provider WTRU. The relay WTRU may broadcast additional information (e.g., via the PC5 interface) along with the ProSe code (e.g., when the relay WTRU and the service provider WTRU are assigned the same code) to indicate, for example, that the code is being broadcast by the relay WTRU.

[0102] Service discovery can be performed, for example, using a relay WTRU. The relay WTRU can request and broadcast a ProSe relay code (relay service broadcast code) for a ProSe relay service. The relay WTRU can monitor the ProSe service to be relayed. The relay WTRU can report the available ProSe services relayed to the ProSe function. A service-using WTRU can discover a specific ProSe service, for example, by querying the ProSe function. The ProSe function can respond, for example, by providing the ProSe relay code (relay service broadcast code) of a relay WTRU that is configured to report (e.g., previously discovered) ProSe services and / or relay ProSe services. The service-using WTRU can discover the relay WTRU, for example, by listening for the ProSe relay code (relay service broadcast code).

[0103] The relay WTRU can request a ProSe relay service from the ProSe function. The request can indicate a ProSe service for which the relay WTRU can operate as a relay. For example, the request can include a list of one or more ProSe application IDs corresponding to the service for which the relay WTRU can operate as a relay.

[0104] The relay WTRU can receive a ProSe relay code (relay service broadcast code) for the ProSe relay service (e.g., in response to a request). The relay WTRU can start broadcasting the ProSe relay code (relay service broadcast code). The relay WTRU can broadcast the ProSe relay code (relay service broadcast code) after detecting, for example, an available ProSe code to be relayed. For example, the relay WTRU can start broadcasting the ProSe relay code (relay service broadcast code) after detecting a ProSe application code (service broadcast code) broadcast by a service provider WTRU.

[0105] The relay WTRU can receive a discovery filter for the relayed ProSe service (e.g., from the ProSe function). The relay WTRU can use the filter to monitor ProSe application codes on an interface discovery (e.g., PC5). The relay WTRU can detect a ProSe application code (service broadcast code) that matches or otherwise satisfies the received discovery filter. The relay WTRU can report one or more discovered ProSe services that are relayed (e.g., to the ProSe function).

[0106] The service - using WTRU can generate a request to discover ProSe services and send it to the ProSe function. This request can specify the discovery of relayed ProSe relay services. The service - using WTRU can receive, as a response, one or more discovery filters for ProSe application codes (service broadcast codes) (e.g., broadcast by one or more service - provider WTRUs) and one or more discovery filters for ProSe relay codes (relay service broadcast codes) (e.g., broadcast by one or more relay WTRUs). The service - using WTRU can monitor ProSe application codes (service broadcast codes) and ProSe relay codes (relay service broadcast codes) on an interface discovery (e.g., PC5) using, for example, the received filters.

[0107] The service - using WTRU can report the discovered ProSe relay service to the ProSe function, for example, when the detected ProSe relay code (relay service broadcast code) matches the discovery filter. The service - using WTRU can receive a ProSe application ID from the relay WTRU. The service - using WTRU can receive one or more relay validity timers for the (e.g., respective) ProSe application IDs received from the relay WTRU. The timer can indicate, for example, how long the corresponding ProSe application ID is valid at the relay WTRU that is the source of the received ProSe application ID. The service - using WTRU can send a match report request to re - request a valid ProSe application ID, for example, when the relay validity timer expires.

[0108] The ProSe function can receive ProSe relay service requests from a relay WTRU. The ProSe function can assign a ProSe relay code (relay service broadcast code) to the ProSe relay service (e.g., in response to a request). The ProSe function can receive a list of ProSe application IDs relayed from the relay WTRU. The ProSe function can communicate a discovery filter for the ProSe relay code (relay service broadcast code) and the list of ProSe application IDs to the relay WTRU.

[0109] The ProSe function can receive a match report from the relay WTRU. The match report can include one or more ProSe application codes (service broadcast codes). The ProSe function can identify and store, for example, the list of ProSe application IDs discovered by the relay WTRU based on the received ProSe application codes.

[0110] The ProSe function can receive a monitoring request from a service-using WTRU. The monitoring request can include a ProSe application ID. The monitoring request can indicate that it is for discovering the ProSe service relayed by this request. The ProSe function can provide a discovery filter for the ProSe relay code (relay service broadcast code) to the service-using WTRU. The ProSe function can determine a relay WTRU (e.g., the relay WTRU that discovered the ProSe service) that can provide a relay service for the ProSe application ID, and can provide one or more discovery filters for the ProSe relay code (relay service broadcast code) of the determined relay WTRU.

[0111] The ProSe function can receive a match report from a service-using WTRU. The match report can include a ProSe relay record (relay service broadcast code). The ProSe function can identify a relay WTRU and provide a list of ProSe application IDs that can be relayed by the relay WTRU. The ProSe function can perform a MIC check, for example, when it receives a match report. The ProSe function can provide a relay validity timer for the service-using WTRU (e.g., for each) ProSe application ID. The relay validity timer can indicate how long the ProSe application ID is valid for the corresponding relay WTRU.

[0112] Figure 6 shows an example of relay WTRU service discovery. As shown in Figure 6, the service provider WTRU can execute an advertisement request procedure. The service provider WTRU can broadcast a ProSe application code for the provided ProSe service. At 1, the relay WTRU can send a discovery request message, which can include a relay service indication and a list of ProSe application IDs to be relayed. At 2, the ProSe function can send a discovery response message, which can include a ProSe relay record and a discovery filter for the ProSe application code of the ProSe application ID. The relay WTRU can receive the ProSe relay record. At 3, the relay WTRU can broadcast the ProSe relay record to announce the relay service.

[0113] At 4, the relay WTRU starts listening for ProSe application codes (e.g., on the PC5 interface) to determine, for example, whether there is a ProSe service available for relaying near the relay WTRU. At 5, the relay WTRU can determine whether the received ProSe application code matches or otherwise satisfies the discovery filter. The relay WTRU can find and discover available ProSe services (e.g., the relay WTRU can detect a ProSe application code that matches the filter). At 6, the relay WTRU can send a match report, which may include the detected ProSe application code and the relay WTRU ID. At 7, the ProSe function can determine the ProSe application ID, for example, based on the received ProSe application code. The ProSe function can store a list of ProSe service IDs for the relay WTRU. At 8, the ProSe function can send a match report positive acknowledgment (Ack) to the relay WTRU.

[0114] At 9, the service-using WTRU can request to discover a ProSe service that can be identified by the ProSe application ID. The service-using WTRU can send a discovery request, which can include, for example, the ProSe application ID, a monitoring request, and / or a requested relay service indication. At 10, the ProSe function can determine which relay WTRU can be adapted to relay the service requested by the service-using WTRU. At 11, the ProSe function can send a discovery response, which can include a discovery filter for the relay WTRU (e.g., a ProSe relay code) and a discovery filter for the service provider WTRU (e.g., a ProSe application code). At 12, the service-using WTRU can start listening for ProSe application codes and ProSe relay codes.

[0115] At 13, the service - using WTRU can match the detected ProSe application code or ProSe relay record with the received discovery filter information. The service - using WTRU can send a match report to the ProSe function (e.g., in response to the detection of a match). At 15, the ProSe function can send a match report Ack message to the service - using WTRU. This message can include available ProSe services relayed by a relay WTRU. For example, this message can include the ProSe application ID discovered by the relay WTRU.

[0116] The WTRU - to - WTRU discovery process can be security - implemented. The monitoring WTRU (M - WTRU) may be located outside the range of the advertising WTRU (A - WTRU) and may not be arranged to discover the advertising WTRU (A - WTRU) without the assistance of a relay WTRU. A WTRU - to - WTRU relay, e.g., a relay WTRU (R - WTRU), performs an enhanced open discovery procedure to enable the monitoring WTRU (M - WTRU) to discover services provided by the advertising WTRU (A - WTRU) via the relay WTRU (R - WTRU), while providing security that is equivalent to or better than the security provided by the open discovery procedure that may not use the relay WTRU (R - WTRU).

[0117] A relay WTRU can generate a discovery request and communicate the discovery request to an HPLMN ProSe function. The discovery request can include a ProSe app ID that can correspond to a service provided by the originating WTRU. The discovery request can indicate that the relay WTRU intends to function as a relay for a (e.g., indicated) service. The relay WTRU can receive a relay Prose app code (e.g., ProSe app ID) that can map to the originating WTRU service and a relay discovery key that can be used to protect the relay Prose app code during transmission over an (e.g., PC5) interface. The relay WTRU can receive a discovery filter that can include a ProSe app code used by the originating WTRU, a discovery key, and / or one or more time-related parameters for security checking of a (e.g., PC5) message from the originating WTRU.

[0118] The relay WTRU can use a discovery filter to detect, for example, a ProSe application code transmitted by an originating WTRU in a first (e.g., PC5) discovery message. The message may be received with a first MIC. The relay WTRU can check the (e.g., PC5) discovery message for integrity and freshness by, for example, using a discovery key and received time-related parameters to (e.g., locally) verify the MIC. The relay WTRU can include the relayed ProSe application code in a second (e.g., PC5) discovery message (e.g., if the discovery message passes a security check). The relay WTRU can protect the message by, for example, calculating a second MIC using a relayed discovery key and time-based parameters. The relay WTRU can transmit the second (e.g., PC5) message with the second MIC for co-discovery. The monitoring WTRU can detect the relayed ProSe application code and complete the discovery procedure. The relay record value may be the same as the non-relay record, for example, except for one or more reserved bits. The reserved bits, if set, can enable identification as a relay record and (e.g., a single) discovery filter, and the discovery filter can include a ProSe application mask configured to match non-relay records associated with the relay record. The (e.g., single) discovery filter can be provided to the monitoring WTRU.

[0119] Figure 7 shows an example related to secure open discovery using a relay WTRU. Referring to Figure 7, at 1, the announcing WTRU can generate a discovery request and communicate the request to the ProSe function. The discovery request can include a ProSe app ID (in addition to other parameters, for example). At 2 and 3, the ProSe function can permit the announcing WTRU. At 4, the announcing WTRU can receive a discovery response from the ProSe function. The discovery response can include a discovery key, in addition to, for example, a ProSe app code, the current time, a maximum offset, and / or a validity timer.

[0120] At 5, the announcing WTRU can initiate an announcement of the ProSe app code in a (for example, PC5) message. The announcing WTRU can calculate the MIC of the message using, for example, the discovery key and a (for example, UTC) time-based counter. The announcing WTRU can transmit the calculated MIC together with the announcement message.

[0121] At 6, the relay WTRU can initiate a discovery procedure as a WTRU-to-WTRU relay using the HPLMN ProSe function. The relay WTRU can generate a discovery request that can include the same ProSe app ID used by the announcing WTRU. The relay WTRU can indicate an intention to operate as a relay WTRU (in the value within the command field, for example), as opposed to, for example, the announcing WTRU or the monitoring WTRU, which can be selectable options for each WTRU. The relay WTRU can use a separate "relay" indication to notify the ProSe function that it attempts to relay the service provided by the relay WTRU.

[0122] In 7, the relay ProSe function can send a message that may include the ProSe app ID (e.g., along with a relay indication) to a second ProSe function (e.g., a local PLMN ProSe function, an informed WTRU HPLMN ProSe function) in another PLMN, for example, when the ProSe app ID has a PLMN-specific scope. In 8, the second ProSe function can return, for example, a relay discovery key, a relay ProSe app code, a discovery filter (e.g., having the same ProSe app code and related discovery key provided to the informed WTRU), and / or a time-related parameter.

[0123] In 9, the relay WTRU can receive a relay discovery key and a relay ProSe app code in a discovery response message from the ProSe function. This message can include a discovery filter having the same ProSe app code and related discovery key provided to the informed WTRU, and one or more time-related parameters. The relay WTRU can receive multiple discovery filters. Each discovery filter can include, for example, a code and a key for a given service, for example, when multiple informed WTRUs announce the same service.

[0124] In 10, the relay WTRU can receive a discovery message (e.g., over PC5), for example, along with an MIC from the informed WTRU. The relay WTRU can detect a match with the ProSe app code, for example, using a discovery filter.

[0125] In 11, the relay WTRU can check (e.g., locally check) the integrity and freshness of the message, for example, using the MIC, the discovery key, and / or the time-related parameter.

[0126] (For example, PC5) The discovery message may pass the security check. The relay WTRU can include the relay ProSe application code in the (e.g., PC5) message, calculate the MIC for the discovery message using the relay discovery key, and transmit that message with the MIC for co-discovery. The monitoring WTRU can detect the relay ProSe application code, for example, as part of the procedure to discover the services provided by the informing WTRU. As shown in Figure 7, at 12, the relay WTRU can start the relay code notification.

[0127] In some (e.g., additional and / or alternative) examples, the security check of the (e.g., PC5) discovery message from the informing WTRU can be performed, for example, by the ProSe function (e.g., not locally by the relay WTRU). The relay WTRU can start the discovery procedure. The relay WTRU can receive, in the discovery response message, the discovery filter for the same ProSe application code provided to the informing WTRU. This message may not include the discovery key, the relay discovery key, and / or the relay ProSe application code.

[0128] The relay WTRU can receive the (e.g., PC5) message for co-discovery with the MIC from the informing WTRU. The relay WTRU can detect a match with the ProSe application code, for example, using the discovery filter. The relay WTRU can determine that the MIC check can be performed by the ProSe function (e.g., not locally by the relay WTRU) (e.g., based on the absence of the provided discovery key). The relay WTRU can transmit the ProSe application code and the MIC to the ProSe function (e.g., in a match report message).

[0129] The ProSe function can obtain a discovery key, for example, using a ProSe application code. The ProSe function can check the MIC using the discovery key. The ProSe function can (for example, if the MIC check is successful) send a relay ProSe application code and a relay discovery key (for example, in a match report positive response message), and the relay WTRU can receive them. The relay WTRU can include the relay ProSe application code, for example, in a protected (for example, PC5) discovery message as described herein.

[0130] The monitoring WTRU may be configured to use (for example, selectively) the relay WTRU, for example, during discovery of services from the informing WTRU. The monitoring WTRU can, for example, lower the priority of or ignore a discovered relay WTRU if the monitoring WTRU is within the range of the informing WTRU. The monitoring WTRU can ignore a "noisy" relay. The monitoring WTRU can discover the relay WTRU and the informing WTRU and can use both in combination. The monitoring WTRU can use redundant communication links, for example, for in-motion service reliability and / or service continuity.

[0131] The monitoring WTRU can discover (e.g., attempt to discover or decide to discover) the announcing WTRU while it is within the range of both the announcing WTRU and the relay WTRU. The monitoring WTRU can delay the transmission of a match report (e.g., using a relay usage threshold timer), for example, if the monitoring WTRU detects that the relay ProSe application code could be from the relay WTRU. The monitoring WTRU can transmit a match report (e.g., including the relay ProSe application code from the relay WTRU) when, for example, the relay usage threshold timer expires. The monitoring WTRU can transmit a match report (e.g., immediately) if, for example, the monitoring WTRU detects a ProSe application code from the announcing WTRU. The monitoring WTRU can stop the relay usage threshold timer (e.g., if it is running) when transmitting (e.g., at the time of transmission).

[0132] Figure 8 shows an example of discovery prioritization (e.g., prioritization of isolated direct discovery). Figure 8 shows an example of an open flow that uses WTRU - to - WTRU relay for co - discovery with a delayed match report by the monitoring WTRU. Referring to Figure 8, at 0, the announcing WTRU and the relay WTRU can each start a discovery procedure using their respective ProSe functions. The discovery procedure can be similar to one or more other discovery procedures described herein.

[0133] At 1, the monitoring WTRU can send a ProSe application ID and a relay discovery indication in a discovery request to the monitoring WTRU's HPLMN ProSe function. The relay discovery indication can notify the network that the monitoring WTRU can perform (e.g., has decided to perform) service discovery regarding the use of a relay WTRU. This indication can communicate one or more operation modes, which can include, for example, "no relay WTRU" and "with relay WTRU". The "no relay WTRU" mode can indicate that the monitoring WTRU can perform service discovery without a relay WTRU. The application / service may involve or include separate communication.

[0134] The "Relay WTRU present" mode can indicate that the monitoring WTRU can use a relay WTRU in the discovery process. This indication can notify the network that the monitoring WTRU may (e.g., has determined to) prioritize separate (e.g., non-relayed) communications. There can be one or more (e.g., selectable) prioritization procedures. The prioritization can be based on the WTRU (e.g., WTRU-specific). The prioritization can use a timer. The prioritization can be network-controlled. The prioritization can include (e.g., use) multiple matching reporting procedures. The prioritization procedure can be selected (e.g., by the network). The prioritization can be selected based on, for example, the ProSe application ID and / or network policy. The WTRU (e.g., the monitoring WTRU) can be notified of which prioritization procedure to select / perform based on, for example, the content of the discovery response message.

[0135] In 2, the monitoring WTRU ProSe function can send a message including the ProSe application ID and / or relay discovery indication (e.g., when the ProSe application ID has a PLMN-specific scope) to a second ProSe function (e.g., local PLMN ProSe function, informing WTRU HPLMN ProSe function) in another PLMN.

[0136] In 3, the second ProSe function can return a discovery filter and a relay discovery filter associated with the ProSe ID. The relay discovery filter can include, for example, a relay ProSe application code, a relay service flag, and / or a relay matching report (RMR) transmission timer.

[0137] In 4, the monitoring WTRU can receive a discovery filter and a relay discovery filter that can be associated with a ProSe app ID. The relay discovery filter can include, for example, a relay ProSe app code, a relay flag, and / or an RMR transmission timer. The monitoring WTRU can be provided with a (e.g., single) discovery filter that can include a ProSe application mask that can match (e.g., is configured to match) relay records and non-relay records. For example, the ProSe application mask can include the same relay record values as the non-relay records (e.g., except for certain reserved "relay" bits that can be set).

[0138] In 5, the monitoring WTRU can listen for a relay ProSe app code and / or a ProSe app code.

[0139] In 6, the monitoring WTRU can start an RMR transmission timer, for example, when the monitoring WTRU detects a relay ProSe app code from a relay WTRU (e.g., via the PC5 interface).

[0140] In 7, the monitoring WTRU can stop a running RMR transmission timer, for example, when the monitoring WTRU detects a ProSe app code from an informing WTRU (e.g., via the PC5 interface).

[0141] In 8, the monitoring WTRU can send a match report message that includes the ProSe app code, for example, when the ProSe app code is received (e.g., via PC5). The monitoring WTRU can send a match report that includes the relay ProSe app code, for example, when the RMR transmission timer expires.

[0142] In 9, the monitoring WTRU can receive a match report positive response that may include a ProSe application ID and / or a relay flag. The flag can indicate whether the ProSe application ID is mapped to a relay ProSe application code. The monitoring WTRU can store (e.g., locally) the mapping between the ProSe application ID and the relay ProSe application code or the ProSe application code.

[0143] The monitoring WTRU can send a match report (e.g., unconditionally and / or without delay) when, for example, the monitoring WTRU detects a relay ProSe application code or a ProSe application code. The monitoring WTRU can receive a discovery response message that can include an indication notifying the WTRU that the network is requesting the WTRU to report relay records and non-relay records (e.g., if detected).

[0144] The monitoring WTRU can detect and report a first code (e.g., a relay record). The monitoring WTRU can continue to monitor a second code (e.g., a non-relay record) (e.g., after detecting the first code). The monitoring WTRU can send a second report when, for example, the second code is detected. The monitoring WTRU can determine to continue monitoring the second code based on, for example, an indication from the ProSe function (e.g., within the first match report Ack). The WTRU can continue monitoring when, for example, the detected first code is a relay record. The WTRU can stop monitoring when, for example, the first code is a non-relay record.

[0145] The monitoring WTRU can send a match report (e.g., when the monitoring WTRU detects a second code). The monitoring WTRU can receive mapping control information (e.g., in a match report Ack) that indicates how to process the mapping between the detected code and the ProSe application ID. This information can be used to notify the WTRU to store multiple mappings or hold only one. The mapping control information can include, for example, priorities assigned to each of the multiple (e.g., both) codes when mappings for the multiple codes are stored. The code priorities can be used (e.g., by the monitoring WTRU) to select, for example, the informing WTRU and / or the relay WTRU to utilize the service. For example, the monitoring WTRU can use the non-relay code together with the relay code as a backup (e.g., and may be instructed to do so), or vice versa (e.g., to set up direct communication with one or both). The mapping control information can be used to notify the monitoring WTRU to override the existing code mapping (e.g., override the relay code mapping with the non-relay code mapping) when one mapping is used (e.g., determined to be used). The monitoring WTRU can receive, for example, a report match rejection for the reported second code (e.g., the relay code reported after the non-relay code) (e.g., additionally and / or alternatively) when the monitoring WTRU uses only one code mapping.

[0146] Figure 9 shows an example related to the monitoring WTRU performing a (e.g., optional) discovery procedure for the informing WTRU and / or the relay WTRU (e.g., as described herein).

[0147] Disclosed herein are systems, methods, and means for WTRU - to - WTRU discovery via a relay WTRU. The relay WTRU can send a discovery request to a Proximity Services (ProSe) server. The discovery request can include, for example, a service identifier (ID), a relay function indication, and / or a relay WTRU ID. The relay WTRU can receive a response that includes a discovery filter corresponding to a broadcast code and / or a service ID. The relay WTRU can use the discovery filter to listen for ProSe codes that can be broadcast by a service - provider WTRU. The relay WTRU can broadcast a ProSe code received from the ProSe server, for example, when the relay WTRU detects a ProSe code corresponding to a service - provider WTRU. A service - consuming WTRU can listen for the relay WTRU and receive the ProSe code. The service - consuming WTRU can use the relay WTRU to request a service from the service - provider WTRU, for example, based on receiving (and using, for example) the ProSe code.

[0148] Exemplary embodiments are disclosed, but it will be understood that the scope of potential embodiments is not limited to those explicitly described. For example, the system has been described with reference to 3GPP, 5G, and / or NR network layers, but the envisioned embodiments extend beyond implementations using specific network - layer technologies. Similarly, potential implementations extend to all types of service - layer architectures, systems, and embodiments. The techniques described herein can be applied independently and / or used in combination with other resource - configuration techniques.

[0149] It is understood that the entity that executes the process described in this specification can be a logical entity implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device, a network node, or a computer system and executed on its processor. That is, the process may be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or a network node such as a node or a computer system, and when these computer-executable instructions are executed by the processor of the node, the described process is executed. Also, it is understood that any transmission and reception processes shown in the drawings can be executed by the communication circuit of the node under the control of the processor of the node and the computer-executable instructions (e.g., software) that it executes.

[0150] The various technologies described herein may be implemented in relation to hardware or software, or a combination of both as required. Accordingly, implementations of the subject matter described herein, apparatuses, or specific aspects or portions thereof, may take the form of program code (e.g., instructions) embodied in a tangible medium including any other machine-readable storage medium, where the program code, when loaded and executed on a machine such as a computer, causes the machine to be an apparatus for implementing the subject matter described herein. When the program code is stored in a medium, the program code may be stored in one or more media that together execute the operations, i.e., the one or more media together contain the code for performing the operations, although when there are two or more single media, there is no need to store a particular portion of the code on a particular medium. In the case of program code execution on a programmable device, a computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in relation to the subject matter herein, for example, through the use of an API, reusable controls, etc. Such programs are preferably implemented in a high-level procedural or object-oriented programming language for communicating with a computer system. However, the programs may be implemented in assembly language or machine language as required. In any case, the language may be a compiled or interpreted language and may also be combined with a hardware implementation.

[0151] Exemplary embodiments may refer to utilizing aspects of the subject matter described herein in the environment of one or more stand-alone computing systems, but the subject matter described herein is not so limited and may rather be implemented in connection with any computing environment such as a network or distributed computing environment. Further, aspects of the subject matter described herein may be implemented within or across multiple processing chips or devices, and storage may similarly be affected across multiple devices. Such devices may include, by way of example, personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles or airplanes.

[0152] In describing preferred embodiments of the subject matter of this disclosure, specific terms are used for clarity, as shown in the drawings. However, the claimed subject matter is not intended to be limited to the specific terms so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

A relay wireless transmit / receive unit (WTRU), comprising: at least:[ sending a discovery request to a network function, the discovery request indicating that the relay WTRU is configured to operate as a relay for discovery of at least one service; receiving a discovery response from the network function, the discovery response comprising a key associated with a relay service code; receiving service discovery information from a second WTRU, the service discovery information being associated with a proximity service; sending a discovery message comprising the service discovery information and the relay service code to at least a third WTRU, the discovery message being protected using the key associated with the relay service code; A relay WTRU comprising a processor configured to perform the above. Claim 2 The relay WTRU according to claim 1, wherein the processor configured to receive the service discovery information from the second WTRU is configured to receive a discovery message comprising a service code from the second WTRU. Claim 3 The relay WTRU according to claim 2, wherein the processor is further configured to check the discovery message for integrity and freshness. Claim 4 The relay WTRU according to claim 2 or 3, wherein the service code is associated with a ProSe service. Claim 5 The relay WTRU according to any one of claims 1 to 4, wherein the processor configured to send the discovery message comprising the service discovery information and the relay service code to at least the third WTRU is configured to send a second discovery message to at least the third WTRU. Claim 6 The relay WTRU according to claim 5, wherein the processor configured to send the discovery message to at least the third WTRU is configured to send a notification to at least the third WTRU. **Claim 7**: A relay wireless transmit / receive unit (WTRU) transmits a discovery request to a network function, the discovery request indicating that the relay WTRU is configured to operate as a relay for discovery of at least one service. The relay WTRU receives a discovery response from the network function, the discovery response comprising a key associated with a relay service code. The relay WTRU receives service discovery information from a second WTRU, the service discovery information being associated with a proximity service. The relay WTRU transmits a discovery message comprising the service discovery information and the relay service code to at least a third WTRU, the discovery message being protected using the key associated with the relay service code. A method comprising the above. **Claim 8** Receiving the service discovery information from the second WTRU comprises receiving a discovery message comprising a service code from the second WTRU, according to the method of Claim 7. **Claim 9** The method of Claim 8 further comprises checking the discovery message for integrity and freshness. **Claim 10** The service code is associated with a ProSe service, according to the method of Claim 8 or 9. **Claim 11**: Transmitting the discovery message comprising the service discovery information and the relay service code to at least the third WTRU comprises transmitting a second discovery message to at least the third WTRU, according to any one of Claims 7 to 10. **Claim 12**: Transmitting the discovery message to at least the third WTRU comprises transmitting a notification to at least the third WTRU, according to the method of Claim 11.

Images