Method and apparatus for direct discovery and communication using a WTRU to WTRU relay

Abstract

Methods, apparatuses, systems, architectures, and interfaces are provided for establishing extended unicast links and managing unicast links performed by a relay radio transmit / receive unit (R-WTRU) including a transmitter, a receiver, a memory, and a processor. The method includes: performing, by the R-WTRU, a link establishment procedure to establish any number of extended unicast links for relaying traffic between a serving provider WTRU (SP-WTRU) and any number of serving user WTRUs (SU-WTRUs) according to a mapping generated by the R-WTRU, the link establishment procedure including: (1) generating a mapping of any of the extended links and layer 2 (L2) identifiers (IDs) for any of the SP-WTRU, the R-WTRU, and any number of the SU-WTRUs, and (2) transmitting a unique relay ID; establishing a management unicast link for the extended unicast link; and applying any number of link management requests received via the management unicast link to the associated extended unicast link.

Description

BACKGROUND OF THE INVENTION

[0001] The present invention relates to the field of communications, and more particularly, to methods, devices, systems, architectures, and interfaces for communications in advanced or next-generation wireless communication systems, including communications using New Radio and / or New Radio (NR) access technologies and communication systems. Such communication systems may include relay communications performed by wireless communication relays and vehicle-to-everything (V2X) services and Proximity Services (ProSe). BRIEF DESCRIPTION OF THE DRAWINGS

[0002] In addition, the same reference numerals in the figures indicate the same elements, and in which:

[0003] Figure 1A is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0004] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in Figure 1A accordance with an embodiment;

[0005] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system shown in Figure 1A accordance with an embodiment;

[0006] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that may be used within the communication system shown in Figure 1A accordance with an embodiment;

[0007] Figure 1E is a block diagram showing various example elements of an example communication system;

[0008] Figure 1F is a block diagram showing an example architecture of an example communication system;

[0009] Figure 2 is a diagram showing Release 16 (Rel-16) vehicle-to-everything (V2X) link establishment;

[0010] Figure 3 is a diagram showing the control plane of eV2X in the PC5 interface;

[0011] Figure 4 is a diagram showing the user plane of eV2X in the PC5 interface;

[0012] Figure 5 is a diagram showing the link identifier update process;

[0013] Figure 6 is a diagram showing a WTRU-to-WTRU relay scenario;

[0014] Figure 7 is a diagram showing a high-level view of transparent relaying according to an embodiment;

[0015] Figure 8 is a diagram showing a control plane protocol stack supporting non-transparent WTRU-to-WTRU relaying according to an embodiment;

[0016] Figure 9 is a diagram showing a user plane protocol stack supporting non-transparent WTRU-to-WTRU relaying according to an embodiment;

[0017] Figure 10 is a diagram showing a service-oriented discovery process using non-transparent WTRU-to-WTRU relaying according to an embodiment;

[0018] Figure 11 is a diagram showing an enhanced link identifier update process using a non-transparent R-WTRU according to an embodiment;

[0019] Figure 12 is a diagram showing an enhanced link identifier update process using a non-transparent R-WTRU according to an embodiment;

[0020] Figure 13 is a diagram showing a control plane stack supporting a transparent R-WTRU according to an embodiment;

[0021] Figure 14 is a diagram showing a user plane stack supporting a transparent R-WTRU according to an embodiment;

[0022] Figure 15 is a diagram showing discovery and unicast link establishment according to an embodiment;

[0023] Figure 16 is a diagram showing discovery and unicast link establishment according to an embodiment;

[0024] Figure 17 is a diagram showing a second unicast link establishment according to an embodiment;

[0025] Figure 18 is a diagram showing a link identifier update process (single management link) initiated by an SP-WTRU on all WTRUs according to an embodiment;

[0026] Figure 19is a diagram showing a link identifier update procedure (multiple management links) initiated by an SP-WTRU on all WTRUs according to an embodiment.

[0027] Example network for implementation of an embodiment

[0028] Figure 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 multi-access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may 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 filtered OFDM, and filter bank multicarrier (FBMC), etc.

[0029] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any one of the WTRUs 102a, 102b, 102c, 102d may be referred to as a "station" and / or "STA", which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (such as remote surgery), an industrial device and application (such as a robot and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, and a device operating on a commercial and / or industrial wireless network, etc. Any one of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0030] The communication system 100 may further include base station 114a and / or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (such as CN 106 / 115, the Internet 110, and / or other networks 112) by wirelessly docking with at least one of the WTRUs 102a, 102b, 102c, 102d in a wireless manner. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a home Node B, a home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), and a wireless router, etc. Although each of the base stations 114a, 114b is described as a single component, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0031] Base station 114a may be part of RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies in a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a relatively fixed or possibly time-varying specific geographical area. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals can be transmitted and / or received in a desired spatial direction.

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

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

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a certain radio technology, such as evolved UMTS terrestrial radio access (E-UTRA), where the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish the air interface 116.

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

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

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

[0038] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can use any suitable RAT to facilitate wireless connections in a local area, such as business premises, residences, vehicles, campuses, industrial facilities, air corridors (e.g., for drones), and roads, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can establish a pico cell or a femto cell by using a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As Figure 1A shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106 / 115.

[0039] The RAN 104 / 113 can communicate with the CN 106 / 115, and the CN 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 the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, etc. The CN 106 / 115 can provide call control, accounting services, location-based services, prepaid calls, Internet connections, video distribution, etc., and / or can perform advanced security functions such as user authentication. Although not shown in Figure 1A , it should be understood that the RAN104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 that uses the NR radio technology, the CN 106 / 115 can also communicate with other RANs (not shown) that use GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technologies.

[0040] CN 106 / 115 can also act as a gateway for the WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global interconnected computer network device system that uses common communication protocols (such as TCP, UDP, and / or IP in the TCP / IP Internet protocol family). The network 112 may include a wired or wireless communication network owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, where the one or more RANs may use the same RAT or a different RAT as the RAN 104 / 113.

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

[0042] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive component 122, a speaker / microphone 124, a numeric 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 peripheral devices 138. It should be understood that the WTRU 102 may also include any sub-combination of the foregoing components while remaining compliant with the embodiments.

[0043] 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), and a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120, and the transceiver 120 can be coupled to a transmit / receive component 122. Although Figure 1B the processor 118 and the transceiver 120 are described as separate components, it should be understood that the processor 118 and the transceiver 120 can also be integrated together in an electronic component or chip.

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

[0045] Although in Figure 1B the transmit / receive component 122 is described as a single component, the WTRU 102 can include any number of transmit / receive components 122. More specifically, the WTRU 102 can use MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals via the air interface 116.

[0046] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive component 122 and demodulate the signals received by the transmit / receive component 122. As described above, the WTRU 102 can have multi-mode capabilities. Therefore, the transceiver 120 can include multiple transceivers that allow the WTRU 102 to communicate using multiple RATs (e.g., NR and IEEE 802.11).

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

[0048] The processor 118 can receive power from a power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 can include one or more dry battery packs (such as nickel cadmium (Ni-Cd), nickel zinc (Ni-Zn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, and fuel cells, and so on.

[0049] The processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (such as longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement for the information from the GPS chipset 136, the WTRU 102 can receive location information from a base station (such as base stations 114a, 114b) via an air interface 116, and / or determine its location based on the signal timing received from two or more nearby base stations. It should be understood that the WTRU 102 can obtain location information by means of any suitable positioning method while remaining in compliance with the embodiments.

[0050] The processor 118 may also be coupled to other peripheral devices 138, where the peripheral devices 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 device 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game console module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, and an activity tracker, among others. The peripheral device 138 may include one or more sensors, and the sensors may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographical location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor, etc.

[0051] The WTRU 102 may include a full-duplex radio device, where for this radio device, the reception or transmission of some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio device may include an interference management unit that reduces and / or substantially eliminates self-interference either by means of hardware (e.g., a choke coil) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio device that transmits and receives some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

[0055] Figure 1C The illustrated CN 106 may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing components is described as being part of the CN 106, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation procedures, and selecting a specific serving gateway during the initial attachment process of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) using other radio technologies (such as GSM and / or WCDMA).

[0057] The SGW 164 can be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from the WTRUs 102a, 102b, 102c. Also, the SGW 164 can perform other functions such as anchoring the user plane during an inter-eNB handover procedure, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0059] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 can include or communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), and the IP gateway can act as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other network 112, where the network can include other wired and / or wireless networks owned and / or operated by other service providers.

[0060] Although the WTRU is described as a wireless terminal in Figure 1A - 1D it should be appreciated that in some representative embodiments, such a terminal and the communication network can use a (e.g., temporary or permanent) wired communication interface.

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

[0062] A WLAN operating in the Basic Service Set (BSS) mode of the infrastructure can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can access or interface with a Distributed System (DS) or another type of wired / wireless network that sends traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for an STA can reach the STA through the AP and be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS can be sent through the AP, for example, in a case where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. The point-to-point traffic can be sent between the source and destination STAs (e.g., directly therebetween) using Direct Link Setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z Channelized DLS (TDLS)). For example, a WLAN operating in the Independent BSS (IBSS) mode does not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode can sometimes be referred to as the "Ad-hoc" communication mode.

[0063] When operating in the 802.11ac infrastructure mode or a similar mode of operation, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a bandwidth of 20 MHz) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) (e.g., in an 802.11 system) can be implemented. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, then the particular STA can back off. In a given BSS, at any given time, there is one STA (e.g., only one station) transmitting.

[0064] High Throughput (HT) STAs can communicate using a channel with a width of 40 MHz (e.g., by combining a primary channel with a width of 20 MHz and an adjacent or non-adjacent channel with a width of 20 MHz to form a channel with a width of 40 MHz).

[0065] 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 consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be passed through a segmentation parser which can split the data into two streams. The inverse fast Fourier transform (IFFT) process and time - domain processing can be performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0066] 802.11af and 802.11ah support operating modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel operating bandwidth and carriers used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non - TVWS spectrum. According to a representative embodiment, 802.11ah can support meter - type control / machine - type communication (MTC) (such as MTC devices in a macro - coverage area). MTC devices can have certain capabilities, such as limited capabilities including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a long battery life).

[0067] For WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by a certain STA, where the STA originates from all STAs operating in the BSS that support the minimum bandwidth operating mode. In the example regarding 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, for an STA that supports (e.g., only supports) the 1MHz mode (such as an MTC type device), the width of the primary channel can be 1MHz. Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy (e.g., because an STA that only supports the 1MHz operating mode is transmitting to the AP), then the entire available frequency band can be considered busy even if most of the available frequency band remains idle and available for use.

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

[0069] Figure 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 using NR radio technology via the air interface 116. RAN 113 can also communicate with CN 115.

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

[0071] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) having different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).

[0072] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor. In the stand-alone configuration, WTRUs 102a, 102b, 102c can use signals in an unlicensed band to communicate with gNBs 180a, 180b, 180c. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c communicate / connect with gNBs 180a, 180b, 180c while communicating / connecting with another RAN (e.g., eNodeBs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In the non-stand-alone configuration, eNodeBs 160a, 160b, 160c can act as the mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, 102c.

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

[0074] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may possibly include data networks (DN) 185a, 185b. Although each of the foregoing components has been described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by entities other than the CN operator.

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

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

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

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

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

[0080] A simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed, in whole or in part, as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform tests, and / or can use over-the-air wireless communication to perform tests.

[0081] One or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., for testing) to perform tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via an RF circuit (e.g., the circuit can include one or more antennas).

[0082] Figure 1E is a block diagram showing various example elements of a communication system 100. For example, in an embodiment of the communication system 100 configured according to 5G and / or NR, such elements can be included. These elements can include elements of one or more WTRUs 102, one or more (R)ANs 113, one or more DNs 185, and a core network 115, which includes an AMF 182, an SMF 183, a UPF 184, a policy control function (PCF) 186, and a network exposure function (NEF) 187. For convenience and simplicity of description, the terms "5G core network" and "5GC" can be used interchangeably with CN 115.

[0083] The AMF 182 can perform various functions, including, for example, any of the following functions: termination of the RAN CP interface (N2), termination of NAS (N1), NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception, etc. The SMF 183 can perform various functions, including, for example, any of the following: session management (including session establishment, modification, and release), IP address allocation, selection and control of user plane function(s), etc. The PCF 186 can perform various functions, including, for example, any of the following functions: providing support for a unified policy framework to manage network behavior, providing policy rules to one or more control plane functions for them to enforce, etc. The NEF 187 can perform various functions, including, for example, any of the following functions: exposing capabilities and events, providing information from external applications to network security, etc. The UPF 184 can perform various functions, including, for example, any of the following functions: serving as an anchor for mobility within / across RATs, allocation of UE IP addresses, external PDU session point for interconnecting with the DN (e.g., DN 185), packet routing and forwarding, packet inspection, etc. The RAN 113 can be configured as either NG-RAN or non-3GPP AN. The RAN 113 can be connected to the CN, for example, the CN can be configured as a 5G core network.

[0084] Figure 1F is a block diagram showing an example architecture of a communication system 100 configured according to 5G and / or NR. For convenience and simplicity of description, the term "5G system" and its abbreviation "5GS" may be used herein to refer to the communication system 100 configured according to 5G and / or NR. Figure 1F The example architecture shown can be applicable to various services in 5GS, including, for example, any of the services such as proximity-based services (ProSe), vehicle-to-everything (V2X) services, and other device-to-device (D2D) communication services. The example architecture may include WTRUs 102a-d, NG-RAN 113, DN 185, and 5GC 115.

[0085] Each of the WTRUs 102a-d may include an application ("WTRU application") 103. The WTRU application can be, for example, any of a ProSe application, a V2X application, and other similar types of applications. The DN 185 may include an application server 189. The application server 189 may include one or more applications serving any of the aforementioned WTRU applications.

[0086] D1 is a reference point between the WTRU application 103 and the applications in the application server 189. D5 is a reference point between WTRU applications 103 (e.g., between two or more WTRU applications 103 of the WTRU102a-d and / or within them). PC5 is a D2D interface for direct D2D communication between two or more WTRU 102a-d and / or within them. The PC5 interface can be configured as, for example, any of the following: LTE-based PC5, NR-based PC5, etc. The terms PC5 interface and "sidelink" (at the PHY layer) can be referred to interchangeably herein.

[0087] Direct D2D communication (e.g., ProSe direct communication) can establish a communication path between two or more WTRU102 that are in proximity / range to each other. Direct D2D discovery (e.g., ProSe direct discovery) can be used by the WTRU 102 to identify other nearby WTRU. For example, details of the WTRU for direct communication and / or direct discovery and / or for in-coverage and out-of-coverage scenarios can be found in 3GPP TS23.303 V15.1.0. Detailed implementation

[0088] V2X direct discovery and link establishment

[0089] Figure 2 is a diagram showing the layer 2 (L2) link establishment of Release 16 (Rel-16) Vehicle-to-Everything (V2X) (e.g., which can be interchangeably referred to as Enhanced V2X (eV2X)).

[0090] For example, the Vehicle-to-Everything (V2X) service specified by the 3rd Generation Partnership Project (3GPP) for the 5th Generation (5G) network (e.g., see Rel-16) can include layer 2 (L2) link establishment using (e.g., on, via, etc.) the PC5 reference point process. Figure 2 Shows the L2 link establishment using the PC5 reference point process, which can be performed according to: (1) a process oriented to the WTRU, and (2) a process oriented to the V2X service.

[0091] In the case of the process oriented to the WTRU, the initiating WTRU (e.g., Figure 2 UE-2 in) broadcasts a Direct Communication Request (DCR) message, which includes, for example, the upper layer identifier (ID) of the peer WTRU and the source L2 ID of the initiating WTRU. The peer WTRU (e.g., Figure 2The UE-2 in ) can decide to use its L2 ID as the source L2 ID and use the initiating UE L2 ID as the destination L2 ID to reply to the request with a unicast direct communication acceptance (DCA) message. In the case of a procedure for V2X services, the initiating WTRU broadcasts a DCR message that advertises the V2X services available for L2 link establishment. In this case, the (e.g., all) WTRUs that receive the DCR message and are interested in the advertised V2X services can reply with a unicast DCA message to establish unicast communication. The interested peer WTRUs (e.g., Figure 2 UE-2 or UE-4 in ) use their L2 ID as the source L2 ID and use the initiating WTRU L2 ID as the destination L2 ID.

[0092] Reference Figure 2 , for example, compared with the direct discovery mechanisms of Release 12 (Rel-12) and Release 13 (Rel-13) Proximity Services (ProSe), this eV2X procedure can be considered (e.g., used) a more lightweight direct discovery mechanism that is (e.g., more) integrated with the link establishment procedure (e.g., more). In the eV2X procedure, for example, as Figure 2 shown, peer WTRUs detect service broadcast messages without having to first request ProSe codes and / or filters from a network server. For example, compared with Rel-12 / Rel-13 ProSe direct discovery, this eV2X procedure can be considered a serverless procedure or a more distributed procedure.

