L2 procedure for unicast and / or multicast link setup and maintenance

Abstract

L2 procedures for unicast and / or multicast link setup and maintenance, including corresponding systems, methods, and devices. A wireless transmit receive unit (WTRU) may send a link setup request broadcast message, where the link may be used for multicast, unicast, or multicast. The WTRU may receive a link setup response broadcast message and a connection report. Once a multicast or unicast link has been established, the WTRU may send a link establishment acknowledgement broadcast message, at which time the WTRU may send and receive a multicast message. A link setup request message may be sent based on one or more triggers: receiving a QoS flow, requiring a new sidelink radio bearer, determining that the new QoS flow or radio bearer requires network controlled admission control, and / or receiving unicast and / or multicast setup requests. The WTRU may transmit a unicast and / or multicast availability signal (UMUS). The WTRU may preempt the established multicast or unicast link.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of September 25, 2019, application number 201980074284.X, and invention name “L2 process for establishing and maintaining unicast and / or multicast links”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of the following applications: U.S. Provisional Application No. 62 / 736,251 filed on September 25, 2018; U.S. Provisional Application No. 62 / 752,865 filed on October 30, 2018; U.S. Provisional Application No. 62 / 783,952 filed on December 21, 2018 and U.S. Provisional Application No. 62 / 886,102 filed on August 13, 2019, the contents of each of which are incorporated herein by reference. Technical Field

[0004] The present application relates to the field of wireless communications. Background Art

[0005] Wireless communication use cases may deal with vehicular communications related to traffic, transportation, safety, navigation, etc. For example, vehicle-to-everything (V2X) communications may involve sending wireless communications to and receiving wireless communications from vehicles. As wireless communication capabilities and requirements evolve, it may be desirable to provide systems, methods, and devices that operate in such environments. Summary of the invention

[0006] Some embodiments provide a method implemented in a wireless transmit / receive unit (WTRU) for determining whether to establish a sidelink radio bearer (SLRB). The method includes: configuring a SLRB resource selection criterion for the WTRU; receiving, by the WTRU, a plurality of SCI transmissions from another WTRU in a pool during a time window; determining, by the WTRU, for each of a plurality of time periods within the time window, whether SLRB resource selection will fail based on the plurality of SCI transmissions and the SLRB resource selection criterion; and determining, by the WTRU, whether to establish a new SLRB based on a percentage of resource selection failures; and establishing the new SLRB with the other WTRUs in the pool if the percentage of time periods in which resource selection is determined to fail is below a threshold percentage.

[0007] Some embodiments provide a WTRU configured to determine whether to establish an SLRB. The WTRU includes a processor operatively coupled to a transmitter and a receiver. The processor is configured with SLRB resource selection criteria. The receiver is configured to receive multiple SCI transmissions from another WTRU in a pool during a time window. The processor is configured to determine whether SLRB resource selection will fail for each of a plurality of time periods within the time window based on the plurality of SCI transmissions and the SLRB resource selection criteria. The processor is also configured to determine whether to establish a new SLRB based on a percentage of resource selection failures. The transmitter is configured to transmit a message to establish a new SLRB with other WTRUs in the pool when the percentage of time periods in which resource selection will fail is determined to be below a threshold percentage.

[0008] Some embodiments provide a method implemented in a WTRU for determining whether to establish an SLRB. The method includes: configuring a mapping of bearer QoS to SLRB resource density for the WTRU; receiving a broadcast by the WTRU, the broadcast indicating the QoS of the SLRB of another WTRU in the pool; determining, by the WTRU, the total SLRB resource density in the pool based on the received QoS and the mapping; and determining, by the WTRU, whether to establish the new sidelink bearer with another WTRU in the pool based on whether the total resource density exceeds a threshold based on the QoS of the new sidelink bearer. The method also includes establishing the new sidelink bearer with the other WTRU in the pool if the WTRU determines to establish the new sidelink bearer.

[0009] Some embodiments provide a WTRU configured to determine whether to establish an SLRB. The WTRU includes a processor operatively coupled to a receiver and a transmitter. The receiver is configured to receive a broadcast indicating the quality of service (QoS) of the SLRB of another WTRU in a pool. The processor is configured to determine the total SLRB resource density in the pool based on the received QoS and a mapping of the bearer QoS to the SLRB resource density. The processor is also configured to determine whether to establish a new sidelink bearer with another WTRU in the pool based on whether the total resource density exceeds a threshold based on the QoS of the new sidelink bearer. The transmitter is configured to transmit a message to establish the new sidelink bearer with the other WTRU in the pool if the processor determines to establish the new sidelink bearer. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings can be understood in more detail from the following description, but are not intended to limit the scope of the embodiments but are merely used as examples in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0011] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0012] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0013] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system shown;

[0014] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another example RAN and another example CN used within the communication system shown;

[0015] Figure 2 is a message sequence diagram illustrating an example link establishment procedure between two WTRUs;

[0016] Figure 3 is a block diagram of a link establishment model illustrating an example process of a connection establishment decision performed by the AS layer;

[0017] Figure 4 is a block diagram of a link establishment model illustrating an example process by which an upper layer performs a connection establishment decision based on information from an AS layer;

[0018] Figure 5 is a message sequence diagram illustrating an example side link establishment procedure at the AS layer between WTRUs;

[0019] Figure 6 is a message sequence chart illustrating example multicast link establishment signaling and decision criteria;

[0020] Figure 7 is a message sequence chart illustrating example multicast link establishment signaling;

[0021] Figure 8 is a flow chart illustrating an example process for admission control based on representative resource selection;

[0022] Fig. 9 is a flow chart illustrating an example method for determining whether to establish a sidelink radio bearer (SLRB); and

[0023] Fig.10 is a flow chart illustrating another example method for determining whether to establish a SLRB. DETAILED DESCRIPTION

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

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

[0026] The communication system 100 may also include a base station 114a and / or a base station 114b. Each base station 114a and / or base station 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0027] The base station 114a may be part of the RAN 104 / 113, and the RAN may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called 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 wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0046] The processor 118 may be further 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. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game console module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, and an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

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

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

[0053] 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 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

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

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

[0056] Although in Figures 1A-1D Although the WTRU is described as a wireless terminal, it should be appreciated that in certain typical embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0057] In a typical embodiment, the other network 112 may be a WLAN.

[0058] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send services into and / or out of the BSS. Services originating from outside the BSS and destined for the STA may be reached by the AP and delivered to the STA. Services originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Services between STAs within the BSS may be sent by the AP, for example, when the source STA may send services to the AP and the AP may deliver services to the destination STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. The point-to-point services may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain typical embodiments, the DLS may use 802.11eDLS or 802.11z tunneled DLS (TDLS)). A WLAN using an independent BSS (IBSS) mode does not have an AP, and STAs (eg, all STAs) within or using the IBSS can communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0059] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set with the aid of signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain typical embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA), including the AP, may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

[0060] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form the 40 MHz wide channel.

[0061] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can divide the data into two streams. Inverse fast Fourier transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be opposite, and the combined data can be sent to the media access control (MAC).

[0062] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a typical embodiment, 802.11ah can support instrument type control / machine type communication (such as MTC devices in macro coverage areas). MTC devices can have certain capabilities, such as limited capabilities including support (for example, only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (for example, for maintaining a very long battery life).

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

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

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

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

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

[0068] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

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

[0070] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although each of the aforementioned elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

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

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

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

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

[0075] In view of Figures 1A-1D and about Figures 1A-1D , one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more of any other devices described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0078] Vehicle-to-everything (V2X) communications may transfer information between a vehicle and other entities, such as other vehicles, roadside units (RSUs), pedestrian user equipment (e.g., WTRUs), etc. In some cases, vehicle V2X communications include a communication mode whereby the WTRUs communicate directly with each other. V2X operations may include in-coverage scenarios and out-of-coverage scenarios. In-coverage scenarios may include operations where the WTRU receives assistance from the network to begin transmitting and receiving V2X messages. Out-of-coverage scenarios may include operations where the WTRU begins transmitting and receiving V2X messages based on preconfigured parameters.

[0079] V2X communications may be supported by LTE and may involve working on device-to-device (D2D) communications. V2X communications may include different types of services, such as V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2N (vehicle-to-network), and V2P (vehicle-to-pedestrian) services. V2V services may facilitate direct communications between vehicle WTRUs. V2I services may facilitate communications between vehicle WTRUs and RSUs and / or eNBs. V2N services may facilitate communications between vehicle WTRUs and the core network. V2P services may facilitate communications between vehicle WTRUs and WTRUs with special conditions (e.g., low battery capacity, etc.), and so on.

[0080] V2X communications may include different operating modes for resource allocation. For example, LTE defines Mode 3 and Mode 4 operations. Mode 3 operation may include a network device, such as an eNB, providing a WTRU with resource scheduling allocations for V2X sidelink (SL) transmissions. Mode 4 operation may include the WTRU autonomously selecting resources from a configured or preconfigured resource pool. V2X (e.g., LTE V2X) may include two types of resource pools: a receive pool and a transmit pool. The WTRU may monitor the V2X resources (e.g., time and / or frequency) in the receive resource pool to receive V2X transmissions. The WTRU may select transmission resources from the V2X transmission resource pool, for example in Mode 4 operation. In some embodiments, a WTRU configured for Mode 3 operation may not use a transmission pool.

[0081] The resource pool may be semi-statically signaled to the WTRU via RRC signaling (e.g., in LTE). In Mode 4 operation, the WTRU may use V2X sensing (e.g., including decoding control channel transmissions of other WTRUs) before selecting resources from the RRC configured transmission pool. LTE V2X may not support dynamic resource pool reconfiguration. In some implementations, the LTE resource pool configuration may be carried only via SIB and / or dedicated RRC signaling.

[0082] New Radio (NR) can support several use cases, such as enhanced mobile broadband (eMBB), ultra-high reliability and low latency (URLLC), and other technologies. Enhanced V2X (eV2X) communications can be used with NR systems. In NR, eV2X can accommodate new services for safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning, remote driving, etc.). Different eV2X services may require different performance requirements, such as a scenario where 3ms latency is required.

[0083] NR V2X can support several use cases such as vehicle platooning, advanced driving, extended sensors and remote driving.

[0084] Vehicle platooning may enable vehicles traveling together to dynamically form groups. All vehicles in a platoon may receive periodic data from the lead vehicle for platooning operations. Such information may facilitate extremely small distances between vehicles (i.e., gap distances converted to time, i.e., communication latency may be very low, e.g., sub-second latency). Platoon applications may facilitate vehicles following a lead vehicle to be autonomously driven.

[0085] Advanced driving can achieve semi-autonomous or fully autonomous driving for greater inter-vehicle distances. For example, V2X devices may include vehicles or other mobile nodes, and roadside units (RSUs) or other fixed nodes. Each vehicle and / or roadside unit (RSU) can share data obtained from its local sensors with nearby vehicles, allowing the vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle can share its driving intentions with nearby vehicles. For example, a vehicle can send messages including various information, such as changes in speed and / or direction, to other vehicles to indicate the vehicle's driving intentions. Advanced driving can promote safer driving, collision avoidance, and improved traffic efficiency.

[0086] The extended sensors can enable the exchange of raw or processed data or live video data collected by local sensors between vehicles, RSUs, pedestrian devices and / or V2X application servers. The vehicle can enhance the perception of its environment beyond what its own sensors can detect, for example, providing a holistic view of the local situation.

[0087] Remote driving can enable a remote driver or V2X application to operate a remote vehicle. This may be advantageous, for example, for providing vehicle operation for passengers who cannot drive themselves or for providing remote operation for vehicles located in hazardous environments. In some cases where variability is limited and routes are predictable, such as public transportation, cloud-based driving can be used to control or facilitate remote driving. A cloud-based backend service platform can be used for remote export. For example, a vehicle or other V2X device can exchange messages with a central server or cloud server to perform calculations.

[0088] LTE V2X may rely only on broadcast communications and therefore may not use link establishment. However, D2D, on which the V2X sidelink is based, may utilize link establishment on the sidelink. For example, in D2D operation, two WTRUs may establish a one-to-one ProSe direct communication on the PC5 protocol layer above the PDCP layer in the protocol stack.

[0089] One-to-one ProSe direct communication may be achieved, for example, by establishing a secure Layer 2 link between two WTRUs via PC5. Each WTRU may have a Layer 2 ID for unicast communication, which is included in the source Layer 2 ID field of each frame it sends on the Layer 2 link and in the destination Layer 2 ID of each frame it receives on the Layer 2 link. The Layer 2 link of a one-to-one ProSe direct communication may be identified by a combination of the Layer 2 IDs of each of the two WTRUs in the direct communication. A WTRU may participate in multiple Layer 2 links for one-to-one ProSe direct communication using the same Layer 2 ID, for example because the Layer 2 link is identified by a combination of the Layer 2 IDs of each of the two WTRUs in the direct communication.

[0090] WTRUs participating in isolated (ie, non-relayed) one-to-one communications may negotiate an IP address allocation mechanism and optionally exchange link-local IPv6 addresses if required during the link establishment process.

[0091] Figure 2 2 is a message sequence diagram illustrating an example process 200 of link establishment between WTRU 210 and WTRU 220. In a first step, WTRU 210 may send a direct communication request message 230 to WTRU 220 to trigger mutual authentication. The content of direct communication request message 230 may be referred to as user information. In a second step, WTRU 220 initiates a process 240 for mutual authentication. Successful completion of the authentication process completes the establishment of a security layer 2 link over PC5. As part of this step, WTRU 220 includes user information in a response message to WTRU 210.

[0092] The PC5 signaling protocol supports a keep-alive function that can be used to detect if the WTRUs are out of ProSe communication range, in which case they may proceed with an implicit Layer 2 link release.

[0093] NR V2X may include link establishment enhancements (e.g., compared to D2D). For example, procedures may be provided for establishing and maintaining secure L2 links over PC5. Such procedures may be enhanced and adapted for use with V2X, or similar signaling may be defined at the RRC layer. V2X link / group handling may also require further consideration. For example, not all WTRUs may support or use unicast communications in V2X communications. To support link establishment, the WTRU may transmit a service announcement to inform peers of the presence of the WTRU and the capabilities of the WTRU (if any) for unicast communications (e.g., the channels on which the WTRU can operate for unicast, the services supported, etc.). This service announcement may be accessible to all WTRUs that are interested in using the service (e.g., an application). For example, such an announcement may be configured to be sent over a dedicated channel (similar to how WAVE Service Advertisements (WSA) are handled), or carried on (e.g., added to or attached to) periodic messages from supporting WTRUs.

[0094] NR V2X may include QoS enhancements. For example, QoS on PC5 may be supported with ProSe per-packet priority (PPPP). The application layer may be allowed to mark packets with PPPP indicating the required QoS level. Other enhancements may be added (e.g., allowing PDB to be derived from PPPP).

[0095] NR V2X QoS requirements may include performance KPIs. Such performance KPIs may be specified using one or more of the following parameters: payload (bytes); transmission rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); and / or minimum required communication range (meters).

[0096] The same set of service requirements may be applied to PC5-based V2X communications and Uu-based V2X communications. For example, such QoS characteristics may be represented by 5QI. Thus, a unified QoS model may be used for PC5 and Uu (e.g., 5QI may also be used for V2X communications over PC5, so that the application layer may have a consistent way of indicating QoS requirements regardless of the link used).

[0097] A 5GS V2X-capable WTRU can support three different types of services: broadcast, multicast, and unicast.

[0098] The same QoS model as for Uu can be used for unicast traffic (i.e., each unicast link can be considered as a bearer and a QoS flow can be associated with it). All QoS characteristics and additional data rate parameters defined in 5QI can be applied. In addition, the minimum required communication range can be considered as a specific additional parameter used by PC5.

[0099] The same or similar considerations may apply to multicast services, which may be viewed as a special case of unicast (ie, utilizing multiple defined receivers for the service).

[0100] For broadcast services, there may be no bearer concept; i.e. there is no association between packets and logical links with certain configuration parameters. Depending on the application requirements, each broadcast message may have different characteristics. The 5QI is accordingly used in a manner similar to PPPP and / or ProSe per-packet reliability, i.e. each packet is associated with (or "tagged with") a QoS value. The 5QI may have the ability to represent all characteristics required for PC5 broadcast operation (e.g. latency, priority, reliability, etc.). A set of V2X broadcast-specific 5G Quality of Service Indicators (V2X 5QIs) or (VQI) may be defined for PC5 use.

[0101] The PC5 QoS parameters may be negotiated at the time of establishment of the one-to-one communication process. Therefore, the one-to-one communication establishment process may be enhanced to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation, the same QoS may be used in both directions of the one-to-one communication.

[0102] You can modify the Figure 2An example process 200 is shown for negotiation of PC5 QoS parameters between WTRU 210 and WTRU 220. For example, in a first step, in addition to or instead of user information, direct communication request message 230 may include requested PC5 QoS parameters. In a second step, in addition to or instead of user information, process 240 may include accepted PC5 QoS parameters in a response message to WTRU 210.

[0103] In some cases, establishing unicast and multicast links for NR V2X based on the QoS model may cause several problems. For example, in some implementations, the signaling for unicast link establishment (for D2D one-to-one establishment) may only support unicast links, but not multicast links.

[0104] Additionally, in some implementations, link establishment decisions (e.g., for one-to-one communications in D2D) may be based on reachability requirements (e.g., received signal received power (RSRP)), while NR V2X may have more stringent requirements (e.g., latency, reliability, etc.) and / or additional requirements (e.g., range, rate, etc.). These various requirements may rely on unicast and / or multicast at the AS layer to implement these requirements. Radio bearer type models may be used for unicast and / or multicast, which may require new sidelink procedures that were previously not required and / or unspecified for D2D or V2X. For example, an admission control procedure handled autonomously by the WTRU may be required for Uu (e.g., Mode 4 operation), which may typically have been performed by the network. In another example, a link maintenance procedure for QoS on the sidelink may require the AS layer to maintain a certain quality level for the SL transmission.

[0105] Additionally, in some implementations, the QoS model may assume that a set of flows are mapped to specific bearers (e.g., similar to Uu). For Uu, the mapping may be done by the gNB based on the available DL / UL resources. For SL, these decisions may need to be made by the WTRU (e.g., for Mode 4 operation) and may need to be based on the properties of the available SL resources and the SL bearer characteristics that the WTRU may establish itself.

[0106] Some embodiments may provide systems, methods, and devices for link establishment and maintenance. Link establishment and maintenance for unicast or multicast transmissions is discussed herein. Substantially similar link establishment and maintenance procedures may also be applied to "broadcast links," whereby broadcast links may require less involved admission control evaluations and / or link maintenance procedures, or no admission control evaluations and / or link maintenance procedures. However, link establishment signaling may still be applied to broadcast transmission situations, as long as a radio bearer can be established for a broadcast service associated with the transmission of a group destination ID or L2 destination ID. Therefore, the techniques and methods discussed herein may also be applicable to broadcast transmissions.

[0107] As used herein, the term "upper layer" may refer to a NAS layer, an application layer, a V2X layer, or may indicate an interaction between a NAS layer, a V2X layer, and an application layer. In some examples, the process for connecting (i.e., linking) may include a link establishment decision performed by the AS layer. AS / NAS layer signaling for link establishment may be based on several models. Figure 3 An example of such a model is shown.

[0108] Some embodiments provide a process for SL radio bearer link establishment. For example, Figure 3 is a block diagram of a link establishment model 300 illustrating exemplary communications between the NAS layer and / or one or more upper layers 310 and the AS layer 320 for establishing a connection between a WTRU and a peer WTRU. The link establishment model 300 illustrates connection establishment decisions performed by the AS layer 320.

[0109] The NAS and / or one or more upper layers 310 may communicate a list 330 of WTRUs between which a connection is desired to be established. The list 330 may be communicated in the form of a request, a packet marked as unicast with a specific L2 ID of the peer WTRU, or in any other suitable manner. Based on the list 330, the AS layer 320 may perform operations 340 to determine reachability (e.g., whether the WTRU can communicate with another WTRU (i.e., reach the other WTRU)), perform admission control, and initiate connection establishment. The AS layer 320 may provide the results of the operations 340 to the NAS and / or one or more upper layers 310 in a communication 350 (e.g., an inter-layer message).

[0110] In some implementations, portions of operation 340 may be performed in a separate discovery process that may or may not be performed concurrently with link establishment. For example, the WTRU may perform a reachability determination as part of a separate discovery process that occurs prior to the link establishment process. Similarly, a response to the link establishment process (e.g., a reachability report, such as those discussed further herein) may also be part of a separate discovery process that is performed prior to link establishment.

[0111] Figure 4 is a block diagram of a link establishment model 400 illustrating example communications between a NAS and / or one or more upper layers 410 and an AS layer 420 for link establishment, wherein the NAS and / or one or more upper layers 410 may make decisions based on information from the AS layer 420.

[0112] The NAS and / or one or more upper layers 410 may send a discovery or service announcement to the AS layer 420 in communication 430 to obtain a list of WTRUs in range (e.g., WTRUs that support unicast services). The communication 430 may be in the form of a request, a packet with a specific L2 ID of one or more peer WTRUs, or an identifier of the service or application being announced, for example. The AS layer 420 may provide connection related information (e.g., an inter-layer message) to the NAS and / or one or more upper layers 410 in communication 440. For example, the connection related information may be information about whether two WTRUs can communicate with each other, the quality of their link, etc.

[0113] The NAS and / or one or more upper layers 410 may initiate connection establishment via a connection establishment communication 450 (e.g., an inter-layer message). After receiving the connection establishment communication 450, the AS layer 420 may perform an admission control process 460, such as discussed further herein. The AS layer 420 may provide the results from the admission control process 460 to the NAS and / or one or more upper layers 410 in a communication 470.

[0114] In model 400, communications 430 and 440 and associated processes for generating, transmitting, receiving, and processing these communications may be optional or may be performed entirely by NAS and / or one or more upper layers 410. For example, NAS and / or one or more upper layers 410 may transmit upper layer discovery or service announcement messages, and connection establishment may be initiated between NAS and / or one or more upper layers 410 (i.e., corresponding to communication 450) without any information from AS layer 420. AS layer 420 may also provide connection-related information to NAS and / or one or more upper layers 410 in communication 470.

