KR20220113359A - Direct discovery and communication method and apparatus using WTRU-to-WTRU relay - Google Patents

Abstract

Methods, apparatuses, systems, architectures performed by a relay wireless transmit/receive unit (R-WTRU) comprising a transmitter, a receiver, a memory, and a processor to establish extended unicast links and management unicast links and interfaces are provided. The method comprises: relaying, by the R-WTRU, traffic between a service provider WTRU (SP-WTRU) and any number of service user WTRUs (SU-WTRUs) according to a mapping generated by the R-WTRU. performing a link establishment procedure to establish any number of extended unicast links, wherein the link establishment procedure is: (1) for any of the SP-WTRU, R-WTRU, and any number of SU-WTRUs. creating a mapping of layer 2 (L2) identifiers (IDs) to any of the extension links, and (2) sending a unique relay ID; establishing a management unicast link for extended unicast links; and applying any number of link management requests received over the management unicast link to the associated extended unicast links.

Description

Direct discovery and communication method and apparatus using WTRU-to-WTRU relay

FIELD OF THE INVENTION The present invention relates to the field of communications, and more particularly, to advanced or next-generation wireless communications systems, including communications conducted using new radio and/or new radio (NR) access technologies and communications systems. to methods, apparatuses, systems, architectures and interfaces for communication in Such communication systems may include wireless communication relays, Vehicle-to-Everything (V2X) services, and relay communication performed by Proximity Services (ProSe).

Moreover, like reference numbers in the drawings indicate like elements.
1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.
1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A in accordance with one embodiment.
1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A according to an embodiment.
1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A according to an embodiment.
1E is a block diagram illustrating various example elements of an example communication system.
1F is a block diagram illustrating an example architecture of an example communication system.
2 is a diagram illustrating a Release 16 (Rel-16) V2X (Vehicle To Everything) link setup.
3 is a diagram illustrating a control plane for eV2X in a PC5 interface.
4 is a diagram illustrating a user plane for eV2X in a PC5 interface.
5 is a diagram illustrating a link identifier update procedure.
6 is a diagram illustrating a WTRU to WTRU relay scenario.
7 is a diagram illustrating a high level view of a transparent relay, according to embodiments.
8 is a diagram illustrating control plane protocol stacks supporting opaque WTRU to WTRU relay in accordance with embodiments;
9 is a diagram illustrating user plane protocol stacks supporting opaque WTRU to WTRU relay, in accordance with embodiments;
10 is a diagram illustrating a service oriented discovery procedure using opaque WTRU to WTRU relay, in accordance with embodiments.
11 is a diagram illustrating an enhanced link identifier update procedure using an opaque R-WTRU, in accordance with embodiments.
12 is a diagram illustrating an enhanced link identifier update procedure using an opaque R-WTRU, in accordance with embodiments.
13 is a diagram illustrating a control plane stack supporting a transparent R-WTRU, in accordance with embodiments;
14 is a diagram illustrating a user plane stack supporting a transparent R-WTRU, in accordance with embodiments;
15 is a diagram illustrating discovery and unicast link establishment, according to embodiments.
16 is a diagram illustrating discovery and unicast link establishment according to an embodiment.
17 is a diagram illustrating establishment of a second unicast link according to embodiments;
18 is a diagram illustrating a SP-WTRU initiated link identifier update procedure for all WTRUs - a single management link, according to embodiments.
19 is a diagram illustrating an SP-WTRU initiated link identifier update procedure - multiple management link for all WTRUs, according to embodiments;
20 is a diagram illustrating an SP-WTRU initiated link identifier update procedure including multiple management links established by peer WTRUs (eg, both) in accordance with embodiments.

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

As shown in FIG. 1A , communication system 100 includes wireless transmit/receive units (WTRUs) 102a , 102b , 102c , 102d , RAN 104/113 , CN 106/115 , public switched (PSTN). telephone network) 108 , the Internet 110 , and other networks 112 , although the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements, and It will be understood that there is Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as "stations" and/or "STAs", may be configured to transmit and/or receive wireless signals, User equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device , Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (eg, telesurgery), industrial devices and applications (eg for example, robots and/or other wireless devices operating in industrial and/or automated processing chain contexts), consumer electronic devices, devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

The base station 114a may be part of the RAN 104/113, which includes other base stations and/or networks, such as a base station controller (BSC), radio network controller (RNC), relay nodes, etc. It may also include elements (not shown). Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless service for a particular geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, ie, one for each sector of the cell. In one embodiment, base station 114a may utilize multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

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

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

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c are configured with Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-A Pro (LTE-Advanced Pro). ) can be used to implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 .

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may establish a radio interface 116 using New Radio (NR), such as NR Radio Access. technology can be implemented.

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, eg, using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a , 102b , 102c is a transmission and/or transmission of multiple types of radio access technologies to/from multiple types of base stations (eg, eNB and gNB). can be characterized by

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c are IEEE 802.11 (ie, Wireless Fidelity (WiFi)), IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000 (Interim Standard 2000), IS-95 (Interim Standard 95), IS-856 (Interim Standard 856), GSM (Global System for Mobile communications), EDGE (Enhanced Data rates for GSM Evolution), GSM EDGE (GERAN), and the like may be implemented.

The base station 114b in FIG. 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and may be a business, home, vehicle, campus, industrial facility, (eg, drones Any suitable RAT may be used to facilitate wireless connectivity in localized areas, such as air corridors, roads, etc.). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d establish a picocell or femtocell to establish a cellular-based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE). -A, LTE-A Pro, NR, etc.) can be used. As shown in FIG. 1A , the base station 114b may have a direct connection to the Internet 110 . Accordingly, the base station 114b may not need to access the Internet 110 via the CN 106/115.

The RAN 104/113 may communicate with a CN 106/115, which may provide voice, data, applications, and/or voice over internet protocol (VoIP) services to the WTRUs 102a; 102b, 102c, 102d) may be any type of network configured to provide for one or more of. Data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. can have things. CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and/or the like; It can perform higher-level security functions, such as user authentication. Although not shown in FIG. 1A , the RAN 104/113 and/or the CN 106/115 may communicate directly or indirectly with other RANs using the same RAT as the RAN 104/113 or a different RAT. It will be understood that there is For example, in addition to being connected to RAN 104/113, which may be using NR radio technology, CN 106/115 may also be connected to GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. may communicate with another RAN (not shown) using

The CN 106 / 115 may also serve as a gateway for the WTRUs 102a , 102b , 102c , 102d to access the PSTN 108 , the Internet 110 , and/or other networks 112 . The PSTN 108 may include circuit switched telephone networks that provide plain old telephone service (POTS). Internet 110 is a device and interconnected computer networks that use common communication protocols, such as transmission control protocol (TCP), user datagram protocol (UDP), and/or internet protocol (IP) within the TCP/IP Internet protocol suite. may include a global system of Networks 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, networks 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104/113 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capability (eg, the WTRUs 102a, 102b, 102c, 102d may have different radio links). may include multiple transceivers for communicating with different wireless networks via For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may utilize a cellular-based radio technology, and with a base station 114b that may utilize an IEEE 802 radio technology. .

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

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with the 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), state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120 , which may be coupled to the transmit/receive element 122 . Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a ) over the air interface 116 . For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and optical signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

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

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

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

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

The processor 118 may further be coupled to other peripherals 138 , which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. can For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photo and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, Hands-free headsets, Bluetooth® modules, frequency modulated (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual and/or augmented reality (VR/AR) devices, activity trackers and the like. Peripherals 138 may include one or more sensors, including a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; geolocation sensor; It may be one or more of an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

The WTRU 102 transmits some or all of the signals (eg, associated with specific subframes for both the UL (eg, for transmission) and the downlink (eg, for reception)). and a full duplex radio in which reception may be concurrent and/or simultaneous. Full-duplex radio provides self-interference through either hardware (eg, a choke) or signal processing via a processor (eg, a separate processor (not shown) or processor 118 ). an interference management unit for reducing and/or substantially eliminating. In one embodiment, the WTRU 102 is a signal (eg, associated with specific subframes for either the UL (eg, for transmission) or the downlink (eg, for reception)) It may include a half-duplex radio in which some or all of these are transmitted and received.

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

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

Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. can be As shown in FIG. 1C , the eNode-Bs 160a , 160b , 160c may communicate with each other via an X2 interface.

The CN 106 shown in FIG. 1C may include a Mobility Management Gateway (MME) 162 , a Serving Gateway (SGW) 164 , and a Packet Data Network (PDN) Gateway (PGW) 166 . Although each of the foregoing elements are depicted as part of the CN 106 , it will be understood that any of these elements may be owned and/or operated by entities other than the CN operator.

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

The SGW 164 may be connected to each of the eNode-Bs 160a , 160b , 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a , 102b , 102c . The SGW 164 is responsible for anchoring the user plane during inter-eNode B handover, paging when DL data for the WTRUs 102a, 102b, 102c is available. triggering the WTRUs 102a , 102b , 102c , and managing and storing contexts of the WTRUs 102a , 102b , 102c .

The SGW 164 may be coupled to the PGW 166 , which may be connected to the Internet 110 to facilitate communication between the WTRUs 102a , 102b , 102c and IP-enabled devices. ) may provide the WTRUs 102a , 102b , 102c access to packet switched networks.

The CN 106 may facilitate communication with other networks. For example, the CN 106 may be used in circuit switched networks, such as the PSTN 108 , to facilitate communication between the WTRUs 102a , 102b , 102c and traditional land-line communication devices. may provide access to the WTRUs 102a, 102b, 102c. For example, the CN 106 may include or communicate with an IP gateway (eg, an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108 . . Additionally, the CN 106 may provide access to other networks 112 to the WTRUs 102a, 102b, which may include other wired and/or wireless networks owned and/or operated by other service providers. 102c).

Although a WTRU is described as a wireless terminal in FIGS. 1A-1D , it is contemplated that such a terminal may use (eg, temporarily or permanently) wired communication interfaces with a communication network in certain representative embodiments.

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

A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) to the BSS and one or more stations (STA) associated with the AP. The AP may have access or interfaces to a distribution system (DS) or other type of wired/wireless network that carries traffic into and/or out of the BSS. Traffic for STAs originating from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be transmitted to the AP to be delivered to their respective destinations. For example, if the source STA may transmit traffic to the AP and the AP may forward the traffic to the destination STA, traffic between STAs in the BSS may be transmitted via the AP. Traffic between STAs in a BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (eg, directly between) a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have an AP, and STAs within or using IBSS (eg, all of the STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an “ad-hoc” communication mode.

When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon over a fixed channel, such as a primary channel. The primary channel may be of a fixed width (eg, a bandwidth of 20 MHz wide) or may be of a width dynamically configured through signaling. The primary channel may be the working channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. In the case of CSMA/CA, STAs (eg, all STAs) including the AP may detect the primary channel. When the primary channel is sensed/detected and/or determined to be busy by a specific STA, that specific STA may back off. One STA (eg, only one station) may transmit at any given time in a given BSS.

HT (High Throughput) STAs, for example, through a combination of a primary 20 MHz channel and an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel, a 40 MHz wide channel for communication can be used

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

Sub 1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah uses the non-TVWS spectrum for 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths are supported. According to an exemplary embodiment, 802.11ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, eg, limited capabilities, including support for (eg, only support for) certain bandwidths and/or limited bandwidths. MTC devices may include a battery with a battery life above a threshold (eg, to maintain very long battery life).

WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by an STA supporting a smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, although other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes, the primary channel supports the 1 MHz mode (e.g. For example, it may be 1 MHz wide for STAs (eg, MTC type devices) that only support 1 MHz mode. Carrier detection and/or Network Allocation Vector (NAV) configuration may depend on the state of the primary channel. For example, if the primary channel is busy due to the STA transmitting to the AP (which only supports 1 MHz mode of operation), all of the available frequency bands are may be considered unwieldy.

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

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

Although the RAN 113 may include gNBs 180a , 180b , 180c , it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a , 180b , 180c may each include one or more transceivers for communicating with the WTRUs 102a , 102b , 102c via the air interface 116 . In one embodiment, gNBs 180a , 180b , 180c may implement MIMO technology. For example, gNBs 180a , 108b may use beamforming to transmit signals to and/or receive signals from gNBs 180a , 180b , 180c . Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a , 180b , 180c may implement a carrier aggregation technique. For example, the gNB 180a may send 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 one embodiment, gNBs 180a , 180b , 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and/or gNB 180c ).

The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may have subframe or transmission time intervals (TTIs) of varying or scalable lengths (eg, containing varying numbers of OFDM symbols and/or lasting varying absolute time lengths). can be used to communicate with gNBs 180a, 180b, 180c.

The gNBs 180a , 180b , 180c may be configured to communicate with the WTRUs 102a , 102b , 102c in a standalone configuration and/or in a non-standalone configuration. In a standalone configuration, the WTRUs 102a , 102b , 102c perform gNBs 180a , 180b , 180c without access to other RANs (eg, such as eNode-Bs 160a , 160b , 160c ). can communicate with In a standalone configuration, the WTRUs 102a , 102b , 102c may use one or more of the gNBs 180a , 180b , 180c as a mobility anchor point. In a standalone configuration, the WTRUs 102a , 102b , 102c may communicate with the gNBs 180a , 180b , 180c using signals in the unlicensed band. In a non-standalone configuration, the WTRUs 102a , 102b , 102c communicate with the gNBs 180a , 180b , 180c while also communicating with/connecting to another RAN, such as the eNode-Bs 160a , 160b , 160c and /can connect to it. For example, the WTRUs 102a , 102b , 102c may implement DC principles to communicate substantially simultaneously with one or more gNBs 180a , 180b , 180c and one or more eNodeBs 160a , 160b , 160c . In a non-standalone configuration, the eNode-Bs 160a , 160b , 160c may serve as mobility anchors for the WTRUs 102a , 102b , 102c , and the gNBs 180a , 180b , 180c may serve as the WTRUs 102a , 102b, 102c) may provide additional coverage and/or throughput.

Each of gNBs 180a, 180b, 180c may be associated with a specific cell (not shown), and may be associated with radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slicing, dual Connection, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) (184a, 184b), Access and Mobility Management Function (AMF) ) may be configured to handle routing of control plane information towards 182a, 182b, and the like. As shown in FIG. 1D , gNBs 180a , 180b , 180c may communicate with each other via an Xn interface.

The CN 115 shown in FIG. 1D includes at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly including Data Network (DN) 185a, 185b. Although each of the foregoing elements are depicted as part of the CN 115 , it will be understood that any of these elements may be owned and/or operated by entities other than the CN operator.

The AMF 182a , 182b may be connected to one or more of the gNBs 180a , 180b , 180c in the RAN 113 via an N2 interface, and may serve as a control node. For example, the AMF 182a, 182b authenticates users of the WTRUs 102a, 102b, 102c, and supports network slicing (eg, handling different PDU sessions with different requirements). , selecting a specific SMF (183a, 183b), management of the registration area (registration area), termination (termination) of NAS signaling, may be in charge of mobility management, and the like. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the service types used by the WTRUs 102a, 102b, 102c. . Different use cases, for example, services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. Different network slices may be configured for AMF 162 may be configured to RAN 113 and other RANs (not shown) using other radio technologies, such as non-3GPP access technologies such as LTE, LTE-A, LTE-A Pro, and/or WiFi. It can provide a control plane function to switch between.

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

The UPF 184a , 184b may be coupled to one or more of the gNBs 180a , 180b , 180c in the RAN 113 via an N3 interface, and the gNBs 180a , 180b , 180c include the WTRUs 102a , 102b . , 102c ) and IP capable devices, access to packet switched networks, such as the Internet 110 , may be provided to the WTRUs 102a , 102b , 102c . UPFs 184, 184b are responsible for routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, downlink packets It may perform other functions, such as buffering files, providing mobility anchoring, and the like.

The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (eg, an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108 . Additionally, the CN 115 may provide access to other networks 112 to the WTRUs 102a, 102b, which may include other wired and/or wireless networks owned and/or operated by other service providers. 102c). In one embodiment, the WTRUs 102a, 102b, 102c connect to the UPF 184a, via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b. 184b) to a local data network (DN) 185a, 185b.

1A-1D, and the corresponding description of FIGS. 1A-1D , WTRUs 102a-120d, base stations 114a and 114b, eNode-Bs 160a-c, MME 162, SGW ( 164), PGW 166, gNB 180a-180c, AMF 182a and 182b, UPF 184a and 184b, SMF 183a and 183b, DN 185a and 185b, and/or as described herein. One or more, or all, of the functions described herein with respect to one or more of any other device(s) may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

The emulation devices may be designed to implement one or more tests on other devices in a lab environment and/or in an operator network environment. For example, one or more emulation devices may 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. One or more emulation devices may be temporarily implemented/deployed as part of a wired and/or wireless communication network while performing one or more, or all, functions. The emulation device may be coupled directly to another device for testing purposes and/or may perform testing using over-the-air wireless communications.