[0093] Figure 3 is a diagram showing the control plane of eV2X in the PC5 interface; and Figure 4 is a diagram showing the user plane for eV2X in the PC5 interface. More specifically, Figure 3 shows the control plane protocol of the access stratum (AS) and PC5 stratum for eV2X, and Figure 4 shows the user plane protocol stack in the PC5 interface for eV2X.

[0094] Figure 5 is a diagram showing the link identifier update process. The link identifier update (e.g., process) can be performed, for example, as defined by 3GPP, as Figure 5 shown. In Figure 5In the case of the link identifier update shown, due to privacy requirements (e.g., standards, requirements, etc.), the IDs (e.g., application layer ID, source layer 2 ID, and IP address / prefix) for the unicast mode of V2X communication via the PC5 reference point change over time. In this case, a link identifier update request specifying a new L2 ID is sent to the peer WTRU. This new L2 ID is sent as a message payload and is security protected. Once the peer WTRU sends a response message to confirm receipt of the new L2 ID, the new L2 ID can be used.

[0095] ProSe UE-to-UE Relay

[0096] Figure 6 is a diagram showing a WTRU-to-WTRU relay scenario.

[0097] ProSe or proximity services can be applied to Release 17 (Rel-17) of the 3GPP 5G standard (e.g., also studied as part of it). Additionally, in the case of 5G ProSe, there are (e.g., newly introduced) scenarios for WTRU-to-WTRU communication using (e.g., via) a relay WTRU. In such a scenario, a WTRU discovers another WTRU and (e.g., subsequently) communicates with the other WTRU via a relay WTRU between the two WTRUs. Referring Figure 6 , the cases where a WTRU communicates via a relay UE can include any of the following: a Service Provider WTRU (SP-WTRU) (e.g., the UE1 in Figure 6 ), a Service Utilizing WTRU (SU-WTRU) (e.g., Figure 6 the UE2 in

[0098] The SP-WTRU provides services (e.g., restaurant service, taxi service, game console and / or game controller service, etc.) that can be sought by other WTRUs (e.g., specific ones). The SU-WTRU can seek services provided by the service provider WTRU. Any number of SU-WTRUs can attempt to discover the services provided by (e.g., specific) SP-WTRUs. Examples of service utilizers WTRUs can be, for example, any of a restaurant customer, a taxi passenger, a game controller, a user of an augmented reality (AR) / virtual reality (VR) headset, etc. The R-WTRU can relay (e.g., assist with) any of the PC5 data communications and relay messages between (e.g., two) other WTRUs (e.g., between the service provider WTRU and the service utilizing WTRU). The R-WTRU can (e.g., also) act as an agent between (e.g., two) other WTRUs for any of discovery and communication, or can transparently relay messages between (e.g., two) other WTRUs. In addition, the R-WTRU can participate in a discovery process that enables the service provider WTRU and the service using the WTRU to discover each other.

[0099] As described above, for example, regarding the 3GPP V2X standard work, the Rel-16 eV2X work can be used as a basis (e.g., expected to be widely reused) (e.g., studied) for system enhancements of ProSe in the 5G system (5GS). Support for WTRU-to-WTRU relay can be considered a key issue (e.g., identified as) for study. However, Rel-16 eV2X does not include support for WTRU-to-WTRU relay, or in other words, does not support the R-WTRU.

[0100] According to an embodiment, support for the WTRU-to-WTRU relay feature (which can be referred to as either the R-WTRU or R-UE feature) can be enabled in the 5GS. According to an embodiment, for example, in order to support the R-WTRU or R-UE feature in the 5GS, at least the following issues / problems may (e.g., must, need, should, etc.) be addressed: (1) How can a WTRU (SP-WTRU or SU-WTRU) discover nearby R-WTRUs?; (2) How can a WTRU (e.g., SU-WTRU) discover a peer WTRU (e.g., SP-WTRU) via the R-WTRU?; (3) How can the network authorize a WTRU to act as an R-WTRU and / or authorize a peer WTRU to provide and / or use services via relay?; and (4) How can a WTRU be enabled to check that an R-WTRU is authorized to act as a relay?

[0101] In addition, according to embodiments, for example, in order to support R-WTRU or R-UE features in 5GS, there are security-related issues / problems that may (e.g., must, need, should, etc.) be addressed. For example, when using an R-WTRU, there may be an issue of how to provide security protection for communication. According to embodiments, the solution thereto may (e.g., should, must, be designed to) provide a security level for the peer WTRU that is comparable to that when communicating without an R-WTRU. In addition, regarding security, when using an R-WTRU, there may be an issue of how to provide privacy protection for the communicating WTRU. According to embodiments, the solution thereto may (e.g., should, must, be designed to) provide a privacy protection level for the peer WTRU that is comparable to that when communicating without an R-WTRU.

[0102] According to embodiments, and as mentioned herein, an SP-WTRU and an SU-WTRU may be used to identify or refer to a peer WTRU, and the SP-WTRU may also be referred to as any of an initiating WTRU, a source WTRU, and a peer WTRU, and the SU-WTRU may also be referred to as any of a responding WTRU, a target WTRU, and a peer WTRU.

[0103] Non-transparent WTRU-to-WTRU relay

[0104] According to embodiments, a relay WTRU (R-WTRU) may enable (e.g., provide, facilitate, assist, etc.) a serving user WTRU (SU-WTRU) to discover services provided by a serving provider WTRU (SP-WTRU). According to embodiments, separate (e.g., two separate) L2 links (including the link between the SP-WTRU and the R-WTRU, and the link between the R-WTRU and the SU-WTRU) may be established (e.g., explicitly) to achieve discovery, for example. According to embodiments, for example, during or at any time after the registration process, a policy control function (PCF) may provide any of a relay policy and relay parameters (e.g., information indicating the same) to the R-WTRU. According to embodiments, any of the relay policy and relay parameters (e.g., information indicating the relay policy and relay parameters) may identify any services and criteria, where the R-WTRU may use the any services and criteria, for example, to determine whether and how to act as any of the relays for a (e.g., given) service. According to embodiments, any of the relay policy and relay parameters may also be considered (e.g., referred to as) stored in a relay authorization context in the WTRU.

[0105] According to an embodiment, in the case where the R-WTRU determines that a service broadcast by the SP-UE matches a service (e.g., one of the services) included in any of the provided relay policies and parameters (e.g., once, or at this time, etc.), the R-WTRU may, for example, announce the service in a broadcast message and may, for example, include in the broadcast message either the SP-WTRU application layer ID (AID) and the relay indication (e.g., information indicating either is included in and / or with the announcement). According to an embodiment, for example, when receiving a reply in a unicast message from the SU-WTRU, the R-WTRU may send (e.g., include therein) the reply in a unicast message transmitted to the SP-WTRU. According to an embodiment, the reply (e.g., transmitted as a unicast message) may include either the relay indication and the SU-WTRU AID. According to an embodiment, the R-WTRU may establish a mapping of the SP-WTRU identifier and the SU-WTRU identifier, e.g., for a (e.g., given) service. According to an embodiment, the mapping may be established during a (e.g., current, ongoing, etc.) link establishment process and may be maintained for, e.g., subsequent communication.

[0106] According to an embodiment, the R-WTRU may use separate (e.g., two, different, etc.) L2 IDs, e.g., two L2 IDs, to communicate with the SP-WTRU (e.g., L2 ID1) and the SU-WTRU (e.g., L2ID2) respectively. According to an embodiment, the R-WTRU sends a message to the SP-WTRU via PC5. According to an embodiment, in this case, when sending a message to the SP-WTRU (corresponding to the SU-WTRU) via PC5, the R-WTRU may use its L2 ID1 (corresponding to L2 ID2) as the source ID / address and may use the SP-WTRU (corresponding to the SU-WTRU) L2 ID as the destination ID / address. According to an embodiment, the SP-WTRU may use its L2 ID as the source L2 ID and the R-WTRU L2 ID1 as the destination L2 ID. According to an embodiment, the SU-WTRU may use its L2 ID as the source L2 ID and may use the R-WTRU L2 ID2 as the destination L2 ID.

[0107] Transparent WTRU-to-WTRU Relay

[0108] According to an embodiment, transparent WTRU-to-WTRU relay can be considered, for example, a variation of the non-transparent WTRU-to-WTRU relay as described above. According to an embodiment, for transparent WTRU-to-WTRU relay, the R-WTRU may not establish communication with either the SU-WTRU or the SP-WTRU. According to an embodiment, the R-WTRU may relay the received message (e.g., almost, substantially, to a large extent, etc., unchanged) between the SU-WTRU and the SP-WTRU. According to an embodiment, the R-WTRU may (e.g., at most, substantially, minimally, only, etc.) modify an ID, such as any of the source L2 ID, the destination L2 ID, and the adaptation layer field. For example, according to an embodiment, the modification may include any of the following: (1) replacing the source L2 ID with the R-WTRU L2 ID, for example, before forwarding the message to either the SP-WTRU or the SU-WTRU; (2) modifying the destination L2 ID with either the SU-L2 ID or the SP-L2 ID; (3) modifying the adaptation layer field with the R-WTRU L2 ID associated with either the SU-WTRU or the SP-WTRU; and (4) adding a Relay WTRU Indicator (RIND). According to an embodiment, the RIND may include the R-WTRU ID (RID).

[0109] According to an embodiment, the SP-WTRU and the SU-WTRU may communicate (e.g., securely) via (e.g., through) the R-WTRU. According to an embodiment, the SP-WTRU and the SU-WTRU may establish (e.g., secure) communication via (e.g., through) the R-WTRU. According to an embodiment, the R-WTRU may not be involved in security context establishment. According to an embodiment, in the case where the R-WTRU is not involved in the establishment of the security context, the R-WTRU may not read and / or modify (e.g., may not be able to modify and / or read) the content of, for example, a protected message (e.g., content whose integrity and / or confidentiality is protected). According to an embodiment, either the source L2 ID or the destination L2 ID may be sent in plain text and may be read and / or modified by the R-WTRU, for example.

[0110] According to an embodiment, an R-WTRU that performs transparent relay operation (which may be referred to as a transparent R-WTRU) may be provided with either a relay policy and relay parameters, e.g., similar to the case of non-transparent relay (e.g., see above). According to an embodiment, the R-WTRU may determine that the service broadcast by the SP-WTRU in the DCR message matches a service (e.g., one of them) based on any provided relay policy and parameters (e.g., included therein, from it, indicated by it, etc.). According to an embodiment, in the case where the R-WTRU determines that such a match exists, the R-WTRU may generate (e.g., a new) relay-L2 ID (R-L2 ID).

[0111] According to an embodiment, the (e.g., new) R-L2 ID may be associated with either the (e.g., specific) DCR message and the SP-L2 ID, and with any other message related to the (e.g.,) link establishment request (e.g., security context establishment message, link establishment acceptance message, etc.). According to an embodiment, the (e.g., new) R-L2 ID may be included (e.g., saved, stored, written, etc.) in a mapping table, e.g., together with the SP-WTRU L2 ID. According to an embodiment, the R-WTRU may (e.g., then) copy the (e.g., newly) assigned R-L2 ID into the source L2 ID field of the received message and / or into the adaptation layer field of the received message, and may add either a relay indication (e.g., RIND) and a relay identifier (e.g., RID). According to an embodiment, the R-WTRU may (e.g., then) broadcast the (e.g., modified, received) message.

[0112] According to an embodiment, the R-WTRU may perform any of the following operations: locate (e.g., determine, find, calculate, etc.) the R-L2 ID in a (e.g., its own) mapping table; add the SU-L2 ID to a (e.g., its own) mapping table, and extract the SP-L2ID from a (e.g., its own) mapping table. For example, when receiving a unicast message from the SU-WTRU with the destination L2 ID field set to its R-L2 ID, the R-WTRU may generate a new relay-L2 ID (R-L2 ID) associated with the SU-WTRU, may locate the R-L2 ID in its mapping table, may add the SU-L2 ID and the associated new R-L2ID to (e.g., add to) the mapping table entry, and may extract the corresponding SP-L2 ID. According to an embodiment, the R-WTRU may (e.g., then) copy the SP-L2 ID into the destination field of the received message and / or copy it into the adaptation layer field of the received message, and / or may copy the R-L2 ID associated with the SU-L2 ID into the adaptation layer field and may add RIND. According to an embodiment, the (e.g., modified, received) message may be sent (e.g., subsequently) to the SP-WTRU. According to an embodiment, the R-WTRU may maintain a mapping table containing any of the SP-L2 ID and the SU-L2 ID. According to an embodiment, the R-WTRU may, for example, assign (e.g., two) R-L2 IDs to itself, for example, to be associated with the SP-L2ID and the SU-L2 ID respectively. According to an embodiment, the R-WTRU may replace (e.g., these) L2 IDs when relaying a message. According to an embodiment, the relay L2 ID may (e.g., also) be stored in the mapping table.

[0113] According to an embodiment, in the case where a DCR message (e.g., a DCR message having a destination addressed to the SP-L2 ID) destined for a (e.g., known) WTRU is received by the R-WTRU, the R-WTRU may (e.g., also) assign (e.g., a new) R-L2 ID to itself. According to an embodiment, in such a case, the same steps as described above may be followed. That is, the R-WTRU may save (e.g., write, map, etc.) the source L2 ID included in (e.g., specified in) the received DCR message and the destination L2 ID (e.g., SP-L2 ID) already stored in the mapping table. According to an embodiment, the R-WTRU may update the source L2 ID of the received DCR message with its newly generated R-L2 ID, and may forward the message to the destination L2 ID.

[0114] Figure 7 is a diagram showing a high-level view of transparent relaying according to an embodiment.

[0115] Reference Figure 7 , according to an embodiment, the transparent relay may include any of the following operations: (1) The SP-WTRU may initiate peer WTRU discovery, for example, by broadcasting a DCR message of the supported services; (2) The management link may be established between the R-WTRU and the SP-WTRU, and the management link may be used to manage the link established with the SU-WTRU via the R-WTRU; for example, the management link may be established by causing the R-WTRU to reply to the broadcast DCR message, and / or for example, the management link may be established (for example, only) when needed (for example, when link management is required to update the link ID on the unicast link #1, etc.); (3) The R-WTRU, for example, assigns an R-L2ID used as the source L2 ID for itself to broadcast the received DCR message; (4) The R-WTRU may broadcast the DCR message, where for example (for example, only) the source field of the DCR message is modified, and the content remains the same except for the possible addition of the RID, where the RID is a unique relay (for example, R-WTRU) identifier for the (for example, specific) R-WTRU; (5) The SU-WTRU (for example, SU-UE2) may be interested in the advertised services (for example, by receiving the advertised services), and may exchange messages with the SP-WTRU via the R-WTRU, for example, to establish a link and set up a security context (for example, keys for integrity protection and encryption); according to an embodiment, these messages are not modified by the R-WTRU, and (for example, only) the source / destination fields (for example, source / destination L2 IDs) are modified; for example, the R-WTRU may forward an SMC message that includes key material exchanged between the SP-WTRU and the SU-WTRU, so that the SP-WTRU and the SU-WTRU can derive security keys for end-to-end communication security; in addition, the SP-WTRU may know the L2 ID of the R-WTRU, and the SU-WTRU may know another L2 ID of the R-WTRU, while the SP-WTRU and the SU-WTRU do not know each other's L2 IDs; (6) A secure unicast link may be established between the SP-WTRU and the SU-WTRU via the R-WTRU, and according to an embodiment, security settings (for example, integrity and / or confidentiality protection) may be processed at the SP-WTRU and the SU-WTRU; and (7) Any of the PC5-S messages and data may be exchanged between the SP-WTRU and the SU-WTRU via the R-WTRU, and according to an embodiment, the R-WTRU may (for example, only) update the source and / or destination L2 IDs based on the information stored in its mapping table.

[0116] IP-based service-oriented discovery and multicast communication using WTRU-to-WTRU relay

[0117] According to an embodiment, a relay from a WTRU to a WTRU (e.g., an R-WTRU) may use Internet Protocol (IP) to support discovery and unicast communication. That is, according to an embodiment, an R-WTRU (e.g., operating as a WTRU-to-WTRU relay) may use an IP-based mechanism to (e.g., provide) support (e.g., only) for WTRU-oriented discovery and unicast (e.g., IP / L2) communication. Additionally, according to an embodiment, support for any service-oriented discovery and multicast (e.g., IP / L2) communication may be used by the R-WTRU (e.g., desired) (e.g., available for WTRU-to-WTRU relay), e.g., to extend the scope of all possible types of discovery and communication.

[0118] According to an embodiment, there may be a situation (e.g., usage scenario) where for either service-oriented discovery or multicast (e.g., IP / L2) communication, the transmitting WTRU may not know (e.g., not know, not need to know, etc.) the receiving (e.g., target) WTRU. For example, in usage cases such as teaming and / or real-time gaming, the transmitting WTRU may not need to know the receiving WTRU. According to an embodiment, an R-WTRU (e.g., a WTRU-to-WTRU relay) may be used to perform (e.g., enable) either service-oriented discovery or multicast communication based on IP, where the R-WTRU acts as a non-transparent IP-based relay between a WTRU (e.g., a first WTRU (e.g., a service-providing WTRU, WTRU 1) and a second WTRU (WTRU 2) and a third WTRU (WTRU 3) WTRU (e.g., a service-utilizing WTRU)).

[0119] According to an embodiment, an R-WTRU may use any of the operations and features described below to perform service-oriented discovery and multicast communication based on IP. According to an embodiment, a WTRU (e.g., an R-WTRU) may broadcast an IP-based WTRU-to-WTRU relay service via PC5 (e.g., broadcast an announcement for the service, a message for the service, etc.), the broadcast including information indicating multicast communication relay capabilities. According to an embodiment, a WTRU (e.g., any of WTRU 1 to 3) may discover (e.g., start discovery of) an R-WTRU (e.g., a WTRU-to-WTRU relay) based, for example, on an application layer trigger. According to an embodiment, a WTRU (e.g., any of WTRU 1 to 3) may select (e.g., use) a relay based on information indicating multicast communication relay capabilities. According to an embodiment, an R-WTRU may establish a secure link with a service-providing WTRU (e.g., WTRU 1) when receiving a unicast DCR message including service information (e.g., and null target user information).

[0120] According to an embodiment, the R-WTRU may allocate, for example, any of a unicast IP address, an IP multicast, and an associated L2 multicast address to the WTRU 1 (e.g., a serving WTRU) (e.g., based on service information, authorization) for the service. According to an embodiment, the R-WTRU may send a DCA message to the WTRU 1, and the DCA message may include the unicast IP address and the IP multicast / L2 multicast address for the service. According to an embodiment, the R-WTRU may create (e.g., generate, update, etc.) a mapping that includes service information, the IP / L2 unicast address and the IP multicast / L2 multicast address of the UE1 for the service. According to an embodiment, the R-WTRU may establish (e.g., generate, determine, etc.) a restriction on which the WTRU may use (e.g., send to it, use it for transmission, etc.) any of the IP multicast address and the L2 multicast address for the service. For example, the R-WTRU may restrict (e.g., only) the use of the address to the WTRU 1 or some specified WTRUs based on any of the WTRU 1 request and / or service information and the provided authorization policy.

[0121] According to an embodiment, the R-WTRU may listen for the L2 multicast address for the service to receive multicast communications from any participating WTRU (e.g., WTRU 1 to 3). According to an embodiment, the R-WTRU may establish a secure link with the service-utilizing WTRU (e.g., WTRU 2 and 3), for example, when receiving a unicast DCR message including either null service information and null target user information. According to an embodiment, the DCR message may include one or more (e.g., any number / quantity of) service information of interest to the service-utilizing WTRU. According to an embodiment, the R-WTRU may assign a unicast IP address to either of WTRU 2 and WTRU 3 and may send it (e.g., respectively) to either of WTRU 2 and WTRU 3 in a DCA message. According to an embodiment, in the case where the service-utilizing WTRU indicates one or more service information in the DCR message, the R-WTRU may also include the WTRU 1 IP unicast address and either the IP multicast address and the L2 multicast address for one or more services requested in the DCA. According to an embodiment, in the case of multiple R-WTRUs, the service-utilizing WTRU may select the R-WTRU that provides these addresses for the service in the DCA (e.g., the service-utilizing WTRU may use a direct connection with the first R-WTRU, where the first R-WTRU includes the service address in the DCA). According to an embodiment, the R-WTRU may receive a Domain Name System (DNS) query from either of WTRU 2 and WTRU 3, and the DNS query may include the service information. According to an embodiment, the R-WTRU may transmit (e.g., in response to the DNS query) a DNS response, which may include, for example, the WTRU 1 IP unicast address for the service and any of the IP multicast and L2 multicast addresses.

[0122] According to an embodiment, for example, once receiving the DNS reply, either of WTRU 2 and WTRU 3 may listen for the L2 multicast and IP multicast for the service. According to an embodiment, for example, when receiving an IP packet (e.g., an IP packet from WTRU 1) destined for the IP multicast of the service in an inbound L2 message, the R-WTRU may forward the IP packet in an outbound message using the L2 multicast address for the service as the destination. According to an embodiment, the inbound message may use either the L2 unicast address of the R-WTRU (e.g., may be sent to the R-WTRU via a unicast link) or the L2 multicast address for the service (e.g., may be sent to a group) as the L2 destination so that either of WTRU 2 and WTRU 3 may receive the IP packet.

[0123] Service-Oriented Discovery and Communication Using Non-Transparent WTRU-to-WTRU Relay

[0124] Control and user plane stacks for non-transparent relays

[0125] Figure 8 is a diagram showing a control plane protocol stack supporting non-transparent WTRU-to-WTRU relay according to an embodiment.

[0126] According to an embodiment, with reference to Figure 8 , there may be a control plane protocol stack supporting an R-WTRU, which may be interchangeably referred to as a non-transparent WTRU-to-WTRU relay. According to an embodiment, for example, as described above, hop-by-hop (e.g., between WTRU1 and the R-WTRU, and between the R-WTRU and WTRU2) link and security establishment may be used. According to an embodiment, when receiving a frame from another WTRU (e.g., from WTRU2 relative to WTRU1), the R-WTRU may use its own (e.g., self-generated) source L2 ID, and may construct an L2 frame for the WTRU (e.g., WTRU1 relative to WTRU2), for example, based on the relay information maintaining the mapping of WTRU1 L2 ID and WTRU2 L2 ID.

[0127] According to an embodiment, the R-WTRU may handle the security of PC5 signaling packets on a per-link basis, which may be performed, for example, by using the security context established for that particular link. According to an embodiment, the R-WTRU may perform an action when receiving a PC5-S message destined for a second WTRU (or vice versa) from a first WTRU. That is, according to an embodiment, the R-WTRU may perform any of the following operations: (1) use the security context established with the first WTRU to check (e.g., review, determine, verify, etc.) integrity protection and / or decrypt the protected PC5-S packet; (2) modify or generate a corresponding PC5-S message (e.g., to include a relay indication information element (IE)); (3) apply security to the packet using the security context established with the second WTRU; and (4) set the source L2 ID to the R-WTRU's own source L2 ID, set the L2 destination to the L2 ID of the second WTRU, and send it to the second WTRU.

[0128] Figure 9 is a diagram showing a user plane protocol stack supporting non-transparent WTRU-to-WTRU relay according to an embodiment.

[0129] According to an embodiment, with reference to Figure 9, a user plane protocol stack that supports an R-WTRU (e.g., non-transparent WTRU-to-WTRU relay) may exist. According to an embodiment, the R-WTRU may be (e.g., act as) the default IP router of the WTRU, for which the R-WTRU is a relay, e.g., for any one of the first and second WTRUs described above. According to an embodiment, the R-WTRU may forward IP packets received on a (e.g., given) (e.g., to the R-WTRU) link, e.g., automatically, based on relay mapping information, via an associated link (e.g., from the R-WTRU). According to an embodiment, with respect to the control plane, the R-WTRU may handle the security of incoming IP packets on a per-link basis. For example, the R-WTRU may use a security context established for the link with the first WTRU to check integrity protection and / or decrypt IP packets received on the link with the first WTRU. According to an embodiment, the R-WTRU may (e.g., then) apply security to the packet and may send the secured packet to the second WTRU in an L2 frame, using the source L2ID as its own source L2 ID and the L2 destination as the L2 ID of the second WTRU.

[0130] Link establishment for non-transparent relay

[0131] According to an embodiment, the R-WTRU may enable an SU-WTRU to discover services provided by an SP-WTRU. According to an embodiment, (e.g., two) separate L2 links may be (e.g., explicitly) established, e.g., a link between the SP-WTRU and the R-WTRU and a link between the R-WTRU and the SU-WTRU. However, the present disclosure is not limited thereto, e.g., the R-WTRU may establish (e.g., configure, operate, etc.) any number of L2 links.

[0132] R-WTRU behavior for non-transparent relay

[0133] According to an embodiment, a WTRU may send a signal of its relay capabilities to a network, for example, during the registration of the WTRU. According to an embodiment, the WTRU may receive authorization to act as a relay, for example, via any of the relay policies and relay parameters provided (e.g., used, passed, according to, etc.) by, for example, a PCF. According to an embodiment, the WTRU may be authorized to act as a relay on a per-service, per-PLMN, or per-RAT basis (e.g., act as an R-WTRU). According to an embodiment, the parameters provided for relay operation (e.g., part of the relay authorization context) may include any of the following: (1) a list of any services or service types for which the WTRU is authorized to relay; (2) relay availability criteria, such as any of the following: a registration area, a geographical area, a time of day, for which or where the WTRU may act as a relay for a (e.g., specific) service; and (3) relay security parameters, such as a signed certificate, which the WTRU may use to provide proof of authorization for relaying to a peer WTRU (e.g., any of an SP-WTRU and an SU-WTRU) that wishes to use the relay service, and according to an embodiment, such relay security parameters may (e.g., alternatively) be provided by the application layer of the WTRU. According to an embodiment, the WTRU may receive a broadcast DCR message for an announced (e.g., given) service. According to an embodiment, the broadcast DCR message may include an indication of whether the service may be used via relay. According to an embodiment, any of the broadcast DCR message or a similar PC5 message may be received via a PC5 discovery channel.

[0134] According to an embodiment, the WTRU may match the announced service with one of the services from the relay policy / parameters provided to it. According to an embodiment, for example, after matching the announced service, the WTRU may invoke mutual authentication with the SP-WTRU and may establish security for the PC5 link. According to an embodiment, the WTRU may store relay mapping information, which may include, for example, either the SP-WTRU L2 ID and the SP-WTRU application layer ID (AID) for any announced service or service type. According to an embodiment, the WTRU may broadcast a DCR that includes any of the following: an indication that the WTRU is operating as a relay (e.g., as an R-WTRU) and the SP-WTRU AID for the announced service. According to an embodiment, for example, after broadcasting the DCR, the WTRU may perform mutual authentication with the SU-WTRU and establish security for the PC5 link. According to an embodiment, once the DCA is received from the SU-WTRU, the WTRU may update its relay mapping information with the SU-WTRU's L2ID and AID. According to an embodiment, for example, by using the stored SP-WTRU L2 ID as the destination L2 ID, the WTRU may send a DCA to the SP-WTRU, which may include, for example, either the RIND and the SU-WTRU AID.

[0135] SU-WTRU Behavior for Non-Transparent Relaying

[0136] According to an embodiment, the PCF may provide either relay policy and relay parameters to the WTRU. The provided parameters for relay operation (e.g., part of the relay user authorization context) may include any of the following: a list of any services and service types that the WTRU may use via the relay (e.g., as an R-WTRU); any of the relay availability and selection criteria; PC5 QoS parameters for the relay service; and relay security parameters. According to an embodiment, any of the relay availability and selection criteria may include any of the registration area, geographical area, and time-of-day constraints, e.g., for which place or time, the use of the relay (e.g., as an R-WTRU) for a (e.g., specific) service is allowed. According to an embodiment, the relay policy may indicate how services may be used when the SP-WTRU, R-WTRU, and SU-WTRU (e.g., all) are within range of each other. According to an embodiment, any connection to (e.g., to) the SP-WTRU and R-WTRU (e.g., both) may be allowed (e.g., as a backup to the SP-WTRU), or a connection to only (e.g., one) SP-WTRU may be allowed.

[0137] According to an embodiment, the PC5 QoS parameter for the relay service can be the default QoS value for any service or service type that can be (e.g., specifically) adapted to be used (e.g., transmitted) via a relay (e.g., R-WTRU). According to an embodiment, some values (e.g., the default QoS value, the PC5 QoS parameter) can be the same as when the service is used directly (e.g., without a relay), while other values can vary (e.g., when the service is used via a relay, the packet delay budget parameter can be higher). According to an embodiment, the PC5 QoS parameter can include any of the following: the maximum relay range or the distance from the relay, e.g., which should not be exceeded to use (e.g., be able to use) the service via the relay. According to an embodiment, the relay security parameter can include an authorization token. According to an embodiment, the WTRU can use the authorization token to check (e.g., determine, verify, calculate, etc.) the proof of authorization to provide the relay service from the R-WTRU. According to an embodiment, the security parameter can be (e.g., alternatively) provided by the application layer of the WTRU.

[0138] According to an embodiment, the WTRU (e.g., R-WTRU) can receive a broadcast DCR announcing a given service. According to an embodiment, the WTRU can (e.g., optionally) monitor the discovery channel, e.g., to receive the broadcast DCR message in the case where the broadcast DCR message (which can be interchangeably referred to as either the DCR message and DCR) is sent as a PC5 discovery message. According to an embodiment, the WTRU can determine that the DCR originates from the R-WTRU (e.g., on behalf of the SP-WTRU) based on, for example, a relay indication (e.g., either RIND or RID) included. According to an embodiment, the WTRU can use the provided security parameter (e.g., authorization token) to check (e.g., determine, verify, calculate, etc.) that the R-WTRU is authorized to act as a relay.

[0139] According to an embodiment, the WTRU can determine that a service can be used via a relay (e.g., the service to be used matches a service from a list of services authorized to be used via a relay in the current registered area) based on any of the provided relay policies and relay parameters. According to an embodiment, for example, after matching the service, the WTRU can invoke mutual authentication with the R-WTRU and (e.g., can perform) establish security for the PC5 link. According to an embodiment, (e.g., optionally, additionally, etc.), the R-WTRU can be used to perform mutual authentication and security establishment (e.g., its steps, its parts, etc.) for end-to-end communication between the SP-WTRU and the SU-WTRU. According to an embodiment, the WTRU can send a DCA to the R-WTRU, e.g., to complete the establishment of the L2 link for the relay service.

[0140] SP-WTRU Behavior for Non-Transparent Relay

[0141] According to an embodiment, a WTRU may be provided with either a relay policy and relay parameters, such as provided by a PCF. According to an embodiment, either of the provided policy and parameters (e.g., part of a relay user authorization context) may include criteria for relay use (e.g., operation) by the SU-WTRU. According to an embodiment, the WTRU may send a broadcast DCR message that advertises (e.g., specific) services. According to an embodiment, the broadcast DCR message (e.g., sent by the WTRU) may include information indicating whether a service (e.g., which services) may be relayed based on (e.g., according to) any of the provided relay policies and relay parameters. According to an embodiment, the WTRU may use such an indication to dynamically restrict (e.g., based on policy) when or where a service may be relayed. According to an embodiment, the broadcast DCR message may be, for example, a PC5 discovery message sent over a discovery channel.

[0142] According to an embodiment, the WTRU may perform mutual authentication with an R-WTRU. According to an embodiment, the WTRU may perform security establishment for a PC5 link, for example, after performing mutual authentication with the R-WTRU. According to an embodiment, for example, when receiving a DCA from the R-WTRU, and / or based on either of the included relay indications (e.g., RIND, RID) and the SU-WTRU AID, the WTRU may determine that a service is being used by the SU-WTRU via the R-WTRU. According to an embodiment, the WTRU may perform (e.g., a final) check to determine whether a service may be relayed, based on either of the provided relay policies or relay parameters.

[0143] Call flow for non-transparent relay

[0144] Figure 10 is a diagram showing a service-oriented discovery process using non-transparent WTRU-to-WTRU relay according to an embodiment.

[0145] Reference Figure 10 , according to an embodiment, the non-transparent process for WTRU-to-WTRU relay (i.e., the process performed by the R-WTRU) may be any of the service-oriented discovery and link establishment processes involving any of the R-WTRU, SP-WTRU, and SU-WTRU. According to an embodiment, any of the service-oriented discovery and link establishment processes may include any of operations 0 to 9 below (e.g., may follow the Figure 10 call / signal flow).

[0146] According to an embodiment, at operation 0, the R-WTRU may register with the network, and the R-WTRU may indicate relay capabilities, for example, when registering with the network. According to an embodiment, the R-WTRU may receive either a relay policy or relay parameters (e.g., from the PCF via the AMF), for example, to perform as a relay (e.g., an operation). According to an embodiment, the SP-WTRU and the SU-WTRU may also register with the network and may be provided with either a relay user policy or relay (e.g., user) parameters, for example, to perform as a user of the relay (e.g., an operation). According to an embodiment, any of the relay policies and relay parameters for the relay and relay users are described above. According to an embodiment, the WTRU (e.g., any or all of the R-WTRU, SU-WTRU, or SP-WTRU) may alternatively or additionally be pre-provided with any (e.g., their respective) relay policies or relay parameters. According to an embodiment, any such parameters may be provided (pre) to either the mobile device (ME) or the universal integrated circuit card (UICC) portion of the WTRU.

[0147] According to an embodiment, at operation 1, the SP-WTRU may send a DCR in a broadcast message, for example, to announce (e.g., a specific) service. According to an embodiment, the SP-WTRU may include an indication of restricted service relay. For example, the SP-WTRU may prioritize (e.g., within an area of SU-WTRUs with a high density) the use of SU-WTRUs in close proximity. According to an embodiment, the SP-WTRU may inform the relay (e.g., the R-WTRU) that relaying the service is prohibited (e.g., temporarily prohibited, based on off-peak to peak times).

[0148] According to an embodiment, at operation 2, for example, upon receiving a broadcast DCR message announcing a given service, the R-WTRU may determine that it may act as a relay for that service (e.g., may provide relay for a service provided by the SP-WTRU), based, for example, on a relay restriction indication or any of the relay policies and / or relay parameters provided to the R-WTRU. According to an embodiment, the announced service and / or service type may match the service and / or service type for which the provided R-WTRU is authorized to relay. According to an embodiment, the R-WTRU may store relay mapping information, which may include, for example, any of the following: service type, L2 ID and AID of the SP-WTRU, R-WTRU L2 ID, and any IP address and QoS information received in the DCR message.

[0149] According to an embodiment, at operation 3, the R-WTRU may broadcast a DCR, which may include any of the following: services and service types received from the SP-WTRU, an indication that the R-WTRU may operate as a relay, and the SP-WTRU AID. According to an embodiment, the R-WTRU may include other parameters in the broadcast DCR, such as a locally formed IP address.

[0150] According to an embodiment, at operation 4, for example, upon receiving a broadcast DCR message announcing (e.g., a given) service, the SU-WTRU may determine that the broadcast DCR message originated from the R-WTRU (e.g., on behalf of the SP-WTRU) based, for example, on the relay indication included in the broadcast DCR. According to an embodiment, the SU-WTRU may determine that it may use the announced service via the relay based on any of the relay policies or relay parameters provided to it (e.g., the SU-WTRU may match the service from a list of services authorized to be used via the relay in the current registration area). According to an embodiment, the SU-WTRU may use the provided security parameters (e.g., an authorization token) to check that the R-WTRU is authorized to act as a relay.

[0151] According to an embodiment, in the case where the SU-WTRU is within the range of both the R-WTRU and the SP-WTRU, in addition to the connection with the SP-WTRU, the SU-WTRU may decide whether to establish a connection via the R-WTRU based on any of the relay policies or relay parameters provided. For example, in the case where the SU-WTRU has an existing connection with the SP-WTRU, the SU-WTRU may not perform operations 5-8 on the R-WTRU. According to an embodiment, (e.g., as an alternative), the SU-WTRU may continue with the remainder of the process and may establish a link with the R-WTRU, for example, as a backup to an existing connection (e.g., link) already established with the SP-WTRU. According to an embodiment, (e.g., conversely), if a link with the SP-WTRU is established later, based on the provided relay policy / parameters, the SU-WTRU may decide to release or maintain the link with the R-WTRU.

[0152] According to an embodiment, (e.g., at operation [Sec-A1]) the SU-WTRU may perform a mutual authentication and link security establishment process with the R-WTRU. According to an embodiment, in the case where the mutual authentication and link security establishment process is not successfully completed (e.g., if the S-WTRU cannot authenticate the R-WTRU or establish appropriate security for the link), the S-WTRU may not (e.g., not, cannot, etc.) perform a service-oriented discovery and link establishment process.

[0153] According to an embodiment, at operation 5, the SU-WTRU may send a DCA unicast message to the R-WTRU to confirm the establishment of the L2 link to be used for the relay service. According to an embodiment, (e.g., at operation [Sec-A2]) the R-WTRU may perform a mutual authentication and link security establishment process with the SP-WTRU. According to an embodiment, in the case where the mutual authentication and link security establishment process is not successfully completed (e.g., if the R-WTRU cannot authenticate the SP-WTRU or establish appropriate security for the link), the R-WTRU may discard any relevant stored relay mapping information and may not proceed with the next steps.

[0154] According to an embodiment, at operation 6, e.g., upon receiving the DCA from the SU-WTRU, the R-WTRU may update the relay mapping information to include either the L2 ID or the AID of the SU-WTRU. According to an embodiment, at operation 7, the R-WTRU may use the SP-WTRU L2 ID obtained from the relay mapping information as the destination L2 ID to send a DCA unicast message to the SP-WTRU that includes either a relay indication (e.g., RIND, RID) or the SU-WTRU AID.

[0155] According to an embodiment, at operation 8, e.g., upon receiving the DCA unicast message, the SP-WTRU may determine that the DCA unicast message originated from the R-WTRU (e.g., on behalf of the SU-WTRU) based on, for example, the included relay indication (e.g., RIND, RID). According to an embodiment, it may be expected that the relay indication may be provided in an earlier message, e.g., during either mutual authentication or security establishment. According to an embodiment, the SP-WTRU may determine that the advertised service may be relayed via the R-WTRU based on any of the relay policies or relay parameters provided to it (e.g., which indicate any of the following: relaying is allowed in the current registration area, there are actually no relay restrictions, etc.).

[0156] According to an embodiment, in the case where the SP-WTRU is within the range of both the R-WTRU and the SU-WTRU, the SP-WTRU may decide whether to allow the establishment of a connection via the R-WTRU in addition to the connection with the SU-WTRU based on any of the relay policies or relay parameters provided to it. For example, if the SU-WTRU has an existing connection with the SP-WTRU, the SP-WTRU may not perform link establishment with the R-WTRU.

[0157] According to an embodiment (e.g., as Figure 10(replacement of the signal flow), the R-WTRU may establish a link with the SP-WTRU (e.g., link 1) (e.g., operations 1, 2, Sec-A1, and 7) before establishing another link with the SU-WTRU of interest (e.g., link 2) (e.g., operation 3-6). According to an embodiment, in this case, the relay mapping information may not include (e.g., initially does not include) any SU-WTRU related information (e.g., L2 ID), and for example, when no SU-WTRU is connected to the R-WTRU, the R-WTRU may discard any service data from the SP-WTRU. According to an embodiment, (e.g., when link 1 is successfully established) the R-WTRU may decide to broadcast the DCR on behalf of the SP-WTRU (e.g., Figure 10 Message 3 in

[0158] According to an embodiment, (e.g., once the DCA is received from the SU-WTRU (e.g., Figure 10 Message 5 in

[0159] Link management for non-transparent relay

[0160] According to an embodiment, non-transparent WTRU-to-WTRU relay (e.g., R-WTRU) may be used to perform link identifier updates for unicast links.

[0161] In a case where an R-WTRU is connected to a first WTRU (e.g., UE1) via a first PC5 link (e.g., link 1) and to a second WTRU (e.g., UE2) via a second PC5 link (link 2), independently using an existing (e.g., conventional) link identifier update process on each link (e.g., see above) may pose a potential risk to the privacy of the WTRU identifier. An attacker may attempt to correlate L2 frames (and the included L2 ID) exchanged over one link with frames exchanged over the other link. For example, the attacker may perform traffic analysis to infer that some L2 frames transmitted on link 1 are triggering L2 frames on link 2 (e.g., traffic from the first WTRU (UE1) to the second WTRU (UE2)), and correlate the corresponding L2 IDs (first WTRU, R-WTRU, second WTRU) used on the two links. In this case, if the R-WTRU performs a traditional link identifier update process on link 1 while the identifier used on link 2 remains unchanged, the attacker can indirectly link the old and new identifiers on link 1 via the unchanged identifier on link 2.

[0162] According to an embodiment, for example, to mitigate the above risk, the R-WTRU may coordinate or synchronize the change of the L2 ID between links (e.g., link 1 and link 2) such that the new L2 ID on the first link is always used in combination with the new L2 ID on the second link (and the old L2 ID on link 1 is used in combination with the old L2 ID on link 2).

[0163] Figure 11 is a diagram of an enhanced link identifier update process using a non-transparent R-WTRU according to an embodiment.

[0164] According to an embodiment, in an exemplary enhanced link identifier update process, secure PC5 unicast links may be established (e.g., assumed to be established) between the first WTRU and the R-WTRU and between the R-WTRU and the second WTRU, respectively. According to an embodiment, the WTRUs are assumed Figure 11 to exchange their signaling messages with confidentiality, integrity, and replay protection as shown.

[0165] According to an embodiment, at operation 1101, a first WTRU (e.g., UE1) may initiate a link identifier update procedure with an R-WTRU by sending a newly generated UE1 L2 ID to the R-WTRU in a link identifier update request message. According to an embodiment, at operation 1102, the R-WTRU may store the new UE1 L2 ID and may generate new source L2 IDs for use on link #1 and link #2, respectively. According to an embodiment, at operation 1103 (e.g., contrary to a traditional link update procedure), the R-WTRU may initiate another link identifier update procedure with a second WTRU (e.g., UE2) for link #2 before replying to the first WTRU request. According to an embodiment, the R-WTRU may send a new R-WTRU L2 ID for link #2 to the second WTRU in a link identifier update request message. According to an embodiment, at operation 1104, the second WTRU may store the new R-WTRU L2 ID for link #2 and generate a new UE2 L2 ID. According to an embodiment, at operation 1105, the second WTRU sends the new UE2 L2 ID in a link identifier update response message.

[0166] According to an embodiment, at operation 1106, e.g., upon receiving the link identifier update response message, the R-WTRU may store the new UE2 L2 ID. According to an embodiment, at operation 1107, the R-WTRU sends a new R-WTRU L2 ID for link #1 to the first WTRU in a link identifier update response message. According to an embodiment, at operation 1108, the first WTRU may store the new R-WTRU L2 ID for link #1. According to an embodiment, at operation 1109, the first WTRU may send a link identifier update ACK message to the R-WTRU to confirm receipt of the new R-WTRU L2 ID. According to an embodiment, the R-WTRU may send a link identifier update ACK message to the second WTRU to confirm receipt of the new UE2 L2 ID. According to an embodiment, at operation 1110, the WTRU may start using the new IDs on link #1 and link #2. According to an embodiment, e.g., instead of (e.g., as an alternative to) using an acknowledgement message (e.g., operation 1109), the first WTRU may (e.g., implicitly) maintain the old IDs as long as there is ongoing communication using the old IDs. According to an embodiment, after communication starts using the new IDs, the WTRU may hold the old IDs for a time limit (e.g., UTC time) (e.g., specific, agreed upon, configured, etc.) to account for potential frames using the old IDs that may still be in transit (e.g., being retransmitted).

[0167] Figure 12FIG. is a diagram showing an enhanced link identifier update process using a non-transparent R-WTRU according to an embodiment.

[0168] According to an embodiment, with reference to Figure 12 , there may be a case where the R-WTRU initiates a link identifier update process. According to an embodiment, for example, as a difference from Figure 8 , as shown in Figure 12 , the R-WTRU may initiate simultaneous (e.g., two or more) processes on multiple links (e.g., Link #1 and Link #2 respectively). According to an embodiment, the R-WTRU may, for example, in the case of receiving a link identifier update response message from a first WTRU (e.g., UE1) and a second WTRU (e.g., UE2), synchronize the use of the new ID on Link #1 and Link #2 by sending an acknowledgement message (see operation 5 in Figure 12 ). Using transparent WTRU-to-WTRU relay for service-oriented discovery and communication

[0169] According to an embodiment, the R-WTRU may receive a message from the SP-WTRU, which may occur when the SU-WTRU is too far away and, for example, the SU-WTRU does not receive these messages. According to an embodiment, in such a case, the R-WTRU may retransmit these messages, for example so that they can be received by the SU-WTRU. According to an embodiment, this may be repeated in the other direction, i.e., from the SP-WTRU to the SU-WTRU. According to an embodiment, the R-WTRU may update either the source or destination field / value (e.g., source / destination L2 ID) and may forward the information of the updated field / value. According to an embodiment, the R-WTRU may not "consume" the message, or in other words, the R-WTRU may not (e.g., cannot) view the content of the received message, verify the integrity and / or decrypt the received message, and sign and / or encrypt the message it forwards. According to an embodiment, a security association may be established end-to-end, for example, between the SP-WTRU and the SU-WTRU.

[0170] Control plane stack and user plane stack

[0171] Figure 13 FIG. is a diagram of a control plane stack supporting a transparent R-WTRU according to an embodiment.

[0172] According to an embodiment, (e.g., as opposed to a non-transparent relay / R-WTRU), a transparent R-WTRU may use its self-generated own (e.g., anonymous) L2 ID, which is inserted as a source L2 ID in an already formed L2 frame relayed between WTRUs (e.g., WTRU1 and WTRU2). According to an embodiment, for example, similar to a non-transparent relay, the L2 frame may be forwarded based on the mapped WTRU L2 IDs (e.g., WTRU1 L2ID, WTRU2 L2 ID). According to an embodiment, in the case of a transparent R-WTRU, security may be established end-to-end between the WTRUs (e.g., WTRU1 and WTRU2), e.g., as Figure 13 shown, where the PDCP layer terminates in WTRU1 and WTRU2 and not in the R-WTRU. According to an embodiment, (e.g., as a result of PDCP layer termination), the R-WTRU may not process any security of an incoming signaling packet (e.g., a signaling packet from WTRU1 destined for WTRU2) before forwarding the incoming signaling packet in the L2 frame using its own L2 ID as the source ID and the L2 ID of the target WTRU according to the relay mapping information (e.g., the L2 ID of WTRU2).

[0173] Figure 14 is a diagram according to an embodiment showing a user plane stack supporting a transparent R-WTRU. According to an embodiment, referring to the user plane stack, for the control plane, the R-WTRU does not process and / or apply any security to incoming / outgoing relay IP packets.

[0174] Link Establishment

[0175] Peer Discovery and Unicast Link Communication Establishment

[0176] According to an embodiment, in the case of a service-oriented approach, the SP-WTRU may broadcast services (e.g., the services it supports) in a unicast link establishment request message (e.g., a DCR message), and the SU-WTRU interested in the service may respond (e.g., reply to the message) by triggering security context establishment and sending a unicast link acceptance message (e.g., a DCA message). According to an embodiment, a user-oriented approach that specifies the application ID of the SU-WTRU instead of the service ID in the broadcast message may be used (e.g., may also be used, etc.). According to an embodiment, the SP-WTRU may broadcast services (e.g., the services it supports) in a discovery message (e.g., either an advertisement message or a discovery response), and the SU-WTRU interested in the service may respond by sending a unicast link establishment request message (e.g., a DCR message). According to an embodiment, a service-oriented approach is used to describe the behavior of any of the SP-WTRU, SU-WTRU, and R-WTRU, and these features may (e.g., may also) be applied to either a user-oriented approach or a discovery approach.

[0177] According to an embodiment, (e.g., compared to, for example, a traditional service-oriented approach), in the case of either a user-oriented approach or a discovery approach (e.g., as described in the above embodiments), the R-WTRU may be used between the SP-WTRU and the SU-WTRU. According to an embodiment, neither the SP-WTRU nor the SU-WTRU may (e.g., may not) know the L2 ID of their peer WTRU. According to an embodiment, the WTRU sends messages to the R-WTRU and receives messages from the R-WTRU. According to an embodiment, a security association and a unicast link are established (e.g., only) between the SP-WTRU and the SU-WTRU, and in this case, the R-WTRU may (e.g., only, merely) forward messages.

[0178] According to an embodiment, the SP-WTRU may advertise (e.g., its) supported services and / or may use a (e.g., normal) discovery mechanism to discover the SU-WTRU, which may be performed, for example, using a user-oriented or service-oriented approach as described above. According to an embodiment, the SP-WTRU may detect that the communication is passing through the R-WTRU by obtaining a relay identifier (e.g., an RID, RIND that may be used as a relay indication) on the received message. According to an embodiment, the SP-WTRU establishes a secure unicast link with the SU-WTRU via the R-WTRU. According to an embodiment, the SP-WTRU (e.g., additionally) establishes a secure unicast link with the R-WTRU for link management (e.g., for any of link identifier update, modification, release, etc.).

[0179] According to an embodiment, when a unicast link is established between peer WTRUs and the R-WTRU can act as a relay for the link, the R-WTRU can assign two R-L2 IDs to itself. According to an embodiment, when forwarding a message from a first WTRU to a second WTRU, the first R-L2 ID can be used. According to an embodiment, when forwarding a message from the second WTRU to the first WTRU, the second R-L2 ID can be used. According to an embodiment, the R-WTRU can maintain a mapping table, for example, the mapping table includes the mapping of peer WTRU L2 IDs (e.g., either the SP-L2 ID and the SU-L2 ID) and the corresponding (e.g., two) R-L2 IDs that have been self-assigned. According to an embodiment, for example, when receiving a message, the R-WTRU can use the L2 ID specified in the destination field (e.g., its R-L2 ID). According to an embodiment, the R-WTRU can (e.g., additionally) use the sending WTRU L2 ID, for example, to find the relevant mapping entry in its mapping table. According to an embodiment, the R-WTRU can (e.g., then) update the source and destination fields of the message with its own R-L2 ID and the L2 ID of the peer WTRU before forwarding the message. According to an embodiment, the R-WTRU can (e.g., also) add its RID to the DCR message and / or discovery message it forwards. According to an embodiment, the R-WTRU can (e.g., also) reply to the broadcast DCR message to establish a unicast management link with the SP-WTRU. According to an embodiment, the R-WTRU can use another self-assigned R-L2 ID for this management link and can specify its relay identifier (RID).

[0180] According to an embodiment, the SU-WTRU can discover the SP-WTRU via the R-WTRU. According to an embodiment, for example, by using any of a user-oriented method, a service-oriented method, and a discovery process, a traditional (e.g., normal) discovery mechanism can be used. According to an embodiment, the SU-WTRU can receive either a broadcast DCR message with an RIND or a discovery message with an RIND, and such an RIND can be an RID. According to an embodiment, the SU-WTRU can establish a secure unicast link with the SP-WTRU via the R-WTRU. According to an embodiment, link management can be accomplished via any communication with the SP-WTRU or via the secure unicast link with the R-WTRU.

[0181] Figure 15 is a diagram showing discovery and unicast link establishment according to an embodiment.

[0182] According to an embodiment, with reference to Figure 15, service-oriented discovery can be performed and a unicast link can be established between the SP-WTRU and the SU-WTRU via the R-WTRU. According to an embodiment, with reference to Figure 15 , the SU-WTRU can reply to the received DCR by sending a direct security mode (DSM) command message (e.g., as described above).

[0183] According to an embodiment, at operation 1501, the R-WTRU can register with the network and can specify its R-WTRU capabilities. According to an embodiment, the R-WTRU can be provided with relay policy parameters from the network. According to an embodiment, at operation 1502, the SU-WTRU can determine a destination L2 ID (e.g., a broadcast L2 ID) associated with any of the applications and services they are interested in receiving and can configure the lower layers to receive such messages. According to an embodiment, at operation 1503, the application layer can provide information to the ProSe layer for PC5 unicast communication (e.g., any of a broadcast L2 ID, a service ID, an application ID of the WTRU, etc.). According to an embodiment, at operation 1504, the ProSe layer can trigger a peer WTRU discovery mechanism, which can be performed, for example, by sending a broadcast DCR message. According to an embodiment, the broadcast DCR message can include any of an SP-L2 ID as the source, a broadcast L2 ID as the destination, and other parameters related to the provided applications and services. According to an embodiment, operations 1505 and 1507 can be optionally performed. For example, according to an embodiment, if a secure link (e.g., already) exists between the SP-WTRU and the R-WTRU for SP-L2 ID1, these operations 1505 - 1507 can be skipped. More details regarding the use of link management are described herein.

[0184] According to an embodiment, at operation 1505, the R-WTRU may receive a broadcast DCR message and may verify whether it can (e.g., whether it is configured to) relay (e.g., this) application and / or service. According to an embodiment, the R-WTRU may compare the announced service with any of the relay policies or relay parameters it is provided with (e.g., look for a match). According to an embodiment, in the case of a match, the R-WTRU may self-assign an R-L2 ID (e.g., R-L2 IDa, where IDa refers to the self-assigned ID) for the management link with the SP-WTRU. According to an embodiment, the R-WTRU may reply to the received DCR message, e.g., to establish a secure unicast link for managing other unicast links related to the broadcast DCR message from the SP-WTRU. According to an embodiment, such other unicast links may be established between the SP-WTRU and the SU-WTRU, and the link may be relayed by the R-WTRU. According to an embodiment, at operation 1506, the R-WTRU and the SP-WTRU may establish a security context. According to an embodiment, the R-WTRU may specify (e.g., that) the link is established for link management. According to an embodiment, the R-WTRU may (e.g., also) specify its unique relay ID (e.g., RID), which uniquely identifies the R-WTRU and serves as a relay WTRU indication (e.g., RIND). According to an embodiment, (e.g., all) R-WTRUs may (e.g., should, must, ought to, etc.) be provided with a unique identifier (e.g., RID). According to an embodiment, the R-WTRU may include its RID in a confidentiality-protected message (e.g., DCA) to protect R-WTRU privacy. According to an embodiment, at operation 1507, e.g., in the case where the security context is established, the unicast link establishment may be completed.

[0185] According to an embodiment, at operation 1508, the R-WTRU may (e.g., continue to) forward the broadcast DCR message received from the SP-WTRU. According to an embodiment, when forwarding a message from the SP-WTRU to the SU-WTRU, the R-WTRU may self-assign an R-L2 ID (e.g., R-L2 IDa) to be used as a replacement for the SP-L2 ID (e.g., SP-L2 ID1). According to an embodiment, these (e.g., tow) IDs may be saved in a local mapping table. For example, the R-WTRU may override the source field with its R-L2 IDa and may add its RID. According to an embodiment, the R-WTRU may (e.g., be capable of) detecting the direction from which the message is received (e.g., the direction from which the message is received). According to an embodiment, in this case, the R-WTRU may maintain the reception direction and the SP-L2ID in the mapping table.

[0186] According to an embodiment, at operation 1509, if another direction is available, the R-WTRU may send a modified DCR message in the other direction (e.g., not to the initial sender / SP-WTRU) with its R-L2 IDa as the source. According to an embodiment, any of the SU-WTRUs (e.g., see Figure 15 , SU-UE1, SU-UE2, and SU-UE3) may receive the broadcast message. According to an embodiment, at operation 1510, the SU-WTRU2 may be interested in such a service (e.g., the service advertised in the DCR), and may reply to the R-WTRU, for example, by transmitting a DSM command message to establish a security context with the SP-UE. According to an embodiment, the SU-WTRU2 may track the R-L2 IDa and the RID. According to an embodiment, for example, the RID may be specified using the DSM command message such that the SP-WTRU knows that the link is through this R-WTRU when it receives the message.

[0187] According to an embodiment, at operation 1511, the R-WTRU may receive the DSM command message and may use the R-L2 IDa specified in the destination field to find the relevant entry in its mapping table. According to an embodiment, in the case where the mapping entry does not have an associated (e.g., any) SU-WTRU, the R-WTRU may update the mapping entry with the L2 ID (e.g., SU-L2 ID2) specified in the source field, and according to an embodiment, the R-WTRU may (e.g., additionally) track the direction (e.g., from where) from which the message was received, which may occur, for example, if such information is available. According to an embodiment, when forwarding a message from SU-L2 ID2 to SP-L2 ID1, the R-WTRU may self-assign a new R-UE L2 ID2b for use. According to an embodiment, this new R-L2 IDb may (e.g., also) be saved in the mapping entry. According to an embodiment, the R-WTRU may set the source field or the adaptation layer field of the message to R-L2IDb, and the R-WTRU may set the destination field to the SP-L2 ID1 retrieved from the mapping entry.

[0188] According to an embodiment, the R-WTRU may not (e.g., not) view or modify the content of the message and may, for example, only modify the source and destination fields of the message. According to an embodiment, for example, upon receiving a DSM command message, the R-WTRU may create a new entry in a table using the same R-L2 ID specified in the destination field, which may occur, for example, in a situation where the entry is already associated with another SU-WTRU, e.g., another SU-WTRU has replied to the broadcast message and a unicast link has been established. According to an embodiment, in a case where multiple entries associated with the R-L2 ID are found in the mapping table, as described below, the R-WTRU may look up the SU-L2 ID in addition to looking up the R-L2 ID. According to an embodiment, at operation 1512, the R-WTRU may send the modified message to the SP-WTRU, which may occur, for example, in any direction in the direction associated with that L2 ID or in a direction other than the direction in which it was received.

[0189] According to an embodiment, at operation 1513, the SP-WTRU may receive the DSM command message, may track the R-L2 IDb and RID, and may reply with a DSM complete message. According to an embodiment, the RID may be specified on the DSM complete message, which may be sent to the R-WTRU. According to an embodiment, at operation 1514, the R-WTRU may receive the DSM command message and may find the corresponding entry in its mapping table (e.g., corresponding to the destination field R-L2IDb). According to an embodiment, if available, the R-WTRU may obtain the associated SU-L2 ID2 and direction from that corresponding entry. According to an embodiment, the R-WTRU may (e.g., then) modify the message to specify the SU-L2 ID2 as the destination (e.g., address / identifier) and its R-L2 ID1 as the source (e.g., address / identifier). According to an embodiment, at operation 1515, the R-WTRU may (e.g., then) forward the DSM command message to the SU-WTRU2, i.e., in the direction of the SU-WTRU2 or in a direction other than the direction in which it was received.

[0190] According to an embodiment, at operation 1516, the SU-WTRU2 may (e.g., then) complete the unicast link establishment, for example, by sending a DCA message to the R-WTRU. According to an embodiment, the RID may be specified (e.g., included) in the DCA message. According to an embodiment, at operation 1517, the R-WTRU may receive the message and may (e.g., again) look up in its mapping table to find an entry corresponding to the destination field. According to an embodiment, in the case of finding the entry, the R-WTRU may modify the message, for example, by setting either the source field or the adaptation layer field of the message to the R-L2 IDb based on (e.g., according to, as specified / found therein, etc.) the mapping entry, and by setting the destination field to the SP-L2 ID1 based on the mapping entry. According to an embodiment, at operation 1518, the R-WTRU may send the modified message to the SP-WTRU, for example, in any direction in the direction associated with the L2 ID or in a direction different from the direction from which it may receive the modified message. According to an embodiment, at operation 1519, a unicast link may be established between the SP-WTRU and the SU-WTRU2 via the R-WTRU. According to an embodiment, the link is secure, for example, such that a security context is created between the WTRUs. According to an embodiment, encrypted and / or integrity-protected messages (e.g., data or PC5-S messages) may be exchanged between the SP-WTRU and the SU-WTRU2. According to an embodiment, the R-WTRU may not be involved in this security association, and thus, for example, it cannot read and / or modify the secure part of the message (e.g., which does not include the source / destination fields).

[0191] Figure 16 is a diagram showing discovery and unicast link establishment according to an embodiment.

[0192] Reference Figure 16 , the SU-WTRU may trigger unicast link establishment, for example, in response to discovery. According to an embodiment, the SP-WTRU may broadcast (e.g., supported) services in a unicast link establishment request message (e.g., a DCR message or a discovery message). Further, according to an embodiment, the SU-WTRU interested in the service replies to the broadcast DCR or discovery message by triggering unicast link establishment with the SP-WTRU (e.g., by sending a DCR message). According to an embodiment, the initiation of security context establishment (e.g., a DSM command message) and the sending of a unicast link acceptance message (e.g., a DCA message) may be done by the SP-WTRU.

[0193] Reference Figure 16 , according to an embodiment, discovery and unicast link / communication establishment may be similar (e.g., the same) as shown in Figure 15 and may include the following forFigure 16 Any operations and modifications discussed in the operations shown. According to an embodiment, at operation 1607, the SU-WTRU may send a DCR message, for example, in response to a received broadcast DCR or discovery message. In this case, according to an embodiment, the SU-WTRU may send the DCR message to the broadcast R-L2 ID. According to an embodiment, the R-WTRU looks up its mapping table, searches for the specified R-L2 ID, and adds the received SU-L2 ID to the table entry, for example, in a manner similar to what is done when receiving a DSM command message (e.g., Figure 14 operation 1507). According to an embodiment, at operation 1609, the SP-WTRU may receive a DCR message and may reply by sending a DSM command message at operation 1610. According to an embodiment, at operation 1613, the SU-WTRU sends (e.g., returns) a DSM completion message, and the SP-WTRU may complete unicast link establishment by sending a DCA message (e.g., at operation 1616). According to an embodiment, at operations 1609, 1612, 1615, and 1617, the R-WTRU may (e.g., merely) forward messages between the SP-WTRU and the SU-WTRU, which may be done, for example, by replacing the source and destination and possibly the adaptation layer fields with appropriate values based on the information stored in its mapping table.

[0194] Multiple SU-WTRUs establish unicast links with the SP-WTRU

[0195] Figure 17 is a diagram showing a second unicast link establishment according to an embodiment.

[0196] Referring Figure 17 , a second SU-WTRU may be interested in the services broadcast by the SP-WTRU. According to an embodiment, the R-WTRU may create a new mapping in its table and may assign a new R-L2 ID to itself, for example, to forward messages from a third SU-WTRU3 to the SP-WTRU. According to an embodiment, at operation 1701, the SP-WTRU may announce services (e.g., any number of supported services) by triggering a peer WTRU discovery mechanism (e.g., by sending a broadcast DCR or discovery message). According to an embodiment, the broadcast DCR or discovery message may include any of the following: the SP-L2ID1 as the source, the broadcast L2 ID as the destination, and other parameters related to any of the provided applications and services.

[0197] According to an embodiment, at operation 1702, the R-WTRU may receive the broadcast message and may verify whether the R-WTRU is configured to relay any of the applications or services announced by the message. According to an embodiment, in the case where any of the applications or services match (e.g., the R-WTRU is configured to relay any of the applications or services), the R-WTRU may continue to forward the message. According to an embodiment, the R-WTRU may assign itself an R-L2 ID (e.g., R-L2IDa), for example, to be used as a replacement for the SP-L2 ID (e.g., SP-L2 ID1) when forwarding a message from the SP-WTRU. According to embodiments, these (e.g., two) IDs may be stored in a local mapping table. According to an embodiment, the R-WTRU may overwrite the source field with its R-L2IDa and may add an RID. According to an embodiment, for example, if the management link with the SP-WTRU does not yet exist (e.g., as described above), the R-WTRU may establish such a link with the SP-WTRU.

[0198] According to an embodiment, at operation 1703, other messages may be exchanged (e.g., as Figure 15 shown), and a unicast link may be established between the SP-WTRU and the SU-WTRU2 via the R-WTRU. According to an embodiment, the SP-WTRU and the R-WTRU may interact together using, for example, SP-L2 ID1 and R-L2 IDb respectively. According to an embodiment, the SU-WTRU2 and the R-WTRU may interact together using, for example, SU-L2ID2 and R-L2 IDa respectively. According to an embodiment, the R-WTRU may maintain a mapping table, for example, replacing SP-L2 ID1 with R-L2 IDa, and replacing SU-L2 ID2 with R-L2 IDb. According to an embodiment, at operation 1704, the SU-WTRU3 may (e.g., also) be interested in the services provided by the SP-WTRU (via the R-WTRU), and the SU-WTRU3 may send any of the DCR or DSM command messages to the R-WTRU (e.g., to R-L2 IDa) using SU-L2ID3. According to an embodiment, any of the DCR and DSM command messages may be sent as described herein.

[0199] According to an embodiment, at operation 1705, the R-WTRU may look up (e.g., search, read, check, etc.) the R-L2 IDa in its mapping table. According to an embodiment, in the case where an entry is found but the entry is being used by the S-WTRU2 (e.g., indicating SU-L2ID2), the R-WTRU may create a new entry in the mapping table. According to an embodiment, either the R-L2 IDa or the SU-L2 ID3 may be saved in the mapping table. According to an embodiment, the R-WTRU may learn that the SP-WTRU is identified as SP-L2 ID1, for example, from the first entry it discovers in the SU-WTRU2. According to an embodiment, this may also be saved in the new entry. According to an embodiment, the R-WTRU may assign a new L2 ID to itself, e.g., R-L2IDc, which may (e.g., also) be saved in the mapping entry and may be used as a replacement for the SU-L2 ID3, which may occur, for example, when forwarding a message to the SP-WTRU3. According to an embodiment, at operation 1706, messages may be exchanged between the R-WTRU and the SP-WTRU using the R-L2 IDc and the SP-L2 ID1, respectively.

[0200] According to an embodiment, messages may be exchanged according to the method highlighted at operation 1704, and for example, the message may be any of the following: advertisement, discovery request, discovery response, authentication request, authentication response, DSM command, DSM completion, DCR, and DCA. According to an embodiment, at operation 1707, messages may be exchanged between the R-WTRU and the SU-WTRU3 using the R-L2 IDa and the SU-L2 ID3, respectively. According to embodiments, messages may be exchanged in a similar manner as stated with respect to operation 1706. According to an embodiment, at operation 1708, a second unicast link may be established from the SP-WTRU side, e.g., this time via the R-WTRU to establish a second unicast link with the SU-WTRU3. According to an embodiment, the SP-WTRU and the R-WTRU may interact together using either the SP-L2 ID1 or the R-L2 IDc. According to an embodiment, the SU-WTRU2 and the R-WTRU may interact together using the SU-L2 ID3 and the R-L2 IDa.

[0201] Link Management

[0202] According to an embodiment, when using an R-WTRU between two peer WTRUs, link management may be (e.g., required, must, etc.) supported. According to an embodiment, link management may include any of the following (e.g., functionality, function, operation, feature, etc.): keep-alive, link identifier update, link release, link modification, and new services, new QoS, etc. According to an embodiment, link management may be (e.g., required) between (e.g., two) ends (e.g., endpoints, termination points, etc.) of a unicast link (e.g., between an SP-WTRU and an SU-WTRU). According to an embodiment, a unicast link security association may be (e.g., only) between an SP-WTRU and an SU-WTRU, and in this case, the L2 ID for sending / receiving messages is between the R-WTRU and the SP-WTRU / SU-WTRU. According to an embodiment, for example, in the above case, when updating the L2 ID on the SP-UE, the updated L2 ID may be (e.g., required, should, etc.) notified to the R-WTRU.

[0203] According to an embodiment, in the case of using a unicast link through an R-WTRU (e.g., using the transparent R-WTRU method as described above), the R-WTRU may (e.g., not know) which messages (e.g., link identifier updates) are exchanged between (e.g., two) WTRUs because these messages may be encrypted; and (e.g., only) the peer WTRU can decrypt the message. According to an embodiment, the R-WTRU may (e.g., only) access the unprotected part of the message, such as either the source L2 ID or the destination L2 ID. However, according to an embodiment, the SP-WTRU and the SU-WTRU may not (e.g., not) know the L2 ID of their peer WTRU, and in this case, these WTRUs may use the L2 ID of the R-WTRU to send messages.

[0204] According to an embodiment, in order to be able to manage the links through the R-WTRU, a unicast link can be established (e.g., managed) between the WTRU (such as an SP-WTRU and / or an SU-WTRU) and the R-WTRU. According to an embodiment, the unicast link can be a management link for managing other links, such as links that pass through the R-WTRU and are associated with the same RID as the management link. According to an embodiment, the management link can be protected (e.g., integrity, replay, and confidentiality are protected) between the SP-WTRU and the R-WTRU. According to an embodiment, existing messages for any of link identifier update, link modification, and link release can be updated, for example, to be able to notify the R-WTRU about any changes on the relayed unicast link. According to an embodiment, for example, for authentication purposes, a management link can be established between the SP-WTRU and the R-WTRU and between the R-WTRU and the SU-WTRU. That is, according to an embodiment, in the case of establishing a management link, an authentication process is performed, allowing the SP-WTRU and the R-WTRU to authenticate each other, and such an authentication process (e.g., the same authentication process) applies to the management link between the R-WTRU and the SU-WTRU. According to an embodiment, the relayed unicast link (e.g., the link between the SP-WTRU and the SU-WTRU) remains as discussed above (e.g., as defined). That is, the relayed unicast link can be between (e.g., two) peer WTRUs, where the R-WTRU (e.g., only) forwards messages without involving any encryption or decryption, etc.

[0205] According to an embodiment, there can be at least two ways to support link management, including any of the following: 1) using a single management link to manage the link between the SP-WTRU and the SU-WTRU; and 2) multiple management links, for example, on each WTRU (such as each SP-WTRU and SU-WTRU). According to an embodiment, for example, in the case where a process that requires a management link is completed, the management link can be released. According to an embodiment, the management link can be maintained. According to various embodiments, in the case of maintaining the management links, they can be considered (e.g., just like) any other links, such that their L2 IDs can (e.g., need to) be updated periodically, etc. According to an embodiment, for example, by using the link identifier update process as an example, how to use the management links based on these two methods is discussed herein.

[0206] According to an embodiment, a single management link can be established between an SP-WTRU (e.g., which has broadcast DRC) and an R-WTRU, for example, while no management link is established between the R-WTRU and an SU-WTRU (one or more) at the same time. According to an embodiment, in this case, the SU-WTRU (one or more) can communicate with the SP-WTRU for link management, and the SP-WTRU can transmit link information to the R-WTRU via the management link and transmit the information received from the R-WTRU back to the SU-WTRU. According to an embodiment, there can be any number of (e.g., multiple, plural) management links, including, for example, a first management link between the SP-WTRU and the R-WTRU, and a second management link between the R-WTRU and the SU-WTRU. According to an embodiment, in this case, for example, as stored in its local mapping table, the R-WTRU can have a first management link with the SP-WTRU and a second management link with the SU-WTRU (e.g., according to the SU-L2 ID).

[0207] According to an embodiment, the L2 link identifier can be updated, for example, via the management link. According to an embodiment, the SP-WTRU and the SU-WTRU can establish a unicast link, and their identifiers (e.g., L2 ID, security information, etc.) can (e.g., must, need, should, etc.) be changed periodically for privacy reasons. According to an embodiment, the process for supporting the above L2 ID update is provided. According to an embodiment, during such a process, other identifiers (e.g., application layer ID, IP address / prefix, etc.) can (e.g., also) be changed. According to an embodiment, in the case where the R-WTRU is involved between two WTRUs and uses its L2 ID for relay purposes, the R-WTRU can (e.g., must, should, need, etc.) (e.g., also) update its L2 ID in the same manner as either the SU-WTRU or the SP-WTRU. That is, according to an embodiment, the R-WTRU can (e.g., must also) periodically change the L2 ID it uses, for example, these L2 IDs are associated with the unicast link. According to an embodiment, in the case where any peer WTRU changes its L2 ID (e.g., once changed, when changed), the R-WTRU can periodically change (e.g., update) the L2 ID.

[0208] According to an embodiment, for example, to ensure that a malicious WTRU cannot associate an old L2 ID with a new L2 ID, all WTRUs involved in a unicast link may (e.g., must, should, need to, etc.) change their identifiers (e.g., L2 ID, security information, and (e.g., optionally) application layer ID and IP address / prefix) simultaneously. According to an embodiment, in the case where an R-WTRU replaces its own L2 ID when forwarding a message, the R-WTRU may (e.g., should, must, etc., also) change its L2 ID. In this case, the R-WTRU may not (e.g., does not need to) change other identifiers during such a process, e.g., because the other identifier is only known to two peer WTRUs. For example, in the case of establishing security end-to-end (e.g., between two peer WTRUs), the R-WTRU may not (e.g., does not need to) update any security information.

[0209] According to an embodiment, as discussed herein, a management link may be used to perform a link identifier update process. According to an embodiment, an existing link identifier update message is modified to additionally include any of the following: 1) other link information; 2) an associated current L2 ID; and 3) an associated new L2 ID. Additionally, according to an embodiment, information about multiple links may be specified. According to an embodiment, as discussed herein, two solutions are proposed (e.g., regarding the management link): 1) a single management link to an R-WTRU, and 2) multiple management links to an R-WTRU. According to an embodiment, in the case where the link identifier update process (e.g., only, solely, etc.) runs on one WTRU (e.g., an SP-WTRU) while other WTRUs (e.g., any of an R-WTRU and an SU-WTRU) do not have to change their L2 ID. According to an embodiment, in such a case, any of the solutions using a single management or multiple management links described above may be used.