[0115] Some embodiments may provide AS / NAS layer signaling to support unicast, multicast links and / or SLRB communications. Some examples include interactions between upper layers and the AS layer to facilitate or ensure QoS for services (e.g., broadcast services, which may or may not be transmitted as SLRBs) or flows (e.g., which may be mapped to SLRBs by the AS layer). In some examples, such interactions may be in any transmission mode (e.g., mode 1 or mode 2) and / or for any type of transmission (e.g., unicast, multicast, or broadcast). In some examples, a WTRU performing an admission control process for a broadcast service may make its own admission control determination (i.e., for mode 2) or may receive an admission control decision from the network (i.e., mode 1). The WTRU may notify the upper layers of such a decision. Alternatively, for cases where unicast and / or multicast links and / or SLRBs are established, the WTRU may initiate link establishment signaling. Each WTRU associated with a unicast or multicast setup may perform its own admission control and may notify its own upper layers of the admission control results, or may notify peer WTRUs of the admission control results, where the peer WTRUs are responsible for interacting with upper layers based on the admission control results of all WTRUs. Without loss of generality, the examples described in the following cases may apply to any of the above cases.

[0116] In some examples, the list of WTRUs may be provided by the NAS layer and / or upper layers to the AS layer (e.g., as described in relation to Figure 3 330), or a connection establishment request may be made by the NAS layer and / or upper layers to the AS layer (e.g., as described with respect to Figure 4 450). In some such examples, the NAS layer and / or upper layers may provide various information and / or parameters to the AS layer, such as a list of L2 source IDs identifying the WTRUs to be included in the unicast and / or multicast connection (e.g., a single WTRU in the case of unicast); a unicast and / or multicast indication (i.e., an indication of whether the connection will be unicast or multicast); data packets to be sent (e.g., an upper layer service announcement); QoS requirements for the unicast and / or multicast links (e.g., VQI, QoS profile); an expected time period during which transmissions between the two or more WTRUs may occur (e.g., to assist the AS layer in deciding on AS layer link establishment); and / or a link identifier for L2 unicast and / or multicast. Such a link identifier may include the L2 source ID of the peer WTRU, which the WTRU may include in the link establishment request message (e.g., connection establishment communication 450). Alternatively, in the unicast case, such a link identifier may include the L2 source ID of the peer WTRU that is the unicast destination, and the upper layers (eg, NAS and / or one or more upper layers 410) may identify the WTRU with another ID.

[0117] In some examples, the AS layer may provide connection information. Figure 4 is a block diagram of a link establishment model, which shows an example process in which an upper layer determines link establishment based on information from an AS layer. Figure 4 AS layer 420 as shown and described may provide connection information in communication 440 or communication 470 . In some examples, the AS layer may provide various information / parameters to the NAS / upper layers, such as a list of WTRUs within the WTRU range that support the announced service or application; reachability for a particular WTRU (e.g., a yes / no indication of whether the WTRU is able to communicate with (i.e., reach) another WTRU), where the reachability may be evaluated by the AS layer based on a VQI provided by the upper layers; measurement values ​​or levels associated with measurement signals (e.g., PHY layer signals, such as reference signals included in the message) transmitted between the WTRUs (e.g., based on a preconfigured mapping of RSRP to levels), where the measurements may be based on transmission of a discovery or service announcement message or transmission of an associated RRC message transmitted in response to the connection establishment initiated by the upper layers; results of the upper layer service announcement (e.g., such results may be carried in a NAS packet); potential trends in discovery or message transmission results (e.g., information indicating an increase, decrease, or no change in the measured RSRP, or indicating a time period x during which another WTRU can discover or hear the WTRU); and / or vehicle trajectory information.

[0118] In some examples, the WTRU AS may send the result of the SL radio bearer link establishment process to upper layers. Figure 4 AS layer 420 shown and described may provide the results in communication 470, or as described with respect to Figure 3 The AS 320 shown and described may provide a result in communication 350. Such a result may include an indication of link establishment success or failure; may include an error code indicating the reason for a failed link establishment; and / or may include a subset of WTRUs connected (i.e., fully connected) in a multicast link in a successful link establishment (e.g., a list of L2 IDs).

[0119] In some examples, the WTRU AS may send an indication to the upper layer that the link establishment failed. Such failure may be due to failed admission control for the requested service, packet, link, and / or SLRB. Such an indication may occur at any time during the active time of the SLRB, for example, if the SLRB link monitoring fails, or is preempted by another WTRU. Such an indication may be sent by any WTRU associated with the procedure (e.g., at the initiating WTRU or a peer WTRU). The AS may provide such an indication to the upper layer in the same message as any information regarding the failed link establishment, or a combination thereof, such as information indicating the WTRU (e.g., WTRU ID) for which QoS is not met or the link cannot be established (e.g., an indication of the WTRU interacting with the upper layers, or a peer WTRU being unable to establish a link), where the WTRU ID provided may be the source L2 ID; information indicating the WTRU that preempted the SLRB (e.g., WTRU ID); QoS parameters of the link and / or SLRB or packet that caused the preemption of the SLRB, the SLRB ID or flow ID; specific QoS parameters that could not be met; indications of other WTRUs (e.g., WTRU IDs) and / or SLRBs (SLRB IDs, QoS flow IDs, or the like) currently established that prevent the establishment of a new SLRB / link or do not allow the establishment of a new SLRB / link (e.g., an indication that the new SLRB conflicts with an existing unicast link, and / or an indication of which existing unicast links conflict with the new SLRB); and / or the cause of the failure. Examples of failure reasons include admission control failure, inability to preempt ongoing services, capability failure (e.g., inability to establish a link or inability to meet QoS), insufficient resources to establish a link (e.g., physical link shared channel (PSSCH), RS resources, feedback channel, preempted resources), and / or preemption of SLRB / link.

[0120] In some examples, the WTRU falls back to best effort. For example, the WTRU AS layer may indicate to the WTRU NAS layer that a link has been established, but the QoS requirements associated with the link may not be met. If indicated by the WTRU AS layer during link establishment initiation, the WTRU AS layer may be further enabled (e.g., depending on the configuration of the WTRU, or a standard or specification) to send such an indication to upper layers. The WTRU AS may indicate specific QoS parameters that may be met (e.g., waiting times), as well as QoS parameters that may be met only as a best effort.

[0121] In some examples, the WTRU AS layer may negotiate or renegotiate with the WTRU NAS layer to determine the appropriate QoS that the AS layer link and / or SLRB can support. The negotiation or renegotiation may occur during link establishment / SLRB setup, or at any time when a link is established, such as upon detection of a failure in link monitoring, following a trigger for AS layer reconfiguration (e.g., as described herein), upon receipt of a preemption indication for a link, or initiated by an upper layer. The negotiation or renegotiation may be performed by any WTRU associated with the process (e.g., at an initiating WTRU or a peer WTRU).

[0122] For example, the WTRU AS layer may indicate that the QoS cannot be met and may wait for the upper layer to provide a new VQI, or indicate termination of the procedure. The WTRU AS layer may wait for an indication from the upper layer for a time indicated by the value of a configured, preconfigured, or defined timer, after which the WTRU AS layer may indicate a failure in AS layer signaling associated with link establishment or AS layer reconfiguration (e.g., by transmitting a reject or failure RRC message). Alternatively, if the upper layer provides a new VQI, the AS layer signaling procedure (e.g., link establishment or AS layer reconfiguration) may continue using the new VQI.

[0123] In another example, the WTRU AS layer may indicate that the QoS cannot be met and may suggest an alternative QoS (e.g., VQI) that may be met instead. The AS layer may wait for the upper layer to provide confirmation of the suggested QoS parameters, or indicate that the suggested QoS is unacceptable for the associated flow or SLRB. The WTRU AS layer may wait for an indication from the upper layer for a period of time indicated by the value of a configured, preconfigured, or defined timer, after which it may indicate a failure in AS layer signaling associated with link establishment or AS layer reconfiguration (e.g., by transmitting a reject or failure RRC message). Alternatively, if the upper layer confirms that the new QoS parameters are acceptable, the AS layer signaling process (e.g., link establishment or AS layer reconfiguration) may continue using the new QoS parameters.

[0124] In the example of the negotiation / renegotiation scenario described above, where the AS layer indicates that QoS cannot be met, the upper layer may inform the AS layer as to whether AS layer signaling should continue for link establishment or AS layer renegotiation. For example, if the QoS negotiation is successful (e.g., the upper layer is able to configure a new QoS for the SLRB), the new QoS may need to be provided to other WTRUs associated with the link establishment or AS layer reconfiguration. The new one or more QoS parameters may be provided in RRC signaling (e.g., the upper layer may provide one or more new QoS parameters to the AS layer, and the AS layer may include the one or more new QoS parameters in the RRC message), or provided by upper layer signaling (e.g., RRC signaling includes one or more new QoS parameters in a transparent (e.g., encapsulated) message sent by the RRC). In either case, the upper layer may instruct the AS layer to continue the RRC signaling exchange in order to deliver the one or more new QoS parameters to the other WTRUs. If the QoS renegotiation process fails, the WTRU may initiate the transmission of an RRC failure message associated with the RRC signaling exchange, at which point the link establishment process or AS layer reconfiguration process may be considered to have failed.

[0125] In some examples, QoS negotiation or renegotiation is conditional on the presence of an upper layer PDU. For example, the WTRU may determine whether to perform QoS negotiation or renegotiation based on the presence, absence and / or size of one or more upper layer PDUs (i.e., transparent, such as encapsulated messages) in a received RRC message. In some examples, the WTRU may receive a link establishment request RRC message. If the RRC message includes an upper layer PDU (or if the upper layer PDU has a given size), the WTRU may determine that failed admission control and / or failed AS layer reconfiguration may initiate a QoS negotiation or renegotiation process with the upper layer. Alternatively, if such a PDU is not included in the RRC message, the WTRU may indicate a failed link establishment or reconfiguration process at the time of failed admission control. Without loss of generality, such an upper layer PDU may be included in any one of the RRC messages associated with link establishment and / or AS layer reconfiguration. In addition, the WTRU may also maintain knowledge of whether a QoS renegotiation process is allowed for a failed link monitoring scenario (e.g., stored information indicating whether a QoS renegotiation process is allowed) based on whether an upper layer PDU is included in the signaling during link establishment of the SLRB.

[0126] Some embodiments may provide sidelink signaling to support unicast and / or multicast links and / or SLRBs. Some examples include active discovery. For example, the WTRU may actively perform periodic discovery to maintain a list of potential unicast and / or multicast targets. Such active discovery transmissions may be initiated by the AS layer, application layer, or NAS layer. The WTRU may use a dedicated destination L2 ID to use discovery messages broadcast on the PSSCH. Such an ID may be associated with unicast service discovery.

[0127] The WTRU (e.g., the AS layer and / or upper layers) may maintain a list of responding WTRUs and certain quality measurements associated with these WTRUs. For example, the WTRU may maintain a list of L2 source IDs that responded to discovery broadcast messages. The WTRU may also maintain certain trends used during AS link establishment decisions, such as measured absolute quality values ​​of discovery responses; consecutive time periods for which the number of responses and / or discovery responses are above a threshold; and / or time periods or number of responses for which the discovery response quality does not change by more than a certain amount.

[0128] The WTRU may determine the link establishment criteria based on any of the above information (e.g., discovery responses above a threshold measured in at least the last T time units), or indicate the criteria to upper layers. The WTRU may respond to a discovery message using the source L2 ID of the initiating WTRU as the destination address.

[0129] Some examples include signaling for autonomous link establishment, performed by the WTRU. For example, Figure 5 5 is a message sequence diagram illustrating an example sidelink link establishment procedure 500 at the AS layer between the WTRU 510 and the WTRU 520. The link establishment may include a link establishment request message 530 from the WTRU 510 to the WTRU 520, a link establishment response message 540 from the WTRU 520 to the WTRU 510, and / or a link establishment confirmation message 550 from the WTRU 510 to the WTRU 520. The WTRUs 510 and 520 may send each message as an RRC message (e.g., the link establishment request message 530 may be an RRC reconfiguration message, a WTRU sidelink information message, or any other such message supported by the RRC protocol). Alternatively, the messages shown in the process 500 may include a mix of upper layer messages and RRC messages. After the WTRU 520 receives the link establishment message 550, the SL transmission may start on the established SL bearer in step 560.

[0130] In some examples, following the indication from higher layers for link establishment, the WTRU 510 may first perform an admission control procedure based on one or more measurements at the WTRU 510. If the admission control is successful, or if the triggered QoS renegotiation is successful, the WTRU 510 may send a link establishment request message 530. The link establishment request message 530 may include any or all of the source L2 IDs of the one or more WTRUs to which the unicast and / or multicast links are requested; the multicast ID for the multicast link being requested; the source L2 ID of the WTRU transmitting the link establishment request; QoS related information; information about the proposed AS configuration for the link or SL bearer to be established; information about one or more capabilities of the WTRU 510; information required to perform link and / or bearer admission control at the one or more peer WTRUs (e.g., WTRU 520); and / or embedded upper layer messages and / or information for upper layer link establishment.

[0131] The QoS related information included in the link establishment request message 530 may include QoS information for the link (e.g., one or more VQIs associated with the bearers to be established). Alternatively, the link may be established before any QoS related information is provided, in which case the AS layer may determine whether link establishment is possible based solely on proximity information. Alternatively, in the absence of any QoS information about flow information from upper layers, the AS layer may determine the associated QoS information (e.g., VQI or similar information) to be used for the signaling connection between the WTRUs. The WTRU may configure, preconfigure, or determine such a default or signaling VQI based on a channel busy ratio (CBR), carrier bandwidth (BW), bandwidth part (BWP), or similar physical layer parameters or measurements.