One or more emulation devices may perform one or more functions, including all functions, without being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be used in a test laboratory and/or in a test scenario in a non-deployed (eg, test) wired and/or wireless communication network to implement a test for one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (eg, which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

1E is a block diagram illustrating various illustrative elements of the communication system 100 . Such elements may be included, for example, in embodiments of the communication system 100 in which such a system is configured according to 5G and/or NR. Elements are WTRU(s) 102 , (R)AN(s) 113 , DN(s) 185 and AMF 182 , SMF 183 , UPF 184 , 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” may be used interchangeably with the CN 115 .

AMF 182, for example, the end of the RAN CP interface (N2), the end of the NAS (N1), NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful intercept (lawful intercept) ), and so on. SMF 183 may perform various functions, including any of, for example, session management (including session establishment, modification, and release), IP address assignment, selection and control of user plane function(s), and the like. can PCF 186 may, for example, provide support for a unified policy framework for governing network behavior, provide policy rules to one or more control plane functions to enforce policy rules, etc. It can perform a variety of functions, including those of NEF 187 may perform various functions, including any of, for example, exposing capabilities and events, secure provisioning of information from external applications to the network, and the like. UPF 184 is, for example, acting as an anchor point for intra/inter-RAT mobility, assignment of UE IP address, external PDU session point of interconnection to DN such as DN 185, packet routing and any of forwarding, packet inspection, and the like. The RAN 113 may be configured as any of a NG-RAN and a non-3GPP AN. The RAN 113 may connect to a CN, which may be configured as a 5G core network, for example.

1F is a block diagram illustrating an example architecture of a communication system 100 configured in accordance with 5G and/or NR. For convenience and simplicity of description, the terms “5G system” and its abbreviation “5GS” may be used herein to refer to the communication system 100 configured according to 5G and/or NR. The example architecture shown in FIG. 1F is suitable for various services in 5GS, including Proximity Based Services (ProSe), vehicle-to-everything (V2X) services, and other device-to-device (D2D) communication services. may be suitable. The example architecture may include WTRUs 102a - 102d , NG-RAN 113 , DN 185 and 5GC 115 .

Each of the WTRUs 102a - 102 - d may include an application (“WTRU application”) 103 . The WTRU application may be, for example, any of a ProSe application, a V2X application, and other similar type applications. DN 185 may include application server 189 . The application server 189 may include one or more applications servicing any of the WTRU applications.

D1 is the reference point between the WTRU application 103 and the application in the application server 189 . D5 is a reference point between WTRU applications 103 (eg, between two or more WTRU applications 103 of WTRUs 102a - 102d ). PC5 is a D2D interface for direct D2D communication between two or more of the WTRUs 102a-102d. The PC5 interface may be configured as, for example, any of LTE-based PC5, NR-based PC5, and the like. The terms PC5 interface and "sidelink" (in the PHY layer) may be used interchangeably herein.

Direct D2D communication, such as ProSe direct communication, enables establishment of communication paths between two or more of the WTRUs 102 that are in proximity/within range of each other. Direct D2D discovery, such as ProSe direct discovery, may be used by the WTRU 102 to identify other WTRUs in proximity. Details on provisioning WTRUs for direct communication and/or direct discovery and/or for both in-coverage and out-of-coverage scenarios may be given, for example, in 3GPP TS 23.303 V15.1.0.

details

V2X Direct Discovery and Link Setting

2 is a diagram illustrating a Release 16 (Rel-16) Vehicle To Everything (V2X) (eg, which may be interchangeably referred to as an enhanced V2X (eV2X)) Layer 2 (L2) link setup.

For example, as specified by the 3rd Generation Partnership Project (3GPP) for fifth generation (5G) networks, V2X (Vehicle-to-Everything) services (see, eg, Rel-16) is a PC5 reference point procedure Layer 2 (L2) link establishment using (eg, coarse, through, etc.) 2 illustrates L2 link establishment using a PC5 reference point procedure that may be performed according to (1) a WTRU-oriented procedure, and (2) a V2X service-oriented procedure.

For a WTRU oriented procedure, the initiating WTRU (eg, UE-2 in FIG. 2 ) requests a direct communication, including, for example, the higher layer identifier (ID) of the peer WTRU and the source L2 ID of the initiating WTRU. Broadcast a (Direct Communication Request, DCR) message. The peer WTRU (eg, UE-2 in FIG. 2 ) uses its L2 ID as the source L2 ID for the request and the initiating UE L2 ID as the destination L2 ID to accept unicast Direct Communication Accept. , DCA) may decide to respond with a message. In the case of the V2X service-oriented procedure, the initiating WTRU broadcasts a DCR message announcing the V2X service available for L2 link establishment. In such a case, (eg, all) WTRUs that receive the DCR message and are interested in the announced V2X service may respond with a unicast DCA message to establish unicast communication. The interested peer WTRU (eg, UE-2 or UE-4 in FIG. 2 ) uses its L2 ID as the source L2 ID and the initiating WTRU L2 ID as the destination L2 ID.

Referring to Figure 2, for example, such an eV2X procedure, for example, Release 12 (Rel-12) and Release 13 (Rel-13) Compared to the Proximity Service (Proximity Service) direct discovery mechanism, the link establishment procedure and It can be considered (eg, used) as a (eg, more) integrated (eg, more) lightweight direct discovery mechanism. In the eV2X procedure, for example, as shown in FIG. 2 , peer WTRUs detect a service broadcast message without having to first request ProSe codes and/or filters from a network server. Such eV2X procedure, for example, compared to Rel-12 / Rel-13 ProSe direct discovery, can be considered as a server-less procedure or a more distributed procedure.

3 is a diagram illustrating a control plane for eV2X in a PC5 interface; 4 is a diagram illustrating a user plane for eV2X in a PC5 interface. More specifically, FIG. 3 illustrates an Access Stratum (AS) for eV2X and a control plane protocol for PC5 layers, and FIG. 4 illustrates a user plane protocol stack in a PC5 interface for eV2X.

5 is a diagram illustrating a link identifier update procedure. Link identifier update (eg, procedure) may be performed as defined by 3GPP, eg, as shown in FIG. 5 . In the case of the link identifier update shown in FIG. 5, due to privacy requirements (eg, standards, requirements, etc.), IDs used in the unicast mode of V2X communication through the PC5 reference point (eg, , application layer ID, source layer 2 ID, and IP address/prefix) change over time. In such case, a link identifier update request specifying the new L2 ID is sent to the peer WTRU. The new L2 ID is sent as the message payload and is secure. Once the peer WTRU sends a response message acknowledging receipt of the new L2 ID, the new L2 ID may be used.

ProSe UE to UE Relay

6 is a diagram illustrating a WTRU to WTRU relay scenario.

ProSe or proximity services may be applied to Release 17 (Rel-17) of 3GPP 5G standards (eg, also being studied as part of Release 17). Furthermore, in the case of 5G ProSe, there is a (eg, newly introduced) scenario for WTRU-to-WTRU communication using (eg, via) relay WTRUs. In such a scenario, the WTRU discovers (eg, subsequently subsequently) another WTRU via a relay WTRU between two (eg, endpoint) WTRUs and communicates with it. Referring to FIG. 6 , an example in which WTRUs communicate via a relay UE is a service provider WTRU (SP-WTRU) (eg, SP-WTRU, UE1 in FIG. 6 ), service utilizing WTRU (SU-) WTRU) (eg, UE2 in FIG. 6 ), and a relay WTRU (R-WTRU).

The SP-WTRU provides (eg, certain) services that other WTRUs seek (eg, restaurant service, taxi service, gaming console and/or gaming controller service, etc.). The SU-WTRU may discover services provided by the service provider WTRU. There may be any number of SU-WTRUs attempting to discover services provided by a (eg, specific) SP-WTRU. Examples of a service user WTRU may be, for example, any of (eg, a user of) a restaurant customer, a taxi passenger, a gaming controller, an augmented reality (AR)/virtual reality (VR) headset, etc. can The R-WTRU relays (eg, supports) any of discovery messages and PC5 data communication between (eg, two) other WTRUs (eg, between a service provider WTRU and a service using WTRU). can do. An R-WTRU may serve as a proxy between (eg, two) other WTRUs for any of (eg, also) discovery and communication or messages between (eg, two) other WTRUs. can be relayed transparently. In addition, the R-WTRU may participate in a discovery process that enables the service provider WTRU and service-using WTRU to discover each other.

As mentioned above, for example, with respect to the 3GPP V2X standards work, the Rel-16 eV2X work as a baseline for system enhancement (e.g., study on it) for ProSe in the 5G system (5GS). can be used (eg, expected to be widely reused). Support for WTRU to WTRU relay may be considered a key issue to be studied (eg, identified). However, Rel-16 eV2X does not include support for WTRU to WRTU relay, or in other words, does not support R-WTRUs.

According to embodiments, support for a WTRU to WTRU relay feature (which may be referred to as either an R-WTRU or an R-UE feature) may be enabled in 5GS. According to embodiments, for example, to enable support for R-WTRU or R-UE feature in 5GS, at least the following problems/questions may be addressed (eg, should be addressed, resolved needs to be, should be resolved, etc.): (1) how a WTRU (SP-WTRUE or SU-WTRU) discovers a nearby R-WTRUE; (2) how a WTRU (eg, SU-WTRU) discovers a peer WTRU (eg, SP-WTRU) via an R-WTRU; (3) how the network authorizes WTRUs to act as R-WTRUs and/or to peer WTRUs to provide and/or use services via relays; and (4) how to enable the WTRU to verify that the R-WTRU is authorized to act as a relay?

Furthermore, according to embodiments, for example, to enable support for R-WTRU or R-UE feature in 5GS, which can be addressed (should be addressed, needs to be addressed, needs to be addressed, etc.) ) may have security related issues/questions. For example, when using R-WTRUs there may be a problem of how to provide security protection for communication. According to embodiments, a solution to this may provide peer WTRUs with a similar level of security as when communicating without an R-WTRU (eg, should, provide, aim to provide) ). Furthermore, with respect to security, there may be a problem of how to provide privacy protection for communicating with WTRUs when using R-WTRUs. According to embodiments, a solution to this may provide peer WTRUs with a similar level of privacy protection as when communicating without an R-WTRU (eg, should provide, should provide, aim to provide do).

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

Opaque WTRU to WTRU relay

According to embodiments, a relay WTRU (R-WTRU) may enable (provide) a service user WTRU (SU-WTRU) to discover services provided by a service provider WTRU (SP-WTRU). , can facilitate, can support, etc.). According to embodiments, for example, to enable discovery, separate (eg, two A separate) L2 link may be established (eg explicitly). According to embodiments, the R-WTRU may set any of the relay policy and relay parameters (eg, by a Policy Control Function (PCF) either during or after the registration procedure) For example, information indicating it) may be provisioned. According to embodiments, any of the relay policy and relay parameters (eg, information indicating it) may, for example, whether and how to act as a relay for a (eg, given) service. It may identify any of the services and criteria that the R-WTRU may use to determine any of the following. According to embodiments, any of the relay policy and relay parameters may also be considered to be stored (eg, referred to) in the relay authorization context at the WTRU.

According to embodiments, the service broadcast by the SP-UE is included in (eg, associated with, from, etc.) any of the provisioned relay policy and parameters service (eg, services) If the R-WTRU determines (eg, upon determining, when determining) that the R-WTRU matches one of the Any of a WTRU application layer ID (AID) and a relay indication (eg, information indicating this within and/or with the announcement) may be included, eg, in a broadcast message. According to embodiments, for example, upon receiving a response in a unicast message from the SU-WTRU, the R-WTRU may transmit the response in a unicast message sent to the SP-WTRU (eg, , can be included in it). According to embodiments, the response (eg, sent as a unicast message) may include any of a relay indication and a SU-WTRU AID. According to embodiments, the R-WTRU may, for example, establish a mapping of SP-WTRU and SU-WTRU identifiers for a (eg, given) service. According to embodiments, a mapping (eg, current, running, etc.) may be established during a link establishment procedure, eg, maintained for subsequent communication.

According to embodiments, the R-WTRU may communicate with the SP-WTRU (eg, L2 ID1) and the SU-WTRU (eg, L2 ID2) separately (eg, two, different, etc.) ) L2 IDs, for example, two L2 IDs may be used. According to embodiments, the R-WTRU sends messages to the SP-WTRU via PC5. According to embodiments, in such a case, the R-WTRU may use its L2 ID1 (for L2 ID2) as source ID/address and send messages to the SP-WTRU (for SU-WTRU) via PC5 The SP-WTRU L2 ID (for the SU-WTRU) may be used as the destination ID/address when doing so. According to embodiments, 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 embodiments, the SU-WTRU may use its L2 ID as the source L2 ID and the R-WTRU L2 ID2 as the destination L2 ID.

Transparent WTRU to WTRU relay

According to embodiments, a transparent WTRU to WTRU relay may be considered, for example, as a variant of an opaque WTRU to WTRU relay, as described above. According to embodiments, for transparent WTRU to WTRU relay, the R-WTRU may not establish communication with either the SU-WTRU or the SP-WTRU. According to embodiments, the R-WTRU may relay the received message between the SU-WTRU and the SP-WTRU (eg, almost, essentially, largely, etc.). According to embodiments, the R-WTRU may modify IDs such as any of a source L2 ID and a destination L2 ID and an adaptation layer field (eg, at most, essentially, minimally, only, etc.). For example, according to embodiments, modifications may include (1) replacing a source L2 ID with an R-WTRU L2 ID, eg, before forwarding messages to any of the SP-WTRU or SU-WTRU; (2) modifying the destination L2 ID to any of SU-L2 ID or SP-L2 ID; (3) modify the adaptation layer field to the R-WTRU L2 ID associated with any of the SU-WTRU and SP-WTRU; and (4) addition of a relay WTRU indication (RID). According to embodiments, the RIND may include an R-WTRU ID (RID).

According to embodiments, the SP-WTRU and the SU-WTRU may communicate (eg, securely) via (eg, via) the R-WTRU. According to embodiments, the SP-WTRU and the SU-WTRU may establish (eg, protected) communication via (eg, passing through) the R-WTRU. According to embodiments, the R-WTRU may not be involved in establishing a security context. According to embodiments, when the R-WTRU is not involved in establishing a security context, the R-WTRU may, for example, store the content of a secured message (eg, content with integrity and/or confidentiality protected). may not be read and/or modified (eg may not be modified and/or read). According to embodiments, any of the source L2 ID and the destination L2 ID may be transmitted as plain text, eg, read and/or modified by the R-WTRU.

According to embodiments, an R-WTRU performing transparent relay operation, which may be referred to as a transparent R-WTRU, may, for example, similarly to the case of an opaque relay (eg, see above) relay policy and relay It can be provisioned with any of the parameters. According to embodiments, the R-WTRU indicates that the service broadcast by the SP-WTRU in the DCR message is based on (eg, included in, from, or by) any of the provisioned relay policy and parameters. etc.) to match the service (eg, one of them). According to embodiments, if the R-WTRU determines that there is such a match, the R-WTRU may generate a (eg, new) relay L2 ID (R-L2 ID).

According to embodiments, the (eg, new) R-L2 ID is any of the (eg, this particular) DCR message and the SP-L2 ID, and the (eg, this) link establishment request. It may be associated with any other related messages (eg, secure context setup message, link setup accept message, etc.). According to embodiments, the (eg, new) R-L2 ID is included in the mapping table (eg, save, store, entered, etc.). According to embodiments, the R-WTRU (eg, subsequently) may (eg, subsequently) insert the (eg, newly) assigned R-L2 ID into the source L2 ID field of the received message and/or the adaptation layer field of the received message. , and add any of a relay indication (eg RIND) and a relay identifier (eg RID). According to embodiments, the R-WTRU may (eg, subsequently) broadcast a (eg, modified, received) message.

According to embodiments, the R-WTRU may find (eg, determine, find, calculate, etc.) the R-L2 ID in (eg, its own) mapping table; It can do any of adding the SU-L2 ID to the (eg, own) mapping table, and extracting the SP-L2 ID from the (eg, own) mapping table. For example, upon receiving a unicast message from a SU-WTRU whose destination L2 ID field is set to its R-L2 ID, the R-WTRU may indicate a new Relay-L2 ID (R-L2 ID) to be associated with the SU-WTRU. ), find the R-L2 ID in its mapping table, add the SU-L2 ID and the associated new R-L2 ID to (e.g., in) this mapping table entry, The corresponding SP-L2 ID can be extracted. According to embodiments, the R-WTRU may (eg, subsequently) copy the SP-L2 ID into the destination field of the received message and/or into the adaptation layer field of the received message and/or the SU-L2 The R-L2 ID associated with the ID can be copied into the adaptation layer field and the RIND can be added. According to embodiments, the (eg, modified, received) message may be sent (eg, subsequently) to the SP-WTRU. According to embodiments, the R-WTRU may maintain a mapping table comprising any of SP-L2 IDs and SU-L2 IDs. According to embodiments, the R-WTRU assigns (eg, two) R-L2 IDs, eg, to itself, eg, to be respectively associated with an SP-L2 ID and a SU-L2 ID can do. According to embodiments, the R-WTRU may substitute (eg, such) L2 IDs when relaying messages. According to embodiments, relay L2 IDs may be (eg, also) preserved in a mapping table.

According to embodiments, when a DCR message destined for a (eg known) WTRU (eg, a DCR message with a destination addressed with an SP-L2 ID) is received by the R-WTRU, R - The WTRU may (eg, too) assign itself a (eg, new) R-L2 ID. According to embodiments, in such a case, the same steps as discussed above may be followed. That is, the R-WTRU stores (eg, specified) the source L2 ID included in the received DCR message along with the destination L2 ID (eg, SP-L2 ID) already stored in the mapping table (eg, write, map, etc.). According to embodiments, 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.

7 is a diagram illustrating a high level view of a transparent relay, according to embodiments.