[0210] According to an embodiment, there may be a case of a single management link. According to an embodiment, for example, as described above, the SP-WTRU may have a management link established with the R-WTRU for managing the link relayed by the (e.g., specific) R-WTRU. For example, the SP-WTRU may have broadcast the specific services it supports (e.g., broadcast via a DCR message using the SP-L2 IDx), and multiple SU-WTRUs interested in that service may have established unicast links with the SP-WTRU via the R-WTRU. In this case, these unicast links may be associated with the SP-L2 IDx, and for example, in addition to its own SP-L2ID update, the SP-WTRU may be responsible for updating the R-WTRU with the L2ID updates of its peer WTRUs. According to an embodiment, the SU-WTRU may share its L2-ID (e.g., current value and updated value) with the SP-WTRU, such that the SP-WTRU can notify the R-WTRU of these IDs. According to an embodiment, the SP-WTRU may send the updated R-L2 ID back to the appropriate SU-WTRU.

[0211] Figure 18 FIG. is a diagram showing a link identifier update process (single management link) initiated by the SP-WTRU on all WTRUs according to an embodiment.

[0212] According to an embodiment, at operation 1801, a unicast link may be established between peer WTRUs via the R-WTRU. According to an embodiment, the SP-WTRU may maintain a link table having any of the following: its L2 ID (e.g., SP-L2 ID1), the relay L2 ID (e.g., R-L2 ID), and an indication that the link is relayed by the R-WTRU (e.g., either RIND or RID). According to an embodiment, the SU-WTRU may also maintain a link table having any of the following: its L2 ID (e.g., SU-L2ID2), the relay L2 ID (e.g., R-L2 IDa), and an indication that the link is relayed by the R-WTRU (e.g., RID, RIND). According to an embodiment, the R-WTRU may maintain a mapping table that contains any of the following: the SP L2 ID (e.g., SP-L2 IDa) and the associated relay L2 ID of the R-WTRU (e.g., R-L2 IDa), and the SU-L2 ID (e.g., SU-L2 ID2) and its associated relay L2 ID (e.g., R-L2 IDb).