[0132] The information required to perform link and / or bearer admission control included in the link establishment request message 530 may include information indicating the gNB and / or PLMN to which the WTRU 510 is camped / connected; the area ID of the SI currently used by the WTRU 510; location information (e.g., geographic location information, area ID, etc.) and / or movement-related information about the WTRU 510 (e.g., speed, heading, identification of a head WTRU such as a scheduling WTRU or a convoy leader, an indication of whether the WTRU is part of a convoy-based or group-based scheduling, QoS-related measurements measured by the WTRU 510, and / or QoS-related metrics measured by the WTRU 510.

[0133] The information related to the upper layer link establishment included in the link establishment request message 530 may include upper layer QoS and / or service related information. Such information may be included in a transparent (e.g., encapsulated) message and delivered to the upper layer by the WTRU520 directly (e.g., without decoding the message). As discussed herein, such information may include information necessary for QoS renegotiation. In another example, the link establishment request message 530 may include a PC5 protocol or NAS protocol establishment message submitted by the upper layer to the lower layer to initiate a connection establishment, wherein the message may be carried as a payload of an RRC message used as a connection establishment request.

[0134] The link establishment request message 530 may include information about a suggested AS configuration for the link or SL bearer to be established, and the signaling connection itself may be associated with a default SL bearer configuration. Further description of potential parameters associated with AS configuration is provided herein.

[0135] In some examples, the WTRU 510 may determine the AS configuration for the SL bearer to be established based on various parameters / information, such as CBR measurements; results of sensing performed over a configurable period of time before sending the link establishment request; admission control results determined at the WTRU 510 based on the QoS of the requested bearer or based on the determined QoS of the signaling-only connection; and / or measurements of transmissions from the WTRU 520 (e.g., RSRP), assuming that the discovery process is initiated before the link establishment request 520. Alternatively, such measurements may be made after the link is established and may be used to update parameters or send a failure indication in the link establishment confirmation message 550.

[0136] The WTRU 510 may transmit the reference signal together with (eg, within a message, such as at the PHY layer) the link setup request message 530. Alternatively, the WTRU 510 may start repeated periodic transmissions of the reference signal after transmitting the link setup request message 530.

[0137] A link establishment request, such as link establishment request message 530, may be sent using a broadcast L2 destination ID. In this case, the receiving WTRU (e.g., WTRU 520) may determine whether it is the intended recipient of the link establishment request by decoding the L2 address included in the link establishment request RRC message. Alternatively, the link establishment request may be sent using the source ID of WTRU2 as the destination ID of the message in the MAC header and / or sidelink control information (SCI). For example, in the case of a multicast link establishment, the link establishment request RRC message may contain a list of L2 source IDs of the WTRUs associated with the multicast link. The MAC header and / or SCI may contain a broadcast ID associated with the service, or may contain a dedicated broadcast L2 ID associated with the RRC signaling.

[0138] After receiving the link setup request message 530 (e.g., based on receiving the message 530), the WTRU 520 may perform admission control using measurements at the WTRU 520. The WTRU 520 may also perform admission control using measurements at the WTRU 510, such as the measurements provided in the link setup request message 530. If the admission control is unsuccessful, the WTRU 520 may perform a QoS renegotiation procedure as discussed herein. In the case of admission control or QoS renegotiation, the WTRU 520 may transmit a link setup response message 540 to the WTRU 510. The link setup response message 540 may include any or all of an acknowledgement or rejection of the link; an indication of success or failure to apply the configuration suggested by the WTRU 510; an alternative suggested AS configuration; an alternative suggested QoS parameters for the link; a response message embedded in an RRC message (e.g., using NAS or PC5 protocol); and / or capability information about the WTRU 520.

[0139] In some examples, if the WTRU 520 does not support the AS configuration proposed in the link establishment message 530, or the AS configuration does not ensure that QoS is met, an alternative suggested AS configuration may be included in the link establishment response message 540. In another example, if the proposed configuration is supported, the WTRU 520 may still propose an alternative configuration (e.g., to support better QoS, which may be requested by higher layers during the establishment process). If the WTRU 510 rejects the alternative configuration, the initial proposed configuration may be used instead.

[0140] In some examples, in the event that the WTRU 520 fails admission control and notifies its upper layers, one or more alternative suggested QoS parameters for the link may be included in the link setup response message 540. In response, the upper layers may provide one or more new QoS parameters, which may be provided to the WTRU 510 in the link setup response message 540 (e.g., in an RRC message, or as part of a NAS / PC5 message embedded in an RRC message).

[0141] In some examples, the WTRU 520 may perform its own admission control, as measured at the location of the WTRU 520. The WTRU 520 may also or alternatively make a reachability determination based on a reference signal transmitted by the WTRU 510. Without loss of generality, the link setup response message 540 may also include the content described in the link setup request message 530.

[0142] After receiving the link setup response message 540 (e.g., based on receiving the message 540), the WTRU 510 may transmit a link setup confirmation message 550 to the WTRU 520, which confirms or rejects the AS configuration change proposed in the link setup response 540. At or before the transmission of the link setup confirmation message 550, the WTRU 510 may notify its upper layers of the successful establishment of the unicast link requested in the link setup request message 530. If the link establishment is successful, the link setup confirmation message 550 may include the AS layer configuration of the unicast and / or multicast link. After receiving the link setup confirmation message 550, the WTRU 520 may notify its upper layers of the successful establishment of the unicast link between the WTRU 510 and the WTRU 520. Without loss of generality, the link setup confirmation message 550 may also contain the content described in the link setup request message 530.

[0143] The various messages described above may include a combination of upper layer messages and RRC messages. For example, each message may be an upper layer message including a lower layer portion (e.g., a message sent between NAS, application, and / or V2X layer entries and not interpreted or decoded by the lower layer). In another example, one or more messages may be upper layer messages, and one or more messages may be lower layer messages.

[0144] In some examples, the WTRU 510 may transmit a link establishment request to the WTRU 520 using a PC5-S (i.e., upper layer) message (e.g., as a link establishment request 530). The WTRU 520 may receive the message and trigger the lower layers (e.g., the AS layer) to start an admission control procedure, as well as trigger an RRC message to send a link establishment response message 540. In response to the link establishment response message 540, the WTRU 510 RRC may perform the admission control procedure and transmit a link establishment confirmation message 550 as an RRC message. After a successful admission control procedure at each of the WTRU 510 and the WTRU 520, and / or after receiving the corresponding RRC messages at the WTRU 510 and the WTRU 520, the WTRU's RRC may notify the upper layers of the successful AS-link layer establishment, after which the upper layers may initiate a security establishment procedure (e.g., similar to the authentication and security establishment based on LTE PC5). If the upper layer authentication process is successful, the upper layer may inform the lower layer of the successful link establishment at the upper layer, and may provide the lower layer with security keys for use in messages sent by the AS over the secure link.

[0145] The SLRB configuration may include L1 and / or L2 configuration and / or configuration for flow to bearer mapping. The L1 and / or L2 configuration may include, but is not limited to, HARQ configuration; BWP configuration; the number of carriers and / or specific carriers that can be used for unicast and / or multicast links; LCH / LCG configuration; RS resource configuration; configuration of resource pools or resource patterns / signatures that can be used by WTRUs communicating on the unicast and / or multicast links; feedback configuration, such as CQI reporting configuration, associated transmit power, etc.; monitoring configuration, such as rules for determining link failures and / or failures to maintain QoS as described herein (e.g., representative sensing configurations or conditions for failure sensing); and / or preemption resource configurations.

[0146] In some examples, the WTRU may determine whether to perform admission control during and / or after link and / or SLRB establishment, or whether admission control is performed by another WTRU or multiple WTRUs in a unicast and / or multicast link. The determination may be made by the peer WTRU during a unicast and / or multicast link. Alternatively, the initiating WTRU may make the determination and may signal the determination to the peer WTRU to indicate that the initiating WTRU will perform admission control. This decision may be based on an indication from an upper layer; based on a NW configuration or pre-configuration; and / or based on a received power of a message (e.g., a discovery message or a link establishment message) received from the other WTRU. In some cases where the decision is based on upper layer indications, the upper layers of the initiating WTRU may determine whether admission control is to be performed by the peer WTRU and may signal the result of this determination explicitly in inter-layer signaling, may signal the result of this determination implicitly (e.g., through the inclusion and / or size of a PDU to be transmitted by the initiating WTRU to the peer WTRU as part of link establishment), or the peer WTRU may determine the need for admission control based on the presence and / or size of the PDU in the AS layer message.

[0147] A WTRU that determines that admission control is to be performed at a peer WTRU may also include information associated with admission control in an RRC message related to link establishment and / or AS layer reconfiguration. Such information may include QoS information (e.g., VQI); rules and / or configuration information associated with admission control; and / or upper layer information (e.g., user information, application layer information, QoS, etc.), which may be in the form of a PDU provided by an upper layer during upper layer-initiated link establishment.

[0148] The WTRU may remain in the admission control enabled state determined during link establishment (i.e., whether the WTRU performs admission control) for the duration of the link. Alternatively, the WTRU may change its admission control enabled state (e.g., the WTRU may assume that it will perform admission control) upon a trigger occurring. Example triggers include situations where the WTRU speed increases beyond a threshold; where the received power of messages from other WTRUs or WTRUs drops below a threshold, and / or where the distance between WTRUs in a link exceeds a threshold, where such distance may be calculated based on the receipt of geographic information transmitted by a peer WTRU(s) associated with the unicast link (e.g., an Area ID transmission in an SCI, or a dedicated RRC message for exchanging geolocation information between two WTRUs).

[0149] Some examples include configuration negotiation between WTRUs. Figure 5is a message sequence diagram illustrating an example AS layer side link establishment process between WTRUs. In some examples, the AS layer configuration may be selected to meet the required link QoS and not exceed the AS layer capabilities of either WTRU. This negotiation may be performed as part of the request / response / confirmation (3-step) signaling process described above, as shown in reference to Figure 5 500 as illustrated in the process 500 shown and described. In some examples, the WTRU that initiates the link establishment by upper layers may perform the configuration selection. In some examples, the WTRU that receives the connection establishment request message from the WTRU whose upper layers initiate the link establishment may perform the configuration selection. Alternatively, both WTRUs may be associated with the configuration selection (e.g., the initiating WTRU makes the initial selection and the peer WTRU makes the alternate selection).

[0150] The WTRU may select one or more AS layer configurations based on the QoS of the link to be established, wherein the unicast and / or multicast link will be established through the AS layer configuration; based on the capabilities of one or more of the WTRUs; based on measurements of the current side link resource usage measured by the WTRU; and / or based on the exchange of the aforementioned information and / or preferred configurations between the WTRU(s) associated with the link establishment.

[0151] In some cases where the WTRU selects an AS layer configuration based on the QoS of the link to be established, for example, the link may be associated with a VQI provided by upper layers. Such a VQI may also be associated with one or more AS layer configurations (e.g., by configuration or pre-configuration). Which AS layer configuration or configurations to use for each VQI may further depend on the CBR, CR, or similar measurement of channel utilization at the WTRU; the number of carriers supported for unicast links (e.g., where the number of carriers supported may depend on the capabilities of either WTRU, or may depend on the carriers configured for the service to which the unicast and / or multicast links are to be established); the BWP (e.g., the size of the current SL BWP); and / or allowed resources (e.g., one or more resource pools configured or used by the WTRU for unicast link establishment).

[0152] In some cases where the WTRU selects an AS layer configuration based on one or more WTRU capabilities, for example, the WTRU may be restricted to using a subset of the AS configuration, or the WTRU may be restricted to specific elements of the AS configuration if any WTRU associated with the link establishment does support the configuration or configuration element. This may be determined at link establishment time (e.g., based on the number of carriers at link establishment, resource selection mode, configuration of reference signal (RS) location / mode / power, etc.).

[0153] In some cases where the WTRU selects an AS layer configuration based on current measured resource usage, for example, the WTRU may select from one of a number of AS layer configurations based on measurements of current sidelink resource usage, for example to avoid conflicts with currently used resources.

[0154] Some examples provide different options for AS configuration selection during link establishment between an initiating WTRU (e.g., a WTRU that receives an indication from an upper layer to initiate connection establishment) and a peer WTRU (e.g., a WTRU that receives an AS layer or upper layer connection establishment message from the initiating WTRU via a SL).

[0155] In some examples, the initiating WTRU may determine the AS configuration to be used based on QoS requirements (e.g., VQI) received from upper layers or from the network. The determination may be based on a mapping of a network-provided configuration or a preconfigured (e.g., stored in the WTRU) VQI to an AS configuration, the WTRU's AS layer capabilities, and the selection of specific resources configured to minimize and / or avoid collisions, conflicts, and / or interference with existing unicast links (e.g., avoiding RS modes already used by other WTRUs or links, preempting resources, etc.). The determination may also be made as part of an admission control process, such as the examples discussed herein. After the WTRU selects an AS configuration, the WTRU may send the selected AS configuration to a peer WTRU using AS layer signaling. The signaling may be included in link establishment signaling. The peer WTRU may receive the selected AS configuration and may accept the configuration or may select an alternative configuration based on criteria similar to the above selection criteria. The peer WTRU may decide to select an alternative configuration, for example, because the initially selected configuration cannot be met given the capabilities of the peer WTRU to meet QoS (e.g., number of SL carriers, etc.), based on measurements taken at the location of the peer WTRU. An indication of an alternative configuration or acceptance of the initial configuration may be sent in the link establishment response. If the WTRU receives a link establishment response with an alternative configuration, the WTRU may determine whether to accept the configuration and send a link establishment confirm message to the peer WTRU, or reject the configuration and send a link establishment reject message to the peer WTRU. In either case, either or both WTRUs may notify upper layers of the outcome.

[0156] In some examples, the initiating WTRU may determine a set of AS layer configurations using selection criteria similar to the above scenario and may send a set of selected AS layer configurations (e.g., configurations or indications of which configurations) to the peer WTRU. The peer WTRU may select an AS layer configuration from the provided list and may transmit an indication of the selection in a link establishment response, or may transmit a failure indication if none of the selected configurations allows the peer WTRU to meet the required QoS at the peer WTRU's location or none of the selected configurations matches the capabilities of the WTRU's peer WTRU (e.g., support for different features, parameter settings at the AS layer, such as which HARQ parameters are supported, power control parameters, etc.).

[0157] In some examples, the initiating WTRU may determine the AS layer configuration using selection criteria as described above and herein, and may send the selected AS layer configuration or an indication of the selected AS layer configuration to the peer WTRU. The peer WTRU may determine whether the selected AS layer configuration meets the QoS requirements (e.g., based on measurements and / or admission control at the peer WTRU location) and / or WTRU capability requirements provided by the upper layers. If the AS layer configuration meets the QoS and / or capability requirements at the peer WTRU, the peer WTRU may send a success indication in a response message. If the AS layer does not meet the QoS requirements and / or does not support the required capabilities, the peer WTRU may provide its own capability, QoS, and / or admission control related measurements to the initiating WTRU in the response message. After receiving such measurements and / or capabilities, the initiating WTRU may reselect an AS layer configuration based on the measurements and / or capabilities that meets the QoS and / or supports the capabilities required at both WTRUs, and may provide the new AS layer configuration to the peer WTRU in a link establishment confirmation message. Depending on whether the appropriate configuration can be selected, either WTRU (or both WTRUs) may notify upper layers of the success or failure of its link establishment procedure.

[0158] In some examples, the initiating WTRU may send its capability and / or QoS related measurements to the peer WTRU. The peer WTRU may perform AS layer configuration selection based on its own capability related and / or QoS related measurements and / or based on capability related and / or QoS related measurements received from the initiating WTRU. The peer WTRU may send the selected AS layer configuration to the initiating WTRU in a link setup response message. The initiating WTRU may accept or reject the selected configuration and may indicate the acceptance or rejection in a link setup confirmation.

[0159] In the above examples, QoS-related measurements may include any measurements described herein, including, for example, measurements used for admission control as further described herein.

[0160] In some examples, a WTRU may determine whether to transmit its capability information to another WTRU based on whether it has transmitted its capability information in the past (e.g., during link establishment signaling). For example, a WTRU may determine to include its capability information in AS layer signaling based on whether it has transmitted its capability information to the same WTRU in the past (e.g., where the WTRU may be identified by its L2 source ID, NW control ID (e.g., I-RNTI, S-TMSI, C-RNTI), or a combination), based on whether it has transmitted its capability information to the same WTRU in the past within a predetermined time period; and / or based on whether its capabilities have changed since the last transmission of its capability information to the same WTRU. When performing a link establishment to a WTRU to which the WTRU previously transmitted its capabilities (e.g., assuming that the capabilities have not changed).

[0161] The WTRU may be configured to store capability information of another WTRU after a unicast link with the WTRU is terminated. The WTRU may receive such capability information during sidelink link establishment. The WTRU may be configured to perform selection of appropriate AS layer configuration or link establishment based on the stored capability information. If the link establishment signaling from another WTRU does not contain its capability information, the WTRU may determine that it should use the stored capability information.

[0162] The WTRU may be configured to delete or clear any stored capability information for another WTRU based on one or more triggers, such as expiration of a timer; an indication from upper layers; receipt of new capability information for the same WTRU; and / or movement between different coverage scenarios, such as between in-coverage and out-of-coverage, or between coverage of different gNBs and / or PLMNs and / or RATs.

[0163] Some examples include updating the AS layer configuration. In some examples, a WTRU associated with a unicast and / or multicast link may initiate an AS layer reconfiguration of a particular unicast and / or multicast link. For example, the WTRU may initiate a reconfiguration of one or more AS layer parameters associated with the link based on one or more triggers, such as a link monitoring failure; a change in the CBR measured at the WTRU; receiving preemption of a unicast and / or multicast link; an indication from an upper layer; and / or determining that the WTRU has exceeded its radio capabilities.

[0164] In some cases, where the trigger includes a link monitoring failure, in some examples, the WTRU may determine that the required QoS for the link is no longer met and may initiate an AS layer configuration update process based on this determination; in another example, after the link monitoring failure, the WTRU may determine that an alternative AS layer configuration that meets the required QoS can be selected (e.g., the WTRU may determine whether a different configuration that meets the QoS is available). In some examples, after the link monitoring failure, the WTRU may negotiate a new or alternative QoS with upper layers and may perform AS layer reconfiguration to meet the new QoS for unicast and / or multicast links.

[0165] In some cases, where the trigger includes a change in the CBR measured at the WTRU, in some examples, the WTRU may be allowed, configured, or preconfigured to use a specific AS layer configuration for a specific range of CBR, in which case a change in the CBR to a value outside of that configured range may trigger reselection of the AS layer configuration.

[0166] In some cases, where the trigger includes receiving a preemption of a unicast and / or multicast link, in some examples, the WTRU may receive a preemption of the unicast and / or multicast link that provides further information about conflicting static resources (e.g., via a reference signal, feedback channel, etc.) or about constraints on utilized resources (e.g., resource pool, mode, amount, etc.). The WTRU may determine to perform an AS layer reconfiguration of the unicast link to facilitate continued operation with acceptable or suboptimal QoS while avoiding the conflict indicated in the preemption signal.

[0167] In some cases where the trigger includes an indication from upper layers, in some examples, the WTRU may receive an indication from upper layers to modify the QoS requirements (e.g., VQI) associated with a particular unicast and / or multicast link and / or SLRB. Such an indication may include adding a new QoS flow to be mapped to the same unicast and / or multicast link and / or SLRB.

[0168] The new AS layer configuration may be determined following a negotiation process similar to that described herein for initial link establishment.

[0169] In some examples, a WTRU initiating an AS layer reconfiguration may transmit a reconfiguration request message over a sidelink. The reconfiguration request message may include one or more selected AS layer configurations for a peer WTRU (e.g., configurations or indications of such configurations); may include new and / or updated capability information for the peer WTRU; and / or may include QoS-based measurements for the peer WTRU. The peer WTRU may transmit a reconfiguration response message to the initiating WTRU. The reconfiguration response message may include one or more selected or alternative AS layer configurations for the peer WTRU; may include new and / or updated capability information for the initiating WTRU; may include QoS-based measurements for the initiating WTRU; and / or may include an indication of acceptance or failure of the selected AS layer configuration to the peer WTRU. In response, the initiating WTRU may transmit a reconfiguration confirmation message. The reconfiguration confirmation message may confirm or indicate a failure of the AS layer reconfiguration process; and / or may include a selected or alternative AS layer configuration to be used (e.g., a configuration or indication of such a configuration). In some cases where the AS layer reconfiguration process fails, the WTRU may perform actions related to releasing unicast and / or multicast links or SLRBs, as described herein.

[0170] A successful link establishment at a WTRU may be considered complete at any time, which may depend on whether the WTRU in question is an initiating WTRU or a peer WTRU. For example, a successful link establishment may occur upon transmission of a link establishment confirmation message, or upon transmission of the last RRC message associated with an establishment / reconfiguration RRC procedure; upon receipt of a link establishment confirmation message, or upon receipt of the last RRC message associated with an establishment / reconfiguration RRC procedure; receiving an acknowledgement of the link establishment confirmation message, or receiving an acknowledgement of the last RRC message associated with the establishment / reconfiguration RRC procedure; transmission of a successful link establishment response message (e.g., a response or a reconfiguration response); receiving a successful response message (an establishment response or a reconfiguration response); and / or receiving an acknowledgement of a successful link establishment response message (an establishment response or a reconfiguration response).

[0171] A WTRU (e.g., initiating or peer) may perform any or a combination of actions upon (e.g., immediately upon or after) successful establishment and / or reconfiguration of a unicast and / or multicast link or SLRB, or may perform actions at different times during the link establishment process. Such actions may include, for example, notifying an upper layer of link establishment completion at the AS layer; indicating to the upper layer to initiate upper layer authentication and security association; initiating security information exchange at the AS layer (which may include security information provided by the upper layer and transparently carried in an AS layer message); starting or restarting transmission of RS based on AS layer configuration; starting or restarting reception of RS and / or transmission of SL CQI based on the AS layer configuration; initiating transmission of UMUS, for example, as described herein; initiating, for example, transmission of resource reservation signals for any resource (e.g., via SCI); initiating a resource selection or reselection process (e.g., taking into account newly established logical channels associated with a unicast link or SLRB and / or service requirements of flows associated with the SLRB); and / or initiating transmission of a group-based resource reservation process.

[0172] Some examples include actions related to releasing a unicast and / or multicast link or SLRB. For example, the WTRU may perform one or more of various actions during the release of a unicast and / or multicast link or SLRB. Release all unicast resources associated with the unicast link or SLRB, such as dedicated channels (e.g., dedicated feedback channels), resource pools, reference signal resources, preempted resources, and any or all other resources that may be part of the AS layer configuration dedicated to the unicast and / or multicast link; stop the transmission and / or reception of any RS, RLM signals, or similar signals associated only with the unicast and / or multicast link or SLRB being released; cancel any ongoing resource selection process associated with the unicast link and / or SLRB being released; trigger an SL resource reselection process, for example, taking into account the current data in the SL buffer without taking into account the SL resource reselection process. RB; transmit the remaining data in the buffer associated with the SLRB using the SL broadcast mechanism (e.g., changing the L2 destination address to the broadcast destination address associated with the service, instead of the L2 source address of the destination WTRU); triggering the immediate broadcast of a UMUS message or a UMUS cancel message to indicate the release of resources associated with the unicast link and / or SLRB; notifying the upper layer of the release (e.g., in some cases where the release is initiated by the lower layer, such as preemption); and / or, transmitting an RRC release message or an RRC failure message to one or more other WTRUs associated with the unicast and / or multicast link or SLRB.

[0173] In some cases where the action includes transmitting an RRC release message or an RRC failure message to one or more other WTRUs associated with a unicast and / or multicast link or SLRB, if the upper layer notifies the WTRU of the release of the SLRB, the WTRU may transmit a side link release message, and the WTRU may maintain the link (e.g., resources, etc.) until it receives confirmation of the release message from the peer WTRU.

[0174] In some cases where the action includes transmitting an RRC release message or an RRC failure message to one or more other WTRUs associated with the unicast and / or multicast link or SLRB, if the release is initiated by a failure of the AS reconfiguration process, the WTRU may transmit a release message (i.e., if the reconfiguration fails at the initiating WTRU) or may transmit a rejection or failure response to the request RRC message (i.e., if the reconfiguration fails at the WTRU receiving the reconfiguration request message or reconfiguration response message).

[0175] In some examples, the WTRU may perform actions related to the release of a unicast and / or multicast link or SLRB as a result of one or more triggers. Such triggers may include an explicit indication from an upper layer or AS layer to release a stream, stream set, unicast and / or multicast link, or SLRB (e.g., an upper layer may indicate the release of a stream or stream set and there are no remaining streams that can be carried by the SLRB, in which case the WTRU may initiate actions related to the release of the SLRB); a failed AS layer link monitoring process, which may be a failed AS layer link monitoring process if followed by a failed QoS renegotiation process and / or a failed AS layer reconfiguration process; receipt of a preemption indication for a particular stream or SLRB from another WTRU; receipt of an SL release message or rejection message; and / or a failed AS layer reconfiguration process.

[0176] In some cases where triggering includes a failed AS layer reconfiguration procedure, if the WTRU detects a QoS monitoring failure and cannot renegotiate new one or more QoS parameters with the upper layer and / or cannot determine a new AS layer configuration that satisfies one or more QoS parameters currently configured for the SLRB, the WTRU may initiate a failed AS layer reconfiguration procedure. In some cases where triggering includes a failed AS layer reconfiguration procedure, if the WTRU receives a reconfiguration request message over the sidelink and cannot apply the proposed AS layer configuration and / or cannot renegotiate one or more new QoS parameters with the upper layer and / or cannot determine a new AS layer configuration that satisfies one or more currently configured QoS parameters for the SLRB, the WTRU may initiate a failed AS layer reconfiguration procedure. In some cases where triggering includes a failed AS layer reconfiguration procedure, if the WTRU receives an AS layer reconfiguration response message with a new AS layer configuration and cannot apply the proposed AS layer configuration and / or cannot renegotiate one or more new QoS parameters with the upper layer and / or cannot determine a new AS layer configuration that satisfies one or more QoS parameters currently configured for the SLRB, the WTRU may initiate a failed AS layer reconfiguration procedure.

[0177] Some examples include a SL release message. For example, the WTRU may perform transmission of a SL release message after one or more triggers, such as the example triggers described above. In some examples, the SL release message may be an RRC message defined for this purpose. In some examples, the SL release message may be an upper layer message (e.g., a NAS or PC5-C message) included in a general RRC message (e.g., a transparent container) or a SL data message. The SL release message may include information about the QoS flow and / or the SL bearer index of the flow or SLRB to be released; the reason for the release; one or more L2 IDs of one or more WTRUs are released from the link (e.g., in the case of a multicast link, the SL release message may only release a subset of the WTRUs); a time scale associated with the release (e.g., the amount of time that one or more WTRUs cannot initiate a new link establishment, and / or the amount of time after which one or more WTRUs should re-establish the same link with similar QoS); and / or an indication to continue a unicast and / or multicast link on a different carrier or set of carriers and a specific carrier.

[0178] If the SL release message is sent using RRC signaling, the WTRU may notify the upper layers of the release and may initiate actions associated with the release of the SLRB. If the SL release message is sent using an upper layer message (e.g., embedded in an RRC message or SL data), the WTRU AS may receive a release indication from the upper layer after the upper layer processes the release.

[0179] Some examples include upper layer SL bearer establishment or bearer reconfiguration. For example, the WTRU may initiate a new bearer establishment or a reconfiguration of an existing bearer based on one or more triggers. Such triggers may include an upper layer indication of the initiation of a new QoS flow, where the WTRU decides to map the flow to an existing bearer or a new bearer; an upper layer indication of the termination of a flow, where the WTRU may perform a reconfiguration of the bearer; and / or an upper layer indication of a change in the source and / or destination L2 ID or the ID of an existing link, where the WTRU may associate a new L2 ID with an existing bearer. The WTRU may establish a new bearer using the same or similar signaling as above and herein. In some examples, the WTRU may establish a new bearer using the same or similar signaling as above and herein without the steps associated with reachability determination.

[0180] Some examples include gNB controlled link establishment signaling. In some examples of gNB controlled link establishment, the signaling may be similar to the WTRU autonomous case, but with some differences.

[0181] Figure 6 is a message sequence diagram illustrating an example process 600 for a gNB to control link establishment. The example process 600 includes the WTRU 610 transmitting a link setup configuration request message 640 to the gNB 630, which responds with a link setup configuration response message 650. After the WTRU 610 receives the link setup configuration response message 650, gNB configuration of reference signal transmission and reception is performed in step 660. After step 660, the WTRU 610 transmits a link setup request message 670 to the WTRU 620, which responds with a link setup response message 680. After the WTRU 610 receives the link setup response message 680, in step 690, SL transmission based on the established SL bearers begins between the WTRU 610 and the WTRU 620.

[0182] The WTRU 610 may determine the AS layer configuration to be sent in the link setup request message 670 using signaling 630 with the gNB 630 (e.g., in the link setup configuration request message 640, and / or in the link setup configuration response message 650). The WTRU 610 may send the VQI for the link and / or bearer to the gNB 630 for use by the gNB 630 in determining the configuration. The WTRU 610 may also send measurements performed by the WTRU 610 on the discovery response transmitted by the WTRU 620 during previous discovery signaling.

[0183] In another example, the configuration of the reference signal for reachability detection may be under the control of the gNB. This is true regardless of whether the reachability detection is performed before or after the Link Setup Configuration Request message 640.

[0184] Some examples may include signaling for establishing a multicast link. Establishment of a multicast link may require knowledge of some or all connections between multiple / all pairs of WTRUs.

[0185] In some examples, the source WTRU may reserve resources for multiple WTRU transmissions / responses. For example, the WTRU may broadcast a request message that schedules timing and / or reserves resources for response messages from multiple WTRUs. The request message may be a link establishment configuration request message transmitted by the WTRU. Such a message may include the information described herein (e.g., regarding link establishment in a unicast case). The request message may also include other information, such as an indication of reserved time, frequency, and / or beam resources for one or more response messages; an indication of which WTRUs should respond to the request message; an indication of the order of transmission of the response messages by the WTRUs; contention resolution rules for resolving contention between the WTRUs for the transmission of the response messages; and / or a request for a connectivity report, for example, as further discussed herein.

[0186] The source WTRU may perform resource reservation for multiple response messages. For example, the source WTRU may select multiple different time and / or frequency resources to be used by other WTRUs to respond to the request message. The source WTRU may reserve these resources by transmitting one or more reservation signals to the responding WTRUs. Such one or more reservation signals may be sent via a physical sidelink control channel (PSCCH) (e.g., as an SCI) or may be sent via an upper layer (e.g., MAC or RRC). The WTRU may transmit a reservation for a response message and a reservation or indication of a PSSCH transmission of a request message. For example, the WTRU may perform resource selection for an initial transmission (e.g., for transmitting a request message) and for N response message transmissions, after which the WTRU may transmit an SCI indicating a time, frequency, and / or beam resource for the request message; indicating decoding parameters (e.g., MCS) for a PSSCH transmission containing the request message; and / or indicating N (potentially different) time, frequency, and / or beam resources for use by N different WTRUs to send response messages along with their SCIs.

[0187] The source WTRU may also transmit the transmission parameters required for the response message to the responding WTRU. In this case, the responding WTRU may transmit a limited size SCI including only the reservation signal, or may not transmit an SCI at all.

[0188] A WTRU receiving a message providing resources for a response message may determine the specific timing of its own response message. The timing determination may be based on an explicit order of responding WTRUs in the request message (e.g., using a specific resource from a plurality of reserved resources); an implicit ordering based on WTRU IDs (e.g., source L2 ID, C-RNTI, group ID, or the like); and / or an implicit ordering based on information from the application layer and / or NAS layer. For example, the receiving WTRU may determine from upper layers whether it should respond to the request message and, if so, which response resource to use based on the ordering provided by the application layer.

[0189] In some examples, the responding WTRU may monitor and / or measure response messages from other responding WTRUs. A WTRU that receives a request message soliciting a response may also monitor response messages from other WTRUs based on resources scheduled by the request message. The WTRU may perform a measurement of the quality of the response messages transmitted by each WTRU. For example, the WTRU may measure the quality of the response messages based on a reference signal transmitted by each WTRU within the response resources.

[0190] The WTRU may maintain a list of quality measurements for each responding WTRU, and the WTRU may transmit a "connection report" that includes a list of WTRU responses that the WTRU was able to decode, for example, together with the WTRU ID and the measured quality (e.g., RSRP, RSRQ, SINR, etc.); and / or the measured quality of the source WTRU (e.g., based on the transmitted request message and / or reference signal).

[0191] In some examples, the source WTRU may determine the members of the multicast group based on a received connection report. For example, the WTRU receiving the connection report may determine the WTRUs that are to be included in the multicast group, for example, based on information such as whether the measurement between the two WTRUs is above a certain threshold; and / or a requirement that one WTRU needs to transmit to another WTRU (e.g., from an application layer). The WTRU receiving the connection report may indicate to the upper layers which WTRUs are to be considered included in the multicast group. The WTRU receiving the connection report may send an acknowledgment message to the other WTRUs, which may include an L2 ID to be used as the destination address for group communications. After receiving the acknowledgment message, if the WTRU's own source WTRU ID is included in the acknowledgment message, the WTRU may notify the upper layers that it has joined the multicast group (e.g., using a specific L2 address).

[0192] In some examples, the decision whether to establish a multicast group may be based on the number of WTRUs in the potential group. For example, the WTRU may decide whether to initiate and / or maintain AS layer multicast communications for the group based on the number of WTRUs in the group (e.g., following a request from an upper layer, or upon receipt of a packet with a specific L2 destination ID). The WTRU may be provided with the number of WTRUs in the group directly from the upper layers. Alternatively, the WTRU may determine the number of WTRUs in the group based on the number of responses received from other WTRUs during link establishment signaling. The WTRU may be configured or pre-configured with a maximum number of WTRUs for which the WTRU may establish an AS layer multicast group. The maximum number of WTRUs may depend on the measured CBR (e.g., when the measured CBR is lower, the WTRU may consider a larger allowed multicast group); the measured path loss or relative path loss between any two WTRUs (e.g., the WTRU may determine the maximum number of WTRUs based on the maximum measured path loss between the two WTRUs, or the WTRU may determine that AS layer multicast may be initiated or maintained when the maximum path loss between any WTRUs in the group is below a threshold); and / or the expected QoS of the multicast link (e.g., any of the thresholds or criteria discussed above may be further modified based on the expected QoS of the link, e.g., where the WTRU may be configured with different thresholds associated with different VQIs to be supported on the multicast link).

[0193] Figure 7 700 is a message sequence diagram illustrating an example multicast link establishment procedure 700. The multicast link establishment procedure 700 includes a link establishment request 740 broadcasted by the WTRU 710 to the WTRU 720 and the WTRU 730, a link establishment response message 750 broadcasted by the WTRU 730 to the WTRU 710 and the WTRU 720, and a link establishment response message 760 broadcasted by the WTRU 720 to the WTRU 710 and the WTRU 730. After the link establishment request and response, the WTRU 720 and the WTRU 730 transmit a connection report 770 and a connection report 780 to the WTRU 710, respectively. After receiving the connection report 770 and the connection report 780, the WTRU 710 broadcasts a link establishment confirmation message 790 to the WTRU 720 and the WTRU 730, after which multicast messaging may begin between the WTRU 710, the WTRU 720, and the WTRU 730 in step 795.

[0194] The Link Setup Request and Link Setup Response messages are broadcast messages in process 700. The Link Setup Ack is also a broadcast message and includes the WTRU IDs included in the group, and the destination address for future multicast messages.

[0195] In some examples, a WTRU may determine a grouping of L2 IDs associated with multiple unicast links between the same WTRUs. For example, a pair of WTRUs may establish multiple unicast links between each other (i.e., multiple unicast links between the same pair of WTRUs), where the L2 ID associated with each link (i.e., source and destination) used by each WTRU is different. In some cases, it may be beneficial for the access stratum (AS) (at each WTRU) to know that the unicast links are actually between the same pair of WTRUs.

[0196] In some examples, the WTRU determines the grouping or association between different L2 source IDs used by the same peer WTRU. For example, the WTRU may determine that different L2 source and / or destination IDs associated with a unicast link at the WTRU are actually associated with the same physical peer WTRU. If the unicast link transmission is associated with the same peer WTRU, the WTRU may group together multiple destination L2 IDs (i.e., source L2 IDs of the peer WTRU) used during transmission to different unicast links. If the unicast links are established with the same peer WTRU, the WTRU may group multiple source L2 IDs used during transmission into different unicast links. The WTRU may maintain a single context associated with multiple unicast links, which are grouped together using the method described below.

[0197] In some embodiments, the first WTRU in the potential group may learn, discover, or otherwise obtain knowledge of such associations between different L2 source IDs and / or between different L2 destination IDs through PC5-RRC signaling. Such PC5-RRC signaling may be associated with unicast link establishment (e.g., PC5 RRC signaling triggered during or after link establishment, such as an SL reconfiguration message). In some examples, the first WTRU may send an AS side link (SL) UE ID to the second WTRU during or after link establishment. In some examples, the WTRU may derive the ASSL UE ID based on a static or semi-static ID associated with the WTRU, such as an International Mobile Subscriber Identity (IMSI), a Temporary Mobile Subscriber Identity (TMSI), a Serving TMSI (S-TMSI), a Globally Unique Temporary UE Identity (GUTI), a Cell Radio Network Temporary Identity (C-RNTI), etc.; based on a randomly selected value; based on a value associated with its location and / or its selected resources; based on a value associated with its location and / or its selected resources; and / or based on a value associated with the encoding of the WTRU's PSCCH and / or PSSCH and / or PSFCH.

[0198] For example, in some cases where the WTRU derives the AS SL UE ID based on a static or semi-static ID associated with the WTRU, the WTRU may send its IMSI to the peer WTRU to inform the peer WTRU that the unicast link is associated with the same WTRU pair. Similarly, the peer WTRU may also send its IMSI to the WTRU to inform the WTRU that the unicast link is associated with the same WTRU pair. In some cases where the WTRU derives the AS SL UE ID based on a randomly selected value, the WTRU may randomly select a number or ID from a subset of values ​​and send the value or a value based on the value to the peer WTRU. In addition, if the WTRU does not have a unicast link established, the WTRU may select such a random value. For example, the WTRU may select a random value for the first unicast link it establishes, and the WTRU may subsequently send the same selected value (or a value based on the value) for subsequent RRC links established. In some examples, if the WTRU no longer has a unicast link established at the WTRU (for example, if the WTRU no longer has any kind of unicast link), the WTRU may delete the randomly selected value. In some cases where the WTRU derives the AS SL UE ID based on values ​​associated with its location and / or its selected resources, the WTRU may send its current geographic location upon link establishment, or send its current area ID to its peer WTRU upon link establishment. In some examples, the WTRU may send an index or information of a related resource selection process performed at a certain time (e.g., time, frequency, beam, etc.). For example, the WTRU may send an index of the last time-frequency resource reserved by the WTRU before the link is established. In some cases where the WTRU derives the AS SL UE ID based on values ​​associated with the encoding of the WTRU's PSCCH and / or PSSCH and / or PSFCH, the value may include values ​​such as scrambling code, RS pattern, etc.

[0199] In some examples, a second WTRU in a potential group may receive a L2 source ID of a peer WTRU in PC5 RRC signaling or from upper layers (e.g., obtained during upper layer signaling between WTRUs). Upon receiving such an ID, the WTRU may determine whether such an ID is associated with (or grouped with) another ID (i.e., for another unicast link) based on the AS SL UE ID received from the peer WTRU. For example, the WTRU may group the L2 IDs of two unicast links if the WTRU receives an AS SL UE ID that matches an AS SL UE ID received from a peer WTRU that is associated with another ongoing unicast link at the WTRU; if the WTRU receives an AS SL UE ID associated with a geographic location that matches the last known geographic location of the peer WTRU associated with another ongoing unicast link at the UE; and / or if the WTRU receives an AS SL UE ID that indicates time / frequency resources used by a peer WTRU with which the WTRU has established a unicast link.

[0200] This process for grouping L2 source IDs may be performed by either or both of the WTRUs. For example, a first WTRU may send its SL UE ID to a second WTRU during and / or after link establishment, and the second WTRU may determine whether to group the L2 ID for a unicast link with another L2 ID for the ongoing unicast link. Similarly, the second WTRU may send its own SL UE ID to the first WTRU (e.g., during and / or after the same link establishment process), and the first WTRU will perform a similar grouping determination.

[0201] In some examples, the WTRU may receive an indication from upper layers that the L2 ID of a peer WTRU (e.g., the L2 source ID of a peer WTRU to be used as a destination in its own transmissions) is associated with another L2 ID previously provided to the WTRU by upper layers in another link establishment. The WTRU may receive different information from upper layers at different times.

[0202] For example, at T1 (i.e., the time of the first link establishment procedure initiated by upper layers), the WTRU may receive from upper layers the L2 source ID (ID1) of the peer WTRU for a unicast link that has no association. Based on the knowledge of active unicast links, the WTRU may determine that it has only a single unicast link established with the peer WTRU. The WTRU may receive from upper layers ID1' as its own source ID for the unicast link, where ID1' may be further provided by upper layers.

[0203] In another example, at T2 (i.e., the time of the second link establishment procedure initiated by the upper layers), the WTRU may receive from the upper layers the L2 source ID (ID2) of the peer WTRU for the unicast link and an indication to associate it with another L2 ID (ID1). The WTRU may also receive from the upper layers ID2' as its source ID for the unicast link with ID2. Based on the received ID2, ID2', and the indication, the WTRU may group ID2 with ID1 and group its own ID2' with ID1'.

[0204] In some examples, the WTRU may use an on-demand SIB or dedicated signaling to obtain SLRB configuration for a specific PC5-5QI (PQI) and / or PC5 flow identifier (PFI). For example, the WTRU may request SLRB configuration associated with one or more PQI / PFIs through a request to the network (e.g., to the gNB). In idle and / or inactive mode, the WTRU may request SLRB configuration using an on-demand SIB request. The WTRU may attach the PQI / PFI or other QoS parameters (e.g., range, GBR, etc.) to the on-demand request. The WTRU may trigger an on-demand SIB request after initiating a flow that is not mapped to any SLRB, where the SLRB is part of the WTRU's SL configuration, and / or when the SL SIB does not broadcast the SLRB configuration associated with the flow. The WTRU may include in the request: the PQI / PFI associated with the flow; the range value associated with the flow; the GBR associated with the flow; an index to a table giving all QoS parameters or QoS profiles, where such table may be predefined or configured or preconfigured; and / or a list of its current SLRBs, which have been stored in its own configuration.

[0205] In some embodiments, a WTRU in connected mode may use dedicated signaling to use similar requests for SLRB configurations associated with one or more PQIs / PFIs. For example, the WTRU may send an RRC message (e.g., using UE Sidelink Information) after initiating a flow for which the WTRU does not have a mapping to the currently stored SLRB configuration.

[0206] In some examples, the WTRU's SLRB configuration and / or the mapping of flows to SLRBs may also or alternatively depend on measurements at the WTRU (e.g., CR, CBR, sensing results, CQI, etc.). For example, if the measured quantity matches a first condition or multiple conditions, the WTRU may use a first configuration for the SLRB (or for the flow), and if the measured quantity matches a second condition or multiple conditions, the WTRU may use a second configuration for the SLRB (or for the flow).

[0207] In some examples, the WTRU uses a default SLRB configuration during a request for an SLRB configuration associated with one or more PQI / PFIs. For example, the WTRU may use a default SLRB after initiation of a flow (i.e., mapping a new flow to the default SLRB), and the flow is not mapped to a SLRB in the SLRB configuration stored by the WTRU. The default configuration may be configured, preconfigured, or predefined. The default configuration may be configured by the network, such as by a gNB. The default configuration may be preconfigured by a V2X preconfiguration at the WTRU. The default configuration may be predefined in an appropriate specification. After the WTRU receives a new SLRB configuration for a flow, the WTRU may move the flow from the default SLRB configuration to the newly received SLRB configuration. Alternatively, if the WTRU receives an indication that a new flow should be mapped to an existing SLRB (e.g., a SLRB stored in its stored configuration), the WTRU may move the flow from the default SLRB configuration to the indicated, stored SLRB configuration.

[0208] In some examples, the WTRU receives an indication that it may use the SLRB configuration during the SLRB transition. For example, the WTRU may use the same SLRB configuration during transitions between idle / inactive and connected states. In some examples, the WTRU may also receive an indication from the NW, such as from the gNB (e.g., in a SIB or dedicated signaling), that the WTRU may do so.

[0209] Some examples include systems, methods, and devices for admission control of unicast and / or multicast on a side link. In some examples, the transmission mode decision may be based on QoS. For example, the WTRU may determine its transmission mode for a link to be established based on QoS attributes associated with the link. The WTRU may decide to establish a new link / radio bearer to address a unicast and / or multicast flow for a certain VQI, and may determine the transmission mode for packets on the link and / or bearer based on the VQI and QoS parameters derived from the VQI. The WTRU may select between NW controlled mode and WTRU autonomous mode based on the VQI. Alternatively, if the WTRU selects the WTRU autonomous mode, or the network allows the WTRU to use the WTRU autonomous mode, the WTRU may further select between resource selection modes based on the VQI. For example, the WTRU may determine whether to use fully autonomous resource selection; autonomous resource selection with assistance from another WTRU; configured or pre-configured authorization; and / or WTRU scheduling resources for the link. For example, the WTRU may be configured or pre-configured with a table of VQIs and allowed resource transmission / resource selection modes, where the WTRU may select a mode from the allowed modes for a particular VQI.

[0210] In some examples, a mode change is performed for admission control. For example, the WTRU may perform a mode change (e.g., from WTRU autonomous resource selection to network-based resource selection) for the purpose of admission control. In some examples, a WTRU operating in WTRU autonomous mode may receive a new flow or may decide to initiate a new sidelink bearer. In doing so, the WTRU may indicate this to the network and may implicitly change the operating mode to NW controlled mode at least during the admission control / link and / or bearer establishment phase. The WTRU may continue in NW controlled mode until the network instructs it to move back to WTRU autonomous mode.

[0211] In some examples, admission control is scheduled by the NW. For example, the WTRU may send a request to the network for sidelink unicast and / or multicast link establishment, or the WTRU may send a request to the network for establishment of unicast and / or multicast links and / or sidelink radio bearers. The WTRU may send such a request in response to an indication from an upper layer that a link should be established. The WTRU may send the request to the gNB via an RRC message or a MAC CE, and the request may include various information, such as a VQI or related one or more QoS parameters associated with one or more flows for which the bearer should be established; an identity of the one or more WTRUs associated with the unicast and / or multicast link; and / or a discovery result.

[0212] In some cases where the information includes a VQI or related QoS parameters or parameters associated with one or more flows for which a bearer should be established, the WTRU may be provided with a VQI for a given flow from the NAS layer and may initiate a link establishment request to the network including such a VQI. In some cases where the information includes identification of one or more WTRUs associated with a unicast and / or multicast link, the WTRU may include a source ID (e.g., L2ID) of the WTRU with which the link should be established. In some cases where the information includes discovery results, the WTRU may send any AS-related information associated with the discovery results, which may be associated with one or more WTRUs with which a unicast and / or multicast link is to be established. The discovery results may include measurements or quality of reference signal or discovery signal transmissions; information indicating supported WTRU capabilities; information indicating synchronization sources of the one or more WTRUs; information indicating the in-coverage or out-of-coverage status of the WTRU; and / or information indicating WTRU capabilities, such as resource selection capabilities, supported carriers, power levels, etc.

[0213] In some examples, the WTRU may send a unicast and / or multicast link establishment request to the network based on one or more triggers or conditions, such as where the WTRU receives a new QoS flow from an upper layer; the WTRU decides to create a new sidelink radio bearer; the WTRU determines that the new QoS flow or radio bearer requires network-controlled admission control; the WTRU receives a unicast and / or multicast establishment request from another WTRU; the WTRU receives a response to the unicast and / or multicast establishment request from another WTRU; and / or the WTRU is performing WTRU autonomous admission control and the new link and / or bearer establishment fails admission control based on the WTRU autonomous admission control mechanism.

[0214] In some examples, if the WTRU autonomous admission control fails, the WTRU may use network controlled admission control. For example, the WTRU may receive a new unicast and / or multicast flow from upper layers and may decide to initiate WTRU autonomous admission control (as described herein) for a new SL radio bearer for the flow. If the WTRU autonomous admission control fails, for example, due to the reasons described herein, the WTRU may initiate network controlled admission control, for example, by transmitting a unicast and / or multicast link establishment request to the network.

[0215] In some examples, the WTRU may receive an acknowledgment of successful admission control with resource and measurement configuration messages. For example, the WTRU may receive an acknowledgment of successful admission control to the network, and following the acknowledgment, the WTRU may initiate transmission of data associated with one or more flows mapped to the established link or bearer. The WTRU may also receive resource usage information with such an acknowledgment. The resource usage information may include an indication of a new resource pool or an existing resource pool; a periodic resource set; arbitration rules; a WTRU-specific or cell-specific link and / or radio bearer identity; and / or configuration of measurements to be reported to the network for link maintenance.

[0216] In some cases where the resource information includes an indication of a new resource pool or an existing resource pool, the resource pool may include a collection of time, frequency, and / or beam resources and may be used to transmit data associated with the established link and / or bearer. In some cases where the resource information includes a periodic resource set, the periodic resource set may include a new SPS configuration, a configuration of a grant (e.g., a type 1 or type 2 grant) to be used for data transmission associated with the established link and / or bearer, or an indication of an existing configuration to be used to transmit such data. In some cases where the resource information includes arbitration rules, the rules may include arbitration rules for use by a particular WTRU for resources shared between WTRUs (e.g., where such a WTRU may or may not be a WTRU associated with a unicast and / or multicast link). The arbitration rules may include a subset of times and / or frequencies that the WTRU may use over the total resource configuration; a timing relationship between transmissions and retransmissions for a link and / or bearer; an order or sequence of transmissions between multiple WTRUs in a multicast link; and / or a timing relationship between transmissions and HARQ feedback (e.g., transmissions on a sidelink or on an uplink).

[0217] In some cases, where the resource information includes a configuration of measurements to be reported to the network for link maintenance, the configuration may include: a configuration of reference signal transmission resources and a power to be transmitted by a WTRU associated with the link; a configuration of reference signal reception resources and an expected power to be measured by the WTRU and reported to the network; and / or a frequency (or periodicity) of sending such measurement reports by the WTRU based on measurements of reference signal reception.

[0218] The WTRU, in response to receiving such a configuration, may initiate measurements and reporting as configured by the network until the network releases the link and / or bearer via a bearer release message from the network.

[0219] In some examples, the WTRU may receive a measurement configuration for admission control. For example, the WTRU may receive a measurement configuration for reporting measurements on the sidelink during admission control / link establishment. The WTRU may receive a measurement configuration that may initiate measurements and reports that only last during the link establishment phase. For example, the WTRU may be configured with: one or more source L2 addresses associated with messages to which the WTRU should report measurements; one or more message types (e.g., a specific type of RRC message, such as a "direct communication request" message); and / or a set of sidelink resources associated with the transmission / reception of reference signals for measurements.

[0220] In some examples, a WTRU configured for measurement reporting may determine the RSRP of any message received from any specific L2 address configured in the measurement configuration, and potentially any RRC message type configured as part of the measurement configuration. In some examples, the WTRU may report the measurement to the network each time a message is received that meets the above criteria. In some examples, the WTRU may delete the configuration when the WTRU completes link establishment with the WTRU indicated in the source L2 ID (i.e., in the measurement configuration).

[0221] In some examples, the WTRU autonomously controls admission control. Some examples include WTRU autonomous admission control decisions. For example, during or before link establishment and / or bearer establishment, the WTRU associated with the link and / or bearer establishment may determine whether the link and / or bearer establishment is acceptable. As discussed herein, upper layers may initiate a unicast link establishment procedure. During this procedure, the AS layer of any WTRU may accept or reject the link and / or bearer establishment, for example, based on AS-related factors, which may be transparent to upper layers.

[0222] In some examples, the WTRU may determine whether to initiate and / or accept or reject a unicast / multicast link, or whether to grant a unicast / multicast side link radio bearer (SLRB) based on one or more criteria.

[0223] The criteria may include: network coverage of one or more WTRUs, for example, where the WTRU may accept or reject a unicast / multicast link or SLRB establishment based on whether the WTRU is within the coverage of a gNB or based on whether the WTRU is within the coverage of the same gNB as one or more other WTRUs to be associated with the unicast link; QoS requirements associated with the link, for example, where the WTRU may accept or reject a unicast / multicast link or SLRB establishment based on the QoS requirements of the link and / or bearer to be established; QoS requirements of other existing links and the ability to preempt such existing links; location, motion, or relative location and / or motion, for example, where the WTRU The U may accept or reject the establishment of a unicast / multicast link or SLRB based on the movement of the WTRU (e.g., speed, heading) and / or the location of the WTRU, possibly in combination with information about the movement of another WTRU or multiple WTRUs associated with the unicast / multicast link; and / or based on available resources (e.g., data and / or reference signals and / or feedback resources), for example, where the WTRU may accept or reject the establishment of a unicast / multicast link or SLRB based on a determination of available resources, potentially based on the available resources required for the unicast / multicast link or SLRB, and / or the WTRU may predict the resources required for the link or SLRB based on the QoS requirements of the link or SLRB.

[0224] Some examples include admission control based on network coverage. In some examples, for a link requiring a particular QoS, the WTRU may determine to reject the link and / or SLRB if the WTRU is out of coverage, and to accept the link and / or SLRB if the WTRU is within coverage. For example, a certain value of VQI, PPPP, PPPR, or similar QoS parameters associated with a link may be configured or preconfigured to require a Mode 1 resource allocation mode, or may require the WTRU to be within coverage so that it can fall back to Mode 1 under certain conditions. In some examples, a WTRU that receives a request for a link and / or SLRB may reject the request when out of coverage. In some examples, the WTRU may be configured with a threshold based on Uu RSRP (e.g., possibly for each VQI or QoS related parameter value), below which the WTRU will reject the link and / or SLRB.

[0225] In some examples, the WTRU may reject a link / SRLB for a given QoS if the gNB to which the WTRU is currently connected and / or camping is not related to a gNB or gNBs that other WTRUs may camp on. Such relatedness may include, for example, the same gNB, a gNB of an equivalent PLMN, a gNB that broadcasts system information that is part of the same validity area. Links and / or SLRBs may have one or more allowed relationships.

[0226] Some examples include admission control based on relative location. In some examples, the WTRU may determine whether to accept or reject a link and / or SLRB for a link that requires a specific QoS, such as a specific range requirement, or has an associated VQI, based on the distance between the WTRUs in combination with the range or QoS requirement. For example, the WTRU may be configured or pre-configured with a threshold distance for each VQI value. The WTRU may receive location information about one or more other WTRUs associated with a link and / or bearer (e.g., during link establishment signaling), and if the distance to the one or more other WTRUs or WTRUs is below a threshold distance associated with the VQI, the WTRU may accept the link and / or SLRB.

[0227] Some examples include admission control based on the availability of link maintenance related resources / channels. In some examples, the WTRU may determine whether to accept or reject a link and / or SLRB based on the availability of resources or channels required for unicast / multicast link maintenance. For example, each unicast / multicast link may be associated with a set of resources or channels used for transmission of RS (e.g., for measurement of CSI), transmission of CQI, transmission of preempted resources, or transmission for HARQ feedback. Such resources may be specifically associated with the transmission of such information for a given unicast link. For example, the WTRU may be configured with a set of resources for RS transmission associated with a unicast link, and the WTRU selects unused configurations of these RS transmissions based on sensing of other unicast transmissions and / or information provided by the network, for example, as further described herein. Alternatively, the WTRU may select unused configurations for these RS transmissions based on information in UMUS signals transmitted by other WTRUs. In some examples, if the WTRU determines that all available RS configurations are currently being used by other WTRUs / links, the WTRU may decide to reject the link and / or SLRB. Alternatively, (eg, as discussed herein) the WTRU may decide to preempt an existing unicast link between a different set of WTRUs to accept the currently requested link and / or SLRB.

[0228] Some examples include transmission of unicast and / or multicast availability signals to assist other WTRUs in performing admission control decisions in a shared resource pool (e.g., for determining or predicting resource usage / availability). For example, when a WTRU is associated with one or more unicast and / or multicast links, the WTRU may transmit a unicast and / or multicast availability signal (UMUS). In some examples, the WTRU may transmit such a signal for each unicast and / or multicast link currently established at the WTRU. Alternatively, if at least one link is established, the WTRU may transmit a single signal, where the usage signal may include information about all established links / SLRBs.

[0229] In some examples, a UMUS may be sent to facilitate the availability of resources on a side link (e.g., on a resource pool) without reserving resources in advance. For example, a UMUS for one or more links / SLRBs may indicate resources that a bearer / link may eventually need to use or reserve. In this case, the purpose of the UMUS may be to facilitate the reservation of resources when needed by a WTRU with specific QoS requirements, which resources will satisfy the QoS of the established unicast and / or multicast links. Alternatively, a UMUS signal may be sent to reserve specific resources or channels (e.g., HARQ feedback, RS transmission, CQI feedback, and / or preempted resources) for unicast / multicast transmissions specifically associated with the unicast link. For example, the UMUS may reserve specific resources or a specific number of resources on a PSSCH, PSCCH, a physical sidelink broadcast channel (PSBCH), a sidelink feedback channel, and the like.

[0230] In some examples, the WTRU may perform decoding of UMUS transmissions from other WTRUs to determine the number of active links / SLRBs and the resources they occupy. In some examples, the decoding may also determine the number of active links / SLRBs and the resources they occupy associated with a geographic area; a resource pool; a SL BWP; a carrier; a group of one or more WTRUs; and / or one or more associated QoS.

[0231] In some examples, the WTRU may decode and store the UMUS during regular SL reception. For example, the WTRU may determine average resource usage, actual reserved resources, and similar information based on the reception of past UMUS signals, such as information for the unicast links that may be associated as discussed above. The WTRU may assume that the content of the UMUS is valid within a configured or preconfigured or defined period. For example, the WTRU may start a timer upon receiving a UMUS signal associated with a single unicast and / or multicast identifier, an L2 source / destination address, or other identifiers carried by the UMUS. The WTRU may immediately consider the resources associated with the transmitted UMUS signal to be active upon receiving the UMUS signal. When the timer expires without receiving an updated UMUS signal associated with the same unicast and / or multicast identifier, an L2 source / destination address, or other identifier, the WTRU may consider the associated resources to be no longer active. In some examples, the effective time may be determined based on the movement of the WTRU, such as the speed, direction of travel, and other relevant information of the WTRU.

[0232] In some examples, the WTRU may cancel, delete, or ignore any past received UMUS signals and associated resource information based on one or more triggers. Such triggers may include, for example, whether the WTRU moves to a new geographic area, such as a new region; if the WTRU changes BWP, carrier, etc.; if the WTRU joins or leaves a queue; and / or whether the WTRU receives a UMUS signal or similar signal indicating the release and / or cancellation of a previous resource / reservation.

[0233] In some examples, the WTRU may transmit a UMUS signal via a broadcast SL transmission. In some examples, the WTRU may transmit the UMUS in a shared resource pool. Such a resource pool may be shared by WTRUs performing WTRU autonomous transmissions. Such a resource pool may be limited to WTRUs performing only unicast and / or multicast transmissions. Alternatively, the pool may also include WTRUs performing broadcast transmissions.

[0234] In some examples, the WTRU may transmit the UMUS on the PSCCH using an SCI or SCI-like transmission; using information in the PSBCH (e.g., SL-MIB or similar); and / or using information sent on the PSSCH, such as a MAC CE or SL-RRC message. For example, the WTRU may transmit a UMUS message using a MAC CE or SL-RRC message. This message may be transmitted via the SL using a special broadcast L2 destination address that is received by all WTRUs.

[0235] In some examples, the WTRU may transmit a UMUS in addition to normal transmissions. For example, the WTRU may transmit the UMUS in an SCI format that contains scheduling information and information about unicast and / or multicast links. Alternatively, or in addition, the WTRU may transmit only the UMUS without combining it with data or scheduling information. For example, the WTRU may transmit the UMUS periodically. Such periodic UMUS transmission may be performed by an SCI having a specific format. The WTRU may determine when to transmit the UMUS based on the expiration of a timer since its last UMUS transmission; based on the number of SCI transmissions since the last UMUS transmission; based on the QoS attributes of the unicast and / or multicast link(s) on which the WTRU is transmitting the UMUS (for example, if the associated unicast link has higher reliability, lower latency, etc., the WTRU may transmit the UMUS signal more frequently); based on the occupancy of a shared resource pool determined by the WTRU, such as a measurement of CBR, the number of available resources, or the number of UMUSs detected to be transmitted by other WTRUs; and / or based on the movement of the WTRU (for example, WTRU speed, heading, etc.).

[0236] The WTRU may include various information in the UMUS. For example, such information may include: VQI (or other QoS related parameters) associated with the unicast and / or multicast links (e.g., obtained from higher layers); one or more source and / or destination L2 addresses associated with the one or more WTRUs; attributes of resources required to transmit data on the unicast and / or multicast links; multiple QoS flows or multiple ASs multiplexed on the unicast and / or multicast links (or each unicast and / or multicast link); SL radio bearer; configuration of the reference signal channel / transmission performed by one or more WTRUs associated with the unicast and / or multicast link (for example, minimum / maximum RS transmission power, time, frequency and / or beam resources for transmitting the RS signal, RS signal sequence, etc.), wherein the configuration can be indicated by transmitting an index of a predefined or configured or preconfigured configuration; configuration of the HARQ feedback channel / transmission associated with the unicast and / or multicast link; configuration for CQI or CSI feedback transmission (for example, time, frequency and / or beam resources for transmitting CQI feedback), wherein the configuration can be indicated by sending an index of a predefined or configured or preconfigured configuration; configuration of preempted resources; BWP and / or the carrier on which resources are being reserved; and / or QoS-related metrics obtained by a WTRU, such as WTRU SL transmissions reflected over a time period.

[0237] In some cases where a configuration of a HARQ feedback channel / transmission associated with a unicast and / or multicast link is included in the UMUS, the configuration may include time, frequency, and / or beam resources for HARQ transmission, for example, in the form of a relationship (time / frequency) between data transmission and HARQ feedback, or the number of HARQ resources associated with each transmission (e.g., for multiple HARQ feedback transmissions); rules / conditions under which HARQ may be enabled / disabled; and / or rules for group-based HARQ transmissions (e.g., transmitting only NACK, transmitting ACK and NACK). The configuration may be indicated by sending an index of a predefined or configured or preconfigured configuration.

[0238] In some cases where a configuration of preemption resources is included in the UMUS, the configuration may include time, frequency and / or beam resources that may be used by other WTRUs to transmit a preemption signal or message that may be used to preempt an associated unicast and / or multicast link or one or more SLRBs associated with the link. Preemption resources may be reserved per WTRU, or per unicast and / or multicast link or SLRB. The configuration may be indicated by sending an index of a predefined or configured or preconfigured configuration.

[0239] In some cases, measurements, averages and / or ratios of QoS metrics obtained at the WTRU are included in the UMUS, which may include: measurements, averages and / or ratios of the number of transmissions required for unicast and / or multicast links; HARQ NACKs sent; a successful resource selection process; LBT fallback operation during resource selection; increasing the RSCP / RSSI thresholds used to determine resource availability during resource selection; preempting transmission or reception; carrier and / or resource reselection due to CBR, resource availability, etc.; and / or packets successfully sent / received or required waiting time in the PDB.

[0240] In some cases where attributes of resources required for data to be sent on unicast and / or multicast links are included in the UMUS, the attributes of the resources may include: a link identifier; resource density (e.g., the amount of time and / or frequency resources per unit time); the granularity of the resources used for the link; the average, maximum, or minimum packet size and / or the amount of time / frequency contiguous resources used for the link; priority; reliability of the link; beam mode (e.g., whether the link will transmit omnidirectionally in a single beam, beam scanned, or beamformed and transmit on a subset of beams (and possibly which beams); and / or a geographic location indicating the location where resources are needed, such as an area ID, directionality, or a geolocation reference for resource reservation. Such attributes may be further associated with a profile or table identifier that may be configured or preconfigured in the WTRU or negotiated between WTRUs.

[0241] Some examples include initiation and / or cancellation and multiplexing of information on the UMUS. For example, the WTRU may multiplex information of multiple unicast and / or multicast links and / or multiple radio bearers and / or multiple QoS flows onto the same UMUS. In some examples, the WTRU may initiate transmission of a new UMUS when or after establishing a unicast and / or multicast link. Alternatively, the WTRU may initiate transmission of a new UMUS, or after establishing the first unicast and / or multicast link, and / or after establishing additional links, may add information of all links to the existing UMUS. In this case, the WTRU may cancel the UMUS transmission or cancel the UMUS transmission after releasing one or all links at the WTRU.

[0242] In some examples, the WTRU may initiate the transmission of a new UMUS or initiate it after establishing a new radio bearer associated with the link. The WTRU may determine whether to transmit the new UMUS when establishing the radio bearer or after establishing the radio bearer based on the QoS characteristics of the data on the new radio bearer compared to the existing radio bearer. For example, if the QoS characteristics of the new radio bearer are significantly different from the QoS characteristics of the existing radio bearer, the WTRU may decide to transmit the new UMUS.

[0243] In some examples, admission control may be based on information included in the UMUS. The WTRU may perform admission control (e.g., determining whether unicast and / or multicast links and / or radio bearers can be established) based on information in one or more UMUS transmitted by other WTRUs in the same pool, BWP, carrier frequency, etc. In some examples, the WTRU may detect and / or decode all UMUS transmitted in the pool. In some examples, the WTRU may be configured with rules for determining possible resource usage associated with unicast and / or multicast transmissions in the pool (e.g., based on all UMUS) and for determining, for example, whether pending links and / or bearers can be added given the resource capacity of the pool.

[0244] In some examples, the WTRU may associate a number of time, frequency, and / or beam / density resources over a configurable time period with unicast and / or multicast links and / or radio bearers (e.g., of a certain VQI). For example, the WTRU may make such an association based on QoS attributes associated with the link, such as the VQI; the network configuration; and / or the measured CBR in the associated pool. For example, the WTRU may be configured with a mapping of the VQI and CBR to resource density or to the number of resource blocks and a time reference period. In another example, the WTRU may determine the number of resource blocks based on a rate-based QoS parameter derived from the VQI associated with the link.

[0245] In some examples, the WTRU may apply a weighting factor to determine the amount of resources required for each link and / or SLRB based on the QoS attributes associated with the link. For example, the WTRU may apply a multiplication factor (e.g., greater than 1) to radio bearers / links whose reliability requirements (or parameters thereof) are above a threshold. In another example, the WTRU may apply a multiplication factor (e.g., greater than 1) to radio bearers / links whose latency requirements or parameters thereof are shorter than a threshold.

[0246] In some examples, the WTRU may monitor / receive the UMUS for a period of time before the link and / or bearer is established. For example, the WTRU may make an admission control decision based on an existing link and / or bearer, wherein the existing link and / or bearer is established based on the UMUS detected over the period, wherein the UMUS identifies a unique link / bearer. In some examples, the WTRU may consider only a subset of the established links / bearers (UMUS) in the decision, for example, based on the QoS attributes associated with the link and / or bearer and whether the link and / or bearer and its QoS have an impact on the QoS of the link to be established. The WTRU may also perform admission control by considering only links / bearers with common QoS parameters and ensuring that the combination of these links / bearers does not result in exceeding another QoS parameter. In some examples, the WTRU may apply multiple decisions or criteria to determine whether admission control is successful, for example, where admission control depends on whether each criterion is successful. The decision or criterion may be performed based on the total amount of resources (e.g., of a particular type) indicated in the UMUS; and / or the number of established links / radio bearers in the UMUS (e.g., weighted).

[0247] In some cases where the criteria includes the total amount of resources indicated in the UMUS, the WTRU may first determine the total amount of resources that will be used by all unicast and / or multicast links in the resource pool determined by the UMUS transmission. For example, this amount may be measured as the number of resource blocks in a fixed time period. The WTRU may determine the total amount of resources set aside by all detected UMUS (e.g., by the sum of resource density or resource amount).

[0248] In some examples, the WTRU may determine the amount of resources used by an existing link over a fixed period based on: based on a VQI or similar QoS parameter (e.g., PPPP, PPPR) transmitted on the link; based on the number of SLRBs associated with the link in the UMUS (e.g., the WTRU may determine the total resource usage of the link based on the sum of the resource usage of each SLRB on the link); and / or based on the average packet size or data rate transmitted in the UMUS signal itself (e.g., the WTRU may use a combination of VQI and packet size to resource amount mapping to determine the amount of resources used by a link).

[0249] In some examples, the WTRU may determine that admission control is successful if the combination of the number of resources already reserved by the UMUS (e.g., in the same time period) and the number of resources required for the link / radio bearer to be established is less than the total number of resources in the pool, a certain percentage of the resources in the pool, or a configured or preconfigured threshold. In some examples, the configured or preconfigured threshold may depend on any of the following: QoS attributes of the link to be established (e.g., priority), QoS attributes of the already established link (e.g., based on the UMUS), or the CBR of the channel.

[0250] In some examples, the WTRU may determine the total amount of resources of a particular type to be used from all UMUS transmissions and make an admission control determination based on the total amount of available resources in a resource pool of that type. The type may be associated with a time granularity (e.g., whether the resource is a slot or a symbol; parameter configuration; and / or direction (e.g., one or more directions associated with transmissions on one or more antenna beams).

[0251] In some cases, where the criteria includes the number of established links / radio bearers indicated in the UMUS, in some examples, the WTRU may determine the number of established links / radio bearers based on all UMUS transmissions, and if the total number of radio bearers / links in the pool remains below a configured or preconfigured threshold, the WTRU may determine that admission control for a particular link / radio bearer is successful. In some examples, the threshold may depend on: the QoS attributes of the link to be established; the QoS attributes of the link present in the UMUS; and / or the CBR of the channel. In some examples, the WTRU may apply a weighting factor to each radio bearer / link indicated in the UMUS and / or the current link / radio bearer to be established. The weighting factor may be based on: the QoS attributes associated with the link; the received power of the UMUS (e.g., the WTRU may apply a multiplication factor greater than 1 to radio bearers / links for which the received UMUS RSRP is greater than a configured or preconfigured threshold); and / or a measured CBR. In some examples, the measured CBR may be on resources reserved for only one type of transmission (e.g., only broadcast transmissions, unicast, and / or multicast transmissions).

[0252] In some cases, where the threshold depends on the QoS attributes of the link to be established, in some examples, the WTRU may apply a multiplication factor (e.g., greater than 1) to radio bearers / links having a reliability requirement or its parameters above the threshold. In some examples, the WTRU may apply a multiplication factor (e.g., greater than 1) to radio bearers / links having a latency requirement or its parameters shorter than the threshold. In some examples, the WTRU may apply a multiplication factor configured for use with a VQI associated with a radio bearer / link.

[0253] In some examples, the WTRU may also apply a weight of 0 in the evaluation of the number of established links / bearers (ie, not considering specific links and / or bearers).

[0254] In some examples, the WTRU may perform admission control based on: the number of remaining available RS resource transmission configurations; the remaining available preemption resource configurations; the remaining available HARQ resource transmission configurations; and / or the remaining available CQI resource transmission configurations. For example, the WTRU may determine the number of available configurations by excluding those configurations that are already in use, for example, as determined by UMUS signals received within a time period. In some examples, the WTRU may determine that admission control is successful if the number of available (i.e., unused) configurations is above a configured or preconfigured or predetermined threshold (e.g., 0); and / or if a configuration exists and can be selected for a link and / or SLRB to establish that does not conflict with any existing configuration from an interference, capability, etc. perspective (e.g., the WTRU may associate the RS transmit power with the QoS of the link to be established, and the WTRU may further determine whether there is a configuration with an associated transmit power that does not exceed the allowed WTRU TX power).

[0255] In some examples, the WTRU may determine the time period during which the WTRU considers the UMUS signal based on latency-related aspects of its QoS to determine which configurations are already in use. For example, latency-related aspects may include a mapping of a VQI to an average or worst-case PDB. In some examples, the WTRU may determine the amount of resources to be transmitted within the period based on rate-related aspects of its QoS, for example by adjusting the rate requirement derived from the VQI to the worst-case PDB. Therefore, the WTRU may assume that its resource density (which is the number of resources per configurable period) is the amount of resources used in its PDB. In some examples, the WTRU may perform the same calculation for all established links / bearers to determine the current resource availability density. In some examples, in this calculation, the WTRU may further apply a multiplication factor associated with a QoS parameter or reliability / range to each link and / or bearer, including the link and / or bearer to be established. In some examples, the factor may be configured by the network for a given value of a reliability / range derived parameter (e.g., from the VQI). In some examples, if the total amount of available resources (including resources for links and / or bearers to be established) over a configurable period is less than a threshold percentage (e.g., X%) of resources in the pool, then admission control for the links and / or bearers may be considered successful. In this example, the network may further configure X% for each pool, and the WTRU may further select one of a number of thresholds applicable to the pool based on the measured CBR. For example, the WTRU may receive a threshold (X%) to apply to each CBR value range for the pool.

[0256] In some examples, the WTRU may perform admission control so that the number of active links / bearers with a particular type of rate requirement does not exceed a maximum number of bearers. In some examples, the maximum number of bearers may be determined based on a requirement related to latency. For example, a WTRU performing admission control for links and / or bearers with a larger data burst size requirement (e.g., which may be associated with a particular VQI value) may determine the number of currently active links / bearers with the same requirement. The WTRU may calculate the allowable number of such active links by assuming that each such link occupies a number of PRBs in a time frame of a minimum PDB associated with each link.

[0257] Some examples include modifying resource selection for broadcast transmissions based on the UMUS. For example, the WTRU may perform resource selection (e.g., for broadcast resources) and may consider the number of established unicast and / or multicast links in the resource selection process. In some examples, the WTRU may perform one or more actions during resource selection. One or more actions may include: avoiding selecting a carrier if the number of links / bearers on the carrier or the amount of available resources for links / bearers on the carrier is above a threshold; and / or scaling or changing certain resource selection parameters based on the presence / number of links in all UMUS or the amount of available resources. Such parameters may include the number of consecutive resource reservations allowed; the probability of maintaining (e.g., renewing a reservation) resources in each reservation period; a CBR threshold for selecting a carrier; an RSRP threshold for determining the availability of resources based on detection of an SCI; LBT parameters such as backoff, sensing time, detection sensitivity; the minimum energy associated with a valid / confirmed preemption signal; and / or based on sensing the percentage of resources that are considered available, the WTRU may make resource selection for that percentage.

[0258] In some examples, admission control is based on representative and / or past resource selection processes. For example, the WTRU may perform a representative resource selection process or a series of such processes to reserve resources for a particular link and / or bearer, and may determine the results of admission control based on the results of these resource selection processes. In this case, the representative resource selection process may not be performed to actually reserve or select any resources, but may be performed to evaluate the occupancy of the channel. In this case, the representative resource selection process may be performed on a set of stored sensing results from past time instances. In this case, each representative resource selection process may represent the expected result of actively performing resource selection at a past moment corresponding to the sensing result stored in the WTRU corresponding to that moment. Alternatively, the resource selection process for admission control may include a resource selection process that is actually used to select broadcast / unicast and / or multicast transmissions in the same pool, BWP and / or carrier, and a configured or preconfigured time has been performed before admission control is performed. For example, the WTRU may maintain statistics of resource selection processes (e.g., link establishment decisions) performed before the time of required admission control, and may perform admission control based on these statistics.

[0259] In some examples, the WTRU can be configured to perform multiple representative resource selection processes, each resource selection process having different resource selection parameters, such as a different PDB or waiting time; a different number of retransmissions; a different MCS, power, or related transmission parameters; a different packet size; and / or a different packet periodicity (or no periodicity; for example, a one-time resource selection).

[0260] In some examples, the WTRU may be configured to use a set (or multiple sets) of resource selection parameters, for example based on the QoS characteristics of the unicast and / or multicast links for which admission control is being performed. For example, the WTRU may be configured with a set of resource selection parameters for unicast and / or multicast links with a specific VQI. Following such configuration, the WTRU may perform multiple sequential resource selection procedures using these parameters to determine whether admission control for a particular link and / or bearer is successful. Alternatively, the WTRU may be provided with multiple sets of resource selection parameters for a particular VQI and may perform representative resource selection procedures in parallel or sequentially, each with a different set of parameters, to determine admission of new links and / or bearers.

[0261] In some examples, the WTRU may be configured with specific criteria related to past resource selection procedures (e.g., such as those discussed herein) whose results the WTRU should consider. For example, for a link with a specific VQI, the WTRU may be configured to only consider past resource selection procedures where the PDB was below a threshold, the number of retransmissions was above a threshold, etc. as part of resource selection for admission control. Following such configuration, the WTRU may perform admission control for the link based only on those past resource selection procedures that met these specific criteria.

[0262] In some examples, the WTRU may determine the result of admission control based on the number or frequency of successes of its representative and / or past resource selection procedures. For example, admission control may be determined to have succeeded if a threshold number (N) or a threshold percentage (X%) of its representative and / or past resource selection procedures succeeded; if a threshold number (M) of recent representative and / or past resource selection procedures all succeeded; and / or if a threshold average (Y%) of its resource selection procedures did not require a threshold change to achieve a threshold availability target (e.g., 20% in LTE). In each of these cases, the values ​​of N, X%, M, Y%, and the availability target may depend on the NW configuration; the CBR measured by the WTRU; and / or QoS parameters associated with the link to be established.

[0263] In some examples, the WTRU may determine the result of admission control based on a combination of results from past resource selection processes and representative resource selection processes. For example, the WTRU may need to base its admission control on a minimum number of resource selection processes (e.g., past and / or representative). In some examples, if the WTRU determines that it does not have a sufficient number of past resource selection processes, it may perform a representative resource selection process at admission control to meet the configured minimum.

[0264] Figure 8 8 is a flow chart illustrating an example process 800 for admission control based on representative resource selection. In step 810, the bearer and / or link establishment may be initiated using the QoS information associated with the bearer / link. In step 870, the WTRU may determine the number of resource selection attempts to be performed for admission control and the parameters for the resource selection attempts (e.g., PDB-packet delay budget, periodicity and / or packet size for resource selection, availability threshold, etc.) using the configuration, pre-configuration and / or CBR. These values ​​may also be configured or pre-configured with each bearer QoS and / or CBR, or may be pre-defined. In some examples, the WTRU may determine the number of successful resource selection processes required to declare a successful admission control. The number of successful resource selection processes required to declare a successful admission control may also be (pre)configured or pre-defined. For example, if the number of successful resource selection processes is above the configured amount, it may be determined that the admission control is successful. The WTRU may determine the success of a single resource selection process based on a configured or pre-configured availability threshold (i.e., the percentage of resources available for use determined by the sensing process). For example, if the resources available based on the sensing results are above an availability threshold, then the single resource selection process is successful.

[0265] In step 820, the WTRU may determine parameters for representative resource selection based on the QoS of the bearer and / or link. As discussed herein, the parameters may include the number of representative resource selection attempts to be made in process 800, as well as a number of parameters inherent to each resource selection process to be performed. Specifically, in step 870, the PDB (packet delay budget used in each resource selection process), the periodicity of the data, and the packet size used in each resource selection process may be determined. In step 830, as discussed herein, the WTRU may determine a resource selection pass / fail criterion, i.e., a criterion for determining whether the representative resource selection process is successful. The pass / fail criterion for the resource selection process may be defined based on the number of available resources that are above / below a percentage availability threshold determined in step 870 based on the sensing results. The pass / fail criterion for the resource selection process may be defined based on the percentage of successful resource selection processes that are above / below a failure percentage threshold determined in step 870. In step 840, the WTRU may perform a representative resource selection process using its stored sensing results. Specifically, the UE may select resources from a set of shared resources (resource pool) using a set of (pre)configured parameters (e.g., waiting time / PDB, periodicity, etc.) by determining available resources based on the sensing results. The UE may perform a resource selection process using the number of attempts determined in step 870, potentially using different sensing results associated with different moments in time. A representative resource selection process may be based on sensing results as discussed herein. Specifically, the UE may store sensing results obtained at different moments in the past, and may perform a resource selection process using sensing results associated with a specific moment in the past. In some examples, the resource selection process may include the WTRU determining available resources based on input parameters.

[0266] In step 850, the WTRU may evaluate representative resource selections based on the pass / fail criteria discussed herein. Specifically, the WTRU may determine whether each resource selection process is successful. The WTRU may determine whether the total number or percentage of successful resource selection processes is above a configured threshold to determine whether the admission control is successful. In step 860, based on the evaluation in step 850, a bearer and / or link establishment decision is provided to the peer WTRU and / or upper layers of the WTRU. Specifically, the WTRU may inform the upper layers that the bearer / link may be established if the admission control is successful.

[0267] In some examples, if a past resource selection process is used instead of a representative resource selection process, process 800 may be modified by omitting the step of performing a resource selection process in step 840 and using the results of the past resource selection process that met the criteria.

[0268] In some examples, admission control is based on sensing results. For example, the WTRU may perform admission control based on: sensing or measurements maintained continuously at the WTRU and / or sensing or measurements analyzed over a period of time prior to the triggering of an admission control decision, and associated with one or more pools, carriers, and / or BWPs, such as CBR measurements; the number of successful / failed LBT processes at a configured time (e.g., based on its own access to the channel, or based on measurement results transmitted in the UMUS); the number of preemption signals detected within a configured time; sensing results (e.g., information included in the SCI detected during sensing of one or more pools); metrics related to other ongoing unicast links of the WTRU (e.g., links in the same pool) (e.g., average retransmission rate); measurements of channel quality (e.g., CQI, path loss) during the discovery process of the process; and / or QoS-related measurements at the WTRU or metrics at the WTRU, or measurements received from other WTRUs or metrics received from other WTRUs (e.g., in the UMUS).

[0269] The WTRU may be configured with a threshold measurement, or thresholds for any or a combination of the above measurements, where if met (e.g., the measurement is below or above the threshold as appropriate), then admission control of the link and / or bearer is considered successful. In some examples, such thresholds may depend on QoS parameters associated with the link and / or bearer to be established.

[0270] Some examples include CBR-based admission control. For example, the WTRU may be configured with a CBR threshold for each VQI. If the WTRU initiates a link and / or bearer establishment for a bearer with a specific VQI, admission control may be considered to have failed if the measured CBR is above the associated CBR threshold. In some examples, the WTRU may be configured with a CBR threshold for each (or any) of the QoS-related parameters for latency, reliability, priority, range, and rate. In some examples, the WTRU may determine the applicable QoS parameters for the radio bearers to be established based on the relevant QoS parameters of the flows to be mapped to those radio bearers. In some examples, the WTRU may determine appropriate values ​​(e.g., priority, reliability, etc.) for the relevant QoS parameters associated with the bearer. In some examples, if the CBR is lower than each QoS parameter-specific threshold for each relevant QoS parameter for the radio bearer, the WTRU may determine that admission control for the bearer is successful.

[0271] In some examples, the WTRU performs admission control based on sensing results. For example, the WTRU may determine the admission control rules based on sensing results determined from SCI transmissions of other WTRUs over a period of time prior to the admission control decision. In some examples, the admission control decision may also depend on the QoS aspects of the link and / or bearer to be established. In some examples, the WTRU may continuously maintain the sensing results and may define the admission control decision based on the results during the time (T) prior to the admission control decision. In some examples, the sensing results used to perform admission control may be derived from one or more pools, BWPs, and / or carriers. In some examples, the admission control decision may depend on one factor or a combination of multiple factors. In some examples, one or more factors include: observed non-periodic traffic, observed periodic traffic, the relative amount of periodic traffic to non-periodic traffic, observed unicast and / or multicast traffic, or the relative amount of observed unicast and / or multicast traffic compared to broadcast traffic; observed QoS characteristics of periodic, non-periodic, unicast, multicast and / or broadcast traffic; and / or the amount of reserved resources of a particular granularity.

[0272] In some cases where the admission control decision depends on the observed amount of non-periodic traffic, the WTRU may measure the amount or percentage of resources associated with non-periodic traffic (e.g., one-time) and may allow the establishment of links and / or bearers if the value is above / below a threshold. In some cases where the admission control decision depends on the observed amount of periodic traffic, the WTRU may measure the amount or percentage of resources reserved (e.g., using forward reservation or similar reservation methods) and may allow the establishment of links and / or bearers if the value is above / below a threshold. In some cases where the admission control decision depends on the relative amount of periodic and non-periodic traffic, the WTRU may be configured to have an acceptable ratio of periodic to non-periodic traffic and may allow the establishment of links and / or bearers if the measured ratio is above / below a threshold. In some cases where the admission control decision depends on observed unicast and / or multicast traffic (e.g., perhaps compared to broadcast), the WTRU may determine the amount or percentage of unicast and / or multicast traffic based on: detection of a unicast indicator in the SCI; detection of a HARQ process ID or similar in the SCI; detection of HARQ transmissions (or resources reserved for HARQ transmissions); and / or detection of CSI reference signals or resources reserved for such transmissions and / or CSI feedback transmissions. In some such cases, the WTRU may allow establishment of a link and / or bearer if the amount or percentage of unicast and / or multicast transmissions or the ratio of such transmissions to broadcast transmissions is above or below a threshold. In some cases where the admission control decision depends on observed QoS characteristics of periodic, aperiodic, unicast, multicast, and / or broadcast traffic, the WTRU may determine a VQI or any QoS-related parameter derived from the VQI (e.g., reliability, delay, priority, rate, range) for transmissions from the SCI associated with the transmission. In some such cases, the WTRU may further modify or select any of the above thresholds based on the worst, average, best, total and / or majority QoS of the observed transmissions. In some cases where the admission control decision depends on the amount of reserved resources at a certain granularity, the WTRU may determine the amount or percentage of symbol-based or slot-based resources reserved and may perform admission control based on whether the value is above / below a threshold.

[0273] In some examples, the WTRU may perform admission control based on an estimate of the number of unicast and / or multicast links and / or SLRBs determined by monitoring the SCI over a period of time. In some examples, the WTRU may further determine an estimate or density of resource usage using methods similar to those associated with UMUS reception, and may make admission control decisions based on a determination of a percentage of resources used.

[0274] Some examples include admission control based on QoS related measurements and / or metrics. For example, as described herein, the WTRU may be configured with rules for admission control based on QoS related measurements and / or metrics. In some examples, the WTRU may obtain such measurements and / or metrics from its own transmissions and / or based on metrics obtained from broadcasts of other WTRUs. For example, the WTRU may obtain such metrics from other WTRUs in a UMUS or in another inter-WTRU message, and / or the WTRU may obtain such metrics during RRC signaling associated with link and / or SLRB establishment. In some examples, the WTRU may further limit which WTRU's metrics are considered in admission control decisions based on geographic region, unicast and / or multicast relationships, and / or QoS or transmission type.

[0275] In some cases where the WTRU limits which WTRUs' metrics are considered in the admission control decision based on a geographic area, the WTRU may only consider metrics received from WTRUs in the geographic area or other areas related to the WTRU performing admission control. In some cases where the WTRU limits which WTRUs' metrics are considered in the admission control decision based on unicast and / or multicast relationships, the WTRU may only consider metrics received from WTRUs with which the WTRU intends to establish a unicast and / or multicast link or SLRB, or with which the WTRU currently has an active unicast and / or multicast link / SLRB. In some cases where the WTRU limits which WTRUs' metrics are considered in the admission control decision based on QoS or transmission type, the WTRU may only consider metrics received from WTRUs with the same transmission type (e.g., unicast, multicast, broadcast, mode 1 and / or mode 2) or QoS (e.g., the same or similar VQI or QoS-related attributes) as the link and / or SLRB for which admission control is required.

[0276] In some examples, the admission control criteria and / or WTRU measurements may depend on the dominant QoS characteristics. For example, some transmissions may have strict latency requirements, but less stringent requirements for reliability (or no requirements at all). For example, the WTRU may further determine the admission control measurements and / or criteria based on the QoS of the link and / or bearer to be established. In some examples, the WTRU may apply different configured or preconfigured measurements and / or criteria (e.g., those discussed herein) for admission control based on the QoS of the link and / or bearer to be established. In some examples, the WTRU may be configured or preconfigured with measurements and / or criteria for each VQI, and the configured measurements and / or criteria may be applied based on the VQI of the associated link. In some examples, the WTRU may determine the QoS characteristics (e.g., one or more dominant QoS characteristics, which may include delay, reliability, etc.) based on the VQI associated with the bearer / link to be established, and may use the configured measurements and / or criteria associated with the characteristics to make admission control decisions. For example, for latency dominated bearers / links (e.g., with latency stringent QoS requirements), the WTRU may use measurements of the amount of reserved resources at a certain granularity, and / or measurements of the total amount of periodic resources reserved. For reliability dominated bearers / links, the WTRU may use measurements of the amount of non-periodic resources. For range dominated bearers / links, the WTRU may use channel measurements during discovery. Other combinations of measurements and / or criteria for a given QoS characteristic or VQI are possible and will be apparent to one skilled in the art.

[0277] Some examples include preemption of existing unicast and / or multicast links. For example, a WTRU performing admission control may decide to perform preemption of one or more existing unicast and / or multicast links in order for admission control to succeed. In some examples, preemption may be performed on links that the WTRU has established with it, or may be performed on links between different sets of WTRUs.

[0278] In some examples, the WTRU may decide to preempt one or more established unicast and / or multicast links (e.g., with its own links or links between other WTRUs) during admission control for establishing its own unicast and / or multicast links. For example, if the WTRU decides to establish a new link that cannot currently be established due to the existence of one or more existing unicast and / or multicast links (e.g., based on the techniques described herein), or if the establishment of the link results in potential non-satisfaction of the QoS requirements of the link or other already established links (e.g., other links with higher priority), the WTRU may determine to preempt the unicast and / or multicast link. In some examples, the WTRU may be aware of the existing unicast and / or multicast links based on receiving UMUS signals transmitted by other WTRUs. Alternatively, the WTRU may decide to preempt one or more radio bearers and / or QoS flows multiplexed onto a unicast link.

[0279] Without loss of generality, although various examples of preemption may be discussed herein with respect to preemption of a link or preemption of a radio bearer, note that preemption may be applied to either a link or a radio bearer or both a link and a radio bearer, although examples, embodiments, situations and scenarios of only one of the two are cited for ease of description.

[0280] In some examples, the WTRU may transmit a preemption signal to suspend a unicast and / or multicast link for a period of time. For example, the WTRU may preempt one of its existing radio bearers in link establishment signaling for establishing a new link or radio bearer with the same one or more WTRUs. In some examples, the WTRU may transmit a preemption signal to force the unicast and / or multicast link to use a different pool, BWP, carrier, or similar set of resources. In some examples, the WTRU may determine whether it can perform preemption based on the QoS of the link to be established; the current occupancy of the channel; the configuration; and / or the existence of suitable unicast and / or multicast link(s) to be preempted.

[0281] In some cases where the WTRU determines whether it can perform preemption based on the QoS of the link to be established, the WTRU may be configured with a threshold associated with one of its QoS characteristics and / or with a threshold priority above which the WTRU can perform preemption of another link. In some cases where the WTRU determines whether it can perform preemption based on the current occupancy of the channel, the WTRU may be configured with a threshold for the CBR, and the WTRU may perform preemption of a unicast and / or multicast link only when the currently measured CBR is above the threshold. In some cases where the WTRU determines whether it can perform preemption based on a configuration, the configuration is configured to allow preemption to be performed, and the configuration may be WTRU-specific, QoS class-specific of the link to be established (e.g., VQI associated with the link / radio bearer), or pool / BWP / carrier-specific.

[0282] In some cases, the WTRU determines whether it can perform preemption based on the existence of a suitable unicast and / or multicast link or links to be preempted. If the WTRU is able to find a unicast and / or multicast link that it can use to preempt (e.g., based on monitoring of the UMUS), the WTRU may perform preemption. In some examples, the conditions for finding such a link may be the same as those described in the selection of a link, as described herein. For example, if there is an existing unicast and / or multicast link with a lower priority than the link to be established, the WTRU may perform preemption on the unicast link.

[0283] In some examples, a WTRU that is unable to perform preemption and is unable to achieve the required QoS for a link on a given pool, carrier and / or BWP or a set of pools, carriers and / or BWPs (e.g., based on a failure of an admission control procedure) may notify upper layers of the failure.

[0284] In some examples, the WTRU may select one or more unicast and / or multicast links to preempt based on: priority and / or QoS; based on satisfaction of attributes of the link to be established; based on which WTRU or WTRUs are associated with the link; positioning; and / or use of similar resource patterns and / or signatures.

[0285] In some cases where the WTRU selects one or more unicast and / or multicast links to preempt based on priority and / or QoS, the WTRU may select the unicast and / or multicast link with the lowest priority based on a set of active detected links, for example, based on monitoring of the UMUS. The WTRU may use any or a combination of priority, data rate, latency, range, or reliability to decide which link to preempt. For example, the WTRU may select one of the links (e.g., from those links it determines in a received UMUS signal) for which the priority is lower than the priority of the link to be established, which may be done by a configured or preconfigured number of priority levels. The WTRU may transmit a preemption signal to preempt the selected unicast and / or multicast link.

[0286] In some cases where the WTRU selects one or more unicast and / or multicast links to preempt based on the satisfaction of the attributes of the link to be established, for example, the WTRU may select a link that reserves a resource amount that is most similar to the link it needs to establish or has a QoS characteristic (e.g., packet size, reliability, etc.) that is most similar to the link it needs to establish, or the WTRU may select a link (one or more) that minimizes the number of links that need to be preempted to meet the needs of the link to be established. In another example, the WTRU may select a link (one or more) that minimizes the number of links that need to be preempted in order to meet the needs of the link to be established. In another example, the WTRU may select a unicast and / or multicast link with an estimated packet arrival time that is closest to the link to be established. For example, the WTRU may determine the packet arrival time of an existing unicast link that transmits periodic traffic. This determination may be made by sensing the SCI over a period of time. The WTRU may select the unicast link to be preempted as the unicast link with the closest packet arrival time to the link to be established and with a lower priority than the link to be established.

[0287] In some cases where a WTRU selects one or more unicast and / or multicast links to preempt based on which WTRU or WTRUs are associated with the link, for example, the WTRU may preempt one of its own ongoing links, or preempt a link of a WTRU with which it has an ongoing link. In some examples, the WTRU may consider its own SLRB or SLRBs between different WTRUs equally, for example, for selecting the SLRB to be preempted, and / or for selection criteria. In some examples, the WTRU may preempt its own SLRB before considering preempting other SLRBs. For example, the selection of the SLRB to be preempted may be based on the following rules: 1) if the WTRU has an active SLRB that meets the above criteria, the WTRU may select the first SLRB among its own SLRBs, otherwise, the WTRU may select another SLRB; and / or 2) the WTRU may select between its own SLRB and the SLRB of another WTRU by applying a bias to any parameter used in the selection process that will determine the preference for its own SLRB or the SLRB of another WTRU (e.g., a threshold priority level below which the SLRB is selected for preemption may be different for the WTRU's own SLRB and the SLRB of another WTRU, where the threshold may be relative to the priority of the new SLRB).

[0288] In some cases where the WTRU selects one or more unicast and / or multicast links to preempt based on location, for example, the WTRU may only consider preemption on links that have reserved resources in the same area (e.g., region, geographic location, and / or direction) as the area required for the new unicast link. In some examples, the WTRU may select a unicast and / or multicast link where one or more communicating WTRUs are closest to one or more WTRUs that will be associated with the unicast and / or multicast link to be established. In some examples, the WTRU may determine the proximity of one or more ongoing unicast and / or multicast links based on detection of the WTRU's location in the SCI / UMUS or one or more similar transmissions of the WTRU (possibly in combination with speed / heading); and / or based on measurements of RSRP of transmissions made by the WTRU in the unicast links, etc. In some examples, the WTRU may select to preempt the unicast link that is closest to its own location (e.g., highest received RSRP) and has a lower priority based on one or more of such measurements.

[0289] In some cases where the WTRU selects one or more unicast and / or multicast links to preempt based on the use of similar resource patterns and / or signatures, the WTRU may select a unicast and / or multicast link that uses a resource usage pattern (e.g., a pool, or a time / frequency resource pattern assigned to a unicast link) that is the same as or overlaps with the resource usage pattern selected for the unicast and / or multicast link to be established. In some examples, such a pattern may also include a transmission signature, such as a scrambling code, or a frequency hopping sequence, etc. In some examples, the WTRU may select to preempt a WTRU with a lower priority than a link established based on the same (or overlapping) pattern / signature.

[0290] In some examples, link preemption selection may be performed at the WTRU that transmits the preemption signal or at the WTRU that receives the preemption signal. For example, the WTRU may first determine the unicast and / or multicast links to be preempted, and may indicate the links associated with the unicast and / or multicast links in the preemption signal sent to one or more of the WTRUs. In some examples, the WTRU that receives the preemption may preempt the unicast and / or multicast links and / or SLRBs indicated in the preemption signal. Alternatively, the WTRU may select the WTRU to which the preemption is sent, and the WTRU that receives the preemption signal may use the rules discussed herein to decide which unicast and / or multicast links and / or SLRBs it is associated with for preemption.

[0291] In some examples, the WTRU may consider all ongoing unicast and / or multicast links that have a lower or the same priority as the planned unicast and / or multicast link to be established for preemption. For example, based on these links, the WTRU may first decide to preempt an existing link that has the same or substantially similar QoS profile or the same or substantially similar QoS attribute values ​​(i.e., except for the priority) as the link to be established, and may select that link to be preempted.

[0292] In some examples, a WTRU that decides to preempt a unicast and / or multicast link may transmit a preemption signal (e.g., a request) using: information in another transmission on the SCI or PSCCH; using a MAC CE or RRC message sent on the PSSCH; using a MIB transmission on the PSBCH; and / or using a message on a channel dedicated to transmitting preemption signals.

[0293] In some examples, the WTRU may include information in the preemption signal. The information may include: the UE ID of the WTRU transmitting the preemption signal; the UE IDs of the one or more WTRUs whose unicast and / or multicast links are to be preempted; the link ID to be preempted; the radio bearer ID to be preempted; one or more destination addresses that identify the one or more WTRUs associated with the unicast and / or multicast link; the time period during which the link / radio bearer should be preempted; the QoS parameter(s) associated with the link / bearer that should be preempted; and / or one or more QoS parameters and / or link / bearer IDs associated with the link / bearer or packet whose admission results in the preemption of the link and / or SLRB.

[0294] In the case where the WTRU includes one or more QoS parameters associated with the links / bearers that should be preempted, the one or more parameters may include: one or more priorities associated with the links that should be preempted (e.g., the WTRU may preempt all unicast links having a priority lower than a certain priority level); and / or a VQI or a set of VQIs (e.g., the WTRU may send a preemption signal that may be associated with one or a set / range of VQI values ​​to which preemption is applied).

[0295] Some examples include reserving preemption resources during link establishment. For example, a WTRU may reserve resources that may be used to preempt a unicast / multicast link and / or bearer during the establishment of the link and / or bearer. In some examples, a WTRU may broadcast preemption resources to be used to preempt a given link and / or SLRB using a reservation signal or using a UMUS to other WTRUs, as further discussed herein.

[0296] In some examples, the WTRU may select time and / or frequency resources and / or periodicity of preempted resources based on a configured or preconfigured set or pool of allowable resources and / or periodicity. For example, a pool of resources to be used for preemption may be configured or preconfigured for each WTRU. Each unicast link may further reserve a subset or pattern of such resources within the preemption pool. The WTRU may select a particular preempted resource from the allowed set based on: one or more criteria such as the QoS of the link or SLRB(s) to be established; a predefined pattern within the preemption pool; and / or resource availability.

[0297] In some cases where the WTRU selects specific preemption resources from the allowed set based on the QoS of the link or SLRB(s) to be established, if the priority of the link or SLRB is greater, or if the latency of the link or SLRB is lower, the WTRU may select a set of resources for link preemption that occurs more frequently. In some examples, this provides more opportunities to preempt a link or associated SLRB when the link / SRLB is associated with a high priority and / or low latency. In some examples, such a greater opportunity may be consistent with a situation where a higher priority link and / or SLRB may only be preempted by a higher priority link / SLRB.

[0298] In some cases where the WTRU selects specific preemption resources from an allowed set based on a preemption pool, the WTRU may select preemption resources associated with a link and / or SLRB based only on some predefined patterns (e.g., RB 1 in subframe 1, repeated every N subframes, as an example, a single predefined pattern).

[0299] In some cases where the WTRU selects a particular preempted resource from the allowed set based on resource availability (e.g., based on sensing and measurement), the WTRU may perform a sensing process (e.g., SCI decoding, RSSI measurement, etc.) to determine available or occupied resources, and may select the preempted resource from the set of available resources. Alternatively, the WTRU may exclude preempted resources associated with an already existing unicast link (e.g., determined by all UMUS received from other WTRUs), and may select the preempted resource for the link and / or SLRB to be established from the remaining allowed resources.

[0300] In some examples, there may be a set of predefined patterns for preempting resources, and each preempted resource may be associated with one or more VQIs. For example, the WTRU may select from among the predefined patterns associated with the VQI associated with the link to be established or the highest VQI. In some examples, the WTRU may exclude any patterns currently used by other WTRUs based on detecting UMUS transmissions of other WTRUs over a period of time. In some examples, the WTRU may randomly select a pattern for preempting resources (e.g., from a set of remaining patterns), or may select a pattern with the lowest measured RSSI over a period of time. In some examples, after selecting a pattern, the WTRU may transmit an index or identifier associated with the pattern in a reserved signal or UMUS.

[0301] Some examples may include transmitting a preemption message on preemption resources reserved for the link. For example, a WTRU that decides to preempt an existing link and / or SLRB may transmit a preemption message only on resources associated with the preemption of the link and / or SLRB. In some examples, the WTRU may determine these resources based on detection of UMUS transmissions by other WTRUs. In some examples, the WTRU may further decide whether to preempt and which unicast link and / or SLRB to preempt based on decoding of UMUS transmissions received at time (T) before the preemption decision. For example, the WTRU may select a link and / or SLRB with the lowest priority among all established links it knows based on the UMUS received at T. In some examples, after selecting a link and / or SLRB, the WTRU may transmit a preemption message on the resources indicated for the link and / or SLRB in the UMUS.

[0302] Some examples include confirmation signaling. In some examples, the WTRU may wait to receive a preemption confirmation signal from one or more WTRUs associated with a unicast and / or multicast link before it initiates / completes link establishment. In some examples, if the WTRU does not receive a preemption confirmation within a threshold amount of time, the WTRU may repeatedly transmit the preemption signal. In some examples, the WTRU may determine the successful preemption of a link, and may therefore initiate / complete link establishment based on the receipt of at least one preemption confirmation signal. Alternatively, the WTRU may determine the successful preemption of a link based on receiving confirmations from a threshold number (N) of WTRUs. In some examples, N may be equal to the number of WTRUs associated with the unicast and / or multicast link (e.g., 2 for unicast), or N may be configured or preconfigured.

[0303] Some examples include receiving a preemption signal. In some examples, the WTRU may determine that the preemption signal it has received is applicable to its currently established bearer / link if the preemption signal includes a destination address that matches the WTRU's own source address or unicast address; if the preemption signal includes the radio bearer ID of one of the WTRU's active bearers; and / or if the preemption signal includes a VQI or QoS-related parameter that matches a VQI or QoS-related parameter of one of the WTRU's established links / bearers.

[0304] In some examples, the WTRU may perform one or more operations based on the receipt of the preemption signal. For example, based on the receipt of the preemption signal, the WTRU may: transmit a preemption confirmation signal or message to the preempting WTRU; notify the upper layer of the release or suspension of the radio bearer or unicast and / or multicast link; delay the transmission of packets associated with the radio bearer / link for the time period indicated in the preemption signal; send a radio bearer release or link release message to the one or more peer WTRUs in the unicast and / or multicast link; notify the gNB of the release or delay of the radio bearer or link; and / or initiate a procedure with one or more peer WTRUs to perform a carrier switch, a BWP switch, or a pool switch (e.g., by sending a channel switch message).

[0305] In some examples, the preemption signal may be transmitted in the same message as the threshold VQI or threshold QoS level (e.g., threshold priority level). In some examples, the preemption signal may be broadcast to all WTRUs. Upon receiving the preemption signal, the WTRU may preempt all unicast and / or multicast links in the signal that have a priority lower than the threshold. The WTRU may then notify upper layers of the preemption and / or may initiate release signaling with peer WTRU(s) in the link.

[0306] Some examples include admission control for broadcast transmissions. For example, admission control may occur at service establishment and / or service startup. In some examples, the WTRU may perform admission control after an upper layer indicates the establishment or initiation of a broadcast service. In some examples, the WTRU may receive an indication from an upper layer to initiate such a service. The indication may include information such as the expected QoS, the period and / or duration of the service, and / or an admission control policy. In the case where the indication includes the expected QoS, the indication may include a worst case or range of QoS attributes for each packet to be sent for the associated service, such as a VQI / VQI range, a PPPP / PPPP range, a PPPR / PPPR range, etc. In the case where the indication includes the period / duration of the service, the indication may include the expected duration of the service in a certain time increment. In the case where the indication includes an admission control policy, the admission control policy may include: guaranteed QoS or best effort QoS, whether the AS layer should indicate to the upper layer when and / or whether the QoS for such service can be met or whether admission control and / or monitoring should be performed; and / or whether preemption of existing broadcast services and / or unicast and / or multicast links / SLRBs is allowed to initiate services, and / or rules associated with such preemption (for example, which services or priorities can be preempted).

[0307] In some examples, the WTRU may perform admission control decisions using the same or substantially the same methods as described herein for the unicast link and / or SLRB establishment case. Without loss of generality, admission control for broadcast transport services may follow the methods used for unicast, except that the decision for admission control may be made entirely at the WTRU receiving an indication from upper layers, rather than based on signaling associated with link establishment.

[0308] In some examples, the WTRU may decide to preempt an ongoing broadcast or unicast and / or multicast SLRB in order to grant broadcast services. The rules for determining whether to preempt an SLRB may be determined based on upper layer policy information and may be similar to the rules for initiating unicast and / or multicast link and / or bearer establishment.

[0309] In some examples, the WTRU may initiate the creation of a broadcast SLRB upon an indication from upper layers and a successful admission control decision at the WTRU. Without loss of generality, the SLRB establishment may be performed at the WTRU using methods similar to those described for unicast and / or multicast links and / or SLRB establishment. For example, the WTRU may initiate a UMUS transmission upon broadcast SLRB initiation, where the information in the UMUS reflects one, multiple, or all broadcast services active at the WTRU. Broadcast SLRB establishment may not require some procedures (e.g., initiation of reference signal transmission).

[0310] Admission control of a single packet may result in one or more actions by the WTRU. Such actions may include: successful admission control, where the packet may be submitted for transmission to lower layers (e.g., MAC / PHY layers), subject to normal resource selection procedures; failed admission control, where the WTRU may initiate preemption of its own transmission (e.g., by releasing an SLRB) or other WTRU transmissions (e.g., by transmitting a preemption signal); failed admission control, where the WTRU may notify upper layers of the failure; and / or failed admission control, where the WTRU may negotiate and / or select new QoS-related attributes for the broadcast service, and the WTRU may submit packets associated with the service with the new QoS-related attributes.

[0311] Some examples include per-packet admission control. For example, the WTRU may perform per-packet admission control each time a packet is received from an upper layer for transmission on a SL. In some examples, admission control decisions for individual packets may be based on the methods described for establishing admission control for unicast and / or multicast links, possibly including certain changes and / or constraints. Such changes and / or constraints may include: WTRU measurements, metrics, and / or estimates of resource usage for admission control may be limited to PDB or latency requirements associated with the packet to be transmitted; WTRU measurements, metrics, and / or estimates of resource usage may use worst-case values ​​rather than averages; decision criteria (e.g., thresholds for comparison to WTRU measurements / metrics / resource usage) may be different for per-packet admission control as compared to link and / or SLRB admission control; based on the conditions described herein, such as regarding temporary admission of packets despite admission control failure, a failed admission control may be tolerated, where the advantage of a failed admission control may be to avoid tearing down an established link and / or SLRB (e.g., as a result of preemption) in order to meet QoS for a single or small number of packets. In some such cases, one or more packets that failed admission control may be temporarily allowed, for example, because the desired service may temporarily exceed the QoS capabilities of the resources.

[0312] In some examples, the WTRU may perform one of multiple operations based on the result of admission control, for example: in the event of successful admission control, the packet may be submitted for transmission to a lower layer (e.g., a MAC / PHY layer) subject to a normal resource selection process; in the event of a failure in admission control, the WTRU may initiate a preemption of its own transmission (e.g., by releasing an SLRB) or another WTRU transmission (e.g., by transmitting a preemption signal); in the event of a failure in admission control, the WTRU may notify an upper layer of the failure; in the event of a failure in admission control, the WTRU may negotiate and / or select new QoS-related attributes for the broadcast service, wherein the WTRU may submit packets associated with the service having the new QoS-related attributes; and / or, in the event of a failure in admission control, the WTRU may still transmit packets that failed admission control based on the rules for temporary admission of failed admission control packets discussed herein.

[0313] Some examples include temporary admission of a packet despite a failure of admission control for the packet. For example, the WTRU may be configured or pre-configured with a rule to allow (i.e., admit) packets for which admission control failed. In some examples, if admission control for a packet fails, this may mean or indicate that the WTRU cannot maintain QoS for the existing link while ensuring QoS for the service subject to per-packet admission control.

[0314] In some examples, the rules for per-packet admission control may be based on the total number of admission packets that fail admission control allowed for a given service. For example, the WTRU may determine the total number (i.e., maximum) of packets that fail admission control during the service duration, where if this number is exceeded during the service lifetime, the WTRU may no longer admit such admission control failed packets.

[0315] In some examples, the rules for per-packet admission control may be based on a rate of failed admission control packets that may be sent, or based on a fixed number of failed admission control packets allowed per predefined time period or time window, where the rate / number / window may be defined per broadcast service or across all broadcast services. For example, the WTRU may determine a rate, such as failed packets per second, that is allowed and additional failed admission control packets exceeding this rate may not be transmitted and / or an indication may be initiated to upper layers and / or a preemption procedure may be initiated.

[0316] In some examples, the rules for per-packet admission control may be based on the maximum number of consecutive broadcast packets that may be associated with a given service for which admission control has failed. For example, the WTRU may determine the number of consecutive packets for which admission control has failed before indicating to upper layers and / or before performing preemption.

[0317] In some examples, the rules for per-packet admission control may be based on the allowable time between packets that may fail admission control associated with a single broadcast service or across all broadcast services. For example, the WTRU may determine the minimum required time between packets that fail admission control and continue to transmit these packets without taking failure action, for example, as long as the time difference between failed admission controls is greater than the calculated minimum value.

[0318] Some examples may include factors used to determine parameters related to temporary admission. For example, the WTRU may determine any of the parameters discussed above for admission control for temporary admission failure of a packet based on one or a number of factors.

[0319] In some examples, factors used to determine parameters related to temporary admission may include the number of unicast and / or multicast and / or broadcast links / SLRBs currently established on a carrier, carrier, BWP, pool, and / or pool in which packet transmission is required. In some examples, factors used to determine parameters related to temporary admission may include QoS attributes (e.g., VQI associated therewith) of one or more currently established links / SLRBs on the same pool, BWP, and / or carrier as the transmission of the broadcast service. In some examples, factors used to determine parameters related to temporary admission may include QoS attributes (e.g., VQI associated therewith) of packets to be transmitted, such as latency, priority, PDB, reliability, etc. of the transmission. In some examples, factors used to determine parameters related to temporary admission may include the measured CBR of the pool, carrier, and / or BWP on which the service and / or packet can be transmitted. Such determinations (e.g., the relationship between the allowable failure rate and the VQI of one or more currently established SLRBs) may be further configured or preconfigured at the WTRU.

[0320] In some examples, the WTRU may be configured to perform admission control for packets associated with a broadcast service by measuring the CBR of one or more resource pools that may be used to transmit the packets. For example, if the CBR measured on the pool is above a configured threshold, the WTRU may determine that admission control for the packet has failed. In some examples, if the time between arrivals of packets with failed admission control is at least a threshold time (e.g., X), the WTRU may allow transmission of lower layers despite the admission control failure for the packet. The value of X may be determined by the WTRU, for example, based on a mapping of the VQI of a particular broadcast packet for which admission failure was configured to X.

[0321] In some examples, the WTRU may be configured to perform admission control for broadcast packets by determining the worst case resource usage associated with all established SLRBs, such as based on decoding of the UMUS, and comparing the percentage of resource usage to the total amount of resources to a threshold. In some examples, if the calculated resource usage is above the threshold when a broadcast packet arrives, it may be considered that admission control for the packet has failed. In some examples, the threshold may be determined by the WTRU based on a configuration or preconfigured mapping of the VQI of the broadcast packet. In some examples, the WTRU may allow a broadcast packet admission control failure rate, where the WTRU still performs the transmission of such a broadcast packet. The rate of allowed failed broadcast packet admission control may be configured or preconfigured based on the VQI of the worst case or best case QoS of any active SLRB determined by the UMUS. For example, the WTRU may be configured or preconfigured with a mapping from VQI (i.e., for the worst case or best case SLRB) to an allowed failure rate, and such a rate may be used to temporarily allow packets that fail admission control.

[0322] Some examples include methods, systems, and devices for unicast and / or multicast link maintenance. For example, the WTRU may be configured to transmit one or more reference signals when a link is established. In some examples, the WTRU may be configured to transmit one or more reference signals when a link is established for sidelink link maintenance. For example, the WTRU may start transmitting such reference signals after a link is successfully established from an upper layer or from an RRC, and may stop transmitting these reference signals after the link is released. In some examples, the WTRU may change its reference signal configuration based on the number and / or type of radio bearers established for the link.

[0323] The WTRU may transmit one reference signal configuration for all established unicast and / or multicast links. In this case, the WTRU may start transmitting reference signals when the first link is established and stop transmitting reference signals when the last remaining link is released. Alternatively, the WTRU may transmit a different set of reference signals (e.g., different time / frequency resources, different sequences, different PHY layer attributes) for each unicast and / or multicast link and may start / stop reference signal transmission for the associated link when establishing / releasing the link.

[0324] Some examples include reference signal reception. For example, the WTRU may monitor and / or measure reference signals for link monitoring after establishing a unicast and / or multicast link. The WTRU may be configured (e.g., via RRC) with specific time, frequency, and / or beam resources associated with the location of reference signals. In some examples, such configuration may be provided to the WTRU by a peer WTRU or by a gNB during link establishment signaling. In some examples, the WTRU may stop monitoring / measuring reference signals for a particular unicast and / or multicast link after link release or after the last active link for that WTRU is released.

[0325] Some examples include determination of reference signals, unicast configuration, and / or monitoring of multicast links. For example, the WTRU may select a reference signal configuration from a shared resource. In some examples, a Mode 2 WTRU may determine the time, frequency, and / or beam position of a reference signal that it needs to transmit, and / or the time, frequency, and / or beam position of a reference signal transmitted by other WTRUs in a unicast and / or multicast link. For example, the WTRU may perform resource selection to reserve a set of time, frequency, and / or beam resources for reference signal transmission by itself and possibly by other WTRUs in a unicast and / or multicast group. In some examples, after the WTRU selects the resources, the WTRU may transmit a long-term reservation signal to reserve such RS resources indefinitely. In some examples, such a reservation signal may be sent on the PSCCH (e.g., a transmission similar to the SCI) and may include a resource configuration for the reference signal, for example, from a configured or pre-configured set.

[0326] In some examples, the WTRU may perform a resource selection process to select one or more resource sets and / or configurations for reference signal transmission from available or predefined / preconfigured resource sets. For example, the WTRU may select a preconfigured resource set for RS based on sensing results, similar to data resource selection. In some examples, the WTRU may perform one or more actions during resource selection of reference signal resources. In some examples, the action may include limiting the WTRU (e.g., via configuration) to only select a resource set associated with a resource set from multiple predefined or preconfigured sets, where the resource set is associated with a transmission reference signal for a single unicast and / or multicast link. In some examples, the action may include the WTRU using different thresholds to determine resource occupancy based on data transmission, or using thresholds associated with the maximum or minimum priority, reliability, and / or range values ​​configured by the network. In some examples, the action may include if multiple resource sets are determined to be available during resource selection, the WTRU selects the resource set with the smallest RSSI. In some examples, the action may include if a plurality of resource sets are determined to be available during resource selection, the WTRU selecting a resource set based on a hash function associated with a link ID, a source L2 ID, or a target L2 ID. In some examples, the action may include if the WTRU cannot find available resources for the reference signal, the WTRU transmitting a preemption signal to preempt other transmissions that may be utilizing the resources, wherein the preemption may be directed to preempting transmissions associated with a particular transmission type (e.g., broadcast, unicast, or multicast) of a particular priority or a particular other QoS parameter (VQI); and / or the WTRU may consider transmission of a reference signal as the highest priority during the resource selection process.

[0327] Some examples include determining the reference signal configuration based on a unique WTRU ID, a link ID, or a bearer ID. For example, the WTRU may transmit a reference signal on a set of time, frequency, and / or beam resources reserved for reference signal transmission. In some examples, such resources may not be used for transmission of PSSCH and PSCCH. In some examples, the WTRU may be configured with one or more sets and / or configurations of reference signal resources per carrier and / or BWP. Alternatively, the WTRU may be configured with one or more sets and / or configurations of reference signal resources per transmit pool, and may select only the reference signal configuration associated with the pool to be used for unicast and / or multicast transmissions.

[0328] In some examples, to avoid collisions between reference signal transmissions, the WTRU may select a resource configuration for reference signal transmission. The WTRU may make this selection based on: a unicast and / or multicast link ID, which may be assigned by the network or upper layers (e.g., where the ID is unique); a source ID of the WTRU transmitting the reference signal; a destination ID of the WTRU to which the reference signal is transmitted, or an L2 ID associated with a unicast and / or multicast link, if any; a destination ID associated with the service; a C-RNTI of the WTRU; or a radio bearer ID.

[0329] In some examples, a WTRU associated with a unicast and / or multicast link may monitor reference signals associated with the link and may determine the time, frequency, and / or beam positions of those reference signals based on: based on the reference signal configuration; based on a unique ID associated with the unicast and / or multicast link, which may be equal to an L2 source ID, an L2 destination ID, an assigned unicast and / or multicast link ID from upper layers or from the network; based on a radio bearer ID; and / or based on a WTRU ID that is unique within a unicast and / or multicast group.

[0330] Some examples include configuring reference signals for a multicast link (e.g., a link including more than 2 WTRUs). In some examples, the WTRU may monitor a different set of reference signals for each WTRU transmitting in the multicast group, and each reference signal set may be associated with a transmission from a different WTRU. In some examples, a transmitting WTRU may transmit its link-based reference signals on the set associated with its own transmission.

[0331] In some examples, the WTRU may be provided with a configuration of possible reference signal time, frequency, and / or beam positions associated with a dedicated physical channel. In some examples, the WTRU may also be configured with a mapping of resources associated with each other (e.g., definition of resource sets). In some examples, the WTRU may use modulo arithmetic to select a resource set to be used for transmission and / or reception of a reference signal based on a configured unicast and / or multicast link ID (e.g., where the reference set is modulo WTRU ID=0).

[0332] In another example, a WTRU may identify a reference signal or reference resource set transmitted by the WTRU based on a unique WTRU ID assigned to the WTRU that is unique in a unicast group. For example, in a multicast group of 3 WTRUs, the WTRUs may be assigned different IDs 1, 2, and 3, and the reference signal transmitted by one of the WTRUs (WTRUx) may correspond to the "xth" reference signal set assigned for the multicast link.

[0333] Some examples include bearer-specific reference signal configurations. For example, the WTRU may be configured with different resource sets for reference signal transmission and / or reception for different radio bearers within the same multicast link. In some examples, the WTRU that transmits and / or receives may transmit and / or receive a greater density of reference signals for radio bearers with stricter reliability requirements. In some examples, the WTRU may transmit and / or receive on different reference signal resource sets for different active radio bearers. Alternatively, the WTRU may transmit and / or receive on a reference signal resource set associated with a radio bearer with worst-case performance requirements. In this case, if a radio bearer is established or removed, or if the WTRU maintains the same configuration, the WTRU may change the reference signal configuration (e.g., from configuration 1 to configuration 2). In some examples, the decision whether to change or maintain the configuration may depend on the QoS characteristics associated with the bearer. In some examples, the WTRU may be configured with a mapping of radio bearers (e.g., radio bearer types) to reference signal configurations.

[0334] Some examples include procedures for changing reference signal configuration due to an ID change. For example, the WTRU may need to change its source L2 ID, for example for security purposes, such as based on a decision by upper layers. In some examples, the WTRU's transmit and receive reference signals may need to be synchronized during an ID change.

[0335] In some examples, a WTRU receiving an indication to change an ID used to determine a reference signal location may determine a subframe and / or time slot (n) relative to a reception time of an upper layer indication. In subframe / time slot n, the WTRU may stop transmitting reference signals with the old configuration and may start transmitting reference signals with the new configuration. In some examples, a WTRU monitoring a reference signal may operate in the same manner or substantially the same manner from a reception perspective. For example, in subframe or time slot (N), the WTRU may stop monitoring reference signals according to the old configuration and may start monitoring reference signals according to the new configuration. In this case, the transmitting and / or receiving WTRU may determine the value of N based on an indication from an upper layer; change the ID based on a defined time position after receiving the upper layer indication (e.g., subframe N may be the first occurrence of subframe 0 after receiving the upper layer indication, which is at least a threshold (k) subframes after the indication); and / or based on reception in RRC signaling (e.g., a source WTRU may determine the timing of the reference signal configuration change and indicate the timing to one or more other WTRUs in a unicast and / or multicast link using an RRC message). In some examples, the receiving WTRU may be configured to discontinue monitoring of the reference signal for a period of time immediately after receiving the upper layer indication. In some examples, the WTRU may start monitoring based on the new configuration at subframe N after receiving the indication, where N may be determined in the same manner as previously described.

[0336] In some examples, the WTRU may determine its sidelink monitoring parameters based on the active SL radio bearers. In some examples, the WTRU may perform a sidelink monitoring procedure based on measurements of reference signals transmitted by other WTRUs on the sidelink. In some examples, the WTRU may perform multiple independent SL monitoring procedures. Such monitoring procedures may be performed for: each unicast and / or multicast link, each radio bearer on each unicast and / or multicast link (e.g., if multiple radio bearers are associated with a single link); and / or for each WTRU associated with a multicast link. In some examples, the sidelink monitoring procedure may include monitoring a quality metric from a reference signal transmitted by another WTRU (e.g., RS-RSRP, BLER on PSCCH or PSSCH, etc.), and indicating to the upper layer when the metric is below a threshold within a threshold time.

[0337] The WTRU may determine its RLM / RLF parameters and procedures based on the VQI associated with the bearer. For example, a SL bearer may be associated with one or more VQIs. In some examples, the WTRU may also be configured to have an RLM / RLF configuration for each VQI, and if a bearer with such a VQI is active, the associated configuration may be applied. In some examples, a bearer with multiple mapped VQIs may be associated with the VQI based on: the numerical value of the VQI, where the WTRU selects the VQI with the lowest or highest number; and / or based on one or more QoS parameters derived from the VQI, where the WTRU may derive a set of QoS-related parameters from the VQI, such as priority, latency, reliability, etc. In some examples, the WTRU may determine one or more derived QoS parameters (e.g., reliability only), and may determine the use of the VQI with the most stringent value among those requirements. In some examples, the WTRU may implicitly change its monitoring procedures and / or parameters when bearers are added and / or removed, for example based on the above rules.

[0338] In some examples, VQI-specific RLM / RLF configurations may include: target PSSCH / PSCCH BLER; target RS-RSRP; frequency of RLM-like indications to upper layers (e.g., RRC; for example, how often the PHY layer can report that RSRP is below a target); and / or timers (e.g., RLF-like timers).

[0339] Some examples include monitoring procedures and / or parameters for each unicast and / or multicast link. In some examples, the WTRU may determine its monitoring procedures and / or quality metrics based on the QoS characteristics of one or more of its active SL bearers. For example, the WTRU may perform a single monitoring procedure with a single set of parameters and select such procedure / monitoring parameters based on a set of currently active SL radio bearers for unicast and / or multicast links. In some examples, the WTRU may select procedures and / or parameters based on "worst case" bearer requirements. For example, RB type 1 and RB type 2 may be configured at the WTRU, each with their own procedures / parameters, where RB type 1 is considered to have a higher priority than RB type 2. In some examples, if two bearers are configured simultaneously, the WTRU performs monitoring based on the parameters of RB type 1. Otherwise, when a single bearer is active, the WTRU may apply the procedures and / or parameters associated with that bearer.

[0340] In some examples, the WTRU may be configured with a parameter derivation function (e.g., average BLER, weighted average BLER, etc.) to derive monitoring procedures and / or parameters for an active radio bearer combination and may apply the procedures and / or parameters if the bearer combination is active. Otherwise, when a single bearer is active, the WTRU may apply the procedures and / or parameters associated with that bearer.

[0341] In some examples, the WTRU may maintain multiple processes and / or parameters. For example, the WTRU may maintain parallel processes (e.g., executed in parallel and independently) and parameter sets for each SL radio bearer, which may be associated with the same or different unicast and / or multicast links, or sets of SL radio bearers. For example, the WTRU may independently report a measured reference signal quality (RS_QUAL) < target for each radio bearer, where each SL radio bearer may be configured with a different reference signal set. In another example, the same reference signal set may be transmitted for all radio bearers, but the WTRU may monitor based on different target qualities and report events independently for each of the different qualities.

[0342] In some examples, if a SL radio bearer is configured with different VQIs that may be associated with different VQI ranges, the WTRU may maintain multiple procedures and / or parameters for a single SL radio bearer. For example, the WTRU may be configured to have a set of procedures and / or parameters for each VQI range. In some examples, if a radio bearer containing flows from different VQI ranges is established, the WTRU may perform multiple monitoring procedures using independent parameters associated with each range of the bearer.

[0343] In some examples, the WTRU may be configured with different link failure timers (e.g., T1 and T2) that may be used to monitor different qualities. Depending on the quality of the monitored failure, the WTRU may initiate an appropriate timer and indicate a link failure to upper layers (e.g., NAS) or to the network upon or after expiration of the timer. If a link failure is declared, the WTRU may also indicate which link timer expired.

[0344] In some examples, the WTRU may maintain independent procedures and / or parameters for each WTRU in a multicast link. In some examples, the WTRU may report RLM-like events to upper layers independently for each WTRU in a multicast link. In some examples, the WTRU may determine a target quality measurement based on initial measurements derived during link establishment. For example, the target quality for link monitoring may be a percentage or a value derived from the discovery quality or the quality of link establishment message transmission measured during unicast and / or multicast link establishment.

[0345] In some examples, a WTRU associated with a multicast link may require a link failure procedure associated with the multicast link. In some examples, a link failure may be associated with various conditions, such as determining that link quality is below a target for some possibly continuous period of time based on reference signal monitoring.

[0346] In some examples, the WTRU may report a link failure independently for each WTRU in a multicast link. For example, the WTRU may declare a link failure associated with the multicast link and further indicate one or more WTRUs for which the link failure occurred (e.g., based on independent monitoring of reference signals transmitted by each of those WTRUs).

[0347] In some examples, if the monitoring indication quality associated with a subset of WTRUs in the multicast link is below a target for a configured period of time, the WTRU may report a link failure. In some examples, the WTRU may determine a specific subset of WTRUs based on upper layer configuration (e.g., application or RRC) or relative location.

[0348] In the case where the WTRU determines a specific subset of WTRUs based on upper layer configuration, the WTRU may be explicitly configured with a set of WTRUs for which link failure should occur, or the WTRU may derive the WTRU subset based on another configuration aspect, such as relay configuration, queue configuration and identification of each WTRU role, resource selection configuration (if WTRU-assisted resource selection is used), and / or synchronization source configuration. In the case where the WTRU determines a specific subset of WTRUs based on relative location, the WTRU may indicate a link failure if the subset of WTRUs closest / farthest from the WTRU experiences a link failure.

[0349] Some examples include additional triggering of link failures based on admission control metrics. For example, a WTRU with established radio bearers may perform measurements that are the same as, or substantially similar to, those admission controls, and may declare a link failure based on the failure of one or consecutive admission control evaluations associated with the SL radio bearer. In some such cases, assuming that the bearer to be added is a bearer for which link monitoring is being performed, the WTRU may utilize any of the mechanisms described herein regarding admission control. In some examples, the WTRU may perform such admission control independently for each established SL bearer. In some examples, the WTRU may utilize different timing based on the SLRB to perform the associated admission control procedures.

[0350] Without loss of generality, the WTRU may perform link monitoring by performing one or more admission control procedures as described herein, which are performed while the link or SLRB is active. In some examples, a link failure may further result in any failure action described for admission control, such as an indication to upper layers, removal of a link and / or SLRB, and / or preemption of another SLRB / link.

[0351] In some examples, the WTRU may be configured with a periodicity for deriving an admission control procedure. In some examples, the periodicity may be determined for each bearer. In some examples, based on the failure of a single admission control procedure, the WTRU may change the frequency of the admission control procedure performance, or may perform multiple subsequent admission control procedures for the radio bearer until the procedure succeeds, or until a maximum number of failed performances is reached. In some examples, if the admission control procedure fails a threshold number (N) of times in a row, the WTRU may thereafter trigger a link failure.

[0352] In some examples, the WTRU may periodically evaluate information in the UMUS signal and, based on that information, may determine whether the total availability of a given pool exceeds a certain amount. In some examples, for the availability of a bearer being monitored, the WTRU may consider: the availability resources broadcasted for the bearer; the actual amount of resources used by the bearer over past time configurations; and / or the amount of data available at the WTRU's buffer associated with the bearer.

[0353] Some examples may include additional triggers for link failures based on resource selection metrics. For example, the WTRU may declare a link failure based on a resource selection failure, or based on some aspect related to the result or an intermediate quantity related to the resource selection algorithm. In some examples, when considering a link failure for a particular link and / or bearer, the WTRU may consider the resource selection algorithm results for intermediate quantities of resource selection specific to that link or bearer. In some examples, the WTRU may declare a link failure for a unicast and / or multicast link or one or more SL bearers associated with the link based on certain events occurring one or more times (possibly consecutively). Such events may include: resource selection is unable to find a threshold amount (X%) of resources available with a constant resource availability threshold; resource selection is unable to reserve a sufficient amount of resources to meet the QoS of the bearers on a single carrier / BWP; the resources selected for transmission of PSCCH and / or PSSCH have an RSRP / RSSI above a threshold; the percentage of "low latency" type resources (e.g., symbol-based resources) deemed available by sensing is below a threshold; the WTRU receives a NACK for unicast and / or multicast transmissions; the WTRU fails the LBT process; and / or wherein the WTRU receives a preemption signal for a radio bearer for a time that may last greater than a threshold (T).

[0354] In some examples, the WTRU may be configured with different sets of link failure criteria that apply depending on a particular radio bearer. For example, the WTRU may be configured with one or more of the above criteria based on a VQI or QoS related parameter associated with the bearer. In some examples, the WTRU may also be configured with different parameters (e.g., the number of consecutive failures that result in a link failure declaration, X%, the value of T, other parameters discussed herein, etc.).

[0355] Some examples may include additional triggers for link failures based on CBR. For example, the WTRU may declare a link failure based on a measured value of CBR. Specifically, the WTRU may monitor CBR on pool(s) / carrier(s) / BWP(s) for unicast and / or multicast links. The WTRU may be configured to have a CBR target per radio bearer, or a CBR target per VQI / QoS. The WTRU may declare a link failure for a CBR measured on a pool(s) / carrier(s) / BWP(s) that falls above a configured threshold. The WTRU may further declare a link failure when such a target is exceeded for a configurable time period.

[0356] In some examples, depending on the type of link failure, a WTRU detecting a link failure may perform one or more actions. Such actions may include triggering group QoS negotiation / resource selection with new resources (e.g., if the link failure process is based on failure of a specific radio bearer or QoS target, the WTRU may choose to initiate a QoS renegotiation process similar to the process performed during initial link establishment); notifying upper layers and / or other WTRUs to remove one or more WTRUs from a multicast group (e.g., if the link failure is only related to one or a subset of WTRUs in the multicast group); initiating a temporary fallback to broadcast process as discussed herein; changing a resource selection mode from one type of mode to another (e.g., a WTRU may initiate a request to change the resource selection mode to mode 1 for a specific bearer); notifying upper layers and / or the network of the failure to meet QoS requirements; initiating link release signaling; and / or releasing all resources associated with the link, including TX / RX of reference signals, unlimited reserved resources, and stopping transmission of UMUS.

[0357] In some examples, the WTRU may include information with any link failure declaration signaling to upper layers, to other WTRUs in the link, or to the network. Such information may include: the RLM / RLF procedure / process ID that declared the failure; the one or more WTRUs that failed in the multicast link; the one or more specific bearers that triggered the failure; and / or the cause of the failure (e.g., CBR above a threshold, etc.) and any associated values.

[0358] In some examples, the WTRU may initiate a temporary fallback to broadcast-based transmission. In some examples, the WTRU may continue to transmit data received for a specific SL bearer, but such data may be transmitted in a broadcast manner and the lower layer AS parameters are set to broadcast. For example, the WTRU may change from using a unicast address to a broadcast address; may change from radio bearer-based resource selection / reservation to non-radio bearer-based resource selection / reservation; may change from using HARQ-based transmission to no HARQ / blind retransmission; may change from beam-based transmission to omni-directional or beam scanning transmission; may disable transmission / monitoring of reference signals for RLM and / or beam management; disable encryption and / or integrity protection of the transmitted data; and / or may change the AS layer configuration of any other parameters from a unicast-based configuration to a broadcast-based configuration. During the temporary fallback to broadcast, the WTRU may maintain the unicast and / or multicast configuration for the temporary fallback.

[0359] In some examples, the WTRU may initiate any one or more parts of the link establishment procedure during the fallback. Alternatively, the WTRU may initiate a link establishment procedure or a link reestablishment procedure, thereby maintaining at least some parts of the current configuration (e.g., QoS, AS, etc.). In some examples, the WTRU may immediately notify the upper layer of the fallback. Alternatively, the WTRU may notify the upper layer of the time (T) after the fallback occurs and if the link establishment and / or reestablishment is unsuccessful.

[0360] In some examples, if the WTRU detects a link failure that may be associated with certain reasons; if the WTRU receives a preemption signal that is potentially associated with a preemption time value that is below a threshold (e.g., associated with the QoS of the bearer); and / or if the WTRU moves out of coverage, potentially if unicast and / or multicast links are being managed by the network (e.g., Mode 1), the WTRU may perform a temporary fallback procedure.

[0361] Some examples include methods, systems, and devices for stream-to-bearer mapping for SL unicast and / or multicast. For example, in SL bearer modeling, if one or more streams are initiated, a SL bearer or SL logical channel may be created. In some examples, the SL bearer or SL logical channel is associated with an AS layer configuration. AS layer configuration may include a set of reserved resources, or be associated with a required amount of resources; may include resource selection and / or reservation methods (e.g., LBT, sensing, periodic resources, use of WTRU assistance, etc.); may include resource selection pools, carriers, BW and / or BWP; may include resource selection parameters, such as resource selection window (T2), LBT back-off timer, sensing threshold, periodicity of resources, amount of resources per cycle, number of repetitions, number of beams, etc.; may include multiple carriers; may include an indication of the ability to use preemption and preemption resource configuration; may include directionality and / or beam configuration of transmission; may include pools, BWP, etc.; may include PHY and / or MAC layer parameters (e.g., HARQ configuration, replication); may include RLM / RLF configuration (e.g., RLF timer, RLM target BLER / RSRP); and / or may include QoS configuration, such as rules for mapping flows to bearers, QoS profile information, and mapping bearer types to AS configurations.

[0362] In some examples, the WTRU may be configured to initiate or create a bearer with a specific configuration or range of configurations if a flow with a specific QoS requirement is initiated. In some examples, such requirements may be determined based on the VQI of the flow (e.g., flows of certain VQIs or ranges of VQIs may require bearers with specific configurations). In some examples, the WTRU may be configured with a mapping of bearer types or bearer configurations to VQIs.

[0363] In some examples, the WTRU may be configured with a mapping of flows to radio bearers based on one or more rules or principles. For example, the WTRU may be configured such that flows with less stringent QoS characteristics than the established radio bearer may be mapped to that bearer (e.g., rate-dependent flows require a new bearer); the WTRU may be configured such that flows with very different QoS characteristics require the establishment of a new radio bearer (e.g., the WTRU may be configured or preconfigured with a mapping of VQI to radio bearer type, or the WTRU may be configured or preconfigured with a maximum difference in flow characteristics, such as a difference in data rate); and / or the WTRU may be configured for directionality (e.g., flows with the same intended direction or geographic location may be mapped to the same radio bearer or flow as a subset of the radio bearer directionality).

[0364] In some examples, the WTRU may perform bearer reconfiguration or new bearer creation depending on whether the new flow can be mapped to an existing bearer type.

[0365] Fig. 9 is a flow chart illustrating an example method 900 for determining whether to establish a SLRB.

[0366] The WTRU is configured with SLRB resource selection criteria in step 910. The resource selection criteria may include a service quality indicator (VQI).

[0367] In step 920, the WTRU receives a plurality of SCI transmissions from at least one other WTRU in the pool during a time window.

[0368] In step 930, for each of a plurality of time periods within the time window, the WTRU determines in step 940 whether the SLRB resource selection process will fail based on the plurality of SCI transmissions and the SLRB resource selection criteria. In some examples, the WTRU determines whether the SLRB resource selection will fail based only on time periods in the plurality of time periods where a packet delay budget (PDB) is below a threshold. In some examples, the WTRU determines whether the SLRB resource selection will fail based only on time periods in the plurality of time periods where a number of retransmissions is above a threshold.

[0369] In step 950, the WTRU determines a percentage of SLRB resource selection procedures that will fail. In some examples, determining the percentage of SLRB resource selection procedures that may fail includes determining what percentage of time periods within the time window include SLRB resource selection procedures that may fail, or includes determining what percentage of SLRB resource selection procedures in the time window will fail.

[0370] Under the condition 960 that the percentage of time periods during which SLRB resource selection within the time window will fail is below a threshold percentage, the WTRU establishes a new SLRB with another WTRU in the pool. Under either condition 960, the WTRU returns to step 920 to start the process again for the next time window, or ends if appropriate.

[0371] Fig.10 is a flow chart illustrating another example method 1000 for determining whether to establish a SLRB.

[0372] In step 1010, the WTRU is configured with a mapping of bearer QoS to SLRB resource density.

[0373] At step 1020, the WTRU receives a broadcast (e.g., a periodic broadcast) indicating the QoS of the SLRB of another WTRU in a pool with the WTRU. In some examples, the broadcast comes from multiple other WTRUs in the pool, each WTRU indicating the QoS of the SLRB of the WTRU from which the broadcast is received.

[0374] In step 1030, the WTRU determines the total SLRB resource density in the pool based on the QoS and mapping received from the broadcast. In some examples, the WTRU determines the total SLRB resource density based on broadcasts from multiple other WTRUs in the pool.

[0375] Under condition 1040 that the total resource density does not exceed a threshold, which may be based on the QoS of the new SLRB, the WTRU establishes a new SLRB with another WTRU in the pool in step 1050. Under either condition 1040, the WTRU returns to step 1020 to start the process again, or ends if appropriate.

[0376] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware, which is incorporated into a computer-readable medium to be executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A method for establishing a sidelink radio bearer (SLRB) for a quality of service (QoS) flow, the method comprising: selecting a SLRB configuration for the SLRB to be established from a plurality of SLRB configurations, the selection being based on values ​​associated with the QoS flow and a mapping of values ​​to the SLRB configurations; as well as A sidelink reconfiguration message is transmitted to a peer WTRU, the sidelink reconfiguration message including a selected subset of SLRB configurations, the subset being based on capabilities of the peer WTRU.

2. The method according to claim 1, further comprising: receiving, from the peer WTRU, an acknowledgement message in response to the sidelink reconfiguration message; In response to the confirmation message, establishing the SLRB; as well as Data associated with the QoS flow is transmitted to the peer WTRU over the established SLRB.

3. The method of claim 1, wherein the value associated with the QoS flow comprises a quality indicator.

4. The method of claim 1, wherein the value associated with the QoS flow comprises a vehicle-to-everything (V2X) quality of service indicator (VQI).

5. The method of claim 1, wherein the value associated with the QoS flow comprises a PC5 Quality Indicator (PQI).

6. The method of claim 1, wherein the sidelink reconfiguration message comprises an RRC reconfiguration message.

7. The method of claim 1, wherein the SLRB configuration comprises: Logical channel (LCH) configuration, feedback configuration, channel quality indicator (CQI) configuration, and / or stream to SLRB mapping.

8. The method of claim 1, wherein the subset of the SLRB configuration comprises: Logical channel (LCH) configuration, feedback configuration, channel quality indicator (CQI) configuration, and / or stream to SLRB mapping.

9. The method of claim 1, further comprising triggering establishment of the SLRB in response to the QoS flow being mapped to the SLRB.

10. A wireless transmit / receive unit (WTRU) configured to establish a sidelink radio bearer (SLRB) for a quality of service (QoS) flow, comprising: a processor operatively coupled to the transmitter and the receiver; The processor is configured to select a SLRB configuration for the SLRB to be established from a plurality of SLRB configurations, the selection being based on values ​​associated with the QoS flow and a mapping of values ​​to the SLRB configurations; as well as The transmitter is configured to transmit a sidelink reconfiguration message to a peer WTRU, the sidelink reconfiguration message including a selected subset of SLRB configurations, the subset being based on capabilities of the peer WTRU.

Images