Referring to FIG. 7 , according to embodiments, the transparent relay may include any of the following operations: (1) The SP-WTRU broadcasts, for example, a DCR message announcing a supported service. may initiate peer WTRU discovery; (2) a management link may be established between the R-WTRU and the SP-WTRU, and the management link may be used to manage the established link with SU-WTRUs through the R-WTRU; For example, the management link may be established by having the R-WTRU respond to a broadcast DCR message and/or, for example, the management link may be established when needed (eg, when link management is needed, to update the link ID for cast link #1, etc.) (eg, only in that case); (3) the R-WTRU assigns to itself, for example, an R-L2 ID that is used as a source L2 ID to broadcast the received DCR message; (4) The R-WTRU may broadcast a DCR message, where, for example, the source field of the DCR message is modified (eg, only) and the content is the same except for the RID, which may be added. , where the RID is a relay (eg, R-WTRU) identifier unique to the (eg, specific) R-WTRU; (5) A SU-WTRU (eg, SU-UE2) may be interested in (eg, by receiving) an announced service, eg, establishing a link and providing a security context (eg, , keys for integrity protection and encryption) may exchange messages with the SP-WTRU via the R-WTRU; According to embodiments, these messages are not modified by the R-WTRU, but (eg, only) source/destination fields (eg, source/destination L2 IDs) are modified; For example, the R-WTRU may include keying material exchanged between the SP-WTRU and the SU-WTRU so that the SP-WTRU and SU-WTRU can derive security keys for end-to-end communication security. can forward SMC messages; Furthermore, the SP-WTRU may know the L2 ID of the R-WTRU, and the SU-WTRU may know the other L2 ID of the R-WTRU, whereas the SP-WTRU and the SU-WTRU do not know each other's L2 ID. ; (6) A protected unicast link may be established between the SP-WTRU and the SU-WTRU via the R-WTRU, and according to embodiments, the security setting (eg, integrity and/or confidentiality protection) may be - Can be handled in WTRUs and SU-WTRUs; (7) Any of PC5-S messages and data may be exchanged between the SP-WTRU and the SU-WTRU via the R-WTRU, and according to embodiments, the R-WTRU receives information stored in its mapping table may (eg, only) update the source and/or destination L2 IDs based on

IP-based service-oriented discovery and groupcast communication using WTRU-to-WTRU relay

According to embodiments, a WTRU to WTRU relay (eg, R-WTRU) may use Internet Protocol (IP) to support discovery and unicast communication. That is, according to embodiments, an R-WTRU (eg, acting as a WTRU to WTRU relay) supports (eg, only) WTRU-directed discovery and unicast (eg, IP/L2) communication. IP-based mechanisms may be used to (eg, provide). Furthermore, according to embodiments, support for any of service-oriented discovery and groupcast (eg IP/L2) communication is provided, for example, to expand the scope of all possible types of discovery and communication. - May be used (eg, desired) by the WTRU (eg, may be used for WTRU-to-WTRU relay).

According to embodiments, for any of service oriented discovery or groupcast (eg, IP/L2) communication, the transmitting WTRU may not know (eg, the receiving (eg, target) WTRU) about the receiving (eg, target) WTRU. , don't know, don't need to know, etc.) For example, in use cases such as group and/or real-time gaming, the transmitting WTRU may not need to know about the receiving WTRUs. According to embodiments, any of IP-based service oriented discovery and groupcast communication may be, for example, a first WTRU (eg, service provider WTRU, WTRU 1) and a second WTRU (WTRU 2) and a third To be performed using an R-WTRU (eg, WTRU to WTRU relay) that acts as an opaque IP-based relay between WTRUs, such as WTRU (WTRU 3) (eg, service user WTRUs) (eg, WTRU to WTRU relay). For example, it may be possible).

According to embodiments, the R-WTRU may perform IP-based service oriented discovery and groupcast communication using any of the operations and features described below. According to embodiments, a WTRU (eg, R-WTRU) may broadcast an IP-based WTRU-to-WTRU relay service (eg, announcement, message, etc.) via PC5, the broadcast being Contains information indicative of cast communication relay capabilities. According to embodiments, WTRUs (eg, any of WTRU 1 through WTRU 3) discover an R-WTRU (eg, WTRU to WTRU relay) based, eg, on an application layer trigger. (eg, start his discovery). According to embodiments, WTRUs (eg, any of WTRU 1 through WTRU 3) may select (eg, to use) a relay based on information indicative of a groupcast communication relaying capabilities. have. According to embodiments, the R-WTRU may, for example, upon receiving a unicast DCR message containing service information (eg, and empty target user information), the service provider WTRU (eg, A secure link can be established with WTRU 1).

According to embodiments, The R-WTRU, e.g., for WTRU 1 (e.g., service provider WTRU), has a unicast IP address (e.g., based on service information, authorization), an IP multicast to service and associated L2 Any of the groupcast addresses can be assigned. According to embodiments, the R-WTRU may send a DCA message to WTRU 1, which may include a unicast IP address and IP multicast/L2 groupcast addresses for the service. According to embodiments, the R-WTRU creates (e.g., creates generate), update, etc.). According to embodiments, the R-WTRU determines which WTRU can use any of an IP multicast address and an L2 groupcast address for a service (eg, can transmit to that address, using that address). You can set (eg, create, determine, etc.) restrictions on whether you can transmit, etc.). For example, the R-WTRU may limit the use of addresses to (eg, only to) WTRU 1 or some designated WTRUs based on any of the WTRU 1 request and/or service information and provisioned authorization policy. can do.

According to embodiments, the R-WTRU may listen for an L2 groupcast address for a service to receive groupcast communication from any of the participating WTRUs (eg, WTRUs 1 through 3). According to embodiments, the R-WTRU may, for example, upon receiving a unicast DCR message comprising any of empty service information and empty target user information, a service-using WTRU (eg, a WTRU 2 and WTRU 3) may establish a secure link. According to embodiments, the DCR message may include one or more (eg, any number/amount) service information of interest to the service-using WTRU. According to embodiments, the R-WTRU may allocate, for any of WTRU 2 and WTRU 3, a unicast IP address (eg, respectively) and indicate (eg, respectively) to any of WTRU 2 and WTRU 3 in a DCA message. can be sent as According to embodiments, when one or more service information is indicated in a DCR message by a service-using WTRU, the R-WTRU shall have a WTRU 1 IP unicast address and an IP multicast address for one or more services requested and an L2 groupcast. Any of the addresses may also be included in the DCA. According to embodiments, in the case of multiple R-WTRUs, the serving WTRU may select an R-WTRU that provides these addresses for service in the DCA (eg, the serving WTRU may provide service addresses to the DCA). Direct connection with the containing first R-WTRU may be used According to embodiments, the R-WTRU may receive a Domain Name System (DNS) query from any of WTRU 2 and WTRU 3. may include service information According to embodiments, the R-WTRU (eg, in response to a DNS query) may include, for example, WTRU 1 IP unicast address and IP multicast for service and It can send a DNS response containing any of the L2 groupcast addresses.

According to embodiments, for example, upon receiving a DNS response, any of WTRU 2 and WTRU 3 may listen for L2 groupcast and IP multicast for the service. According to embodiments, upon receiving in an inbound L2 message an IP packet (eg, an IP packet from WTRU 1), eg, destined for an IP multicast of a service, the R-WTRU may: For example, an IP packet can be forwarded in an outbound message, using the L2 groupcast address for the service as the destination. According to embodiments, for example, such that any of WTRU 2 and WTRU 3 receives the IP packet, the inbound message may be directed to the R-WTRU's L2 unicast address (eg, to the R-WTRU via a unicast link). may be sent) or an L2 groupcast address for the service (eg, may be sent as a group) may be used as the L2 destination.

opacity Using WTRU to WTRU relays Service Oriented Discovery and Communication

Control plane stacks and user plane stacks for opaque relays

8 is a diagram illustrating control plane protocol stacks supporting opaque WTRU to WTRU relay in accordance with embodiments;

According to embodiments, with reference to FIG. 8 , there may be control plane protocol stacks supporting R-WTRU, which may be interchangeably referred to as opaque WTRU to WTRU relay. According to embodiments, hop by hop (eg, between WTRU1 and R-WTRU and between R-WTRU and WTRU2) link and security establishment, eg, as described above this can be used According to embodiments, the R-WTRU may use its (eg, self-generated) source L2 IDs, and upon receiving frames from another WTRU (eg, from WTRU2 to WTRU1): For example, based on the maintained relay information mapping the WTRU1 L2 ID to the WTRU2 L2 ID, L2 frames for the WTRU may be built (eg, towards WTRU1 for WTRU2).

According to embodiments, the R-WTRU may process the security of PC5 signaling packets on a per-link basis, for example, using the security context established for that particular link. According to embodiments, the R-WTRU may perform actions upon receiving from a first WTRU a PC5-S message destined for a second WTRU (or vice versa). That is, according to embodiments, the R-WTRU may perform any of the following: (1) checking (eg, reviewing, determining, verifying, etc.) integrity protection and/or with the first WTRU decrypting the protected PC5-S packet using the established security context; (2) any of modifying or generating the corresponding PC5-S message (eg, to include a relay indication information element (IE)); (3) applying security to the packet using the security context established with the second WTRU; and (4) setting the source L2 ID to the R-WTRU's own source L2 ID and setting the L2 destination to the L2 ID of the second WTRU and sending it to the second WTRU.

9 is a diagram illustrating user plane protocol stacks supporting opaque WTRU to WTRU relay, in accordance with embodiments;

According to embodiments, with reference to FIG. 9 , there may be user plane protocol stacks that support R-WTRU (eg, opaque WTRU to WTRU relay). According to embodiments, the R-WTRU may be the default IP router for WTRUs that are relay, eg, for any of both the first and second WTRUs discussed above (eg, can act as such). According to embodiments, the R-WTRU may convert (eg, to) IP packets received on a (eg, given) link (eg, to the R-WTRU) based on relay mapping information. , may forward (eg, automatically) via the associated link (from the R-WTRU). According to embodiments, with respect to the control plane, the R-WTRU may process the security of incoming IP packets on a per-link basis. For example, the R-WTRU may check integrity protection and/or decrypt IP packets received on a link with the first WTRU using the security context established for that link with the first WTRU. According to embodiments, the R-WTRU may (eg, subsequently) apply security to that packet, using the source L2 ID as the R-WTRU's own source L2 ID and the L2 destination as the L2 of the second WTRU. It may transmit the protected packet in the L2 frame to the second WTRU using it as an ID.

Link settings for opaque relays

According to embodiments, the R-WTRU may enable discovery, by the SU-WTRU, of services provided by the SP-WTRU. According to embodiments, (e.g., two) separate L2 links, e.g., a link between an SP-WTRU and an R-WTRU and a link between an R-WTRU and a SU-WTRU (e.g., a ) can be set. Accordingly, the present disclosure is not limited thereto, and any number of L2 links may be established (eg, configured, operated, etc.), eg, by the R-WTRU.

R-WTRU behavior for opaque relays

According to embodiments, the WTRU may signal relay capabilities, eg, to the network during registration of the WTRU. According to embodiments, the WTRU may be configured to act as a relay via (eg, using, by, thereby, etc.) a relay policy and provisioning of any of the relay parameters, eg, by the PCF. authorization can be received. According to embodiments, a WTRU may be authorized to act as a relay (eg, as an R-WTRU), any of on a per-service, per-PLMN, or per-RAT basis. According to embodiments, provisioned parameters (eg, part of a relay authorization context) for relay operations may include any of the following: (1) Services or service type for which the WTRU is authorized to relay. a list of any of; (2) relay availability criteria, eg, any of a registration area, geographic area, time of day for a place or when a WTRU may act as a relay for a (eg, specific) service; and (3) relay security parameters, e.g., as proof of authority to relay to peer WTRUs (e.g., any of SP-WTRU and SU-WTRU) for which the WTRU wishes to use the relay service. A signed certificate that may be used to do this, and according to embodiments, these relay security parameters may (eg, also alternatively) be provided by the WTRU's application layer. According to embodiments, a WTRU may receive a broadcast DCR message announcing a service (eg, given). According to embodiments, the broadcast DCR message may include an indication of whether the service may be used via relay. According to embodiments, any of a broadcast DCR message or similar PC5 message may be received over the PC5 discovery channel.

According to embodiments, the WTRU may match the announced service with one of the services from its provisioned relay policy/parameters. According to embodiments, the WTRU may invoke mutual authorization with the SP-WTRU and establish security on the PC5 link, eg, after matching a known service. According to embodiments, the WTRU may send relay mapping information, including, for example, any of an SP-WTRU L2 ID and an SP-WTRU Application Layer ID (AID) for any of a known service or service type. can be saved According to embodiments, the WTRU may broadcast a DCR comprising any of an indication that the WTRU is acting as a relay (eg, as an R-WTRU) and an SP-WTRU AID for the announced service. According to embodiments, the WTRU may perform mutual authorization with the SU-WTRU and security setup on the PC5 link, eg, after broadcasting the DCR. According to embodiments, upon receiving the DCA from the SU-WTRU, the WTRU may update its relay mapping information with the L2 ID and AID of the SU-WTRU. According to embodiments, the WTRU transmits to the SP-WTRU a DCA including, for example, any of the RIND and the SU-WTRU AID, for example using the stored SP-WTRU L2 ID as the destination L2 ID. can do.

SU-WTRU behavior for opaque relays

According to embodiments, the WTRU may be provisioned by the PCF with any of a relay policy and relay parameters. Parameters provisioned for relay operations (eg, part of the relay user authorization context) may include any of the following: Services that the WTRU may use via the relay (eg, R-WTRU). and a list of any of the service types; any of relay availability and selection criteria; PC5 QoS parameters for relayed services; and relay security parameters. According to embodiments, any of the relay availability and selection criteria may be determined by, for example, where the use of a relay (eg, R-WTRU) for a (eg, specific) service may be permitted. or any of the registration area, geographic area, and time of day constraints for time of day. According to embodiments, a relay policy may indicate how a service may be used when the SP-WTRU, R-WTRU and SU-WTRU (eg, all) are within range of each other. According to embodiments, any of the connections to the SP-WTRU (eg, backup to the SP-WTRU) and to the R-WTRU (eg, both) may be allowed or only the SP-WTRU (eg, the SP-WTRU) For example, a connection to one) may be allowed.

According to embodiments, PC5 QoS parameters for relayed services may be adapted (eg, specifically) for use (eg, transmission) via a relay (eg, R-WTRU). may be default QoS values for any of the services or service types. According to embodiments, some values (eg, basic QoS values, PC5 QoS parameters) may be the same as when using the service directly (eg, without relay), while other values may be different (eg, For example, when the service is used via relay, the Packet Delay Budget parameter may be higher). According to embodiments, the PC5 QoS parameters may include any of a maximum relay range or a distance from a relay, eg, to use (eg, be able to use) a service via the relay. may not be exceeded. According to embodiments, the relay security parameters may include an authorization token. According to embodiments, the WTRU may use the authorization token to check (eg, determine, verify, compute, etc.) proof of authority to provide relay services from the R-WTRU. According to embodiments, the security parameter may (eg, alternatively) be provided by the application layer of the WTRU.

According to embodiments, a WTRU (eg, R-WTRU) may receive a broadcast DCR announcing a given service. According to embodiments, the WTRU may broadcast, e.g., when a broadcast DCR message (which may be interchangeably referred to as any of a DCR message and a DCR) is transmitted as a PC5 discovery message, e.g. To receive the cast DCR message, the discovery channel may be (eg, optionally) monitored. According to embodiments, the WTRU may, for example, based on a relay indication (eg, any of RIND or RID) (eg, included), a DCR on behalf of) from the R-WTRU. According to embodiments, the WTRU checks (eg, determines, verifies, calculates, etc.) whether the R-WTRU is authorized to act as a relay, using provisioned security parameters, such as, for example, an authorization token. )can do.

According to embodiments, the WTRU may determine that a service may be used via relay based on any of a provisioned relay policy and relay parameters (eg, a service to be used may be used via a relay in the current registration area). matching services from authorized services (eg, a list of services). According to embodiments, the WTRU may perform (eg, perform) mutual authorization with the R-WTRU and security establishment for the PC5 link, eg, after service matching. ). According to embodiments, the R-WTRU (eg, optional, additional, etc.) establishes mutual authorization and security of end-to-end communication between the SP-WTRU and the SU-WTRU (eg, its steps, its parts, etc.). According to embodiments, the WTRU may transmit a DCA to the R-WTRU, eg, to complete establishment of an L2 link for a relayed service.

SP-WTRU behavior for opaque relays

According to embodiments, the WTRU may be provisioned with any of relay policies and relay parameters, eg, by the PCF. According to embodiments, any of the provisioned policies and parameters (eg, part of a relay user authorization context) include criteria for relay usage (eg, operations) for the SU-WTRU. can do. According to embodiments, the WTRU may transmit a broadcast DCR message announcing a (eg, specific) service. According to embodiments, a broadcast DCR message (eg, sent by the WTRU) may be relayed for service based on (eg, according to) any of the provisioned relay policies and relay parameters. It may include information indicating whether there is (eg, which services can be relayed). According to embodiments, the WTRU may use (eg, such) an indication to dynamically limit (eg, based on policy) any of when or where a service may be relayed. According to embodiments, the broadcast DCR message may be, for example, a PC5 discovery message, transmitted over a discovery channel.

According to embodiments, the WTRU may perform mutual authorization with the R-WTRU. According to embodiments, the WTRU may perform security setup on the PC5 link, eg, after performing mutual authorization with the R-WTRU. According to embodiments, the WTRU may respond to any of the relay indications (eg, RIND, RID) and SU-WTRU AIDs included and/or upon receiving DCA from the R-WTRU and/or the service, for example. Based on the R-WTRU, it may be determined that it is being used by the SU-WTRU. According to embodiments, the WTRU may perform a (eg, final) check to determine whether the service may be relayed, eg, based on any of a provisioned relay policy or relay parameters. have.