[0213] According to an embodiment, at operation 1802, the SP-WTRU may receive a trigger (e.g., timer expiration) to update its SP-L2 ID1, which may be associated with a unicast link established with a SU-WTRU via an R-WTRU (e.g., R-L2 IDb). According to an embodiment, at operation 1803 (e.g., which may be considered an optional operation / process), the SP-WTRU may establish a secure unicast link with the R-WTRU, e.g., for link management purposes, which may occur, for example, if such a link has not been established yet. According to an embodiment, for this management link, the SP-WTRU may assign a new L2 ID (e.g., SP-L2 ID3) for itself and may use a known relay L2 ID (e.g., R-L2 IDb). According to an embodiment, the management link may be established with the R-WTRU (identified by RID) that processes the link that needs to be updated.

[0214] According to an embodiment, at operation 1804, the SP-WTRU may assign a new SP-L2 ID2 for itself to replace SP-L2 ID1. According to an embodiment, the SP-WTRU may send a link identifier update request to the R-WTRU, e.g., to notify the R-WTRU about the current and new L2 IDs of the SP-WTRU and to request information about the unicast link (e.g., relay link) associated with the SU-WTRU. According to an embodiment, an indication for another link may be specified, e.g., to indicate that the message includes information related to a link different from the link on which the message is being transmitted. According to an embodiment, the SP-WTRU may specify the current L2 IDs (e.g., SP-L2 ID1 and R-L2 ID) identifying the other link and the new SP-L2 ID2. According to an embodiment, a GetPeer indication may be specified to indicate that information from the SU-WTRU (e.g., the R-L2 ID and S-L2 ID associated with this link) should be returned so that it can be sent to the SU-WTRU. According to an embodiment, the SP-WTRU does not have this information as it is through the R-WTRU.