Call flow to opaque relay

10 is a diagram illustrating a service oriented discovery procedure using opaque WTRU to WTRU relay, in accordance with embodiments.

Referring to Figure 10, according to embodiments, the procedure for opaque WTRU to WTRU relay, i.e., the procedure performed by the R-WTRU, involves any of R-WTRU, SP-WTRU, and SU-WTRU. It may be any of the service-oriented discovery and link establishment procedures. According to embodiments, any of the service oriented discovery and link establishment procedures may include any of the following operations 0-9 (eg, may follow the call/signal flow of FIG. 10 ).

According to embodiments, in operation 0, the R-WTRU may register with the network, and the R-WTRU may indicate relay capabilities, eg, when registering with the network. According to embodiments, the R-WTRU may use any of relay policies or relay parameters (eg, from PCF via AMF), eg, to perform (eg, operations) as a relay. can receive According to embodiments, the SP-WTRU and the SU-WTRU may (eg, also) register with the network, eg, to perform (eg, perform operations) as users of the relay, the relay user. It may be provisioned with any of policies or relay (eg user) parameters. According to embodiments, any of relay policies and relay parameters for relay and relay users have been described above. According to embodiments, a WTRU (eg, all or any three of R-WTRU, SU-WTRU, or SP-WTRU) (eg, alternatively or additionally) (eg, may be pre-provisioned with any of its respective) relay policy or relay parameters. According to embodiments, any of such parameters may be (pre)provisioned into any of the Mobile Equipment (ME) and Universal Integrated Circuit Card (UICC) portions of the WTRU.

According to embodiments, in operation 1 , the SP-WTRU may transmit a DCR in a broadcast message, eg, to announce a (eg, specific) service. According to embodiments, the SP-WTRU may include an indication limiting relay of service. For example, an SP-WTRU may prioritize (eg, grant) use by SU-WTRUs that are in close range (eg, in an area with a high density of SU-WTRUs within range). can be desired). According to embodiments, the SP-WTRU may notify the relays (eg, R-WTRUs) that relaying the service is prohibited (eg, temporarily, based on off-to-peak time). have.

According to embodiments, in operation 2, e.g., upon receiving a broadcast DCR message announcing a given service, the R-WTRU, e.g. a relay restriction indication or provisioned relay policy of the R-WTRU and/or based on any of the relay parameters, may determine that it may act as a relay for a service (eg, may provide a relay for a service provided by an SP-WTRU). . According to embodiments, the known service and/or service type may match a provisioned service and/or service type to which the R-WTRU may be authorized to relay. According to embodiments, the R-WTRU includes any of, for example, the service type received in the DCR message, the L2 ID and AID of the SP-WTRU, the R-WTRU L2 ID and any IP address and QoS information. to store relay mapping information.

According to embodiments, in operation 3, the R-WTRU broadcasts a DCR including any of the service and service type received from the SP-WTRU, an indication that the R-WTRU may act as a relay, and the SP-WTRU AID. can be cast According to embodiments, the R-WTRU may include other parameters in the broadcast DCR, such as a locally formed IP address.

According to embodiments, in operation 4, e.g., upon receiving a broadcast DCR message announcing a (e.g., given) service, the SU-WTRU, e.g., included in the broadcast DCR Based on the relay indication, it may be determined that the broadcast DCR message is originating from the R-WTRU (eg, on behalf of the SP-WTRU). According to embodiments, the SU-WTRU may determine that it can use the announced service via relay, for example based on its provisioned relay policy or any of the relay parameters. For example, the SU-WTRU may match a service that is authorized to be used via relay in the current registration area, eg, a service from a list of services). According to embodiments, the SU-WTRU may check whether the R-WTRU is authorized to act as a relay using provisioned security parameters (eg, authorization token).

According to embodiments, if the SU-WTRU is within range of both the R-WTRU and the SP-WTRU, the SU-WTRU may, for example, based on a provisioned relay policy or any of the relay parameters: In addition to the connection with the SP-WTRU, the R-WTRU may decide whether to establish a connection or not. For example, if the SU-WTRU has an existing connection with the SP-WTRU, the SU-WTRU may not proceed with operations 5 through 8 with the R-WTRU. According to embodiments (eg, as an alternative) the SU-WTRU may proceed with the remainder of the procedure, eg, as a backup to an already established existing connection (eg, link) with the SP-WTRU. , may establish a link with the R-WTRU. According to an embodiment, the SU-WTRU decides to release or maintain the link with the R-WTRU when the link with the SP-WTRU is thereafter established based on the provisioned relay policy/parameters (eg, conversely). can

According to embodiments, the SU-WTRU may perform a mutual authorization and link security establishment procedure with the R-WTRU (eg, in operation [Sec-A1]). According to embodiments, if the mutual authorization and link security establishment procedures are not successfully completed (eg, the S-WTRU cannot authorize the R-WTRU or cannot establish proper security of the link), the S- The WTRU may not (eg, do not, cannot, etc.) go through the service oriented discovery and link establishment procedure.

According to embodiments, in operation 5, the SU-WTRU may send a DCA unicast message to the R-WTRU to confirm establishment of an L2 link to be used for relayed service. According to embodiments, the R-WTRU may perform mutual authorization and link security establishment procedures with the SP-WTRU (eg, in operation [Sec-A2]). According to embodiments, if the mutual authorization and link security establishment procedures are not successfully completed (eg, the R-WTRU cannot authorize the SP-WTRU or cannot establish proper security of the link), the R- The WTRU may discard any relevant stored relay mapping information and may not proceed with the following steps.

According to embodiments, in operation 6, for example, upon receiving DCA from the SU-WTRU, the R-WTRU may update the relay mapping information to include any of the SU-WTRU's L2 ID and AID. have. According to embodiments, in operation 7 , the R-WTRU uses the SP-WTRU L2 ID retrieved from the relay mapping information as the destination L2 ID, the relay indication (eg, RIND, RID) and the SU-WTRU AID A DCA unicast message containing any of the following may be sent to the SP-WTRU.

According to embodiments, in operation 8, e.g., upon receiving a DCA unicast message, the SP-WTRU, e.g., based on an included relay indication (e.g., RIND, RID): It may be determined that the DCA unicast message originates from the R-WTRU (eg, on behalf of the SU-WTRU). According to embodiments, it is contemplated that the relay indication may be provided in a previous message, for example, during any of mutual authorization or security establishment. According to embodiments, the SP-WTRU may configure its provisioned relay policy or relay parameters (eg, indicating any of that relaying is allowed in the current registration zone, no relay restrictions are in effect, etc.) may determine that the announced service may be relayed via the R-WTRU based on any of the following:

According to embodiments, if the SP-WTRU is within range of both the R-WTRU and the SU-WTRU, the SP-WTRU, for example, based on any of its own provisioned relay policy or relay parameters. Thus, in addition to connections with the SU-WTRU, it can be determined whether to allow the establishment of a connection through the R-WTRU. For example, if the SU-WTRU has an existing connection with the SP-WTRU, the SP-WTRU may not proceed with link establishment with the R-WTRU.

According to embodiments (eg, as an alternative to the signal flow of FIG. 10 ), the R-WTRU may, before establishing a link (eg, link 2) different from the SU-WTRU of interest (eg, link 2). For example, operations 3 to 6) may (eg, first) establish a link (eg, link 1) with the SP-WTRU (eg, operation 1, operation 2, operation Sec -A1, operation). 7). According to embodiments, in such a case, the relay mapping information may (eg, initially) not include any SU-WTRU related information (eg, L2 ID), eg, the SU-WTRU While not connected to the R-WTRU, the R-WTRU may discard any service data coming from the SP-WTRU. According to embodiments (eg, upon successful establishment of link 1), the R-WTRU may decide to broadcast a DCR on behalf of the SP-WTRU (eg, message 3 in FIG. 10 ). ).

According to embodiments (eg, upon receiving DCA from a SU-WTRU) (eg, message 5 in FIG. 10 ), the R-WTRU may send any of the SU-WTRU or Link 2 information The relay mapping information may be updated to include (eg, operation 6). According to embodiments, service data may be relayed between the SP-WTRU and the SU-WTRU via the R-WTRU, eg, after updating relay mapping information. According to embodiments, the R-WTRU may repeat the process of establishing a new link and waiting for an interested SU-WTRU to connect before relaying service information. According to embodiments, the R-WTRU pre-configures with the SP-WTRU, eg, based on the received DCR message content (eg, any of the source L2 ID, application layer ID, and service). Checks may be performed to limit the number of link(s) being made. According to embodiments, if the R-WTRU has already pre-established a link for service A with the SP-WTRU, but the SU-WTRUs are not connected to the R-WTRU for service A, the R-WTRU and may not attempt (eg, do not try) to create a new link.

Link management for opaque relays

According to embodiments, link identifier update may be performed for a unicast link using an opaque WTRU to WTRU relay (eg, R-WTRU).

An R-WTRU is coupled to a first WTRU (eg, UE1) via a first PC5 link (eg, link 1) and via a second PC5 link (eg, link 2) to a second WTRU (eg, UE2) ), using an existing (e.g., conventional) link identifier update procedure (e.g., see above) independently on each link may pose potential risks to the privacy of WTRU identifiers. have. An attacker may attempt to correlate L2 frames (and containing L2 IDs) exchanged over one link with a frame exchanged over another link. For example, an attacker infers that some L2 frames transmitted on link 1 are triggering L2 frames on link 2 (eg, traffic from a first WTRU (UE1) to a second WTRU (UE2)) and 2 Traffic analysis may be performed to associate corresponding L2 IDs (first WTRU, R-WTRU, second WTRU) used across the links. In such a case, if the R-WTRU performs the conventional link identifier update procedure on link 1 (while the identifiers used on link 2 remain unchanged), the attacker can Through this, it is possible to indirectly link the old identifiers in link 1 with the new identifiers.

According to embodiments, for example, to mitigate the risks mentioned above, the R-WTRU may be configured such that new L2 IDs in the first link are always used together with new L2 IDs in the second link (and link coordinating or synchronizing changes of L2 IDs across links (eg, link 1 and link 2), to use previous L2 IDs in 1 with previous L2 IDs in link 2 any of these can be done.

11 is a diagram illustrating an enhanced link identifier update procedure using an opaque R-WTRU, in accordance with embodiments.

According to embodiments, in an exemplary enhanced link identifier update procedure, secure PC5 unicast links may be established between a first WTRU and an R-WTRU and between an R-WTRU and a second WTRU, respectively (eg, , is assumed to be set). According to embodiments, it is assumed that WTRUs exchange all their signaling messages shown in FIG. 11 using confidentiality, integrity and replay protection.

According to embodiments, in operation 1101, the first WTRU (eg, UE1) transmits to the R-WTRU the newly generated UE1 L2 ID in a link identifier update request message to the R-WTRU and the link identifier update procedure. can be initiated. According to embodiments, in operation 1102 , the R-WTRU may store a new UE1 L2 ID and may generate new source L2 IDs to be used via link #1 and link #2 respectively. According to embodiments, in operation 1103 (eg, as opposed to conventional link update procedures), the R-WTRU sends a second WTRU to link #2 (eg, UE2) and may initiate a different link identifier update procedure. According to embodiments, 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 embodiments, in operation 1104 , the second WTRU may store a new R-WTRU L2 ID for link #2 and generate a new UE2 L2 ID. According to embodiments, in operation 1105 , the second WTRU transmits a new UE2 L2 ID in a link identifier update response message.

According to embodiments, in operation 1106 , for example, upon receiving a link identifier update response message, the R-WTRU may store the new UE2 L2 ID. According to embodiments, in operation 1107 , the R-WTRU transmits to the first WTRU a new R-WTRU L2 ID for link #1 in a link identifier update response message. According to embodiments, in operation 1108 , the first WTRU may store a new R-WTRU L2 ID for link #1. According to embodiments, at operation 1109 , the first WTRU may transmit a link identifier update ACK message to the R-WTRU to acknowledge receipt of the new R-WTRU L2 ID. According to embodiments, the R-WTRU may send a link identifier update ACK message to the second WTRU to acknowledge receipt of the new UE2 L2 ID. According to embodiments, at operation 1110 , the WTRU may start using new IDs across link #1 and link #2. According to embodiments, the first WTRU may use the IDs instead of (eg, as an alternative thereto), eg, using acknowledgment messages (eg, operation 1109 ). As long as there is an ongoing communication (eg, implicitly), the old IDs may be retained. According to embodiments, the WTRUs may initiate communication using new IDs (e.g. For example, a specific, agreed upon, configured, etc.) may retain old IDs for a time limit (eg, UTC time).

12 is a diagram illustrating an enhanced link identifier update procedure using an opaque R-WTRU, in accordance with embodiments.

According to embodiments, referring to FIG. 12 , there may be a case where an R-WTRU initiates a link identifier update procedure. According to embodiments, for example, as shown in FIG. 12 as a difference compared to FIG. 8 , the R-WTRU configures multiple links (eg, link #1 and link #2, respectively, respectively). can initiate simultaneous (eg, two or more) procedures. According to embodiments, the R-WTRU confirms, eg, under the condition of receiving link identifier update response messages from both a first WTRU (eg, UE1) and a second WTRU (eg, UE2). By sending a response message (see operation 5 in FIG. 12 ), it is possible to synchronize the use of new IDs across both Link#1 and Link#2.

Service-oriented discovery and communication using opaque WTRU-to-WTRU relays

According to embodiments, the R-WTRU may receive messages from the SP-WTRU while the SU-WTRU is too far away, eg, the SU-WTRU does not receive those messages. According to embodiments, in such a case, the R-WTRU may retransmit such messages, eg, so that they may be received by the SU-WTRU. According to embodiments, the same may be repeated in the other direction, ie from the SP-WTRU to the SU-WTRU. According to embodiments, the R-WTRU may update any of the source or destination fields/values (eg, source/destination L2 IDs) and may forward information in the updated fields/values. have. According to embodiments, the R-WTRU may not “consume” the messages, or in other words, the R-WTRU may not see (eg, cannot see) the content of received messages and verify the integrity. It does not and/or does not decrypt received messages, does not sign messages it forwards, and/or does not encrypt messages. According to embodiments, a security association may be established end-to-end, for example between an SP-WTRU and a SU-WTRU.

Control plane stack and user plane stack

13 is a diagram illustrating a control plane stack supporting a transparent R-WTRU, in accordance with embodiments;

According to embodiments, a transparent R-WTRU (eg, as opposed to an opaque relay/R-WTRU) has a source L2 ID in already formed L2 frames relayed between WTRUs (eg, WTRU1 and WTRU2). You can use your own (eg, eponymous) L2 ID that is inserted as a self-generated (eponymous) L2 ID. According to embodiments, L2 frames may be forwarded based on mapped WTRU L2 IDs (eg, WTRU1 L2 ID, WTRU2 L2 ID), eg, similar to opaque relay. According to embodiments, in the case of a transparent R-WTRU, for example, as shown in Figure 13 where the PDCP layer terminates at WTRU1 and WTRU2 and not at the R-WTRU, and WTRU2) may be secured end-to-end. According to embodiments, the R-WTRU (eg, as a result of PDCP layer terminations) may map an incoming signaling packet (eg, from WTRU1 to WTRU2) to its L2 ID as source ID and relay mapping. Before forwarding in the L2 frame using the L2 ID of the target WTRU according to the information (eg, the L2 ID of WTRU2), it may not process any security of that incoming signaling packet.

14 is a diagram illustrating a user plane stack supporting a transparent R-WTRU, in accordance with embodiments; According to embodiments, referring to the user plane stack, as with the control plane, the R-WTRU does not process and/or apply any security to relayed ingress/outgoing IP packets.

Link settings

Peer discovery and unicast link communication establishment

According to embodiments, in the case of a service-oriented method, the SP-WTRU may broadcast a service (eg, that it supports) in a unicast link establishment request message (eg, a DCR message), A SU-WTRU interested in the service may respond (eg, respond to this message) by triggering a security context establishment and sending a unicast link accept message (eg, a DCA message). According to embodiments, a user-oriented method may be used (eg, also, too, etc.) in which, for example, instead of a service ID, the application ID of the SU-WTRU is specified in the broadcast message. According to embodiments, the SP-WTRU may broadcast a service (eg, it supports) in a discovery message (eg, any of an announcement message or a discovery response), and may be interested in a service An existing SU-WTRU may respond by sending a unicast link establishment request message (eg, a DCR message). According to embodiments, a service oriented method is used to describe any of the SP-WTRU, SU-WTRU and R-WTRU behavior, such features being (eg, also) any of a user oriented method or a discovery method. can be applied to

According to embodiments, in the case of any of user-oriented and discovery methods (eg, as described in accordance with embodiments above) (eg, as compared to conventional service-oriented methods) , the R-WTRU may be used between the SP-WTRU and the SU-WTRU. According to embodiments, both the SP-WTRU and the SU-WTRU may not know (eg, do not know) the L2 ID of their peer WTRU. According to embodiments, the WTRUs transmit messages to and receive messages from the R-WTRU. According to embodiments, a security association and unicast link is established between (eg, only between) the SP-WTRU and the SU-WTRU, in which case the R-WTRU (eg, only, just) Messages can be forwarded.

According to embodiments, the SP-WTRU may announce (eg, its own) supported services and/or use a (eg, generic) discovery mechanism, eg, as described above. The SU-WTRU may be discovered using either a user-oriented or a service-oriented method. According to embodiments, the SP-WTRU may detect that a communication is going through the R-WTRU by obtaining a relay identifier (eg, RID, RIND, which may serve as a relay indication) on received messages. have. According to embodiments, the SP-WTRU establishes a protected unicast link with the SU-WTRU via the R-WTRU. According to embodiments, the SP-WTRU (eg, additionally) establishes a protected unicast link with the R-WTRU for link management (eg, any of link identifier update, modification, release, etc.) set

According to embodiments, an R-WTRU may assign itself two R-L2 IDs when a unicast link is established between peer WTRUs, and the R-WTRU may act as a relay for this link. . According to embodiments, the first R-L2 ID may be used when forwarding a message from a first WTRU to a second WTRU. According to embodiments, the second R-L2 ID may be used when forwarding a message from the second WTRU to the first WTRU. According to embodiments, the R-WTRU may, for example, associate the L2 IDs of peer WTRUs (eg, any of an SP-L2 ID and a SU-L2 ID) and a corresponding (eg, a corresponding one) assigned to it. For example, a mapping table including mapping of two R-L2 IDs may be maintained. According to embodiments, for example, when receiving a message, the R-WTRU may use the L2 ID specified in the destination field (eg, its own R-L2 ID). According to embodiments, the R-WTRU may (eg, additionally) use the transmitting WTRU L2 ID, eg, to look up a relevant mapping entry in its mapping table. According to embodiments, the R-WTRU (eg, subsequently) updates the source and destination fields of the message, eg, with its R-L2 ID and the peer WTRU's L2 ID, before forwarding the message. can do. According to embodiments, the R-WTRU may (eg, also) add its RID to the DCR message and/or discovery message it forwards. According to embodiments, the R-WTRU may (eg, also) respond to a broadcast DCR message to establish a unicast management link with the SP-WTRU. According to embodiments, the R-WTRU may use another R-L2 ID assigned to it for this management link and may specify its relay identifier (RID).

According to embodiments, the SU-WTRU may discover the SP-WTRU via the R-WTRU. According to embodiments, a conventional (eg, generic) discovery mechanism is used, eg, using any of a user oriented method, a service oriented method, and a discovery procedure. According to embodiments, the SU-WTRU may receive any of a broadcast DCR message with RIND or a discovery message with RIND, and such RIND may be a RID. According to embodiments, the SU-WTRU may, via the R-WTRU, establish a protected unicast link with the SP-WTRU. According to embodiments, link management may be performed via any of communication with the SP-WTRU or a protected unicast link with the R-WTRU.

15 is a diagram illustrating discovery and unicast link establishment, according to embodiments.

According to embodiments, with reference to FIG. 15 , service-oriented discovery may be performed and a unicast link may be established between the SP-WTRU and the SU-WTRU via the R-WTRU. According to embodiments, with reference to FIG. 15 , the SU-WTRU may respond to the received DCR by sending a Direct Security Mode (DSM) command message (eg, as described above). can

According to embodiments, at operation 1501 , the R-WTRU may register with the network and may specify its R-WTRU capabilities. According to embodiments, the R-WTRU may be provisioned with relay policy parameters from the network. According to embodiments, at operation 1502, the SU-WTRU may determine a destination L2 ID (eg, broadcast L2 ID) associated with any of the applications and services it is interested in receiving; Lower layers can be configured to receive such messages. According to embodiments, in operation 1503 , the application layer provides information (eg, any of broadcast L2 ID, service ID, WTRU's application ID, etc.) for PC5 unicast communication to the ProSe layer. can do. According to embodiments, at operation 1504 , the ProSe layer may trigger the peer WTRU discovery mechanism, eg, by sending a broadcast DCR message. According to embodiments, a broadcast DCR message may include an SP-L2 ID as a source, a broadcast L2 ID as a destination, and any of other parameters related to the provided application and service. According to embodiments, operations 1505 to 1507 may be selectively performed. For example, according to embodiments, if a protected link between the SP-WTRU and the R-WTRU exists (eg, already) to the SP-L2 ID1, then these operations 1505 - 1507 are can be skipped. Additional details of using link management are described herein.

According to embodiments, in operation 1505 , the R-WTRU may receive the broadcast DCR message and determine whether it is capable of relaying (eg, this) applications and/or services (eg, configured to relay). According to embodiments, the R-WTRU may compare the known service to (eg, find a match for) any of its provisioned relay policy or relay parameters. According to embodiments, in the case of a match, the R-WTRU sets itself an R-L2 ID (eg, R-L2 IDa, where Ida refers to the ID assigned to it) to be used for the management link with the SP-WTRU. can be assigned to According to embodiments, the R-WTRU responds to a received DCR message, eg, to establish a protected unicast link for management of other unicast links related to a broadcast DCR message from the SP-WTRU. can do. According to embodiments, such other unicast links may be established between the SP-WTRU and SU-WTRU and relayed by the R-WTRU. According to embodiments, in operation 1506 , the R-WTRU and the SP-WTRU may establish a security context. According to embodiments, the R-WTRU may specify (eg, this) that the link is established for link management. According to embodiments, the R-WTRU uniquely identifies itself (eg, also) and has its own unique relay ID (eg, RID) that serves as a relay WTRU indication (eg, RIND). can be specified. According to embodiments, (eg, all) R-WTRUs may be provisioned with a unique identifier (eg, RID) (eg, will be, should be, should be, etc.). According to embodiments, the R-WTRU may include its RID in a confidentiality protected message (eg, DCA) to preserve R-WTRU privacy. According to embodiments, in operation 1507 , unicast link establishment may be completed, eg, if a security context is established.

According to embodiments, at operation 1508 , the R-WTRU may forward (eg, begin forwarding) a broadcast DCR message received from the SP-WTRU. According to embodiments, the R-WTRU may use an R-L2 ID (eg, SP-L2 ID1) to be used as a replacement for the SP-L2 ID (eg, SP-L2 ID1) when forwarding messages from the SP-WTRU to the SU-WTRUs. , R-L2 IDa) can be assigned to itself. According to embodiments, these (eg, tow) IDs may be stored in a local mapping table, eg, the R-WTRU overrides the source field with its R-L2 IDa You can, and you can add your own RID. According to embodiments, the R-WTRU may detect (eg, have the ability to detect) the direction in which the message was received (eg, from where the message was received). According to embodiments, in such a case, the R-WTRU may keep the receive direction together with the SP-L2 ID in the mapping table.

According to embodiments, in operation 1509 , if another direction is available, the R-WTRU sends a modified DCR message with its R-L2 IDa as the source toward the other directions (eg, the initial transmitter). /not towards SP-WTRU), may transmit. According to embodiments, any of the SU-WTRUs (eg, see FIG. 15 , SU-UE1, SU-UE2 and SU-UE3) may receive the broadcast message. According to embodiments, at operation 1510 , SU-WTRU2 may be interested in such a service (eg, a service announced in DCR), eg, to establish a security context with the SP-UE. It may respond to the R-WTRU by sending a DSM command message. According to embodiments, SU-WTRU2 may track R-L2 IDa and RID. According to embodiments, the RID may be specified using the DSM command message, for example, so that when the SP-WTRU receives the DSM command message, it knows that the link is going through this R-WTRU.

According to embodiments, at operation 1511 , the R-WTRU may receive the DSM command message and may look up the relevant entry in its mapping table using the R-L2 IDa specified in the destination field. According to embodiments, if a mapping entry does not have a (eg, any) SU-WTRU associated with it, then the R-WTRU uses the L2 ID (eg, SU-L2 ID2) specified in the source field. The mapping entry may be updated, and according to embodiments, the R-WTRU may (eg, additionally) determine the direction in which the message was received (eg, where the message was received from) can be tracked. According to embodiments, the R-WTRU may assign itself a new R-UE L2 ID2b to be used when forwarding messages from SU-L2 ID2 to SP-L2 ID1. According to embodiments, the new R-L2 IDb may be (eg, also) stored in the mapping entry. According to embodiments, the R-WTRU may set the source field or adaptation layer field of the message to R-L2 IDb, and the R-WTRU may set the destination field to the SP-L2 ID1 retrieved from the mapping entry.

According to embodiments, the R-WTRU may not view or modify (eg, view or not modify) the content of the message, eg, may only modify the source and destination fields of the message. According to embodiments, e.g., upon receipt of a DSM command message, the R-WTRU, e.g., if the entry is already associated with another SU-WTRU, e.g., the other SU-WTRU If you have already responded to a cast message and have already established a unicast link, you can create a new entry in the table with the same R-L2 ID specified in the destination field. According to embodiments, when multiple entries in the mapping table associated with the R-L2 ID are found, the R-WTRU looks up the SU-L2 ID in addition to the R-L2 ID, as discussed below. )can do. According to embodiments, at operation 1512 , the R-WTRU sends the modified message to the SP-WTRU, eg, in any of a direction associated with this L2 ID or a direction other than the direction in which the modified message was received. can be sent to

According to embodiments, at operation 1513 , the SP-WTRU may receive a DSM command message, track the R-L2 IDb and RID, and respond with a DSM complete message. According to embodiments, the RID may be specified in a DSM complete message that may be sent to the R-WTRU. According to embodiments, in operation 1514 , the R-WTRU may receive the DSM command message and may find a corresponding entry in its mapping table (eg, corresponding to the destination field R-L2 IDb). have. According to embodiments, from this corresponding entry, the R-WTRU may obtain the associated SU-L2 ID2 and direction, if available. According to embodiments, the R-WTRU (eg, then) designates SU-L2 ID2 as destination (eg address/identifier) and its R-L2 ID1 as source (eg address/identifier) You can modify the message to specify it as an identifier). According to embodiments, at operation 1515 , the R-WTRU (eg, subsequently) sends the DSM toward SU-WTRU2, ie, in any of the direction of SU-WTRU2 or other than the received direction, according to embodiments. Command messages can be forwarded.

According to embodiments, at operation 1516 SU-WTRU2 may (eg, subsequently) complete unicast link establishment, eg, by sending a DCA message towards the R-WTRU. . According to embodiments, the RID may be specified in the DCA message (eg, included in the DCA message). According to embodiments, at operation 1517 the R-WTRU may receive the message and (eg, again) perform a lookup in its mapping table to find an entry corresponding to the destination field. have. According to embodiments, when an entry is found, the R-WTRU, eg, based on the mapping entry (eg, accordingly, as specified/discovered therein, etc.) in the source field of the message. or by setting any of the adaptation layer fields to R-L2 IDb and setting the destination field to SP-L2 ID1 based on the mapping entry. According to embodiments, at operation 1518 the R-WTRU is directed towards the SP-WTRU, e.g., in any of a direction other than a direction associated with this L2 ID or a direction in which a modified message may be received; A modified message can be sent. According to embodiments, at operation 1519 , a unicast link may be established between the SP-WTRU and the SU-WTRU2 via the R-WTRU. According to embodiments, the link is protected, for example, such that a security context is created between the WTRUs. According to embodiments, encrypted and/or integrity protected messages (eg, data or PC5-S messages) may be exchanged between the SP-WTRU and the SU-WTRU2. According to embodiments, the R-WTRU may not be involved in this security association, thus, for example, to read and/or modify the protected part of the message (eg, excluding the source/destination fields). can't

16 is a diagram illustrating discovery and unicast link establishment, according to embodiments.

Referring to FIG. 16 , the SU-WTRU may trigger unicast link establishment in response to discovery, for example. According to embodiments, the SP-WTRU may broadcast a (eg, supported) service in a unicast link establishment request message (eg, a DCR message or a discovery message). Furthermore, according to embodiments, a SU-WTRU interested in a service responds to a broadcast DCR or discovery message by triggering a unicast link establishment with the SP-WTRU (eg, by sending a DCR message). do. According to embodiments, the initiation of a security context establishment (eg, a DSM command message) and transmission of a unicast link accept message (eg, a DCA message) may be performed by the SP-WTRU.

Referring to FIG. 16 , according to embodiments, discovery and unicast link/communication setup may be similar (eg, identical to) as shown in FIG. 15 , discussed in connection with the operations shown in FIG. 16 . may include any of the following operations and modifications. According to embodiments, at operation 1607 , the SU-WTRU may transmit a DCR message, eg, in response to a received broadcast DCR or discovery message. In such a case, according to embodiments, the SU-WTRU may transmit a DCR message with a broadcast R-L2 ID. According to embodiments, for example, in a manner similar to that which may be performed when a DSM command message is received (eg, operation 1507 of FIG. 15 ), the R-WTRU examines its mapping table to , searches for the specified R-L2 ID and adds the received SU-L2 ID to the table entry. According to embodiments, in operation 1609 , the SP-WTRU may receive a DCR message, and in operation 1610 , the SP-WTRU may receive a DCR message. It can respond by sending a DSM command message. According to embodiments, in operation 1613 , the SU-WTRU transmits (eg, again) a DSM complete message, and the SP-WTRU transmits a DCA message by sending (eg, operation 1616) a DCA message. in) unicast link setup can be completed. According to embodiments, the R-WTRU selects the source field and destination field and possibly the adaptation layer field in operations 1609 , 1612 , 1615 , and 1617 , eg, based on information stored in its mapping table. By substituting appropriate values, messages may be forwarded (eg, just) between the SP-WTRU and the SU-WTRU.

Multiple SU-WTRUs establishing a unicast link with the SP-WTRU

17 is a diagram illustrating establishment of a second unicast link according to embodiments;

Referring to FIG. 17 , a second SU-WTRU may be interested in a service broadcast by an SP-WTRU. According to embodiments, the R-WTRU may create a new mapping in its table and give it a new R-L2 ID, eg, to forward messages from the third SU-WTRU3 to the SP-WTRU. can be assigned According to embodiments, at operation 1701 , the SP-WTRU provides a service (eg, any any number of supported services). According to embodiments, the broadcast DCR or discovery message may include any of SP-L2 ID1 as source, broadcast L2 ID as destination, and other parameters related to any of the provided applications and services.

According to embodiments, at operation 1702, the R-WTRU may receive the broadcast message and verify that the R-WTRU is configured to relay any of the application or service advertised by the message. have. According to embodiments, if any of the application or service matches (eg, when the R-WTRU is configured to relay any of the application or service), the R-WTRU starts forwarding the message. can According to embodiments, the R-WTRU may, for example, have an R-L2 ID (eg, SP-L2 ID1) to be used as a replacement for the SP-L2 ID (eg, SP-L2 ID1) when forwarding messages from the SP-WTRU. , R-L2 IDa) can be assigned to itself. According to embodiments, these (eg, two) IDs may be stored in a local mapping table. According to embodiments, the R-WTRU may override the source field with its R-L2 IDa and may add the RID. According to embodiments, the R-WTRU may establish a management link with the SP-WTRU, for example if such a link does not already exist (eg, as discussed above).

According to embodiments, at operation 1703 , other messages may be exchanged (eg, as illustrated in FIG. 15 ) and unicast between the SP-WTRU and SU-WTRU2, via the R-WTRU. A link may be established. According to embodiments, the SP-WTRU and the R-WTRU may interact together, eg, using the SP-L2 ID1 and R-L2 IDb, respectively. According to embodiments, SU-WTRU2 and R-WTRU may interact together, eg, using SU-L2 ID2 and R-L2 IDa, respectively. According to embodiments, the R-WTRU may maintain a mapping table, eg, to replace SP-L2 ID1 with R-L2 IDa and SU-L2 ID2 with R-L2 IDb. According to embodiments, in operation 1704 , SU-WTRU3 may (eg, also) be interested in a service provided by an SP-WTRU (eg, via R-WTRU) and may (eg, service), the SU-WTRU3 may send any of a DCR or DSM command message to the R-WTRU (eg, to R-L2 IDa) using SU-L2 ID3. According to embodiments, any of the DCR and DSM command messages may be transmitted as described herein.

According to embodiments, at operation 1705 , the R-WTRU may look up (eg, search, read, examine, etc.) the R-L2 IDa in its mapping table. According to embodiments, if an entry is found but the entry is used by S-WTRU2 (eg, indicating SU-L2 ID2), the R-WTRU may create a new entry in the mapping table. According to embodiments, any of R-L2 IDa and SU-L2 ID3 may be stored in the mapping table. According to embodiments, the R-WTRU may know, for example, from the first entry it finds with SU-WTRU2, that the SP-WTRU is identified with the SP-L2 ID1. According to embodiments, it may also be stored in a new entry. According to embodiments, the R-WTRU may (eg, also) be stored in a mapping entry and used as a replacement for the SU-L2 ID3, eg, when forwarding messages towards the SP-WTRU3. , a new L2 ID, such as R-L2 IDc, may be assigned to itself. According to embodiments, in operation 1706, messages may be exchanged between the R-WTRU and the SP-WTRU using R-L2 IDc and SP-L2 ID1, respectively.

According to embodiments, messages may be exchanged depending on the method used, as highlighted in act 1704, eg, Announce, Discovery Request, Discovery Response, Authorization Request, Authorization Response, DSM Command, DSM Complete , DCR, and DCA. According to embodiments, in operation 1707 , messages may be exchanged between the R-WTRU and SU-WTRU3 using R-L2 IDa and SU-L2 ID3 respectively. According to embodiments, messages may be exchanged in a manner similar to that noted with respect to operation 1706 . According to embodiments, at operation 1708, a second unicast link may be established via the R-WTRU, from the SP-WTRU side, eg, this time with SU-WTRU3. According to embodiments, the SP-WTRU and the R-WTRU may interact together using any of the SP-L2 ID1 and R-L2 IDc. According to embodiments, SU-WTRU2 and R-WTRU may interact together using SU-L2 ID3 and R-L2 IDa.