[0215] According to an embodiment, at operation 1805, the R-WTRU may receive the request and may find an entry in its mapping table. According to an embodiment, the R-WTRU may obtain information related to other parts of the link, such as the SU-L2 ID and the associated R-L2 ID. According to an embodiment, the R_WTRU may (e.g., then) assign two new L2 IDs to itself, namely, the R-L2 IDd associated with the link to the SP-WTRU (e.g., other links) and the R-L2 IDc associated with the link to the SU-WTRU. According to an embodiment, the R-WTRU may reply to the SP-WTRU by sending a link identifier update response message that has an other link indication, followed by the new R-L2 IDd, and optionally has a new SP-L2ID for acknowledging it, and has a GetPeer indication, followed by its new R-L2 IDc. According to an embodiment, at operation 1806, the SP-WTRU may use the link identifier update request to send the new R-L2 IDc information to the SU-WTRU. According to an embodiment, the link identifier update request may be used to send other identifiers that may be updated. For example, security information (e.g., the MSB of the K NRP-sess ID, and (optionally) the application layer ID and the IP address / prefix).

[0216] According to an embodiment, at operation 1807, the SU-WTRU may self-assign a new SU-L2 ID3, may save the new R-L2 IDc (and / or other updated identifiers) it received, and may send a link identifier update response message including its new SU-L2 ID3 to the SP-UE. According to an embodiment, the SU-WTRU may (e.g., also) include the information received on the request message, such as to ACK the request message. According to an embodiment, such a message may (e.g., also) be used to send other identifiers that may be updated. For example, security information (e.g., K NRP-sessThe LSB of the ID and (optionally) the application layer ID and IP address / prefix). According to an embodiment, at operation 1808, the SP-WTRU that receives the message may save the received updated identifier and may update the R-WTRU with the new SU-L2 ID3. According to an embodiment, the update may be identified by using a "GetPeer" indication. According to an embodiment, the SP-WTRU may (e.g., also) include the new R-L2 IDd received on a previous response message (e.g., see operation 1805) to confirm it. According to an embodiment, (e.g., additionally) a validity time may be specified, e.g., to indicate the actual time when to start using the new L2 IDs from the SP-WTRU, R-WTRU, and SU-WTRU. According to an embodiment, this may ensure that all involved WTRUs start using the new L2 IDs simultaneously. According to an embodiment, at operation 1809, the SP-WTRU may (e.g., also) send a link identifier update ACK message to the SP-WTRU to, for example, provide the validity time.