Link Management

According to embodiments, link management may be supported (eg, needs to be supported, should be supported, etc.) when an R-WTRU is used between two peer WTRUs. According to embodiments, link management may be any of (eg, its functionalities, functions, operation) keepalive, link identifier update, link release, link modification, and new services, new QoS, etc. , features, etc.). According to embodiments, link management is performed between (eg, two) ends (eg, endpoints, endpoints, etc.) of a unicast link, eg, an SP-WTRU and a SU-WTRU. between (eg, needs to be performed). According to embodiments, a unicast link security association may be (eg, only) between an SP-WTRU and a SU-WTRU, in which case the L2 IDs used to transmit/receive messages are R- It is between the WTRU and the SP-WTRU/SU-WTRU. According to embodiments, when updating the L2 ID in the SP-UE, for example as in the case above, the R-WTRU may be notified of the updated L2 IDs (eg need to be notified). , should be notified, etc.).

According to embodiments, when using a unicast link going over the R-WTRU (eg, using the transparent R-WTRU method as discussed above), the R-WTRU can be encrypted because messages can be encrypted. may not know (eg, do not know) which messages are exchanged (eg, link identifier update) between (eg, two) WTRUs; Peer WTRUs may (eg, only) decrypt the message. According to embodiments, the R-WTRU may access the unprotected portion (eg, only the unprotected portion) of the message, such as, for example, any of the source L2 IDs and the destination L2 IDs. can However, according to embodiments, the SP-WTRU and SU-WTRU may not know (eg, do not know) the L2 ID of their peer WTRU, in which case such WTRUs may not know the L2 ID of the R-WTRU. can be used to send messages.

According to embodiments, between a WTRU (eg, SP-WTRU and/or SU-WTRU) and an R-WTRU (eg, management) to enable management of links going through the R-WTRU A unicast link may be established. According to embodiments, this unicast link may be a management link used to manage other links, eg, links that go through the R-WTRU and are associated with the same RID as the management link. According to embodiments, the management link may be protected (eg, integrity, replay, and confidentiality protected) between the SP-WTRU and the R-WTRU. According to embodiments, existing messages for any of link identifier update, link modification, and link release may, for example, notify the R-WTRU about any changes to a relayed unicast link. , can be updated. According to embodiments, a management link may be established between the SP-WTRU and the R-WTRU and between the R-WTRU and the SU-WTRU, eg, for authorization purposes. That is, according to embodiments, when establishing a management link, an authorization procedure that enables the SP-WTRU and the R-WTRU to authorize each other is executed, and such authorization procedure (eg, the same authorization procedure) is Applies to the management link between R-WTRUs and SU-WTRUs. According to embodiments, the relayed unicast link (eg, the link between the SP-WTRU and the SU-WTRU) is maintained as discussed above (eg, as defined). That is, the relayed unicast link may be between an R-WTRU and (eg, two) peer WTRUs that forward messages (eg, just) without engaging in any of the encryption or decryption etc. have.

According to embodiments, there may be at least two ways to support link management, including any of the following: 1) using a single management link to manage the links between the SP-WTRU and SU-WTRUs to do; and 2) using multiple management links, eg, for all WTRUs (eg, all SP-WTRUs and SU-WTRUs). According to embodiments, the management links may be released, for example, when a procedure that requires the management links has been completed. According to embodiments, management links may be maintained. According to embodiments, if the management links are maintained, the L2 IDs of the management links may be updated (eg, need to be updated) periodically, etc., so that the management links may be considered any other link. It can be (eg, just like any other link). According to embodiments, it is discussed herein how a management link may be used based on these two methods, using, for example, a link identifier update procedure as an example.

According to embodiments, for example, no management link is established between the R-WTRU and the SU-WTRU(s), and there is a single An administrative link may be established. According to embodiments, in such a case, the SU-WTRU(s) may communicate with the SP-WTRU for link management, which, via the management link, communicates link information to the R-WTRU and R - communicate information received from the WTRU, back to the SU-WTRU; According to embodiments, any number (e.g., multiple , there may be multiple) management links. According to embodiments, in such a case, the R-WTRU has a SU and a first management link with the SP-WTRU (eg, per SU-L2 ID), eg, as stored in its local mapping table. - may have a second management link with the WTRU.

According to embodiments, the L2 link identifier may be updated, for example, via a management link. According to embodiments, the SP-WTRU and SU-WTRU may have an established unicast link, and their identifiers (eg, L2 ID, security information, etc.) may change periodically for privacy reasons (eg, For example, it must be changed, needs to be changed, must be changed, etc.). According to embodiments, the procedure for supporting L2 ID update has been described above. According to embodiments, other identifiers (eg, application layer ID, IP address/prefix, etc.) may (eg, also) change during such procedure. According to embodiments, when an R-WTRU engages between two WTRUs and uses its L2 IDs for relay purposes, the R-WTRU may, for example, with any of a SU-WTRU and an SP-WTRU In the same way, you can update your own L2 IDs (eg must update, must update, need to update, etc.). That is, according to embodiments, the R-WTRU may (eg, should also change) periodically the L2 IDs it is using and associated with, for example, the unicast link. According to embodiments, if any of the peer WTRUs change their L2 ID (eg, upon change, whenever it changes), the R-WTRU periodically changes the L2 IDs (eg, update) can be done.

According to embodiments, all WTRUs participating in a unicast link are assigned their identifiers (eg, L2 IDs) to ensure that, for example, a malicious WTRU cannot associate old L2 IDs with new L2 IDs. , security information), and (eg, optionally) application layer ID and IP address/prefix) can, for example, be changed simultaneously (eg, must change, will change, need to change, etc.) ). According to embodiments, if the R-WTRU replaces its L2 IDs when forwarding messages, the R-WTRU may also change its L2 IDs (eg, should change, should change) etc). In such a case, the R-WTRU may not (eg, need not change) other identifiers during such a procedure, eg, because the other identifiers are known only to the two peer WTRUs. For example, if security is established end-to-end (eg, between two peer WTRUs), the R-WTRU may not update (eg, need to) update any security information. none).

According to embodiments, an administrative link may be used to perform a link identifier update procedure, as discussed herein. According to embodiments, existing link identifier update messages include 1) other link information; 2) associated current L2 IDs; and 3) any of the associated new L2 IDs. Furthermore, according to embodiments, information regarding multiple links may be specified. According to embodiments, as discussed herein, two solutions (eg, with respect to management links) are proposed: 1) a single management link for the R-WTRU and 2) for the R-WTRU Multiple admin links. According to embodiments, the link identifier update procedure (eg only, only, etc.) allows other WTRUs (eg, any of R-WTRU and SU-WTRU) to change their L2 IDs without having to change their L2 IDs. WTRU (eg, SP-WTRU). According to embodiments, in such a case, any of the solutions described above using a single management link or multiple management links may be used.

According to embodiments, there may be a single management link. According to embodiments, for example, as discussed above, an SP-WTRU may have a management link established with the R-WTRU for management of links relayed by the (eg, specific) R-WTRU. . For example, an SP-WTRU may have broadcast a particular service it supports (eg, via a DCR message using SP-L2 IDx), and multiple SU-WTRUs interested in the service may: Through the R-WTRU, you may have established unicast links with the SP-WTRU. In such case, the unicast links may be associated with the SP-L2 IDx, and the SP-WTRU updates the R-WTRU with, for example, its peer WTRUs' L2 ID updates in addition to its SP-L2 ID update. can be responsible for According to embodiments, SU-WTRUs may share their L2-IDs (eg, current value and updated value) with the SP-WTRU, such that, for example, the SP-WTRU can to notify the R-WTRU about the According to embodiments, the SP-WTRU may transmit the updated R-L2 ID back to the appropriate SU-WTRU.

18 is a diagram illustrating an SP-WTRU initiated link identifier update procedure for all WTRUs - single management link, according to embodiments;

According to embodiments, at operation 1801 , a unicast link may be established between peer WTRUs via the R-WTRU. According to embodiments, the SP-WTRU has its L2 ID (eg, SP-L2 ID1), relay L2 ID (eg, R-L2 IDb), and this link is the R-WTRU (eg, , RIND, or RID). According to embodiments, the SU-WTRU may also have its L2 ID (eg SU-L2 ID2), a relay L2 ID (eg R-L2 IDa), and this link to the R-WTRU (eg, For example, one can maintain a link table with any of the indications relayed by RID, RIND). According to embodiments, the R-WTRU has an SP L2 ID (eg, SP-L2 IDa) versus the R-WTRU's associated relay L2 ID (eg, R-L2 IDa) and a SU-L2 ID (eg, R-L2 ID). For example, it may maintain a mapping table containing any of SU-L2 ID2) versus its associated relay L2 ID (eg, R-L2 IDb).

According to embodiments, in operation 1802, the SP-WTRU may associate itself with a unicast link established with the SU-WTRU, eg, via an R-WTRU (eg, R-L2 IDb). A trigger (eg, timer expiration) to update the SP-L2 ID1 of may be received. In accordance with embodiments, in operation 1803 (eg, which may be considered an optional operation/procedure), the SP-WTRU, eg, if such a link has not already been established, eg, , for link management purposes, may establish a protected unicast link with the R-WTRU. According to embodiments, for this management link, the SP-WTRU may assign itself a new L2 ID (eg, SP-L2 ID3), and a known relay L2 ID (eg, R-L2 IDb) ) can be used. According to embodiments, a management link may be established with an R-WTRU that handles the link that needs to be updated, as identified by the RID.

According to embodiments, at operation 1804 , the SP-WTRU may assign itself a new SP-L2 ID2 to replace the SP-L2 ID1. According to embodiments, the SP-WTRU may, for example, inform the R-WTRU about the current and new L2 ID of the SP-WTRU and an associated unicast link (eg, a relayed link) with the SU-WTRU. To request information about the R-WTRU A link identifier update request may be sent to the R-WTRU. According to embodiments, an indication for another link may be designated, for example, to indicate that the message contains information referring to a link other than the link that is sending the message. According to embodiments, the SP-WTRU may specify a current L2 ID that identifies another link (eg, SP-L2 ID1 and R-L2 IDb) and a new SP-L2 ID2. According to embodiments, a GetPeer indication is displayed to indicate that information from the SU-WTRU (eg, R-L2 ID and S-L2 ID associated with this link) should be returned so that it can be transmitted to the SU-WTRU. can be specified. According to embodiments, the SP-WTRU does not have this information because it is going through the R-WTRU.

According to embodiments, at operation 1805 the R-WTRU may receive the request and may look up an entry in its mapping table. According to embodiments, the R-WTRU may obtain information related to other parts of the link, such as, for example, a SU-L2 ID and an associated R-L2 ID. According to embodiments, the R-WTRU (eg, then) has two new L2 IDs: an R-L2 IDd associated with a link with the SP-WTRU (eg, another link) and a link with the SU-WTRU; The associated R-L2 IDc may be assigned to itself. According to embodiments, the R-WTRU sends a new R-L2 IDd followed by another link indication and, optionally, a new SP-L2 ID acknowledging it, and its new R-L2 IDc followed by a GetPeer indication. It may respond to the SP-WTRU by sending a link identifier update response message with According to embodiments, in operation 1806, the SP-WTRU may transmit new R-L2 IDc information to the SU-WTRU using a link identifier update request. According to embodiments, other identifiers that may be updated may be transmitted using a link identifier update request. For example, security information (eg MSB of K _NRP-sess ID, and (optionally) application layer ID and IP address/prefix).

According to embodiments, at operation 1807 , the SU-WTRU may allocate to itself a new SU-L2 ID3 and store the new R-L2 IDc (and/or other updated identifiers) it receives. and may transmit a link identifier update response message including its new SU-L2 ID3 to the SP-UE. According to embodiments, the SU-WTRU may include (eg, also) information received on the request message, eg, to ACK the request message. According to embodiments, other identifiers that may be updated may be sent using such a message (eg, also). For example, security information (eg, LSB of K _NRP-sess ID, and (optionally) application layer ID and IP address/prefix). According to embodiments, in operation 1808 , the SP-WTRU receiving this message may store the received updated identifiers and may update the R-WTRU with the new SU-L2 ID3. According to embodiments, an update may be identified by using the "GetPeer" indication. According to embodiments, the SP-WTRU may (eg, also) include a new R-L2 IDd received on the old response message to ACK the previous response message (see, eg, act 1805 ). ). According to embodiments (eg, additionally), for example, to indicate the actual time when to start using new L2 IDs from the SP-WTRU, R-WTRU, and SU-WTRU, the effective time ( validity time) can be specified. According to embodiments, such may ensure that all involved WTRUs start using the new L2 IDs at the same time. According to embodiments, at operation 1809 the SP-WTRU may (eg, also) transmit a link identifier update ACK message to the SP-WTRU, eg, providing a valid time.

According to embodiments, another link (eg, a link between an SP-WTRU and a SU-WTRU) may be identified using any of the current SP-L2 ID and R-L2 ID. According to embodiments, once an entry is identified by the R-WTRU, the R-WTRU may return a reference number (eg, link number) to be used on all other related messages. According to embodiments, an alternative solution is that the SP-WTRU first queries its peer SU-WTRU to obtain its new L2 ID and then provides the new SU-L2 ID and the new SP-L2 ID to the R-WTRU. It may be to change the sequence of events to be notified. In such a case, the R-WTRU may (eg, subsequently) provide its new R-L2 IDs (eg, to both sides of the relay). According to embodiments, the SP-WTRU may (eg, subsequently) transmit an associated R-L2 ID to the SU-WTRU.

According to embodiments, the SU-WTRU may initiate a link identifier update procedure for all WTRUs. According to embodiments, if the link identifier update procedure is initiated by the SU-WTRU, it may be similar to the update procedure described above. That is, according to embodiments, the SU-WTRU may send messages to the SP-WTRU forwarding information to the R-WTRU over the management link, which in turn sends the SP-WTRU to the new R-L2 ID from the R-WTRU. It may respond back to the SU-WTRU. According to embodiments, the SU-WTRU may specify the RID in its message for the SP-WTRU to use the management link associated with the corresponding R-WTRU.

According to embodiments, there may be a case where only the L2 ID of the SP-WTRU is changed. According to embodiments, the link identifier update procedure may be initiated by the SP-UE only for its own L2 ID (eg, neither R-WTRU or SU-WTRU need to change its L2 ID at the same time) no). According to embodiments, such may be similar to that described above, with another link indication and current SP-L2 and R-L2 IDs and a new SL-L2 ID added.

According to embodiments, there may be a case where only the L2 ID of the SU-WTRU is changed. According to embodiments, the link identifier update procedure may be initiated by the SU-WTRU only for its own L2 ID (eg, neither the R-WTRU or the SP-WTRU needs to change its L2 ID at the same time) no). According to embodiments, in such a case, the management link may be handled by the SP-WTRU, and thus the SP-WTRU may need to engage in a procedure, as described herein.

According to embodiments, there may be multiple management links. According to embodiments, as with a single management link, the SP-WTRU may have a management link established with the R-WTRU, eg, for management of all links related to a particular SP-L2 ID. In such a case, according to embodiments with multiple management link features (eg, a solution), the SU-WTRU may notify the R-WTRU about the SU-WTRU's new L2 IDs and the R-WTRU's new L2 IDs. It may establish a direct management link with the R-WTRU to know about the L2 IDs as well. According to embodiments, the management links between the SP-WTRU and the R-WTRU and between the SU-WTRU and the R-WTRU may be independent. According to embodiments, every peer WTRU may directly manage links with its own R-WTRU.

According to embodiments, in the case of a multiple management link feature (eg, a solution), for example, a link identifier update request message is received from the SP-WTRU over the management link between the R-WTRU and the SP-WTRU. In some cases (eg, when received, when received, after received, etc.), the R-WTRU may trigger establishment of a management link with the SU-WTRU. Such a link identifier update request message may be applied to (eg, associated with) a particular PC5 unicast link between the SP-WTRU and the SU-WTRU, via the R-WTRU. According to embodiments (eg, not shown in FIG. 18 ), other updated identifiers (eg, not shown in FIG. 18 ) may be updated (eg, such that security information may be updated and application layer ID and IP address/prefix updated) For example, it may also be exchanged between SP-WTRU and SU-WTRU).

19 is a diagram illustrating an SP-WTRU initiated link identifier update procedure - multiple management link for all WTRUs, according to embodiments;

According to embodiments, at operation 1901 , a unicast link may be established between peer WTRUs via the R-WTRU. According to embodiments, the SP-WTRU has its own L2 ID (eg, SP-L2 ID1), relay L2 ID (eg, R-L2 IDb), and this link is an R-WTRU (RID or RIND). to maintain a link table with the indication that it is relayed by any of the According to embodiments, the SU-WTRU also has its L2 ID (eg SU-L2 ID2), a relay L2 ID (eg R-L2 IDa), and this link is relayed by the R-WTRU You can keep a table of links with the indication that it is. According to embodiments, the R-WTRU has an SP L2 ID (eg, SP-L2 ID1) versus its associated relay L2 ID (eg, R-L2 IDa) and a SU-L2 ID (eg, SU-L2 ID2) to its associated relay L2 ID (eg, R-L2 IDb) may maintain a mapping table.

According to embodiments, at operation 1902 , the SP-WTRU may receive a trigger (eg, timer expiration) to update its SP-L2 ID1. According to embodiments, at operation 1903 , optionally, the SP-WTRU may establish a protected unicast link with the R-WTRU for link management purposes, if such a link has not yet been established, where the SP -L2 ID3 and R-L2 IDb are used for the management link.