[0217] According to an embodiment, any of the current SP-L2 ID and R-L2 ID may be used to identify other links (e.g., the link between the SP-WTRU and the SU-WTRU). According to an embodiment, once the R-WTRU identifies the entry, it may return a reference number (e.g., a link number) to be used on all other relevant messages. According to an embodiment, an alternative solution may be to switch the event sequence such that the SP-WTRU may first query its peer SU-WTRU to obtain its new L2 ID and then notify the R-WTRU of the new SU-L2 ID and its new SP-L2 ID. In this case, the R-WTRU may (e.g., then) provide its new R-L2 ID (e.g., for each side of the relay). According to an embodiment, the SP-WTRU may (e.g., then) send the relevant R-L2 ID to the SU-WTRU.

[0218] According to an embodiment, the SU-WTRU may initiate a link identifier update process on all WTRUs. According to an embodiment, in the case where the link identifier update process is initiated by the SU-WTRU, this may be similar to the above update process. That is, according to an embodiment, the SU-WTRU may send a message to the SP-WTRU, the SP-WTRU may forward the message to the R-WTRU via the management link, and the SP-WTRU may reply to the SU-WTRU with the new R-L2 ID from the R-WTRU. According to an embodiment, the SU-WTRU may specify the RID in its message so that the SP-WTRU uses the management link associated with the corresponding R-WTRU.

[0219] According to an embodiment, there may be a case where only the L2 ID of the SP-WTRU is changed. According to an embodiment, the SP-UE may initiate a link identifier update procedure only for its own L2 ID (e.g., without causing any R-WTRU or SU-WTRU to change its L2 ID simultaneously). According to an embodiment, this may be similar to that described above, except that additional link indications and the current SP-L2 and R-L2 IDs and the new SL-L2 ID are added.

[0220] According to an embodiment, there may be a case where only the L2 ID of the SU-WTRU is changed. According to an embodiment, the SU-WTRU may initiate a link identifier update procedure only for its own L2 ID (e.g., without any R-WTRU or SP-WTRU changing its L2 ID simultaneously). According to an embodiment, in this case, the management link may be handled by the SP-WTRU, and thus the SP-WTRU may need to be involved in the procedure, as described herein.

[0221] According to an embodiment, there may be a case of multiple management links. According to an embodiment, for a single management link, the SP-WTRU may have a management link established with the R-WTRU, e.g., for managing all links related to a specific SP-L2 ID. In this case, according to an embodiment with multiple management link features (e.g., solutions), the SU-WTRU may directly establish a management link with the R-WTRU to notify the R-WTRU of the new L2 ID of the SU-WTRU and also learn the new L2 ID of the R-WTRU. According to an embodiment, the management link between the SP-WTRU and the R-WTRU and the management link between the SU-WTRU and the R-WTRU may be independent. According to an embodiment, each peer WTRU may directly manage its own link with the R-WTRU.

[0222] According to an embodiment, in the case of multiple management link features (e.g., solutions), the R-WTRU may trigger the establishment of a management link with the SU-WTRU, which may be sent, for example, in the case where a link identifier update request message is received from the SP-WTRU on the management link between the R-WTRU and the SP-WTRU (e.g., once that occurs, at that time, afterwards, etc.). Such a link identifier update request message may be applied to (e.g., associated with) a specific PC5 unicast link between the SP-WTRU and the SU-WTRU via the R-WTRU. According to an embodiment (e.g., although not shown in Figure 18 ), other updated identifiers may (e.g., also) be exchanged between the SP-WTRU and the SU-WTRU, so that, for example, security information may be updated and the application layer ID and IP address / prefix may be updated.

[0223] Figure 19 It is a diagram showing the SP-WTRU-initiated link identifier update process (multiple management links) on all WTRUs according to an embodiment.

[0224] According to an embodiment, at operation 1901, a unicast link may be established between peer WTRUs via an R-WTRU. According to an embodiment, the SP-WTRU may maintain a link table having its L2 ID (e.g., SP-L2 ID1), a relay L2 ID (e.g., R-L2 ID b), and an indication that the link is relayed by the R-WTRU (either RID or RIND). According to an embodiment, the SU-WTRU may also maintain a link table having its L2 ID (e.g., SU-L2 ID2), a relay L2 ID (e.g., R-L2 IDa), and an indication that the link is relayed by the R-WTRU. According to an embodiment, the R-WTRU may maintain a mapping table that contains the SPL2 ID (e.g., SP-L2 ID1) and its associated relay L2 ID (e.g., R-L2 IDa), and the SU-L2 ID (e.g., SU-L2 ID2) and its associated relay L2 ID (e.g., R-L2 IDb).

[0225] According to an embodiment, at operation 1902, the SP-WTRU may receive a trigger (e.g., timer expiration) to update its SP-L2 ID1. According to an embodiment, at operation 1903, optionally, the SP-WTRU may establish a secure unicast link with the R-WTRU for link management purposes, which may occur if such a link has not yet been established, where SP-L2 ID3 and R-L2IDb are used for the management link.

[0226] According to an embodiment, at operation 1904, the SP-WTRU may assign itself a new SP-L2 ID2 to replace the SP-L2ID1 and may notify the R-WTRU by sending a link identifier update request message via the management link. According to an embodiment, the message may have (e.g., use) the link management ID as the source and / or destination (e.g., SP-L2ID3 and R-L2 IDb). According to an embodiment, the content of the message may be modified to include any of the following: (i) an indication that the information is related to another link (e.g., an indicator for another link), and (ii) the current L2 ID and the new L2 ID of another link, e.g., the L2 ID of the unicast link between the SP-WTRU and the SU-WTRU. According to an embodiment, the message may be modified to (e.g., also) include the associated R-L2 ID (e.g., R-L2 IDb). According to an embodiment, these L2 IDs are new fields in the link identifier update request message.

[0227] According to an embodiment, at operation 1905, the R-WTRU may receive a link identifier update request message, e.g., the message triggers an update of the R-L2 IDb and an update of the associated L2 ID of the relay (e.g., R-L2 IDa). According to an embodiment, at operation 1906, optionally, the R-WTRU may trigger the establishment of a management link with a peer WTRU (e.g., SU-WTRU) (e.g., if the link has not been established yet) so that the SU-WTRU can update its L2 ID. According to an embodiment, at operation 1907, the R-WTRU may send a link identifier update request to the SU-WTRU, the request including any of the following: an indication that the update is for another link; the current R-L2 IDa of the R-WTRU; and the new R-L2 IDc of the R-WTRU (e.g., for replacing the current ID). According to an embodiment, the current SU-L2 ID2 may also be specified. According to an embodiment, at operation 1908, the SU-WTRU may receive the identifier update request and may search its link table for a matching entry for the indicated other link. According to an embodiment, the SU-WTRU may save the new R-L2 IDc, may assign itself a new SU-L2ID3, and may reply to the R-WTRU by sending a link identifier update response message including its new SU-L2 ID3. According to an embodiment, the new R-L2 IDc received from the R-WTRU may be included in the message for confirmation purposes.

[0228] According to an embodiment, at operation 1909, the R-WTRU may receive a response from the SU-WTRU, may find an entry in its mapping table corresponding to the identified other link, and may save the new SU-L2 ID3. According to an embodiment, the R-WTRU may (e.g., then) self-assign a new R-L2 IDd to replace the R-L2 IDb and may reply to the SP-WTRU by sending a link identifier update response including its new R-L2 IDd. According to an embodiment, the new SP-L2 ID2 received from the SP-UE (at operation 1904) may be added to the message and an "other link" indication may also be included. According to an embodiment, at operation 1910, the SP-WTRU may reply to the R-WTRU with a link identifier update acknowledgment message, e.g., to confirm receipt of the new relay identifier and complete the update process. According to an embodiment, a validity time may be included in (e.g., specified in) the message to enforce the use of the new L2 ID simultaneously on all involved WTRUs. According to an embodiment, in the case of a validity timer, the SP-WTRU may start the timer to expire at a time corresponding to the validity timer.

[0229] According to an embodiment, at operation 1911, the R-WTRU may receive the message, may find a matching entry in its mapping table, may send a link identifier update acknowledgment message to the SU-WTRU, and may specify the new SU-L2 ID3 for the acknowledgment. According to an embodiment, if the ACK message received from the SP-WTRU specifies a validity time, then that time is added to the ACK message sent to the SU-WTRU. According to an embodiment, the R-WTRU and the SU-WTRU may also start their respective timers accordingly. According to an embodiment, from this point forward or when the timer expires, all new L2 IDs may be used on the unicast link of the R-WTRU between the SP-WTRU and the SU-WTRU.

[0230] According to an embodiment, the link identifier update process may be similar to multiple administrative link characteristics (e.g., as described above). Additionally, according to an embodiment, the link identifier update process may be performed (e.g., directly) between the SP-WTRU and the SU-WTRU and the new L2 ID that may be exchanged may be the new relay L2 ID to be used by the SP-WTRU and the SU-WTRU. According to an embodiment, in such a case, the SP-WTRU and the SU-WTRU may establish an administrative link with the R-WTRU, e.g., to obtain the new relay L2 ID that may be exchanged with the peer WTRU.

[0231] The present invention provides a link identifier update procedure initiated by an SP-WTRU. The link identifier update procedure initiated by the SP-WTRU includes a plurality of management links established by (e.g., two) peer WTRUs.

[0232] According to an embodiment, the SP-WTRU and the SU-WTRU may have a unicast link established via the R-WTRU. According to an embodiment, in this case, end-to-end security may be established, and the R-WTRU may forward messages between two peer WTRUs (e.g., the SP-WTRU and the SU-WTRU), which may be performed, for example, by changing the source / destination L2 ID. According to an embodiment, the SP-WTRU and the R-WTRU may use the SP-WTRU L2 ID1 and the R-L2 IDb, respectively, while the SU-WTRU and the R-WTRU may use the SU-WTRU L2 ID2 and the R-L2 IDa, respectively. According to an embodiment, the SP-WTRU may trigger a link identifier update procedure. According to an embodiment, the SP-WTRU may establish a secure unicast link with the R-WTRU for managing an existing relayed unicast link (e.g., a unicast link established via the R-WTRU), which may occur, for example, in the absence of such a management link (e.g., when it does not yet exist).

[0233] According to an embodiment, the SP-WTRU may generate a new L2 ID and may send the L2 ID to the R-WTRU, for example, via (e.g., using, including therein, etc.) a link identifier update request message. According to an embodiment, such a message may be sent via the management link and may include any of the following: a relay management indication (e.g., another link indicator), either the source L2 ID and the destination L2 ID identifying the link to be updated, and the new L2 ID of the SP-WTRU (e.g., SP-L2ID2), which may be used with the identified link to be updated. According to an embodiment, other identifiers (e.g., security information, application layer ID, IP address / prefix, etc.) may not be included in the link identifier update request to the R-WTRU, for example, because such other identifiers may (e.g., only) have meaning for the peer WTRU (e.g., may be only associated with the peer WTRU). According to an embodiment, the R-WTRU may send (e.g., reply with) a link identifier update response message including its new relay L2 ID (e.g., R-L2 IDc), for example, to replace the current relay L2 ID (e.g., R-L2 IDa) known (e.g., used) by the SU-WTRU.

[0234] According to an embodiment, the SP-WTRU may send a link identifier update request message to the SU-WTRU via the R-WTRU, the message including any of the following: a new R-L2 IDc and other updated identifiers (such as any of security information, optional application layer ID, optional IP address / prefix, etc.). According to an embodiment, in addition to a new L2 ID parameter including a new relay L2 ID (e.g., instead of the new L2 ID of the SP-WTRU) that may be used by the SU-WTRU, the link identifier update request message may be used as described above. According to an embodiment, the SU-WTRU may identify (e.g., accept, store / record, track, distinguish, confirm, understand, monitor, etc.) the updated parameters, and the SU-WTRU may establish a secure unicast link with the R-WTRU for relay (e.g., "other") unicast link management, which may occur, for example, in the absence of such a management link.

[0235] According to an embodiment, the SU-WTRU may send a link identifier update request message to the R-WTRU via the management link. According to an embodiment, such a message may include any of the following: an other link indication, a source / destination L2 ID identifying the link that may be updated, and, for example, a new SU-WTRU L2 ID (SU-WTRU L2ID3) for updating the identified unicast link. According to an embodiment, the R-WTRU may reply with a link identifier update response message including its new R-WTRU L2 ID (R-L2 IDd), for example, to replace the relay L2 ID (R-L2 IDb) known to the SP-UE. According to an embodiment, the SU-WTRU may send a link identifier update response message to the SP-WTRU via the R-WTRU, the message including the new R-L2 IDd and other updated identifiers, such as security information and, for example (optionally), any of the following: application layer ID and IP address / prefix. According to an embodiment, the SU-WTRU may (e.g., also) include the parameters received via the link identifier update request message.

[0236] According to an embodiment, the SP-WTRU may keep track of updated parameters (e.g., accept, store / record, identify, distinguish, confirm, understand, monitor, etc.), and may send a Link Identifier Update Ack message to the SU-WTRU, the message including the parameters received via the Link Identifier Update Response message. According to an embodiment, the SP-WTRU may send a Link Identifier Update Ack message to the R-WTRU, the message including the new R-L2 ID sent to the SU-WTRU and other link indications. According to an embodiment, the SU-WTRU may send a Link Identifier Update Ack message to the R-WTRU, the message including the new R-L2 ID sent to the SP-WTRU and other link indications. According to an embodiment, (e.g., all) WTRUs (e.g., any of the SP-WTRU, SU-WTRU, and R-WTRU) may start using the new L2 ID and other updated identifiers.

[0237] According to an embodiment, the L2 link release procedure may be performed via the management link. According to an embodiment, in the case of a relay link, the link release procedure may be performed between two peer WTRUs, e.g., in a manner similar (e.g., the same) to that of a direct unicast link. According to an embodiment, a Disconnect Request message may be sent to the peer WTRU, and in response, the peer WTRU may send a Disconnect Response message. According to an embodiment, either of the Disconnect Request and Disconnect Response messages may be sent via the R-WTRU, and such messages may include, for example, a new K NRP ID, which may be used on a subsequent DCR message to establish another unicast link between the same peer WTRUs.

[0238] According to an embodiment, exchanging a new K NRP ID in a link release may avoid (e.g., prevent) the linkability of a subsequent unicast link between the current unicast link and the same peer WTRU. According to an embodiment, the new K NRP ID may be retained (e.g., saved, recorded, stored, etc.) on the peer WTRU. According to an embodiment, the R-WTRU may not need (e.g., not be required) to know the new K NRP ID, e.g., because the R-WTRU may not be involved in end-to-end authentication, authorization, and security establishment. According to an embodiment, in the case of releasing an end-to-end link (e.g., once released, after release, etc.), the Disconnect Request message may be sent to the R-WTRU, for example, via the management link.

[0239] According to an embodiment, a disconnect request message (e.g., in a manner similar to a link identifier update message) can include any of the following: other link indication and an L2 ID identifying a link that has been released. According to an embodiment, in the case where the disconnect request message includes such information, the R-WTRU can update (e.g., release, revise, purge, delete portions of, etc.) its mapping table. For example, the R-WTRU can update its mapping table in any of the following ways: release two R-WTRU L2 IDs allocated for forwarding for the link; and delete the entry having the SP-WTRU L2 ID and the SU-WTRU L2 ID. According to an embodiment, for example, in the case of using multiple management links, the disconnect request message can be sent by two peer WTRUs. According to an embodiment, the R-WTRU can purge its mapping table and can reply to the WTRU with a disconnect response message that includes any of the following: an L2 ID that identifies a link that has been released; and other link indication.

[0240] According to an embodiment, DCA can be direct communication acceptance; DCR can be direct communication request; RID can be R-WTRU identifier; R-WTRU can be WTRU-to-WTRU relay; SMC can be security mode command; SP-WTRU can be service provider WTRU; and SU-WTRU can be service utilization WTRU.

[0241] Service-Oriented Discovery and Communication via a Relay WTRU (R-WTRU)

[0242] As described above, there may be a situation where a (traditional) WTRU-to-WTRU relay using an IP-based mechanism only supports WTRU-oriented discovery and unicast (e.g., IP, L2, etc.) communication. On the other hand, according to an embodiment, there may be a situation (e.g., as described above) where a (e.g., non-traditional, new) WTRU-to-WTRU relay (which can be referred to as an R-WTRU) can provide support for any service-oriented discovery and multicast (e.g., IP, L2, etc.) communication. That is, according to an embodiment, the R-WTRU can support more (e.g., all possible) types of discovery and communication. According to an embodiment, an R-WTRU can be used to perform (e.g., enable) IP-based service-oriented discovery and multicast communication, e.g., the R-WTRU acts as a "non-transparent" IP-based relay between an SP-WTRU and any number of SU-WTRUs.

[0243] According to an embodiment, the SU-WTRU may discover ProSe services provided by the SP-WTRU, for example, by using (e.g., via) an IP-based WTRU-to-WTRU relay (e.g., R-WTRU). According to an embodiment, for example, when the PC5 connection with the R-WTRU is established or after (e.g., in this case), the SP-WTRU may provide a list of ProSe service IDs to the R-WTRU (e.g., an IP-based WTRU-to-WTRU relay). According to an embodiment, the R-WTRU may determine (e.g., know, be signaled, etc.) and / or store the association between the list of ProSe service IDs and the SP-WTRU ID.

[0244] According to an embodiment, in the case where the SU-WTRU requests (e.g., available) ProSe services from the R-WTRU, the R-WTRU may provide (e.g., transmit, reply, etc.) any number of any of the following: any SP-WTRU ID associated with the requested ProSe service and (e.g., the corresponding, associated, etc.) ProSe service ID. According to an embodiment, (e.g., when receiving any of the SP-WTRU ID and ProSe service ID), the SP-WTRU may, for example, use (e.g., via) any of a DCR message, an authentication message (e.g., during the security establishment process) to provide the list of ProSe service IDs and the SP-WTRU ID to the R-WTRU.

[0245] According to an embodiment, the R-WTRU may transmit (e.g., reply to the SP-WTRU) any number of any of the following, for example, by using (e.g., via) a DNS response message: the SP-WTRU ID associated with the requested ProSe service and the ProSe service ID. According to an embodiment, the SP-WTRU ID may refer to any of an IP address, a layer 2 (L2) ID, an application layer ID, etc. According to an embodiment, the ProSe service (e.g., requested by the SU-WTRU) may be mapped by the R-WTRU to any number of ProSe service IDs. For example, the requested ProSe service may be "restaurant", which may be mapped to any of "restaurant_A", "restaurant_B", etc. According to an embodiment, (e.g., before replying to the ProSe service request received from the SU-WTRU), the R-WTRU may, for example, verify whether the SU-WTRU is authorized to discover the requested ProSe service based on authorization parameters (e.g., which are (pre-)configured or received from the (core) network), and the authorization parameters may include any number of any of the following: the SU-WTRU ID and the allowed ProSe service IDs.

[0246] According to an embodiment, the SP-WTRU may provide any of the following: a list of service IDs and a flag indicating either restricted service discovery or restricted access. According to an embodiment, such a flag (e.g., such as this) may be stored by the R-WTRU together with, for example, mapping information (e.g., in addition to the mapping information) as discussed above. According to an embodiment, for example, in a case where the SU-WTRU queries service information by, for example, sending a request for a service associated with a restriction flag to the R-WTRU, the R-WTRU may send a request to the SP-WTRU, which may be done, for example, by (e.g., first) providing SU-WTRU information (e.g., this request for the SP-WTRU includes user information).