According to embodiments, in operation 1904, the SP-WTRU may assign itself a new SP-L2 ID2 to replace the SP-L2 ID1, and send, via the management link, a link identifier update request message to the R- The R-WTRU may be notified by sending to the WTRU. According to embodiments, a message may have (eg may use) link management IDs as source and/or destination (eg, SP-L2 ID3 and R-L2 IDb). According to embodiments, the content of the message may include (i) an indication that the information relates to another link (eg, an indicator to another link), (ii) the current L2 ID and new L2 ID of the other link, e.g. For example, it may be modified to include any of the L2 IDs of the unicast link between the SP-WTRU and the SU-WTRU. According to embodiments, the message may be modified to include (eg, also) an associated R-L2 ID (eg, R-L2 IDb). According to embodiments, these L2 IDs are new fields in the link identifier update request message.

According to embodiments, in operation 1905 , the R-WTRU triggers, for example, an update of an R-L2 IDb as well as an update of an associated L2 ID for a relay (eg, R-L2 IDa). , a link identifier update request message may be received. According to embodiments, in operation 1906, optionally, the R-WTRU establishes a management link with a peer WTRU (eg, a SU-WTRU) so that the SU-WTRU can update its L2 ID (eg, SU-WTRU). For example, if such a link has not already been established). According to embodiments, in operation 1907 , the R-WTRU may send a link identifier update request to the SU-WTRU, the request indicating that the update is for another link, the R-WTRU's current R-L2 IDa ; and a new R-L2 IDc of the R-WTRU (eg, to replace the current R-L2 IDc). According to embodiments, the current SU-L2 ID2 may also be designated. According to embodiments, at operation 1908 the SU-WTRU may receive the identifier update request and may search its link table for a matching entry of another indicated link. According to embodiments, the SU-WTRU may store a new R-L2 IDc, allocate a new SU-L2 ID3 to it, and send a link identifier update response message containing its new SU-L2 ID3 It can respond to the R-WTRU by According to embodiments, the new R-L2 IDc received from the R-WTRU may be added to this message for acknowledgment purposes.

According to embodiments, in operation 1909, the R-WTRU may receive a response from the SU-WTRU, it may look for an entry in its mapping table corresponding to the other link identified, and a new SU-L2 ID3 can be saved. According to embodiments, the R-WTRU may (eg, subsequently) assign itself a new R-L2 IDd to replace the R-L2 IDb, and a link identifier comprising its new R-L2 IDd. It may respond to the SP-WTRU by sending an update response. According to embodiments, the new SP-L2 ID2 received from the SP-UE (at operation 1904) may be added to this message, and an "other link" indication may also be included. According to embodiments, at operation 1910 the SP-WTRU may respond to the R-WTRU with a Link Identifier Update Ack message, eg, to acknowledge receipt of a new relay identifier and complete the update procedure. have. According to embodiments, an effective time may be included in the message (eg, may be specified on the message) to enforce the use of new L2 IDs for all involved WTRUs at the same time. According to embodiments, in the case of a validity timer, the SP-WTRU may start the timer to expire at a time corresponding to the validity timer.

According to embodiments, at operation 1911 the R-WTRU may receive the message, find a matching entry in its mapping table, and send a Link Identifier Update Ack message to the SU-WTRU and , may designate a new SU-L2 ID3 for acknowledgment. According to embodiments, if a valid time is specified on the ACK message received from the SP-WTRU, this time is added to the ACK message sent to the SU-WTRU. According to embodiments, the R-WTRU and SU-WTRU may also start their respective timers accordingly. According to embodiments, from this point on or upon timer expiry, all new L2 IDs may be used in the unicast link between the SP-WTRU and the SU-WTRU, via the R-WTRU.

According to embodiments, the link identifier update procedure may be similar to multiple management link features (eg, as discussed above). Furthermore, according to embodiments, a link identifier update procedure may be executed (eg, directly) between the SP-WTRU and the SU-WTRU, and new L2 IDs that may be exchanged are performed by the SP-WTRU and the SU-WTRU. May be new relay L2 IDs to be used. According to embodiments, in such a case, the SP-WTRU and the SU-WTRU may establish a management link with the R-WTRU, eg, to obtain a new relay L2 ID that may be exchanged with the peer WTRU.

20 is a diagram illustrating an SP-WTRU initiated link identifier update procedure including multiple management links established by peer WTRUs (eg, both) in accordance with embodiments.

According to embodiments, in operation 2001, the SP-WTRU and the SU-WTRU may have a unicast link established via the R-WTRU. According to embodiments, in such a case, end-to-end security may be established, and the R-WTRU may be configured to have two peer WTRUs (eg, SP - forward messages between WTRUs and SU-WTRUs. According to embodiments, the SP-WTRU and R-WTRU may use the SP-WTRU L2 ID1 and R-L2 IDb respectively, and the SU-WTRU and the R-WTRU may use the SU-WTRU L2 ID2 and R-L2 IDa respectively. Can be used. According to embodiments, in operation 2002, the SP-WTRU may trigger a link identifier update procedure. According to embodiments, in operation 2003, the SP-WTRU may use existing relayed unicast links (eg, if no such management link exists (eg, already)) , may establish a protected unicast link with the R-WTRU for management of unicast links established through the R-WTRU).

According to embodiments, in operation 2004, the SP-WTRU may generate a new L2 ID, eg, via a link identifier update request message (eg, using a link identifier update request message; included in the link identifier update request message, etc.), and send the L2 ID to the R-WTRU. According to embodiments, such a message may be sent over a management link, any of a relay management indication (eg, another link indicator), a source L2 ID identifying the link to be updated, and a destination L2 ID , and a new L2 ID (eg, SP-L2 ID2) of the SP-WTRU that may be used for the identified link to be updated. According to embodiments, other identifiers (eg, security information, application layer ID, IP address/prefix, etc.) may not be included in the link identifier update request to the R-WTRU because such other identifiers may (eg, only) be meaningful to (eg, only associated with a peer WTRU). According to embodiments, in operation 2005 , the R-WTRU sets a current relay L2 ID (eg, R-WTRU) known to the SU-WTRU (eg, used by the SU-WTRU). To replace L2 IDa), a link identifier update response message including its new relay L2 ID (eg, R-L2 IDc) may be transmitted (eg, responded with a link identifier update response message). .

According to embodiments, in operation 2006, the SP-WTRU receives one of the new R-L2 IDc and other updated identifiers (eg, security information, optionally an application layer ID, optionally an IP address/prefix, etc.). Link identifier update request message including any), via the R-WTRU, to the SU-WTRU. According to embodiments, the link identifier update request message includes a new L2 ID parameter that includes a new relay L2 ID that may be used by the SU-WTRU (eg, instead of a new L2 ID of the SP-WTRU). can be used as discussed above. According to embodiments, in operation 2007, the SU-WTRU may recognize (eg, accept, store/record, track, discern, acknowledge, understand, monitor, etc.) updated parameters, the SU-WTRU may may establish a protected unicast link with the R-WTRU for relayed (eg, “another”) unicast link management, eg, when such a management link does not exist.

According to embodiments, at operation 2008 , the SU-WTRU may transmit a link identifier update request message to the R-WTRU over the management link. According to embodiments, such a message may include other link indications, e.g. to update the identified unicast link, source/destination L2 IDs identifying the link that may be updated, and the SU-WTRU's new L2 ID (SU-WTRU L2 ID3). According to embodiments, in operation 2009 , the R-WTRU performs its new R-WTRU L2 ID (R), eg, to replace the relay L2 ID (R-L2 IDb) known to the SP-UE. It can respond with a link identifier update response message including -L2 IDd). According to embodiments, in operation 2010 , the SU-WTRU may send, via the R-WTRU, a link identifier update response message to the SP-WTRU, which message includes a new R-L2 IDd and other updated identifiers such as, for example, security information and (eg, optionally) any of an application layer ID and IP address/prefix. According to embodiments, the SU-WTRU may include (eg, also) parameters received via the link identifier update request message.

According to embodiments, in operation 2011, the SP-WTRU may track (eg, accept, store/record, recognize, discern, acknowledge, understand, monitor, etc.) updated parameters, update link identifier A Link Identifier Update Ack message including the parameters received via the response message may be sent to the SU-WTRU. According to embodiments, in operation 2012, the SP-WTRU may transmit, to the R-WTRU, a Link Identifier Update Ack message including the new R-L2 ID and other link indication sent to the SU-WTRU. . According to embodiments, in operation 2013, the SU-WTRU may transmit to the R-WTRU a Link Identifier Update Ack message including the new R-L2 ID and other link indication sent to the SP-WTRU. . According to embodiments, in operation 2014, (eg, all) WTRUs (eg, any of SP-WTRU, SU-WTRU, and R-WTRU) receive new L2 IDs and other You can start using the updated identifiers.

According to embodiments, an L2 link release procedure may be performed through a management link. According to embodiments, in the case of a relayed link, a link release procedure may be performed between two peer WTRUs, eg, in a similar (eg, identical) manner to that for a direct unicast link. . According to embodiments, a Disconnect Request message may be sent to the peer WTRU, eg, in response, the peer WTRU may send a Disconnect Response message. According to embodiments, any of a connection release request message and a connection release response message may be transmitted via an R-WTRU, such messages may be sent, for example, to establish different unicast links between the same peer WTRUs. It may include a new K _NRP ID, which may be used in subsequent DCR messages for

According to embodiments, exchanging a new K _NRP ID upon link release may avoid (eg, prevent) linkability between a subsequent unicast link and a current unicast link between the same peer WTRUs. have. According to embodiments, the new K _NRP ID may be preserved (eg, saved, recorded, stored, etc.) on peer WTRUs. According to embodiments, the R-WTRU may not need to know a new K _NRP ID (e.g., because the R-WTRU may not be involved in end-to-end authentication, authorization and security setup). , do not need to know). According to embodiments, when an end-to-end link is released (eg, upon release, after release, etc.), a disconnection request message is sent to the R-WTRU, eg, via the management link. can be transmitted.

According to embodiments, the connection release request message may include any of L2 IDs and other link indications identifying the released link (eg, in a manner similar to link identifier update messages). According to embodiments, when the connection release request message includes such information, the R-WTRU updates its mapping table (eg, release, modify, clean-up, delete part of it, etc.) )can do. For example, the R-WTRU may release two R-WTRU L2 IDs allocated for forwarding of this link; and deleting the entry with the SP-WTRU L2 ID and the SU-WTRU L2 ID. According to embodiments, a disconnection request message may be sent by both peer WTRUs, for example when multiple management links are used. According to embodiments, the R-WTRU may clean up its mapping table and respond to the WTRU with a disconnect response message including any of the L2 IDs identifying the released link, and any other link indications. have.

According to embodiments, DCA may be direct communication acceptance; The DCR may be a direct communication request; The RID may be an R-WTRU identifier; The R-WTRU may be a WTRU to WTRU relay; SMC may be a secure mode command; The SP-WTRU may be a service provider WTRU; The SU-WTRU may be a service-using WTRU.

Service Oriented Discovery and Communication via Relay WTRU (R-WTRU)

As discussed above, the case of (eg, conventional) WTRU-to-WTRU relay using IP-based mechanisms providing support for WTRU-oriented discovery and unicast (eg, IP, L2, etc.) communication only there may be On the other hand, according to embodiments, it may be referred to as an R-WTRU (eg, as discussed above) and is used for any of service oriented discovery and groupcast (eg, IP, L2, etc.) communication. There may be a case of (eg, non-conventional, new) WTRU-to-WTRU relay that may provide support for That is, according to embodiments, the R-WTRU may support more (eg, all possible) types of discovery and communication. According to embodiments, IP-based service-oriented discovery and groupcast communication uses the R-WTRU, for example, acting as an “opaque” IP-based relay between the SP-WTRU and any number of SU-WTRUs. may be performed (eg, may be enabled).

According to embodiments, the SU-WTRU may be configured by the SP-WTRU using (eg, via) an IP-based WTRU to WTRU relay, such as an R-WTRU, for example. ProSe service can be discovered. According to embodiments, for example, upon or after a PC5 connection with the R-WTRU is established (eg, under the condition that it is), the SP-WTRU may to WTRU relay) and provide a list of ProSe service IDs. According to embodiments, the R-WTRU determines (eg, knows, signaled, etc.) and/or stores an association between the list of ProSe service IDs and the SP-WTRU IDs. can do

According to embodiments, when a SU-WTRU requests a (eg, available) ProSe service from an R-WTRU, the R-WTRU may include any number of WTRU IDs associated with the requested ProSe service and ( provide (eg, transmit, respond to, etc.) any of the ProSe Service IDs (eg, corresponding, associated, etc.). According to embodiments (eg, upon receiving any of the SP-WTRU IDs and ProSe service IDs), the SP-WTRU may use, for example, a DCR message, an authentication message, a security establishment procedure ( For example, in the meantime) may be used (eg, via) to provide the list of ProSe service IDs and the SP-WTRU IDs to the R-WTRU.

According to embodiments, the R-WTRU identifies an SP-WTRU ID associated with any number of requested ProSe service and ProSe service IDs, eg, using (eg, via) a DNS response message. It may transmit (eg, respond with it to the SP-WTRU) (eg, to the SP-WTRU) any of these. According to embodiments, the SP-WTRU ID may refer to any of an IP address, a Layer 2 (L2) ID, an application layer ID, and the like. According to embodiments, a ProSe service (eg, requested by the SU-WTRU) may be mapped to any number of ProSe service IDs, eg, by the R-WTRU. For example, the requested ProSe service may be "Restaurant", which may be mapped to "Restaurant_A", "Restaurant_B", and the like. According to embodiments, (eg, prior to responding to a ProSe service request received from a SU-WTRU), eg, any number of SU-WTRU IDs and any of the allowed ProSe service IDs. Based on authorization parameters (eg, any of (pre)configured or received from the (core) network), which may include can verify whether it is authorized to discover (eg, being authorized).

According to embodiments, the SP-WTRU may provide any of the flags and a list of service IDs indicating any of restricted service discovery and restricted access. According to embodiments, (eg, such) flags may be stored by the R-WTRU along with (eg, in addition to) mapping information, as discussed above. According to embodiments, when querying for service information, e.g., by the SU-WTRU sending a request for service associated with a restriction flag to the R-WTRU, the R-WTRU may, e.g., ( For example, a request may be sent to the SP-WTRU by providing the SU-WTRU information (eg, the request to the SP-WTRU includes user information).

According to embodiments, the R-WTRU may provide service information (eg, SP-WTRU IP address) to the SU-WTRU. According to embodiments, such service information may be provided under the condition that the SP-WTRU authorizes the R-WTRU to provide such information, eg, based on information provided by the SU-WTRU. According to embodiments, the service may be limited based on application requirements (eg, only certain users, limited number of concurrent users to a maximum, etc.). On the other hand, according to embodiments, the R-WTRU may request authorization to a ProSe function (eg, as described herein), eg, based on the presence of a service restriction flag. According to embodiments, the service restriction flag may indicate whether the R-WTRU may request authorization (eg, for service) to any of the ProSe function and the SP-WTRU. According to embodiments, for example, when the R-WTRU is out of network coverage (eg, the R-WTRU cannot reach or communicate with the ProSe function), the R-WTRU: (1) may request authorization from the SP-WTRU (eg, as a fallback mechanism); (2) Deny access to service information, eg, to the SU-WTRU, (eg, until the R-WTRU returns to network coverage).

According to embodiments, the R-WTRU is configured to: (1) receive a list of ProSe service IDs from the SP-WTRU; (2) storing the association between the list of ProSe service IDs and the SP-WTRU IDs; and (3) after receiving a ProSe service request, e.g., from a SU-WTRU, responding (e.g., sending it to do) (eg, can do, can perform, can have behaviors including these, etc.). According to embodiments, the SP-WTRU may provide a list of ProSe service IDs to the R-WTRU (eg, may perform providing, may perform providing, may perform providing) , can have behaviors including providing, etc.).

According to embodiments, the SU-WTRU (1) sends a ProSe service request (eg, a message containing a ProSe service request, a signal for a ProSe service request, etc.) to the R-WTRU - the ProSe service request is includes (eg, identifies) the requested ProSe service; and (2) receiving any number of SP-WTRU IDs and associated ProSe service IDs (eg, may, may perform, including these) behaviors, etc.).

According to embodiments, the SP-WTRU may provide (eg, transmit, transmit, register, etc.) any number of (eg, its own) ProSe service IDs to a ProSe function. According to embodiments, for example, when the SP-WTRU establishes a PC5 connection with the R-WTRU (eg, under the condition that a PC5 connection with the R-WTRU is established), the R-WTRU A ProSe service query message including an ID may be transmitted as a ProSe function. According to embodiments, the ProSe function may send (eg, respond to the R-WTRU with the list) a list of ProSe service IDs associated with the SP-WTRU to the R-WTRU. According to embodiments, the R-WTRU may store the association between the list of ProSe service IDs and the SP-WTRU IDs. According to embodiments, when a SU-WTRU requests an available ProSe service from an R-WTRU, the R-WTRU may select any number of WTRU IDs and ProSe service IDs associated with the requested ProSe service. can respond with