[0247] According to an embodiment, the R-WTRU may provide service information (e.g., SP-WTRU IP address) to the SU-WTRU. According to an embodiment, such service information may be provided on the condition that the SP-WTRU authorizes the R-WTRU to provide such information, for example, based on information provided by the SU-WTRU. According to an embodiment, services may be restricted based on application requirements (e.g., only specific users, limiting the number of concurrent users to a maximum, etc.). On the other hand, according to an embodiment, the R-WTRU may request authorization from the ProSe function (e.g., as described herein), for example, based on the presence of a service restriction flag. According to an embodiment, the service restriction flag may indicate whether the R-WTRU may request authorization (e.g., for a service) from either the ProSe function or the SP-WTRU. According to an embodiment, for example, in a case where the R-WTRU is outside network coverage (e.g., the R-WTRU cannot reach or communicate with the ProSe function), the R-WTRU may: (1) request authorization from the SP-WTRU (e.g., as a fallback mechanism); and / or (2) deny access to service information to, for example, the SU-WTRU (e.g., until the R-WTRU returns to network coverage).

[0248] According to an embodiment, the R-WTRU may perform (e.g., complete, run, have behavior including the following, etc.) any of the following: (1) receive a list of ProSe service IDs from the SP-WTRU; (2) store the association between the list of ProSe service IDs and the SP-WTRU ID; and (3) reply (e.g., transmit) in any number of the following ways, for example, after receiving a ProSe service request from the SU-WTRU: the SP-WTRU ID and the associated ProSe service ID. According to an embodiment, the SP-WTRU may (e.g., perform, complete, run, have behavior including the following, etc.) provide a list of ProSe service IDs to the R-WTRU.

[0249] According to an embodiment, the SU-WTRU may perform (e.g., complete, run, have behavior including the following, etc.) any of the following: (1) send a ProSe service request (e.g., a message including the ProSe service request, a signal for the ProSe service request, etc.) to the R-WTRU, the ProSe service request including (e.g., identifying) the requested ProSe service; and (2) receive any number of any of the following: SP-WTRU ID and associated ProSe service ID.

[0250] According to an embodiment, the SP-WTRU may provide (e.g., convey, send, register, etc.) any number of (e.g., its) ProSe service IDs to the ProSe function. According to an embodiment, for example, in the case where the SP-WTRU establishes a PC5 connection with the R-WTRU (e.g., when the PC5 connection is established), the R-WTRU may send a ProSe service query message including the SP-WTRU ID to the ProSe function. According to an embodiment, the ProSe function may send (e.g., reply with) a list of ProSe service IDs associated with the SP-WTRU to the R-WTRU. According to an embodiment, the R-WTRU may store the association between the ProSe service ID list and the SP-WTRU ID. According to an embodiment, in the case where the SU-WTRU requests available ProSe services from the R-WTRU, the R-WTRU may reply with any number of any of the following: SP-WTRU ID and ProSe service ID associated with the requested ProSe service.

[0251] According to an embodiment, the R-WTRU may perform (e.g., complete, run, have such behavior, etc.) any of the following: (1) receive the SP-WTRU ID from the SP-WTRU; (2) send a ProSe service query message including, for example, the SP-WTRU ID to the ProSe function; (3) receive a list of ProSe service IDs associated with the SP-WTRU from the ProSe function; (4) store the association between the ProSe service ID list and any number of SP-WTRU IDs; and (5) and for example, after receiving a ProSe service request from the SU-WTRU, reply with any number of any of the following: SP-WTRU ID and associated ProSe service ID.

[0252] According to an embodiment, the SP-WTRU may perform (e.g., complete, run, have behavior including the following, etc.) any of the following: (1) provide a list of ProSe service IDs to the ProSe function; and (2) send the SP-WTRU ID to the R-WTRU. According to an embodiment, the SU-WTRU may perform (e.g., complete, run, have behavior including the following, etc.) any of the following: (1) send a ProSe service request to the R-WTRU, e.g., indicating the requested ProSe service ID; and (2) receive any number of any of the following: SP-WTRU ID and associated ProSe service ID.

[0253] Conclusion

[0254] Although the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware executed by a computer or processor and embedded in a computer-readable medium. Examples of non-transitory computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memories, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a UE, WTRU, terminal, base station, RNC, or any host computer.

[0255] In addition, in the above embodiments, processing platforms, computing systems, controllers, and other devices including a processor (including a constraint server and a rendezvous point / server) are mentioned. These devices may include at least one central processing unit (“CPU”) and a memory. According to the practice of those skilled in the computer programming art, references to symbolic descriptions of actions and operations or instructions may be executed by various CPUs and memories. These actions and operations or instructions may be referred to as “being executed”, “computer-executed”, or “CPU-executed”.

[0256] Those skilled in the art will understand that the operations or instructions of the symbolic descriptions of actions include the manipulation of electrical signals by the CPU. An electrical system representation can identify data bits, which cause the electrical signals to be transformed or restored and the maintenance of the storage location of the data bits in a storage system thereby to reconfigure or otherwise change the operation of the CPU and other processing of the signals. The maintenance of the storage location of the data bits is to have a specific electrical, magnetic, optical, or organic property corresponding to or representing the data bits. It should be understood that the exemplary embodiments are not limited to the above platforms or CPUs and other platforms and CPUs can support the provided methods.

[0257] The data bits may also be maintained on a computer-readable medium, which includes magnetic disks, optical disks, and any other large storage systems readable by a CPU, whether volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)). The computer-readable medium may include cooperative or interconnected computer-readable media, which exist either specifically on a processor system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[0258] In the illustrated embodiments, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0259] There is a difference between the hardware and software implementations in terms of the system. The use of hardware or software is generally (but not always, as the choice between hardware and software can be important in some environments) a design choice that takes into account the cost and efficiency trade-off. There can be various tools (e.g., hardware, software, and / or firmware) that can affect the processes and / or systems and / or other technologies described herein, and the preferred tool may change depending on the context of the process and / or system and / or other technology being deployed. For example, if the implementer determines that speed and accuracy are the most important, the implementer may choose mainly hardware and / or firmware tools. If flexibility is the most important, the implementer may choose mainly a software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0260] The above detailed description has presented various embodiments of the device and / or process by using block diagrams, flowcharts, and / or examples. To the extent that these block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will appreciate that each function and / or operation within these block diagrams, flowcharts, or examples can be implemented individually and / or together in a wide variety of ways by hardware, software, or firmware, or substantially any combination thereof. Suitable processors include, for example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0261] Although features and elements are described in terms of particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this application, which are intended as examples of various aspects. Many modifications and variations can be made without departing from its essence and scope, which are known to those skilled in the art. Elements, acts, or instructions used in the description of this application should not be construed as critical or essential to the invention unless explicitly stated. In addition to the methods and apparatuses recited herein, those skilled in the art will also know, based on the foregoing description, methods and apparatuses that are functionally equivalent within the scope of the present disclosure. These modifications and variations should also fall within the scope of the appended claims. The present disclosure is defined only by the appended claims, including their full scope of equivalents. It should be understood that the present disclosure is not limited to a particular method or system.

[0262] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, when the terms "user equipment" and its abbreviation "UE" are referred to herein, it can mean: (i) a wireless transmit and / or receive unit (WTRU), such as those described below; (ii) any of a plurality of embodiments of a WTRU, such as those described below; (iii) a wireless and / or wired (e.g., wirelessly communicable) device configured with some or all of the structures and functions of a WTRU, such as those described below; (iii) a device having wireless capabilities and / or wired capabilities configured with structures and functions having less than all of the structures and functions of a WTRU, such as those described below; or (iv) the like. Details of an example WTRU, which example WTRU can represent any WTRU described herein.

[0263] In certain representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will appreciate that some aspects of the embodiments disclosed herein, in whole or in part, may equivalently be implemented by integrated circuits, as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or substantially any combination thereof, and designing circuits and / or writing code for the software and / or firmware according to this disclosure is known to those skilled in the art. Additionally, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed in various forms of program products, and that the exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually effect such distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, etc., and transmission type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0264] The subject matter described herein sometimes shows different components that are included in or connected to different other components. It will be appreciated that these depicted architectures are merely examples, and that many other architectures that implement the same functionality may be implemented in practice. Conceptually, any arrangement of components that implement the same functionality more effectively "associates" therewith such that the desired functionality may be implemented. Thus, any two components that are combined to implement a particular functionality may be regarded as "associated" with each other such that the desired functionality is implemented, regardless of the architecture or intermediate components. Similarly, any two associated components may also be regarded as "operatively connected" or "operatively coupled" to each other to implement the desired functionality, and any two components that can be so associated may also be regarded as "operatively couplable" to each other to implement the desired functionality. Specific examples of operatively couplable include, but are not limited to, components that are physically pairable and / or physically interactive and / or wirelessly interactive and / or wirelessly interacting and / or logically interactive and / or logically interactable.

[0265] Regarding the use of substantially any plural and / or singular terms herein, those skilled in the art may translate from the plural to the singular and / or from the singular to the plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly set forth herein.

[0266] Those skilled in the art can understand that the terms generally used herein and especially the terms used in the claims (such as the main part of the claims) are generally "open" terms (for example, the term "comprising" should be understood as "comprising but not limited to", the term "having" should be understood as "having at least", the term "including" should be understood as "including but not limited to", etc.). Those skilled in the art can also understand that if the claims are to describe a specific quantity, it will be explicitly described in the claims, and in the absence of such a description, there is no such meaning. For example, if it is to indicate only one item, the term "single" or similar language can be used. To assist understanding, the following claims and / or the description herein may include the use of the preamble phrase "at least one" or "one or more" to introduce the claim description. However, the use of these phrases should not be understood as implying that a claim description introduced by the indefinite article "a" will limit any particular claim including such an introduced claim description to an embodiment including only one such description, even when the same claim includes the preamble phrase "one or more" or "at least one" and the indefinite article (such as "a") (for example, "a" should be understood as meaning "at least one" or "one or more"). The same is true for the use of the definite article to introduce the claim description. In addition, even if the specific quantity of the introduced claim description is explicitly described, those skilled in the art can understand that such a description should be understood as meaning at least the described quantity (for example, simply describing "two descriptions" without other modifiers means at least two descriptions, or two or more descriptions). In addition, in these instances where a convention similar to "at least one of A, B, and C, etc." is used, generally such a convention is understood by those skilled in the art (for example, "the system has at least one of A, B, and C" can include but is not limited to the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). In these instances where a convention similar to "at least one of A, B, or C, etc." is used, generally such a convention is understood by those skilled in the art (for example, "the system has at least one of A, B, or C" can include but is not limited to the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). Those skilled in the art can also understand that substantially any separated word and / or phrase representing two or more alternative items, whether in the specification, the claims, or the drawings, should be understood as including the possibility of including one of the two items, either, or both. For example, the phrase "A or B" is understood to include the possibility of "A" or "B" or "A" and "B". In addition, the term "any" used herein followed by a list of multiple items and / or multiple types of items is intended to include "any", "any combination", "any number", and / or "any combination of a number" of the multiple items and / or multiple types of items, alone or in combination with other items and / or other types of items.In addition, the terms "set" or "group" as used herein are intended to include any number of items, including zero. Further, the term "number" as used herein is intended to include any number, including zero.

[0267] In addition, if the features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will appreciate that the present disclosure can also be described in terms of any individual member or subgroup of members of the Markush group.

[0268] Those skilled in the art will appreciate that, for any and all purposes, e.g., to provide a written description, all ranges disclosed herein also include any and all possible subranges and combinations thereof. Any listed range can be readily understood to describe and enable the same range being broken into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range disclosed herein can be readily broken into a lower third, middle third, and upper third, etc. Those skilled in the art will also appreciate that all language such as "up to," "at least," "greater than," "less than," etc., including the recited numbers, and ranges which can be divided into the above subranges. Finally, those skilled in the art will appreciate that ranges include each individual member. Thus, for example, a group and / or set having 1 - 3 cells refers to a group / set having 1, 2, or 3 cells. Similarly, a group / set having 1 - 5 cells refers to a group / set having 1, 2, 3, 4, or 5 cells, and so on.

[0269] In addition, the claims should not be construed as limited to the recited order or elements unless so described. Further, the use of the term "means for" in any claim is intended to invoke 35 U.S.C.§112, paragraph 6 or the means - plus - function claim format, and any claim without the term "means for" is not so intended.

[0270] A processor associated with software can be used to implement a radio frequency transceiver used in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME), or evolved packet core (EPC), or any host computer. The WTRU can be combined with modules implemented in hardware and / or software (including software - defined radio (SDR)) and other components such as a camera, video camera module, video phone, walkie - talkie, vibrating device, speaker, microphone, television transceiver, hands - free headset, keyboard, Module, frequency modulation (FM) radio unit, near field communication (NFC) module, liquid crystal display (LCD) display unit, organic light emitting diode (OLED) display unit, digital music player, media player, video game console module, Internet browser and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0271] Although the present invention has been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software controlling the general purpose computer.

[0272] Furthermore, although the invention has been shown and described with reference to specific embodiments, the invention is not limited to the details shown. Instead, various modifications may be made to the details within the scope of the equivalents of the claims and without departing from the invention.

Claims

1. A method implemented by a relay wireless transmit / receive unit (WTRU), the method comprising: Receiving a first discovery message from a first WTRU, the first discovery message including a first identifier (ID) for the first WTRU; Modifying the received first discovery message by adding a relay ID (RID) identifying the relay WTRU and by replacing the first ID of the first WTRU with a first relay ID of the relay WTRU; Sending the modified discovery message; Receiving a link establishment message from a second WTRU in response to the modified discovery message, the link establishment message including a second ID for the second WTRU; Modifying the received link establishment message by adding the RID and by replacing the second ID of the second WTRU with a second relay ID of the relay WTRU; Forwarding the modified link establishment message to the first WTRU; And Relaying PC5 unicast messages between the first WTRU and the second WTRU, wherein a PC5 unicast message received from the first WTRU indicating a destination associated with the second relay ID of the relay WTRU is forwarded to the second WTRU, the unicast message having an indication of a source associated with the first relay ID of the relay WTRU.

2. The method according to claim 1, wherein a PC5 unicast message received from the second WTRU indicating a destination associated with the first relay ID of the relay WTRU is forwarded to the first WTRU, the unicast message having an indication of a source associated with the second relay ID of the relay WTRU.

3. The method according to claim 1, wherein the first discovery message includes an indication of a service provided by the first WTRU, and wherein the modified discovery message includes an indication of the service provided by the first WTRU.

4. The method according to claim 1, the method further comprising: Generating a mapping table that indicates the relationship between the first relay ID, the first ID, the second ID, and the service provided by the first WTRU.

5. The method according to claim 1, further comprising: Receiving at least one relay policy, wherein the determination of sending the modified discovery message is based on the at least one relay policy.

6. The method according to claim 1, the method further comprising: Receiving authorization to act as a relay WTRU during registration with the network.

7. The method according to claim 1, wherein The first discovery message is a direct communication request message.

8. A relay wireless transmit / receive unit (WTRU), the WTRU comprising: A transceiver configured to receive a first discovery message from a first WTRU, the first discovery message including a first identifier (ID) for the first WTRU; And A processor configured to: Modify the received first discovery message by adding a relay ID (RID) identifying the relay WTRU and by replacing the first ID of the first WTRU with a first relay ID of the relay WTRU; Send the modified discovery message; Receive, via the transceiver, a link establishment message from a second WTRU in response to the modified discovery message, the link establishment message including a second ID for the second WTRU; Modify the received link establishment message by adding the RID and replacing the second ID of the second WTRU with a second relay ID of the relay WTRU; Forward the modified link establishment message to the first WTRU via the transceiver; And Relay PC5 unicast messages between the first WTRU and the second WTRU via the transceiver, wherein a PC5 unicast message received from the first WTRU indicating a destination associated with the second relay ID of the relay WTRU is forwarded to the second WTRU, the unicast message having an indication of a source associated with the first relay ID of the relay WTRU.

9. The relay WTRU according to claim 8, wherein a PC5 unicast message received from the second WTRU indicating a destination associated with the first relay ID of the relay WTRU is forwarded to the first WTRU, the unicast message having an indication of a source associated with the second relay ID of the relay WTRU.

10. The relay WTRU according to claim 8, wherein the first discovery message includes an indication of a service provided by the first WTRU, and wherein the modified discovery message includes an indication of the service provided by the first WTRU.

11. The relay WTRU according to claim 8, the processor further configured to generate a mapping table indicating a relationship between the first relay ID, the first ID, the second ID, and the service provided by the first WTRU.

12. The relay WTRU according to claim 8, wherein the transceiver is further configured to receive at least one relay policy, and wherein the processor is further configured to determine that sending the modified discovery message is in accordance with the at least one relay policy.

13. The relay WTRU according to claim 8, the transceiver further configured to receive authorization to act as a relay WTRU during registration with the network.

14. The relay WTRU according to claim 8, wherein the first discovery message is a direct communication request message.

15. The relay WTRU according to claim 8, the processor further configured to send, via the transceiver, a message including an indication of the multicast communication relay capability of the relay WTRU.

Images