According to embodiments, the R-WTRU is configured to: (1) receive an SP-WTRU ID from the SP-WTRU; (2) sending a ProSe service query message to the ProSe function, eg, including the SP-WTRU ID; (3) receiving a list of ProSe service IDs associated with the SP-WTRU from the ProSe function; (4) storing an association between a list of ProSe service IDs and any number of SP-WTRU IDs; and (5), for example, after receiving a ProSe service request from a SU-WTRU, responding with any number of SP-WTRU IDs and associated ProSe service IDs. are (eg, can do, can do, can act to do, etc.).

According to embodiments, the SP-WTRU is configured to: (1) provide a list of ProSe service IDs to the ProSe function; and (2) sending the SP-WTRU ID to the R-WTRU (eg, may, may perform, may have behaviors including these, etc.). According to embodiments, the SU-WTRU may (1) send a ProSe service request to the R-WTRU, eg, indicating the requested ProSe service ID; and (2) receiving any number of SP-WTRU IDs and associated ProSe service IDs (eg, may, may perform, including these) behaviors, etc.).

conclusion

Although features and elements are described above in specific combinations, one of ordinary skill in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware included in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and CDs. -Includes, but is not limited to, optical media such as ROM disks and digital versatile disks (DVDs). The processor, together with software, may be used to implement a radio frequency transceiver for use in a UE, WTRU, terminal, base station, RNC, or any host computer.

Moreover, in the embodiments described above, other devices are mentioned including processing platforms, computing systems, controllers, and a rendezvous point/server including processors and a constraint server. Such devices may include at least one central processing unit (“CPU”) and memory. According to the practices of one of ordinary skill in the computer programming arts, reference to acts and symbolic representations of acts or instructions may be performed by various CPUs and memories. Such acts and acts or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

A person of ordinary skill in the art will understand that acts and symbolic acts or instructions include manipulation of electrical signals by a CPU. The electrical system causes the resulting conversion or reduction of electrical signals and maintaining the data bits in memory locations within the memory system, thereby converting data bits that can reconfigure or otherwise alter the operation of the CPU as well as other processing of the signals. express The memory locations where data bits are maintained are physical locations that have specific electrical, magnetic, optical or organic properties that correspond to or represent data bits. It should be understood that the exemplary embodiments are not limited to the platforms or CPUs mentioned above and that other platforms and CPUs may support the provided methods.

Data bits may also be stored on magnetic disks, optical disks, and any other volatile (eg, random access memory (“RAM”)) or non-volatile (eg, read-only memory (“ROM”) readable by a CPU). ) may be maintained on a computer readable medium including a mass storage system. Computer readable media may include interconnected computer readable media that reside exclusively on a processing system or distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that representative embodiments are not limited to the memories mentioned above and that other platforms and memories may support the described methods.

In an exemplary embodiment, any of the acts, 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.

There is little difference between hardware and software implementations of aspects of the systems. The use of hardware or software is usually (but not always) a design option that represents a cost versus efficiency trade-off, in that the choice between hardware and software may become important in certain contexts. There may be various means (eg, hardware, software, and/or firmware) in which the processes and/or systems and/or other techniques described herein may be practiced, with the preferred means being processes and/or firmware. or depending on the context in which the systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may choose primarily hardware and/or firmware means. Where flexibility is paramount, implementors may choose an implementation that is primarily software. Alternatively, the implementer may choose any combination of hardware, software, and/or firmware.

The foregoing detailed description has described various embodiments of devices and/or processes through the use of block diagrams, flowcharts, and/or examples. To the extent such block diagrams, flowcharts, and/or examples include one or more functionality and/or operation, each function and/or operation within such block diagrams, flowcharts, or examples may be extensive in hardware, software, or software. , firmware, or virtually any combination thereof, individually and/or collectively, will be understood by those skilled in the art. Suitable processors include, for example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated (ASIC) circuits), Application Specific Standard Products (ASSPs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuits (ICs), and/or state machines.

Although features and elements are provided above in specific combinations, one of ordinary skill in the art will understand that each feature or element may be used alone or in any combination with other features and elements. The disclosure should not be limited with respect to the specific embodiments described herein, which are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the present disclosure. No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The disclosure should be limited only by the terms of the appended claims, along with the full scope of equivalents to which those claims qualify. It should be understood that the present disclosure is not limited to specific methods or systems.

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 referred to herein, the terms “user equipment” and its abbreviation “UE” refer to (i) a wireless transmit and/or receive unit (WTRU), as described below; (ii) any of a number of embodiments of a WTRU, as described below; (iii) wireless-capable and/or wired-capable (e.g., tethering capable (eg, tetherable)) device; (iii) a radio-capable and/or wire-capable device configured with less than all of the structures and functions of a WTRU, as described below; or (iv) the like. Details of an example WTRU, which may represent any WTRU described herein.

In certain representative embodiments, various portions of the subject matter described herein may be implemented via an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a digital signal processor (DSP), or other integrated formats. have. However, some aspects of the embodiments disclosed herein may be implemented, in whole or in part, on integrated circuits, as one or more computer programs running on one or more computers (eg, as one or more programs running on one or more computer systems); may equally be implemented as one or more programs running on one or more processors (eg, one or more programs running on one or more microprocessors), as firmware, or almost any combination thereof, designing circuits and/or Alternatively, those skilled in the art will recognize that writing code for software and/or firmware would be well within the capabilities of those skilled in the art in view of this disclosure. In addition, the mechanisms of the subject matter described herein may be distributed as a program product in various forms, with the particular type of signal bearing medium being used in which the illustrative embodiment of the subject matter described herein is actually used to effect the distribution. It will be understood by those skilled in the art that it applies regardless of signal bearing medium. Examples of signal bearing media include recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and the like, and digital and/or analog communication media (eg, fiber optic cables, waveguides, a transmission type medium such as, but not limited to, a wired communication link, a wireless communication link, etc.).

The subject matter described herein illustrates different components that are sometimes included in or connected to different other components. It should be understood that such depicted architectures are merely examples, and that, in fact, many other architectures that achieve the same functionality may be implemented. In a conceptual sense, any arrangement of components to achieve the same function is effectively "associated" such that a desired function can be achieved. Thus, any two components herein that are combined to achieve a particular function, regardless of architecture or intermediate component, may appear "associated" with each other such that the desired function is achieved. Likewise, any two components so associated may also be viewed as “operably connected” or “operably coupled” to each other to achieve a desired function, and any two components that may be so associated achieve the desired function. may also be seen as “operably engageable” with each other to achieve Specific examples of operatively coupleable include physically mateable and/or physically interacting components, and/or wirelessly interactable and/or wirelessly interacting components, and/or including, but not limited to, logically interacting and/or logically interactable components.

With respect to the use of almost all plural and/or singular terms herein, those skilled in the art may interpret the plural from the singular and/or from the singular to the plural as appropriate to the context and/or application. Various singular/plural permutations may be explicitly set forth herein for clarity.

It is understood by those of ordinary skill in the art that, generally, terms used in this specification and in particular in the appended claims (eg, the texts of the appended claims) are generally intended as "open" terms. will be (eg, the term “including” is to be construed as “including but not limited to” and the term “having” is to be interpreted as “having at least at least)", the term "includes" should be construed as "includes but is not limited to," etc.). Where a particular number of introduced claim recitations are intended, it is recognized by those of ordinary skill in the art that such intent will be expressly recited in the claims, and in the absence of such recitation, no such intent exists. It will be further understood. For example, where only one item is intended, the term “single” or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim enumerations. However, the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (eg, “a” and/or “an” are typically “at least one” or (which should be construed to mean "one or more"), the use of such phrases indicates that the incorporation of a claim recitation by the indefinite article "a" or "an" indicates that the introduction of such introductory claim recitation includes any particular claim. is not to be construed as implying a limitation to embodiments including only one such listing. The same is true for the use of definite articles used to introduce claim enumerations. In addition, even if a particular number in an introductory claim recitation is explicitly recited, one of ordinary skill in the art will recognize that such recitation should at least be construed as meaning the recited number (eg, without other modifiers). A bare recitation that is "two enumerations" means at least two recitations or two or more recitations). Moreover, in those instances where a conventional convention similar to "at least one of A, B, and C, etc." is used, in general, such a construction would (e.g., "a system having at least one of A, B, and C" means A only, B only, C only, A and B together, A and C together, B and C together, and/or systems having A, B, and C together, etc.). In those instances where a conventional expression similar to "at least one of A, B, or C, etc." is used, in general, such structure is intended to mean that one of ordinary skill in the art would understand the conventional expression. For example, "a system having at least one of A, B, or C" means A only, B only, C only, A and B together, A and C together, B and C together, and/or A, B , and C together, etc.). Almost all disjunctive words and/or disjunctive phrases that set forth two or more alternative terms, whether in the description, claims, or drawings, refer to one of the terms, any one of the terms. It will be further understood by one of ordinary skill in the art that it should be construed to contemplate possibilities including , or both. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B”. Moreover, as used herein, a list of a plurality of items and/or categories of a plurality of items following the terms "any of" means any of "items and/or categories of items." "thing", "any combination of", "any many of", and/or "any combination of many of", individually or in conjunction with other items and/or categories of other items, are intended to include It is intended Moreover, as used herein, the term “set” or “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “number” is intended to include any number, including zero.

Additionally, where features or aspects of the present disclosure are described in terms of Markush groups, those of ordinary skill in the art will recognize that the present disclosure may also thereby be of any individual member or members of the Markush group. It will be appreciated that descriptions are made in terms of subgroups.

As will be understood by one of ordinary skill in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein include any and all possible subranges and these Also encompasses combinations of subranges of Any recited range can be readily recognized as sufficiently descriptive and enabling that the same range is divisible by at least equal 1/2, 1/3, 1/4, 1/5, 1/10, etc. As a non-limiting example, each of the ranges discussed herein may be readily divided into lower thirds, middle thirds, upper thirds, and the like. As will also be understood by one of ordinary skill in the art, such as “up to”, “at least”, “greater than”, “less than”, etc. All expressions refer to ranges that are inclusive of the recited numbers and which may subsequently be subdivided into subranges as discussed above. Finally, as will be understood by one of ordinary skill in the art, ranges include each individual member. Thus, for example, a group having 1 to 3 cells refers to groups having 1, 2 or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

Moreover, the claims should not be read as limited to the order or elements presented, unless stated to that effect. Additionally, use of the terms “means for” in any claim is consistent with 35 U.S.C. It is intended to invoke §112, ¶6 or the means-plus-function claim form, and any claim that does not have the terms "means to" is not so intended.

The processor associated with the software is 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 for use in a radio frequency transceiver for use in a host computer. can be used to implement The WTRU includes modules implemented in hardware and/or software, including Software Defined Radio (SDR), and cameras, video camera modules, videophones, speakerphones, vibrating devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth ® module, frequency modulated (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 player module , an Internet browser, and/or other components such as any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

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

Additionally, while the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details without departing from the invention within the scope and range of equivalents of the claims.

Claims (20)

A method for establishing extended unicast links and management unicast links performed by a wireless transmit/receive unit (WTRU) that is a relay-WTRU (R-WTRU) comprising a transmitter, a receiver, a memory, and a processor, the method comprising:
Any for relaying traffic by the R-WTRU between a service provider WTRU (SP-WTRU) and any number of service user WTRUs (SU-WTRUs) according to a mapping generated by the R-WTRU performing a link establishment procedure for establishing a number of extended unicast links, the link establishment procedure comprising: (1) the above for any of an SP-WTRU, an R-WTRU, and any number of SU-WTRUs. creating a mapping of layer 2 (L2) identifiers (IDs) to any of the extension links, and (2) sending the unique relay ID as a relay indicator;
establishing a management unicast link for the extended unicast links; and
applying any number of link management requests received through the management unicast link to the associated extended unicast links according to the generated mapping;
A method for establishing extended unicast links and managed unicast links, comprising: 2. The method of claim 1, wherein the management unicast link is established with any of the SP-WTRU and the SU-WTRU during or after the extended unicast link establishment is performed;
and the unique relay ID is sent to any of (1) the SU-WTRUs via a discovery message, and (2) the SP-WTRUs via a unicast message. How to set up unicast links. The method of claim 2, wherein the discovery message is any of a link establishment message, a discovery request message, and a notification message,
wherein the unicast message is any of an authentication message or a security message. 2. The discovery of claim 1, comprising information that (1) indicates an SP-L2 ID associated with the SP-WTRU, and (2) identifies any of the services and applications provided by the SP-WTRU. Steps to receive messages
A method for establishing extended unicast links and managed unicast links, further comprising: 2. The method of claim 1, further comprising: (1) a first relay L2 ID (R-L2 ID1) identifying the R-WTRU as a transmission source for transmissions to the SU-WTRUs; and (2) generating a second relay L2 ID (R-L2 ID2) identifying the R-WTRU as a transmission source for transmissions to the SP-WTRU.
A method for establishing extended unicast links and managed unicast links, further comprising: 3. The method of claim 2, relaying the discovery message to the SU-WTRUs - the relayed broadcast DCR message is the service provided by the SP-WTRU, a unique relay ID, and the R-L2 ID2. contains information identifying any of the fields and applications -
A method for establishing extended unicast links and managed unicast links, further comprising: 2. The method of claim 1, wherein the R-WTRU and any number of relaying messages between SU-WTRUs
A method for establishing extended unicast links and managed unicast links, further comprising: 2. The method of claim 1, further comprising: overriding the SP-L2 ID and the SU-L2 ID of a PC5 message, and forwarding the PC5 message to any of the SP-WTRU and the SU-WTRU according to the mapping
A method for establishing extended unicast links and managed unicast links, further comprising: 2. The method of claim 1, wherein the R-WTRU is a transparent layer 2 (L2) R-WTRU. 2. The method of claim 1, further comprising: receiving information indicative of any of a relay policy and relay parameters;
A method for establishing extended unicast links and managed unicast links, further comprising: 5. The method of claim 1, further comprising: relaying keying material between the SP-WTRU and any number of SU-WTRUs respectively interested in any of the applications and the services provided by the SP-WTRU.
A method for establishing extended unicast links and managed unicast links, further comprising: A relay wireless transmit/receive unit (R-WTRU) for establishing extended unicast links and management unicast links, the R-WTRU comprising any of a transmitter, a receiver, a memory, and a processor, the processor comprising:
Any number of extended unicast links for relaying traffic between a service provider WTRU (SP-WTRU) and any number of service user WTRUs (SU-WTRUs) according to the mapping generated by the R-WTRU. perform a link establishment procedure to establish, the link establishment procedure comprising: (1) Layer 2 and any of the above extension links to any of SP-WTRU, R-WTRU, and any number of SU-WTRUs; comprising the WTRU configured to (L2) create a mapping of identifiers (IDs), and (2) transmit a unique relay ID as a relay indicator;
establish a management unicast link for the extended unicast links;
and apply any number of link management requests received on the management unicast link to associated extended unicast links according to the generated mapping. 13. The method of claim 12, wherein the management unicast link is established with any of the SP-WTRU and the SU-WTRU during or after the extended unicast link establishment is performed;
and the unique relay ID is sent to any of (1) the SU-WTRUs via a discovery message and (2) the SP-WTRUs via a unicast message. 14. The method of claim 13, wherein the discovery message is any of a link establishment message, a discovery request message, and a notification message,
wherein the unicast message is any of an authentication message or a security message. 13. The discovery of claim 12, comprising information that (1) indicates an SP-L2 ID associated with the SP-WTRU, and (2) identifies any of the services and applications provided by the SP-WTRU. and the R-WTRU is configured to receive a message. According to claim 1,
(1) a first relay L2 ID (R-L2 ID1) identifying the R-WTRU as a transmission source for transmissions to the SU-WTRUs; and (2) generating a second relay L2 ID (R-L2 ID2) identifying the R-WTRU as a transmission source for transmissions to the SP-WTRU;
Override the SP-L2 ID and the SU-L2 ID of a PC5 message, and forward the PC5 message to any of the SP-WTRU and the SU-WTRU according to the mapping, R- WTRU. 14. The method of claim 13,
relay the discovery message to the SU-WTRUs - the relayed discovery message identifying any of the services and applications provided by the SP-WTRU, a unique relay ID, and the R-L2 ID2 Contains information that provides -;
and relay messages between the SP-WTRU and any number of SU-WTRUs according to the mapping associated with the R-L2 ID1, SP-L2 ID, R-L2 ID2, and SU-L2 ID. , R-WTRU. A method for service discovery and link establishment performed by a relay wireless transmit/receive unit (R-WTRU) comprising a transmitter, a receiver, a memory, and a processor, the method comprising:
establishing a PC5 connection with a service provider WTRU (SP-WTRU);
receiving an SP-WTRU ID and any number of service identifiers (IDs) associated with the SP-WTRU ID;
storing, by the R-WTRU, information indicating an association between the arbitrary number of service IDs and any number of SP-WTRU IDs;
receiving, from the SU-WTRU, a signal for requesting a service to be relayed by the R-WTRU; and
sending, to the SU-WTRU, any number of SP-WTRU IDs and respective service IDs associated with the requested service;
A method for service discovery and link establishment, including. 19. The method of claim 18, wherein the arbitrary number of service IDs are received from any of the SP-WTRU and ProSe function. 19. The method of claim 18, wherein the arbitrary number of SP-WTRU IDs and respective service IDs are sent to the SU-WTRU under a condition that a server authorizes the SU-WTRU to receive the service;
the arbitrary number of SP-WTRU IDs and respective service IDs are sent to the SU-WTRU under the condition that the SP-WTRU authorizes the SU-WTRU to receive the service;
The method for service discovery and link establishment, wherein the service is any of a ProSe service, a sidelink service, a V2X service, an eV2X service, a D2D service, and a direct communication service.

Images