CN112997565A - L2 procedure for unicast and/or multicast link establishment and maintenance - Google Patents

Abstract

Systems, methods, and devices for unicast and/or multicast link establishment and maintenance. A Wireless Transmit Receive Unit (WTRU) may send a link setup request broadcast message, where the link may be for multicast, unicast, or multicast. The WTRU may receive a link setup response broadcast message and a connection report. Once the multicast or unicast link has been established, the WTRU may send a link establishment confirmation broadcast message, at which point the WTRU may send and receive multicast messages. The link establishment 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 unicast and/or multicast availability signals (UMUS). The WTRU may preempt an established multicast or unicast link.

Description

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

Cross Reference to Related Applications

This application claims the benefit of the following applications: U.S. provisional application No.62/736,251 filed on 25/09/2018; U.S. provisional application No.62/752,865 filed on 30/10/2018; U.S. provisional application No.62/783,952 filed on 21.12.2018 and U.S. provisional application No.62/886,102 filed on 13.08.2019, the contents of each of these applications being incorporated herein by reference.

Background

The wireless communication use case may handle vehicle communications related to traffic, transportation, security, navigation, and the like. For example, vehicle-to-anything (V2X) communication may involve sending and receiving wireless communications to and from the vehicle. As wireless communication capabilities and requirements develop, it may be desirable to provide systems, methods, and devices that operate in such environments.

Disclosure of Invention

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 comprises the following steps: configuring SLRB resource selection criteria 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 criteria; and determining, by the WTRU, whether to establish a new SLRB based on a percentage of resource selection failures; and on a condition that a percentage of a time period for which resource selection is determined to fail is below a threshold percentage, establishing the new SLRB with other WTRUs in the pool.

Some embodiments provide a WTRU configured to determine whether to establish a 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 a plurality of SCI transmissions from another WTRU in the pool during a time window. The processor is configured to determine, for each of a plurality of time periods within a time window, whether SLRB resource selection will fail based on a plurality of SCI transmissions and SLRB resource selection criteria. The processor is further 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 on a condition that a percentage of a time period during which resource selection will fail is determined to be below a threshold percentage.

Some embodiments provide a method implemented in a WTRU for determining whether to establish an SLRB. The method comprises the following steps: configuring a mapping of bearer QoS to SLRB resource density for the WTRU; receiving, by the WTRU, a broadcast indicating a QoS for an SLRB of another WTRU in a pool; determining, by the WTRU, a total SLRB resource density in the pool based on the received QoS and the mapping; and determining, by the WTRU, 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 QoS of the new sidelink bearer. The method also includes establishing the new sidelink bearer with the another WTRU in the pool if the WTRU determines to establish the new sidelink bearer.

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 a quality of service (QoS) of an SLRB of another WTRU in the pool. The processor is configured to determine a total SLRB resource density in the pool based on the received QoS and a mapping of bearer QoS to SLRB resource density. The processor is further 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 QoS of the new sidelink bearer. The transmitter is configured to transmit a message to establish the new sidelink bearer with the another WTRU in the pool on a condition that the processor determines to establish the new sidelink bearer.

Drawings

The drawings are to be understood in more detail and not as limiting the scope of the embodiments, but as merely examples in connection with the accompanying drawings, wherein like reference numerals represent like elements, and in which:

FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

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

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

figure 1D is a system diagram illustrating another example RAN and another example CN that may be used within the communication system shown in figure 1A, according to an embodiment;

figure 2 is a message sequence chart illustrating an example link establishment procedure between two WTRUs;

FIG. 3 is a block diagram of a link establishment model illustrating an example process of connection establishment decisions performed by the AS layer;

FIG. 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 the AS layer;

figure 5 is a message sequence chart illustrating an exemplary sidelink establishment procedure between WTRUs at the AS layer;

fig. 6 is a message sequence chart illustrating example multicast link setup signaling and decision criteria;

fig. 7 is a message sequence chart illustrating example multicast link setup signaling;

FIG. 8 is a flow diagram illustrating an example process for admission control based on representative resource selection;

FIG. 9 is a flow diagram illustrating an example method for determining whether to establish a sidelink radio bearer (SLRB); and

fig. 10 is a flow diagram illustrating another example method for determining whether to establish a SLRB.

Detailed Description

Fig. 1A is a diagram illustrating 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 a plurality of wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, 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-tailed unique word DFT-spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), among others.

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

Communication system 100 may also include base station 114a and/or base station 114 b. Each base station 114a and/or 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN106/115, internet 110, and/or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102 d. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home enodebs, gnbs, NR node bs, site controllers, Access Points (APs), and wireless routers, among others. 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.

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 Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, known as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area that is relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., each transceiver corresponding to a sector of a cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, using beamforming, signals may be transmitted and/or received in desired spatial directions.

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

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

In 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 LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-APro).

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

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 collectively implement LTE radio access and NR radio access (e.g., using Dual Connectivity (DC) principles). As such, 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).

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 high fidelity (WiFi)), IEEE 802.16 (worldwide interoperability for microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000 EV-DO, temporary Standard 2000(IS-2000), temporary Standard 95(IS-95), temporary Standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), and GSM EDGE (GERAN), among others.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may facilitate wireless connectivity in a local area using any suitable RAT, such as a business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), and a road, among others. In one embodiment, the base station 114b and the WTRUs 102c, 102d may 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 may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, base station 114b need not access the internet 110 via CN 106/115.

The RAN 104/113 may communicate with a CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102 d. 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, and mobility requirements, among others. CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104/113 and/or CN 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 using NR radio technology, the CN 106/115 may communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

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

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers that communicate with different wireless networks over different wireless links). For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a using a cellular-based radio technology and with a base station 114b, which may use an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an example WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touch pad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU102 may include any subcombination of the foregoing elements while maintaining consistent embodiments.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive element 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated into an electronic component or chip.

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 a radiator/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 optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As 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 (e.g., NR and IEEE 802.11).

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

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

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (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 maintaining consistent embodiments.

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 peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, mass spectrometers, and the like,

Modules, Frequency Modulation (FM) radio units, digital music players, media players, video game modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, and activity trackers, among others. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer and azimuth sensor A sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic position sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

The WTRU102 may include a full duplex radio for which reception or transmission of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full-duplex radio may include an interference management unit that reduces and/or substantially eliminates self-interference via signal processing by hardware (e.g., a choke coil) or by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU102 may include a half-duplex radio that transmits or receives some or all signals, such as associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception).

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

RAN 104 may include enodebs 160a, 160B, 160c, however, it should be appreciated that RAN 104 may include any number of enodebs while maintaining consistent embodiments. Each enodeb 160a, 160B, 160c may include one or more transceivers that communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enodebs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102 a.

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, scheduling of users in the UL and/or DL, and so on. As shown in FIG. 1C, eNode Bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a mobility management gateway (MME)162, a Serving Gateway (SGW)164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing elements are described as being part of CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

The MME 162 may be connected to each enodeb 162a, 162B, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation/deactivation processes, and selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, among other things. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies (e.g., GSM or WCDMA).

The SGW 164 may be connected to each enodeb 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, 102 c. The SGW 164 may also perform other functions such as anchoring the user plane during inter-enodeb handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.

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

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., 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.

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

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

A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access another type of wired/wireless network that is either interfaced to a Distribution System (DS) or that carries traffic into and/or out of the BSS. Traffic originating outside the BSS and destined for the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs within the BSS may be transmitted through the AP, for example, in the case where the source STA may transmit traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as point-to-point traffic. The point-to-point traffic may be transmitted between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In some exemplary embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (tdls)). WLANs using Independent Bss (IBSS) mode do not have an AP and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, 40MHz wide channels formed by combining a 20MHz wide primary channel with 20MHz wide adjacent or non-adjacent channels.

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

802.11af and 802.11ah support operating modes below 1 GHz. The operating bandwidth and carriers of the channels used in 802.11af and 802.11ah are reduced compared to 802.11n and 802.11 ac. 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. In accordance with an exemplary embodiment, 802.11ah may support meter type control/machine type communication (e.g., MTC devices in a macro coverage area). MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., supporting only) certain and/or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a threshold (e.g., to maintain a long battery life).

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 may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA that is sourced by all STAs operating in the BSS and that supports the minimum bandwidth operating mode. In the example for 802.11ah, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes, the width of the primary channel may be 1MHz for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy (e.g., because STAs (which support only 1MHz mode of operation) transmit to the AP), the entire available band may be considered busy even though most of the band remains idle and available for use.

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

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

RAN 113 may include gnbs 180a, 180b, 180c, but it should be appreciated that RAN 113 may include any number of gnbs while maintaining consistent embodiments. 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 techniques. 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, 180 c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a. 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 102 a. A subset of the component carriers may be on the unlicensed spectrum and the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive a cooperative transmission from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with 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 wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) having different or scalable lengths (e.g., including different numbers of OFDM symbols and/or lasting different absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c without accessing other RANs, such as the enodebs 160a, 160B, 160 c. In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNB180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gnbs 180a, 180B, 180c while communicating/connecting with other RANs, such as the enodebs 160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c in a substantially simultaneous manner by implementing DC principles. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput to serve the WTRUs 102a, 102B, 102 c.

Each gNB180a, 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 processing between NR and E-UTRA, route user plane data to User Plane Functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185 b. While each of the foregoing elements are depicted as being part of the CN 115, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

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

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

The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. 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 connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface that interfaces to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185 b.

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

The simulated device may be designed to conduct one or more tests with respect to other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more simulated devices may perform one or more or all functions while implemented and/or deployed, in whole or in part, as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more or all functions while temporarily implemented or deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device to perform testing and/or may perform testing using over-the-air wireless communication.

The one or more emulation 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 may be used in a test scenario of a test laboratory and/or a wired and/or wireless communication network that is not deployed (e.g., tested) in order to conduct testing with respect to one or more components. The one or more simulation devices may be test devices. The simulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (which may include one or more antennas, as examples).

Vehicle-to-anything (V2X) communication may transfer information between a vehicle and other entities, such as other vehicles, Road Side Units (RSUs), pedestrian user equipment (e.g., WTRUs), etc. In some cases, the vehicle V2X communication includes a communication mode whereby the WTRUs communicate directly with each other. The V2X operations may include an in-coverage scene and an out-of-coverage scene. The in-coverage scenario may include the WTRU receiving assistance from the network to begin transmitting and receiving V2X messages. The out-of-coverage scenario may include the WTRU starting to transmit and receive V2X messages based on pre-configured parameters.

V2X communication may be supported by LTE and may involve operating on device-to-device (D2D) communication. 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. The V2V service may facilitate direct communication between vehicular WTRUs. The V2I service may facilitate communication between the vehicle WTRU and the RSU and/or eNB. The V2N service may facilitate communication between the vehicle WTRU and the core network. The V2P service may facilitate communication between a vehicle WTRU and a WTRU with special conditions (e.g., low battery capacity, etc.), and so on.

V2X communication may include different modes of operation for resource allocation. For example, LTE defines mode 3 and mode 4 operation. Mode 3 operation may include a network device, such as an eNB, providing a WTRU with resource scheduling assignments for V2X Sidelink (SL) transmissions. Mode 4 operation may include the WTRU autonomously selecting resources from a configured or pre-configured resource pool. V2X (e.g., LTE V2X) may include two types of resource pools: a receive pool and a send pool. The WTRU may monitor the V2X resources (e.g., time and/or frequency) in the receive resource pool to receive the V2X transmission. The WTRU may select a transmission resource from the V2X pool of transmission resources, for example, in mode 4 operation. In some embodiments, a WTRU configured for mode 3 operation may not use a transmission pool.

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 transmit 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.

The New Radio (NR) may support several use cases, such as enhanced mobile broadband (eMBB), ultra-high reliability and low latency (URLLC), and other technologies. Enhanced V2X (eV2X) communication may be used with NR systems. In NR, eV2X may accommodate new services for safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, vehicle formation, remote driving, etc.). Different eV2X services may require different performance requirements, such as the case requiring a 3ms delay.

The NR V2X may support several use cases, such as vehicle queuing, advanced driving, extended sensors, and remote driving.

Vehicle queues may enable vehicles traveling together to dynamically form groups. All vehicles in the fleet may receive periodic data from the lead vehicle for fleet operation. Such information may facilitate extremely small distances between vehicles (i.e., gap distances that translate into time, i.e., communication latency may be very low, e.g., sub-second latency). The fleet application may facilitate autonomous driving of vehicles following a leading vehicle.

Advanced driving may enable semi-automatic or fully automatic driving for greater inter-vehicle distances. For example, a V2X device may include a vehicle or other mobile node, and a Road Side Unit (RSU) or other fixed node. Each vehicle and/or Road Side Unit (RSU) may share data obtained from its local sensors with vehicles in its vicinity, allowing the vehicles to coordinate their trajectories or maneuvers. Further, each vehicle may share its driving intent with nearby vehicles. For example, the vehicle may send messages to other vehicles that include various information, such as changes in speed and/or direction, to indicate the vehicle's driving intent. Advanced driving may promote safer driving, collision avoidance, and improved traffic efficiency.

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

Remote driving may enable a remote driver or a 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 computing-based driving may be used to control or facilitate remote driving. A cloud-based backend service platform may be used for remote export. For example, a vehicle or other V2X device may exchange messages with a central server or cloud server to perform computations.

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

One-to-one ProSe direct communication may be achieved, for example, by establishing a secure layer 2 link between two WTRUs via PC 5. Each WTRU may have a layer 2ID for unicast communication that is included in the source layer 2ID field of each frame it transmits on the layer 2 link and in the destination layer 2ID 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. The WTRUs may participate in multiple layer 2 links for one-to-one ProSe direct communication using the same layer 2ID, e.g., because the layer 2 links are identified by a combination of the layer 2 IDs of each of the two WTRUs in the direct communication.

WTRUs participating in isolated (i.e., non-relayed) one-to-one communication may negotiate an IP address assignment mechanism and optionally exchange link-local IPv6 addresses if needed during link establishment.

Figure 2 is a message sequence chart illustrating an example process 200 for link establishment between a WTRU 210 and a WTRU 220. In a first step, the WTRU 210 may send a direct communication request message 230 to the WTRU 220 to trigger mutual authentication. The contents of the direct communication request message 230 may be referred to as user information. In a second step, the WTRU 220 initiates a procedure 240 for mutual authentication. Successful completion of the authentication process completes the establishment of the secure layer 2 link on PC 5. As part of this step, the WTRU 220 includes the user information in a response message to the WTRU 210.

The PC5 signaling protocol supports keep-alive functionality that can be used to detect whether WTRUs are not in ProSe communication range, in which case they can continue with implicit layer 2 link release.

NR V2X may include link setup enhancements (e.g., compared to D2D). For example, a procedure for establishing and maintaining a secure L2 link through the PC5 may be provided. This procedure 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 advertisement to inform peers of the WTRU's presence and the WTRU's capabilities (if any) for unicast communication (e.g., the channel on which the WTRU may operate for unicast, the services supported, etc.). This service announcement may be accessed by all WTRUs interested in using the service (e.g., an application). For example, such an advertisement may be configured to be sent over a dedicated channel (similar to how WAVE Service Advertisements (WSAs) are handled), or carried on (e.g., added or appended to) periodic messages from supporting WTRUs.

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

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

The same set of service requirements may apply to PC 5-based V2X communications and Uu-based V2X communications. Such QoS characteristics may be represented by, for example, 5 QI. Thus, a unified QoS model may be used for PC5 and uu (e.g., 5QI may also be used for V2X communication on PC5 so that the application layer may have a consistent way of indicating QoS requirements regardless of the link used).

A WTRU with 5GS V2X capability may support three different types of services: broadcast, multicast, and unicast.

The same QoS model as Uu may be used for unicast traffic (i.e., each unicast link may be considered a bearer and a QoS flow may be associated therewith). All QoS characteristics and additional data rate parameters defined in 5QI may be applied. Further, the minimum required communication range may be considered a specific additional parameter used by the PC 5.

The same or similar considerations may apply to multicast traffic, which may be considered a special case of unicast (i.e., with multiple defined receivers of the traffic).

For broadcast services, there may be no bearer concept; i.e. there is no association between the packet and the logical link with certain configuration parameters. Each broadcast message may have different characteristics depending on application requirements. The 5QI is correspondingly used in a manner similar to PPPP and/or ProSe per packet reliability (i.e., each packet is associated (or "marked") with a QoS value). The 5QI may have the capability to represent all of the characteristics (e.g., latency, priority, reliability, etc.) required for the PC5 broadcast operation. A specific 5G quality of service indicator (V2X 5QIs) or (VQI) may be broadcast for PC5 using a defined set of V2X.

The PC5 QoS parameters may be negotiated at the setup of a one-to-one communication process. Thus, the one-to-one communication setup procedure may be enhanced to support PC5 QoS parameter negotiation between two WTRUs. After PC5 QoS parameter negotiation, the same QoS may be used in both directions of one-to-one communication.

The example process 200 shown with respect to fig. 2 may be modified for the negotiation of PC5 QoS parameters between the WTRU 210 and the WTRU 220. For example, in a first step, the direct communication request message 230 may include the requested PC5 QoS parameters in addition to or instead of the user information. In a second step, the process 240 may include the accepted PC5 QoS parameter in a response message to the WTRU 210 in addition to or instead of the user information.

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, signaling for unicast link establishment (for D2D one-to-one establishment) may support only unicast links, not multicast links.

Further, in some implementations, link establishment decisions (e.g., for one-to-one communication 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 achieve these requirements. The radio bearer type model may be used for unicast and/or multicast, which may require new sidelink procedures that were previously not needed and/or specified for D2D or V2X. For example, admission control procedures handled autonomously by the WTRU may be required for Uu (e.g., mode 4 operation), which may have typically been performed by the network. In another example, link maintenance procedures for QoS on the sidelink may require the AS layer to maintain a certain quality level for SL transmissions.

Further, in some implementations, the model for QoS may assume that a set of flows are mapped to a particular bearer (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 performed 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.

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 the broadcast link may require less involved admission control evaluation and/or link maintenance procedures or may not require admission control evaluation and/or link maintenance procedures. However, the link establishment signaling is still applicable to the broadcast transmission case as long as a radio bearer can be established for the broadcast service associated with the transmission of the group destination ID or the L2 destination ID. Thus, the techniques and methods discussed herein may also be applicable to broadcast transmissions.

The term "upper layer" as used herein may refer to the NAS layer, the application layer, the V2X layer, or may indicate interactions between a NAS layer, the V2X layer, and an application layer. In some examples, the procedure for connecting (i.e., the link) may include a link establishment decision performed by the AS layer. The AS/NAS layer signaling for link establishment may be based on several models. An example of such a model is shown in fig. 3.

Some embodiments provide procedures for SL radio bearer link establishment. For example, fig. 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 the connection establishment decisions performed by the AS layer 320.

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 delivered in the form of a request, a packet marked as unicast with a specific L2 ID for a 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 may communicate with (i.e., reach) another WTRU), perform admission control, and initiate connection establishment. The AS layer 320 may provide the results of the operations 340 (e.g., inter-layer messages) to the NAS and/or one or more upper layers 310 in communications 350.

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

FIG. 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, where the NAS and/or one or more upper layers 410 may make decisions based on information from the AS layer 420.

The NAS and/or one or more upper layers 410 may send a discovery or service advertisement 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, for example, an advertised service or application. The AS layer 420 may provide connection-related information (e.g., inter-layer messages) to the NAS and/or one or more upper layers 410 in communications 440. For example, the connection-related information may be information regarding whether two WTRUs may communicate with each other, their link quality, and the like.

The NAS and/or one or more upper layers 410 may initiate connection establishment through connection establishment communications 450 (e.g., inter-layer messages). Upon receiving the connection establishment communication 450, the AS layer 420 may perform an admission control procedure 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.

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

Some embodiments may provide AS/NAS layer signaling to support unicast, multicast link, 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 by the AS layer to SLRBs). In some examples, such interaction 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 procedure 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 inform the upper layers of this decision. Alternatively, the WTRU may initiate link setup signaling for the case of unicast and/or multicast links and/or SLRB setup. Each WTRU associated with the unicast or multicast setup may perform its own admission control and may inform its own upper layer of the admission control result, or may inform a peer WTRU responsible for interacting with the upper layer based on the admission control results of all WTRUs. Without loss of generality, the examples described in the following cases may be applied to any of the above cases.

In some examples, the list of WTRUs may be provided by the NAS layer and/or upper layers to the AS layer (e.g., list 330 AS shown and described with respect to fig. 3), or a connection establishment request may be made by the NAS layer and/or upper layers to the AS layer (e.g., connection establishment communication 450 AS shown and described with respect to fig. 4). 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 WTRUs to be included in unicast and/or multicast connections (e.g., a single WTRU in a unicast case); unicast and/or multicast indications (i.e., indications of whether a connection will be unicast or multicast); data packets to be sent (e.g., upper layer service announcements); QoS requirements of 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 determining AS layer link establishment); and/or link identifiers for L2 unicast and/or multicast. Such a link identifier may include the L2 source ID of the peer WTRU, which may include the ID in the link establishment request message (e.g., connection establishment communication 450). Alternatively, in the unicast case, such link identifier may include the L2 source ID of the peer WTRU as the unicast destination, and the upper layers (e.g., NAS and/or one or more upper layers 410) may identify the WTRU with another ID.

In some examples, the AS layer may provide connection information. Fig. 4 is a block diagram of a link establishment model showing an example process by which an upper layer determines link establishment based on information of an AS layer. For example, AS layer 420, AS shown and described with respect to fig. 4, may provide the 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 range of the WTRU that support the advertised 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 reachability may be evaluated by the AS layer based on VQI provided by upper layers; a measurement value or level (e.g., based on a pre-configured mapping of RSRP to level) associated with a measurement signal (e.g., a PHY layer signal such as a reference signal included in the message) transmitted between the WTRUs, wherein the measurement 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 layer; the results of the upper layer service announcement (e.g., such results may be carried in NAS packets); a potential trend in discovery or message transmission results (e.g., information indicating that the measured RSRP is increasing, decreasing, or unchanged, or indicating a time period x during which another WTRU may discover or hear the WTRU); and/or vehicle trajectory information.

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

In some examples, the WTRU AS may send an indication of link establishment failure to the upper layer. Such a failure may be due to failed admission control of the requested service, packet, link, and/or SLRB. Such an indication may occur at any time during the active time of the SLRB, such as if 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 peer WTRU). The AS may provide such an indication to the upper layer in the same message AS any information regarding failed link establishment or a combination thereof, such AS information indicating a WTRU (e.g., WTRU ID) with which QoS is not met or a link cannot be established (e.g., an indication that a WTRU interacts with an upper layer, or that a peer WTRU cannot establish a link), where the WTRU ID provided may be the source L2 ID; information (e.g., WTRU ID) indicating a WTRU preempting the SLRB; QoS parameters of the link and/or SLRB or packet, the SLRB ID or flow ID, causing preemption of the SLRB; specific QoS parameters that cannot be met; an indication of other WTRUs (e.g., WTRU ID) and/or SLRB (SLRB ID, QoS flow ID, or the like) that are currently established that either block the establishment of the new SLRB/link or are not allowed to establish the new SLRB/link (e.g., an indication that the new SLRB collides with an existing unicast link, and/or an indication of which existing unicast links collide with the new SLRB); and/or cause of failure. Examples of failure causes include admission control failure, inability to preempt ongoing service, 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 (pscch), RS resources, feedback channels, preemption resources), and/or preemption SLRB/link.

In some examples, the WTRU reverts to best effort. For example, the WTRU AS layer may indicate to the WTRU NAS layer that a link has been established, but that 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 allowed (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 certain QoS parameters (e.g., latency) that may be met, AS well AS QoS parameters that are only met AS best efforts.

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. This negotiation or renegotiation may occur during link setup/SLRB setup, or at any time the link is established, such AS upon detection of a failure in link monitoring, after triggering of AS-layer reconfiguration (e.g., AS described herein), upon receipt of a preemption indication for the link, or initiated by upper layers. The negotiation or renegotiation may be performed by any WTRU associated with the procedure (e.g., at the initiating WTRU or peer WTRU).

For example, the WTRU AS layer may indicate that QoS cannot be met and may wait for the upper layers to provide a new VQI or indicate termination of the procedure. The WTRU AS layer may wait for an indication from an upper layer for a time indicated by a 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 procedures (e.g., link establishment or AS layer reconfiguration) may proceed with the new VQI.

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 not acceptable for the associated flow or SLRB. The WTRU AS layer may wait for an indication from upper layers for a time indicated by the value of a configured, pre-configured, 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 procedure (e.g., link establishment or AS layer reconfiguration) may proceed with the new QoS parameters.

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 can 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, or through, RRC signaling (e.g., upper layers may provide the one or more new QoS parameters to the AS layer, and the AS layer may include the one or more new QoS parameters in an RRC message). In either case, the upper layer may instruct the AS layer to continue RRC signaling exchanges to deliver one or more new QoS parameters to other WTRUs. If the QoS renegotiation procedure fails, the WTRU may initiate transmission of an RRC failure message associated with the RRC signaling exchange, at which point the link establishment procedure or AS layer reconfiguration procedure may be deemed to have failed.

In some examples, QoS negotiation or renegotiation is a condition for 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, e.g., encapsulated messages) in the received RRC message. In some examples, the WTRU may receive a link setup 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 a failed admission control and/or a failed AS layer reconfiguration may initiate a QoS negotiation or renegotiation procedure with the upper layer. Alternatively, if such PDUs are not included in the RRC message, the WTRU may indicate a failed link establishment or reconfiguration procedure upon failed admission control. Without loss of generality, such upper layer PDUs may be included in any of the RRC messages associated with link establishment and/or AS layer reconfiguration. The WTRU may also maintain knowledge of whether the QoS renegotiation procedure is allowed for the failed link monitoring case (e.g., stored information indicating whether the QoS renegotiation procedure is allowed) based on whether an upper layer PDU is included in the signaling during link establishment of the SLRB.

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

WTRUs (e.g., AS layers and/or upper layers) may maintain a list of responding WTRUs and certain quality measurements associated with the WTRUs. For example, the WTRU may maintain a list of L2 source IDs that respond to the discovery broadcast message. The WTRU may also maintain certain trends used during AS link establishment decisions, such AS absolute quality values of measured discovery responses; a number of consecutive responses and/or a period of time for which a response is found to be above a threshold; and/or find that the quality of the response does not change more than a certain amount of time period or number of responses.

The WTRU may determine the link establishment criteria based on any of the information described above (e.g., discovery responses measured over at least the last T time units that are above a threshold), or indicate the criteria to the upper layer. The WTRU may respond to the discovery message using the originating WTRU's source L2 ID as the destination address.

Some examples include signaling for autonomous link establishment, performed by the WTRU. For example, fig. 5 is a message sequence chart illustrating an example side link setup procedure 500 at the AS layer between WTRU 510 and 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 setup request message 530 may be an RRC reconfiguration (rrcrconfiguration) message, a WTRU side link information (WTRU sidelinkinformation) message, or any other such message supported by the RRC protocol). Alternatively, the messages shown in process 500 may include a mix of upper layer messages and RRC messages. After WTRU 520 receives link setup message 550, SL transmission may begin on the established SL bearer in step 560.

In some examples, after an 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. The WTRU 510 may send a link setup request message 530 if admission control is successful or if the triggered QoS renegotiation is successful. The link establishment request message 530 may include any or all of the source L2 IDs of one or more WTRUs to which the unicast and/or multicast link is requested; a multicast ID for the multicast link being requested; a source L2 ID of the WTRU transmitting the link establishment request; QoS related information; information on proposed AS configuration of a link to be established or SL bearer; information about one or more capabilities of the WTRU 510; information needed 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.

The QoS-related information included in the link setup request message 530 may include QoS information of the link (e.g., one or more VQIs associated with the bearer to be setup). 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 on the proximity information only. Alternatively, the AS layer may determine associated QoS information (e.g., VQI or the like) to be used for a signaling connection between WTRUs without any QoS information from an upper layer regarding flow information. The WTRU may configure, pre-configure, or determine such default or signaling VQI based on Channel Busy Ratio (CBR), carrier Bandwidth (BW), bandwidth part (BWP), or similar physical layer parameters or measurements.

The information included in the link establishment request message 530 required to perform link and/or bearer admission control may include information indicating the gNB and/or PLMN on which the WTRU510 is camped/connected; the zone ID of the SI currently used by the WTRU 510; location information (e.g., geographical location information, area ID, etc.) and/or motion-related information (e.g., speed, heading, identification of a leading WTRU such as a scheduled WTRU or fleet leader, an indication of whether the WTRU is fleet-based or part of fleet-based scheduling, QoS-related measurements measured by the WTRU510, and/or QoS-related metrics measured by the WTRU510 regarding the WTRU 510.

The information related to upper layer link setup included in the link setup 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 directly (e.g., without decoding the message) by the WTRU 520 to upper layers. As discussed herein, such information may include information necessary for QoS renegotiation. In another example, the link establishment request message 530 may comprise a PC5 protocol or NAS protocol establishment message submitted by upper layers to lower layers to initiate connection establishment, where the message may be carried as a payload of an RRC message used as a connection establishment request.

The link establishment request message 530 may include information on a proposed 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.

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; sensing a result of execution over a configurable time period before sending the link establishment request; admission control results determined at the WTRU 510 based on the requested QoS of the bearer or based on the determined QoS of the signaling connection only; and/or measurements of transmissions from the WTRU 520 (e.g., RSRP), assuming that the discovery process was initiated prior to the link establishment request 520. Alternatively, such measurements may be made after link establishment, and may be used to update parameters or send failure indications in link establishment confirmation message 550.

The WTRU 510 may transmit a reference signal with the link establishment request message 530 (e.g., within a message, such as at the PHY layer). Alternatively, the WTRU 510 may start repeated periodic transmissions of reference signals after transmitting the link establishment request message 530.

The link establishment request, such as link establishment request message 530, may be sent using 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 the WTRU2 as the destination ID of a message in the MAC header and/or Sidelink Control Information (SCI). For example, in the case of multicast link establishment, the link establishment request RRC message may contain a list of L2 source IDs of 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 RRC signaling.

After receiving the link establishment request message 530 (e.g., based on receiving the message 530), the WTRU 520 may perform admission control using measurements at the WTRU 520. WTRU 520 may also perform admission control using measurements at WTRU 510, such as the measurements provided in link establishment request message 530. If admission control is unsuccessful, the WTRU 520 may perform a QoS re-negotiation 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 establishment response message 540 may include any or all of an acknowledgement or a rejection of the link; an indication of success or failure to apply the configuration proposed by the WTRU 510; alternative suggested AS configurations; alternative proposed QoS parameters for the link; a response message embedded in the RRC message (e.g., using NAS or PC5 protocols); and/or capability information about the WTRU 520.

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

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

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 contain the content described in the link setup request message 530.

After receiving the link setup response message 540 (e.g., based on receiving the message 540), the WTRU510 may transmit a link setup confirmation message 550 to the WTRU 520 that confirms or rejects the AS configuration change suggested in the link setup response 540. At or prior to the transmission of the link establishment confirmation message 550, the WTRU510 may inform its upper layers of the successful establishment of the unicast link requested in the link establishment request message 530. The link establishment confirmation message 550 may include AS layer configuration of unicast and/or multicast links if the link establishment is successful. Upon receiving the link establishment confirmation message 550, the WTRU 520 may inform its upper layers of the successful establishment of the unicast link between the WTRU510 and the WTRU 520. Without loss of generality, the link establishment confirmation message 550 may also contain the content described in the link establishment request message 530.

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 that includes lower layer portions (e.g., messages sent between NAS, applications, and/or V2X layer entries and not interpreted or decoded by the lower layers). In another example, the one or more messages may be upper layer messages and the one or more messages may be lower layer messages.

In some examples, the WTRU510 may transmit the link establishment request to the WTRU 520 using a PC5-S (i.e., upper layer) message (e.g., as the link establishment request 530). The WTRU 520 may receive the message and trigger lower layers (e.g., AS layers) to start an admission control procedure and RRC messages to send a link setup response message 540. In response to the link setup response message 540, the WTRU510RRC may perform an admission control procedure and transmit a link setup confirmation message 550 as an RRC message. After a successful admission control procedure at each of the WTRU510 and the WTRU 520, and/or after receipt of the respective RRC messages at the WTRU510 and the WTRU 520, the RRC of the WTRU may inform 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 LTE PC5 based authentication and security establishment). If the upper layer authentication procedure 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 a security key for messages sent by the AS over the secure link.

SLRB configurations may include L1 and/or L2 configurations and/or configurations for flow to bearer mapping. The L1 and/or L2 configurations may include, but are not limited to, HARQ configurations; BWP configuration; a number of carriers and/or specific carriers available for unicast and/or multicast links; LCH/LCG configuration; RS resource allocation; configuring a resource pool or resource pattern/signature usable by WTRUs communicating over the unicast and/or multicast link; feedback configurations, e.g., CQI reporting configurations, associated transmit powers, etc.; monitoring configurations, 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 preempting the resource configuration.

In some examples, the WTRU may determine whether to perform admission control during and/or after link and/or SLRB establishment, or whether to perform admission control in unicast and/or multicast links by other WTRUs or multiple WTRUs. The determination may be made by the peer WTRU during the unicast and/or multicast link. Alternatively, the initiating WTRU may make the determination and may signal the determination to a peer WTRU to indicate that the initiating WTRU is to perform admission control. This decision may be based on the indication of the upper layer; based on NW configuration or pre-configuration; and/or based on a received power of a message (e.g., a discovery message or a link setup message) received from the other WTRU. In some cases where the decision is based on an upper layer indication, an upper layer of the initiating WTRU may determine whether to perform admission control by the peer WTRU and may explicitly signal the result of the determination in inter-layer signaling, may implicitly signal the result of the determination (e.g., by the inclusion and/or size of a PDU to be transmitted by the initiating WTRU to the peer WTRU AS part of the 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.

A WTRU determining that admission control is to be performed at a peer WTRU may also include information associated with admission control in RRC messages 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 PDUs provided by the upper layer during an upper layer initiated link setup.

The WTRU may maintain the admission control enabled state determined during link establishment for the link duration (i.e., whether the WTRU performs admission control). Alternatively, the WTRU may change its admission control enabled state (e.g., the WTRU may assume that it will perform admission control), triggering occurs. Example triggers include a case where the WTRU speed increases beyond a threshold; where the received power of messages from other WTRUs or WTRUs falls below a threshold and/or the distance between WTRUs in the link exceeds a threshold, where such distance may be calculated based on the reception of geographical information transmitted by the peer WTRU(s) associated with the unicast link (e.g., area ID transmission in SCI, or dedicated RRC messages for exchanging geographical positioning information between two WTRUs).

Some examples include configuration negotiation between WTRUs. Figure 5 is a message sequence chart illustrating an example sidelink establishment procedure at the AS layer 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 any WTRU. This negotiation may be performed as part of a request/response/acknowledge (3-step) signaling procedure as described above, as illustrated by procedure 500 shown and described with reference to fig. 5. In some examples, a WTRU that initiates link establishment by an upper layer may perform configuration selection. In some examples, a WTRU that receives a connection setup request message from a WTRU whose upper layer initiated link setup may perform configuration selection. Alternatively, both WTRUs may be associated with configuration selection (e.g., the initiating WTRU makes an initial selection and the peer WTRU makes an alternate selection).

The WTRU may select one or more AS layer configurations by which unicast and/or multicast links are to be established based on the QoS of the link to be established; based on capabilities of one or more of the WTRUs; based on the measurement of the current sidelink resource usage measured by the WTRU; and/or based on the aforementioned information and/or preferred configuration exchange between the WTRU(s) associated with the link establishment.

In some cases where the WTRU selects 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 an upper layer. Such VQI may also be associated with (e.g., by configuration or pre-configuration) one or more AS layer configurations. Which AS layer configuration or configurations to use for each VQI may further depend on similar measures of channel utilization at the CBR, CR, or WTRU; the number of carriers supported for the unicast link (e.g., where the number of carriers supported may depend on the capabilities of any WTRU or may depend on the carriers configured for the service for which the unicast and/or multicast link is to be established); BWP (e.g., size of current SL BWP); and/or allowed resources (e.g., one or more resource pools configured or used by the WTRU for unicast link establishment).

In some cases where the WTRU selects an AS layer configuration based on the capabilities of one or more WTRUs, for example, the WTRU may be restricted to using a subset of the AS configuration, or the WTRU may be restricted to a particular element of the AS configuration if any WTRU associated with the link establishment does support the configuration or configuration elements. This may be determined at link setup (e.g., based on the number of carriers at link setup, resource selection pattern, configuration of Reference Signal (RS) location/pattern/power, etc.).

In some cases where the WTRU selects an AS layer configuration based on the currently measured resource usage, for example, the WTRU may select from one of a number of AS layer configurations based on the current side link resource usage measurement, e.g., to avoid conflicts with the currently used resources.

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

In some examples, the initiating WTRU may determine the AS configuration to use based on QoS requirements (e.g., VQI) received from upper layers or from the network. The determination may be based on network-provided configuration or pre-configured (e.g., stored in the WTRU) mapping of VQI to AS configuration, AS layer capabilities of the WTRU, and selection of specific resources of the configuration (e.g., RS patterns, preemption resources, etc.) to minimize and/or avoid collisions, and/or interference with existing unicast links. This 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 the 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 selection criteria described above. 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 that meet the QoS (e.g., the number of SL carriers, etc.) based on measurements made at the location of the peer WTRU. An indication of the alternate configuration or acceptance of the initial configuration may be sent in a link establishment response. If the WTRU receives a link setup response with an alternate configuration, the WTRU may determine whether to accept the configuration and send a link setup confirm message to a peer WTRU or reject the configuration and send a link setup reject message to a peer WTRU. In either case, either or both WTRUs may inform the upper layers of the results.

In some examples, the initiating WTRU may determine a set of AS layer configurations using similar selection criteria to the scenario described above, and may send the selected set of AS layer configurations (e.g., an indication of the configuration or configurations) to the peer WTRU. The peer WTRU may select one AS layer configuration from the provided list and may transmit an indication of the selection in a link setup response, or may transmit a failure indication if none of the selected configurations allow the peer WTRU to meet the required QoS at the location of the peer WTRU or none of the selected configurations match the capabilities of the peer WTRU (e.g., support different features, parameter settings at the AS layer, such AS HARQ for which HARQ parameters, power control parameters, etc.) of the peer WTRU.

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 QoS requirements provided by upper layers (e.g., based on measurements and/or admission control at the peer WTRU location) and/or WTRU capability requirements. The peer WTRU may send a success indication in a response message if the AS layer configuration meets QoS and/or capability requirements at the peer WTRU. 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 a 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, the AS layer configuration satisfying QoS and/or supporting 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 may be selected, either WTRU (or both WTRUs) may inform the upper layers of the success or failure of its link establishment procedure.

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 originating 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 establishment confirmation.

In the above examples, the QoS related measurements may include any of the measurements described herein, e.g., including measurements for admission control as further described herein.

In some examples, the WTRU may determine whether to transmit its capability information to another WTRU based on whether it has transmitted the capability information in the past (e.g., during link setup signaling). For example, the WTRU may include its capability information in the AS layer signaling based on the following determinations: 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 for a predetermined period of time; and/or whether its capabilities have changed since the last transmission of its capability information to the same WTRU. When performing link setup to a WTRU, the WTRU may omit transmission of its WTRU capabilities that it previously transmitted to it (e.g., assuming these capabilities did not change).

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

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 an upper layer; receiving 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.

Some examples include updating the AS layer configuration. In some examples, WTRUs associated with unicast and/or multicast links may initiate AS layer reconfiguration of particular unicast and/or multicast links. For example, the WTRU may initiate 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 CBR measured at the WTRU; receiving preemption of unicast and/or multicast links; an indication from an upper layer; and/or determining that the WTRU has exceeded its radio capabilities.

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

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

In some cases, where triggering includes receiving preemption of unicast and/or multicast links, in some examples, the WTRU may receive preemption of unicast and/or multicast links that provides further information regarding conflicting static resources (e.g., via a reference signal, feedback channel, etc.) or regarding limitations on utilized resources (e.g., resource pool, mode, number, etc.). The WTRU may determine to perform AS layer reconfiguration of the unicast link to facilitate continued operation at an acceptable or sub-optimal QoS while avoiding collisions indicated in the preemption signal.

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

The new AS layer configuration may be determined after a negotiation procedure similar to that described herein for initial link establishment.

In some examples, a WTRU initiating 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 (e.g., configurations or indications of such configurations) for the peer WTRU; may include new and/or updated capability information for peer WTRUs; and/or may include QoS-based measurements for peer WTRUs. 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 initiating the WTRU; may include QoS-based measurements for the initiating WTRU; and/or may include an indication of acceptance or failure of the peer WTRU for the selected AS layer configuration. In response, the initiating WTRU may transmit a reconfiguration confirm message. The reconfiguration confirm message may confirm or indicate a failure of the AS layer reconfiguration procedure; and/or may include selected or alternative AS layer configurations to be used (e.g., configurations or indications of such configurations). In some cases where the AS layer reconfiguration procedure fails, the WTRU may perform actions related to releasing unicast and/or multicast links or SLRBs, AS described herein.

Successful link establishment at a WTRU may be considered to be completed at any time, which may depend on whether the WTRU in question is an initiating WTRU or a peer-to-peer WTRU. For example, successful link establishment may occur upon transmission of a link establishment confirmation message, or upon transmission of a last RRC message associated with the setup/reconfiguration RRC procedure; upon receiving a link establishment confirmation message, or upon receiving a last RRC message associated with the setup/reconfiguration RRC procedure; receiving an acknowledgement of the link setup confirm message or an acknowledgement of a last RRC message associated with the setup/reconfiguration RRC procedure; transmission of a successful link setup response message (e.g., a response or reconfiguration response); receiving a success response message (setup response or reconfiguration response); and/or receiving an acknowledgement of a successful link setup response message (setup response or reconfiguration response).

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

Some examples include actions related to releasing unicast and/or multicast links or SLRBs. For example, the WTRU may perform one or more of various actions during the release of the unicast and/or multicast link or SLRB. Releasing all unicast resources related to the unicast link or SLRB, such AS dedicated channels (e.g., dedicated feedback channels), resource pools, reference signal resources, preemption resources, and any or all other resources that may be part of an AS layer configuration dedicated to unicast and/or multicast links; ceasing 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; canceling any ongoing resource selection process associated with the unicast link and/or SLRB being released; triggering an SL resource reselection procedure, e.g., taking into account current data in an SL buffer, and not taking into account a logical channel associated with the SLRB; transmitting remaining data in a buffer associated with the SLRB using an SL broadcast mechanism (e.g., changing the L2 destination address to a broadcast destination address associated with the service, instead of the L2 source address of the destination WTRU); triggering an immediate broadcast of a UMUS message or a UMUS cancel message to indicate a release of resources associated with the unicast link and/or SLRB; upper layers that notify the release (e.g., in some cases where the release is initiated by a lower layer, such as preemption); and/or transmitting an RRC release message or an RRC failure message to other one or more WTRUs associated with the unicast and/or multicast link or SLRB.

In some cases where the actions include transmitting an RRC release message or an RRC failure message to other one or more WTRUs associated with unicast and/or multicast links or SLRBs, if the upper layer notifies the WTRU of the release of the SLRB, the WTRU may transmit a sidelink release message and the WTRU may maintain the link (e.g., resources, etc.) until it receives an acknowledgement of the release message from the peer WTRU.

In some cases where the actions include transmitting an RRC release message or an RRC failure message to other one or more WTRUs associated with unicast and/or multicast links or SLRBs, the WTRU may transmit the 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 that receives the reconfiguration request message or reconfiguration response message) if the release is initiated by a failure of the AS reconfiguration procedure.

In some examples, the WTRU may perform actions related to the release of unicast and/or multicast links or SLRBs as a result of one or more triggers. Such a trigger may include an explicit indication from an upper layer or AS layer to release the flow, flow set, unicast and/or multicast link or SLRB (e.g., the upper layer may indicate to release the flow or flow set and no remaining flows may be carried by the SLRB, in which case the WTRU may initiate an action related to the release of the SLRB); a failed AS layer link monitoring procedure, which may be a failed AS layer link monitoring procedure if followed by a failed QoS renegotiation procedure and/or a failed AS layer reconfiguration procedure; reception of a preemption indication for a particular flow or SLRB from another WTRU; SL release message or rejection message reception; and/or a failed AS layer reconfiguration procedure.

In some cases where the trigger includes a failed AS-layer reconfiguration procedure, the WTRU may initiate the failed AS-layer reconfiguration procedure if the WTRU detects a QoS monitoring failure and is unable to renegotiate new QoS parameter(s) with an upper layer and/or is unable to determine a new AS-layer configuration that satisfies one or more QoS parameter(s) currently configured for the SLRB. In some cases where the trigger includes a failed AS-layer reconfiguration procedure, the WTRU may initiate the failed AS-layer reconfiguration procedure if the WTRU receives the reconfiguration request message over a sidelink and is unable to apply the proposed AS-layer configuration and/or is unable to renegotiate one or more new QoS parameters with an upper layer and/or is unable to determine a new AS-layer configuration that satisfies the one or more currently configured QoS parameters for the SLRB. In some cases where the trigger includes a failed AS-layer reconfiguration procedure, the WTRU may initiate the failed AS-layer reconfiguration procedure if the WTRU receives an AS-layer reconfiguration response message with a new AS-layer configuration and is unable to apply the proposed AS-layer configuration and/or is unable to renegotiate one or more new QoS parameters with an upper layer and/or is unable to determine a new AS-layer configuration that satisfies one or more QoS parameters currently configured for the SLRB.

Some examples include SL release messages. For example, the WTRU may perform transmission of the 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., NAS or PC5-C message) included in a generic RRC message (e.g., transparent container) or a SL data message. The SL release message may contain information on the SL bearer index of the QoS flow and/or the flow to be released or the SLRB; the reason for the release; one or more L2 IDs for one or more WTRUs are released from the link (e.g., in the case of a multicast link, the SL release message may release only a subset of the WTRUs); a time scale associated with the release (e.g., an amount of time that one or more WTRUs may not initiate a new link setup, and/or an amount of time after which one or more WTRUs should re-establish the same link with a similar QoS); and/or an indication to continue the unicast and/or multicast link on a different carrier or set of carriers and a particular carrier.

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 RRC message or SL data), the WTRU AS may receive a release indication from the upper layer after the upper layer handles the release.

Some examples include upper layer SL bearer establishment or bearer reconfiguration. For example, the WTRU may initiate new bearer establishment or 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 flow termination, wherein the WTRU may perform bearer reconfiguration; and/or an upper layer indication of a change in source and/or destination L2 ID or an ID of an existing link, where the WTRU may associate a new L2 ID with an existing bearer. The WTRU may use the same or similar signaling as above and here to establish the new bearer. In some examples, the WTRU may establish the new bearer using the same or similar signaling as above and here without the steps associated with reachability determination.

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

Fig. 6 is a message sequence diagram illustrating an example process 600 for a gNB control link establishment. Example process 600 includes WTRU 610 transmitting a link setup configuration request message 640 to gNB 630, which responds with a link setup configuration response message 650. After the WTRU 610 receives the link establishment configuration response message 650, the reference signal transmission and the received gbb configuration are 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 establishment response message 680, SL transmission based on the established SL bearer begins between the WTRU 610 and the WTRU 620 at step 690.

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). WTRU 610 may send VQI for the link and/or bearer to gNB 630 for use by gNB 630 in determining the configuration. The WTRU 610 may also send measurements performed by the WTRU 610 on discovery responses transmitted by the WTRU 620 during previous discovery signaling.

In another example, the configuration of reference signals for reachability detection may be under the control of the gNB. This is true whether the reachability detection is performed before or after the link setup configuration request message 640.

Some examples may include signaling to establish a multicast link. The establishment of the multicast link may require knowledge of some or all connections between pairs/all pairs of WTRUs.

In some examples, the source WTRU may reserve resources for multiple WTRU transmissions/responses. For example, a 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 setup configuration request message transmitted by the WTRU. Such messages may include information described herein (e.g., regarding link establishment in the unicast case). The request message may also contain 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 a transmission order of the WTRU for the response message; a contention resolution rule for resolving contention between the WTRUs for transmission of the response message; and/or a request for a connectivity report, e.g., as discussed further herein.

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

The source WTRU may also transmit 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 the SCI at all.

A WTRU receiving a message providing resources for a response message may determine the specific timing of its own response message. The timing determination is based on an explicit order of responding WTRUs in the request message (e.g., using a particular resource of a plurality of reserved resources); implicit ordering based on WTRU ID (e.g., source L2 ID, C-RNTI, group ID, or the like); and/or 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 ranking provided by the application layer.

In some examples, the responding WTRU may monitor and/or measure response messages from other responding WTRUs. The WTRU receiving the request message soliciting a response may also monitor for response messages from other WTRUs based on the resources scheduled by the request message. The WTRUs may perform measurements of the quality of the response messages transmitted by each WTRU. For example, the WTRU may measure the quality of the response message based on reference signals transmitted by each WTRU within the response resource.

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 is able to decode, e.g., along with WTRU IDs and measured qualities (e.g., RSRP, RSRQ, SINR, etc.); and/or a measurement quality of the source WTRU (e.g., based on the transmitted request message and/or the reference signal).

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

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 communication for the group based on the number of WTRUs in the group (e.g., after a request from an upper layer, or upon receiving a packet with a particular L2 destination ID). The WTRU may be provided with the number of WTRUs in the group directly from the upper layer. 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 preconfigured 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., a WTRU may consider a larger allowed multicast group when the measured CBR is lower); measured or relative path loss between any two WTRUs (e.g., a WTRU may determine a maximum number of WTRUs based on a maximum measured path loss between two WTRUs, or a WTRU may determine that AS layer multicast may be initiated or maintained when a maximum path loss between any WTRU in the group is below a threshold); and/or an 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).

Fig. 7 is a message sequence chart illustrating an example multicast link setup procedure 700. The multicast link setup procedure 700 includes a link setup request 740 broadcast by the WTRU 710 to the WTRU 720 and the WTRU 730, a link setup response message 750 broadcast by the WTRU 730 to the WTRU 710 and the WTRU 720, and a link setup response message 760 broadcast by the WTRU 720 to the WTRU 710 and the WTRU 730. After the link establishment request and response, WTRU 720 and WTRU 730 transmit a connection report 770 and a connection report 780, respectively, to WTRU 710. After receiving the connection report 770 and the connection report 780, the WTRU 710 broadcasts a link setup confirm message 790 to the WTRU 720 and the WTRU 730, after which a multicast message may start among the WTRU 710, the WTRU 720 and the WTRU 730 in step 795.

In process 700, the link establishment request and link establishment response messages are broadcast messages. The link establishment confirmation is also a broadcast message and includes the WTRU ID included in the group and the destination address for future multicast messages.

In some examples, the WTRU may determine a grouping of L2 IDs associated with multiple unicast links between the same WTRU. 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 advantageous for the Access Stratum (AS) (at each WTRU) to know that the unicast link is actually between the same pair of WTRUs.

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 the unicast link at the WTRU are actually associated with the same physical peer WTRU. If the unicast link transmissions are associated with the same peer WTRU, the WTRU may group together multiple destination L2 IDs (i.e., source L2 IDs of peer WTRUs) used during transmissions to different unicast links. If the unicast link is established with the same peer WTRU, the WTRU may group the multiple source L2 IDs used during transmission into different unicast links. The WTRU may maintain a single context associated with multiple unicast links that are grouped together using the methods described below.

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 SL reconfiguration messages). In some examples, a first WTRU may send an AS Side Link (SL) UE ID to a second WTRU during or after link establishment. In some examples, the WTRU may derive an AS SL UE ID, such AS an International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI), serving TMSI (S-TMSI), globally unique temporary UE identity (GUTI), cell radio network temporary identity (C-RNTI), etc., based on a static or semi-static ID associated with the WTRU; based on a randomly selected value; based on the value associated with its location and/or its selected resource; based on the value associated with its location and/or its selected resource; and/or based on a value associated with a coding of the PSCCH and/or pscsch and/or PSFCH of the WTRU.

For example, in some cases where the WTRU derives an 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 a peer WTRU. Further, the WTRU may select such a random value if the WTRU has not established a unicast link. For example, the WTRU may select a random value for the first unicast link it establishes, and the WTRU may then send the same selected value (or a value based on that value) for the subsequent RRC link established. In some examples, the WTRU may delete the randomly selected value if the WTRU no longer has a unicast link established at the WTRU (e.g., if the WTRU no longer has any kind of unicast link). 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 at link establishment, or its current area ID to its peer WTRUs at link establishment. In some examples, the WTRU may send information (e.g., time, frequency, beam, etc.) of an index or related resource selection procedure performed at a time. For example, the WTRU may send an index of the last time-frequency resource that the WTRU reserved before link establishment. In some cases where the WTRU derives the AS SL UE ID based on a value associated with the coding of the WTRU's PSCCH and/or pscsch and/or PSFCH, the value may include a value such AS a scrambling code, RS pattern, etc.

In some examples, the second WTRU in the potential group may receive the L2 source ID of the peer WTRU in PC5 RRC signaling or from an upper layer (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, if the WTRU receives an AS SL UE ID that matches the AS SL UE ID received from a peer WTRU, the WTRU may group the L2 IDs for two unicast links, where the peer WTRU 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 a peer WTRU associated with another ongoing unicast link at the UE; and/or if the WTRU receives an AS SL UE ID indicating the time/frequency resources used by a peer WTRU with which the WTRU has established a unicast link.

This process for grouping the L2 source IDs may be performed by either or both WTRUs. For example, the first WTRU may send its SL UE ID to the second WTRU during and/or after link establishment, and the second WTRU may determine whether to group the L2 ID for the unicast link with another L2 ID of 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 procedure), and the first WTRU will perform a similar packet determination.

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

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

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

In some examples, the WTRU may use an on-demand SIB or dedicated signaling to obtain the SLRB configuration for a particular PC5-5qi (pqi) and/or PC5 flow identifier (PFI). For example, a WTRU may request SLRB configuration associated with one or more PQI/PFIs by 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 SL configuration of the WTRU, and/or when the SL SIB does not broadcast the SLRB configuration associated with the flow. The WTRU may include in the request a PQI/PFI associated with the flow; a range value associated with the stream; a GBR associated with the flow; an index to a table giving all QoS parameters or QoS profiles, wherein such table may be predefined or configured or preconfigured; and/or a list of its current SLRBs, which are already stored in its own configuration.

In some embodiments, a WTRU in connected mode may use a similar request for SLRB configuration associated with one or more PQI/PFIs using dedicated signaling. 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.

In some examples, the SLRB configuration of the WTRU 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, the WTRU may use a first configuration for SLRB (or for flow) if the measured quantity matches a first condition or conditions, and may use a second configuration for SLRB (or for flow) if the measured quantity matches a second condition or conditions.

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 the flow (i.e., mapping the new flow to the default SLRB), and in the WTRU's stored SLRB configuration, no flow is mapped to the SLRB. The default configuration may be configured, preconfigured, or predefined. The default configuration may be configured by the network, e.g., by the gNB. The default configuration may be preconfigured by V2X pre-configuration 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., an SLRB stored in its stored configuration), the WTRU may move the flow from the default SLRB configuration to the indicated, stored SLRB configuration.

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

Some examples include systems, methods, and devices for admission control of unicast and/or multicast on a sidelink. In some examples, the transmission mode decision may be based on QoS. For example, the WTRU may determine its transmission mode for the 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 unicast and/or multicast flows for a VQI, and may determine a transmission mode for packets on the link and/or bearer based on the VQI, QoS parameters derived from the VQI. The WTRU may select between an NW control mode and a WTRU autonomous mode based on the VQI. Alternatively, if the WTRU selects WTRU autonomous mode, or the network allows the WTRU to use WTRU autonomous mode, the WTRU may select between resource selection modes further based on VQI. For example, the WTRU may determine whether to use fully autonomous resource selection; autonomous resource selection with assistance from another WTRU; configured or preconfigured authorization; and/or the WTRU schedules resources for the link. For example, the WTRU may be configured or preconfigured with a table of VQIs and allowed resource transmission/resource selection modes, where the WTRU may select one mode for a particular VQI from the allowed modes.

In some examples, the 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 admission control purposes. 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 mode of operation to NW control mode at least during admission control/link and/or bearer establishment phases. The WTRU may continue in the NW control mode until the network instructs it to move back to the WTRU autonomous mode.

In some examples, admission control is scheduled by the NW. For example, the WTRU may send a request to the network for the establishment of a sidelink unicast and/or multicast link, or the WTRU may send a request to the network for the establishment of a unicast and/or multicast link and/or a sidelink radio bearer. 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 a request to the gNB via an RRC message or MAC CE, and the request may include various information, such as a VQI associated with one or more flows for which a bearer should be established or related one or more QoS parameters; an identity of the one or more WTRUs associated with the unicast and/or multicast link; and/or finding the result.

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 provisioned with a VQI for a given flow from the NAS layer and may initiate a link setup request including such VQI to the network. In some cases, where the information includes an identification of one or more WTRUs with which the link should be established, the WTRU may include a source ID (e.g., L2 ID) of the WTRU with which the link should be established. In some cases, where the information includes a discovery result, the WTRU may send any AS-related information associated with the discovery result, possibly associated with one or more WTRUs with which unicast and/or multicast links are 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 a synchronization source of the one or more WTRUs; information indicating an in-coverage or out-of-coverage status of the WTRU; and/or information indicating WTRU capabilities such as resource selection capabilities, supported carriers, power classes, etc.

In some examples, the WTRU may send a unicast and/or multicast link setup request to the network based on one or more triggers or conditions, e.g., where the WTRU receives a new QoS flow from an upper layer; the WTRU deciding to create a new sidelink radio bearer; the WTRU determining that a new QoS flow or radio bearer requires network controlled admission control; the WTRU receiving a unicast and/or multicast setup request from another WTRU; the WTRU receiving a response to a unicast and/or multicast setup request from another WTRU; and/or the WTRU is performing WTRU autonomous admission control and the new link and/or bearer establishes admission control that fails based on the WTRU autonomous admission control mechanism.

In some examples, the WTRU may use network-controlled admission control if the WTRU autonomous admission control fails. For example, the WTRU may receive a new unicast and/or multicast flow from an upper layer and may decide to initiate WTRU autonomous admission control for a new SL radio bearer for that flow (as described herein). If the WTRU autonomously fails admission control, for example for the reasons described herein, the WTRU may initiate network-controlled admission control, for example, by transmitting unicast and/or multicast link establishment requests to the network.

In some examples, the WTRU may receive an acknowledgement of successful admission control with the resource and measurement configuration message. For example, the WTRU may receive an acknowledgement for successful admission control by the network, and after the acknowledgement, 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 a confirmation. The resource usage information may include an indication of a new resource pool or an existing resource pool; a periodic set of resources; an arbitration rule; WTRU-specific or cell-specific link and/or radio bearer identification; and/or a configuration of measurements to be reported to the network for link maintenance.

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 set 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 grants (e.g., type 1 or type 2 grants) to be used for configuration of data transmissions associated with the established link and/or bearer, or an indication of an existing configuration to be used for transmitting such data. In some cases where the resource information includes arbitration rules, the rules may include arbitration rules for use by particular WTRUs for resources shared between the WTRUs (e.g., where such WTRUs may or may not be WTRUs associated with unicast and/or multicast links). The arbitration rules may include a subset of times and/or frequencies that the WTRU may use on the total resource configuration; timing relationships between transmissions and retransmissions for links and/or bearers; transmission order or sequence between multiple WTRUs in a multicast link; and/or a timing relationship between the transmission and HARQ feedback (e.g., transmission on the side link or uplink).

In some cases, wherein 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 power to be transmitted by a WTRU associated with a link; configuration of reference signal reception resources and expected power for measurement and reporting by the WTRU to the network; and/or the frequency (or periodicity) at which such measurement reports are sent by the WTRU based on measurements received by the reference signals.

The WTRU, in response to receiving such a configuration, may initiate measurement and reporting in accordance with the network configuration until the network releases the link and/or bearer via a bearer release message from the network.

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 persist only during the link establishment phase. For example, a WTRU may be configured with: one or more source L2 addresses associated with messages that 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 transmission/reception of reference signals for measurement.

In some examples, a WTRU configured for measurement reporting may determine RSRP of any message received from any particular 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 measurements to the network each time a message is received that meets the above criteria. In some examples, when the WTRU completes link setup with the WTRU indicated in the source L2 ID (i.e., in the measurement configuration), the WTRU may delete the configuration.

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

In some examples, the WTRU may determine whether to initiate and/or accept or reject the unicast/multicast link, or whether to grant a unicast/multicast Side Link Radio Bearer (SLRB) based on one or more criteria.

The criteria may include: network coverage of one or more WTRUs, e.g., where a WTRU may accept or reject a unicast/multicast link or SLRB establishment based on whether the WTRU is within coverage of a gNB or based on whether the WTRU is within coverage of the same gNB of one or more other WTRUs with which the unicast link is to be associated; QoS requirements associated with the link, e.g., where the WTRU may accept or reject 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 may accept or reject the unicast/multicast link or SLRB establishment based on the movement of the WTRU (e.g., speed, heading) and/or the location of the WTRU, possibly in combination with information regarding the movement of another WTRU or WTRUs associated with the unicast/multicast link; and/or based on available resources (e.g., data and/or reference signal and/or feedback resources), e.g., where the WTRU may accept or reject establishment of the unicast/multicast link or SLRB based on a determination of the 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 QoS requirements for the link or SLRB.

Some examples include network coverage based admission control. 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 in coverage. For example, a certain value of VQI, PPPP, PPPR, or similar QoS parameter associated with a link may be configured or preconfigured to require mode 1 resource allocation mode, or the WTRU may be required to be in coverage so that it may fall back to mode 1 under certain conditions. In some examples, a WTRU receiving 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 Uu-based RSRP (e.g., a value that may be for each VQI or QoS-related parameter) below which the WTRU will reject the link and/or SLRB.

In some examples, the WTRU may reject a link/SRLB for a given QoS if the gNB on which the WTRU is currently connected and/or camped is not related to the gNB or gNB on which other WTRUs may camp. The correlation may include, for example, the same gbb, a gbb of an equivalent PLMN, a gbb broadcasting system information as part of the same active area. The links and/or SLRBs may have one or more allowed relationships.

Some examples include relative location-based admission control. In some examples, the WTRU may determine whether to accept or reject a link and/or SLRB based on the distance between WTRUs in combination with range or QoS requirements for links that require a particular QoS, such as a particular range requirement, or have an associated VQI. For example, the WTRU may be configured or preconfigured with a threshold distance for each VQI value. The WTRU may receive location information regarding one or more other WTRUs associated with the link and/or bearer (e.g., during link setup signaling) and may accept the link and/or the SLRB if the distance to the one or more other WTRUs or WTRUs is below a threshold distance associated with the VQI.

Some examples include admission control based on availability of link maintenance related resources/channels. In some examples, the WTRU may determine whether to accept or reject the link and/or the 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 for transmission of RSs (e.g., for measurement of CSI), transmission of CQIs, transmission of pre-emptive 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 transmissions associated with the unicast link, and the WTRU selects unused configurations for these RS transmissions based on sensing of other unicast transmissions and/or information provided by the network, e.g., as described further herein. Alternatively, the WTRU may select unused configurations for these RS transmissions based on information in the UMUS signals transmitted by other WTRUs. In some examples, the WTRU may decide to reject the link and/or the SLRB if the WTRU determines that all available RS configurations are currently being used by other WTRUs/links. Alternatively, (e.g., as discussed herein), the WTRU may decide to preempt an existing unicast link between different sets of WTRUs to accept the currently requested link and/or SLRB.

Some examples include transmission of unicast and/or multicast availability signals to assist other WTRUs in performing admission control decisions (e.g., for determining or predicting resource usage/availability) in a shared resource pool. For example, a WTRU may transmit a unicast and/or multicast availability signal (UMUS) when the WTRU is associated with one or more unicast and/or multicast links. 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 on all established links/SLRBs.

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

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 associated with the geographic area and the resources they occupy; a resource pool; SL BWP; a carrier wave; a group of one or more WTRUs; and/or one or more associated QoS.

In some examples, the WTRU may decode and store the UMUS during normal SL reception. For example, the WTRU may determine average resource usage, actual reserved resources, and similar information, such as information for the possible associated unicast links discussed above, based on the reception of past UMUS signals. The WTRU may assume that the contents of the UMUS are valid for a configured or pre-configured 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, a L2 source/destination address, or other identifier carried by the UMUS. The WTRU may consider the resources associated with the transmitted UMUS signal to be active immediately upon receipt of the UMUS signal. Upon expiration of the timer without receiving an updated UMUS signal associated with the same unicast and/or multicast identifier, L2 source/destination address, or other identifier, the WTRU may consider the associated resources to no longer be active. In some examples, the validity time may be determined based on movement of the WTRU, such as the speed, heading, and other relevant information of the WTRU.

In some examples, the WTRU may cancel, delete, or ignore any previously 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 area; 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 indicating the release and/or cancellation of a previous resource/reservation.

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

In some examples, the WTRU may transmit the UMUS on the PSCCH using SCI or SCI-like transmissions; using information in PSBCH (e.g., SL-MIB or the like); and/or using information transmitted on the psch, such as MAC CE or SL-RRC messages. For example, the WTRU may transmit the UMUS message using MAC CE or SL-RRC messages. This message may be transmitted over the SL using a special broadcast L2 destination address received by all WTRUs.

In some examples, the WTRU may transmit the UMUS in addition to normal transmissions. For example, the WTRU may transmit the UMUS in SCI format, which contains scheduling information and information about unicast and/or multicast links. Alternatively, or additionally, 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 a SCI having a particular format. The WTRU may determine when to transmit the UMUS based on expiration of a timer since its last UMUS transmission; based on the number of SCI transmissions since the last transmission of the UMUS; based on the QoS attributes of the unicast and/or multicast link(s) for which the WTRU is transmitting UMUS (e.g., the WTRU may transmit UMUS signals more frequently if the associated unicast link has higher reliability, lower latency, etc.); based on occupancy of a shared resource pool determined by the WTRU, such as a measurement of CBR, a number of available resources, or a detected number of UMUS transmitted by other WTRUs; and/or based on WTRU motion (e.g., WTRU speed, direction of travel, etc.).

The WTRU may include various information in the UMUS. For example, such information may include: VQI (or other QoS related parameters) associated with 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 over unicast and/or multicast links; multiple QoS streams or multiple AS SL radio bearers multiplexed over the (or each) unicast and/or multicast link; a configuration of the reference signal channel/transmission (e.g., minimum/maximum RS transmission power, time, frequency and/or beam resources, RS signal sequence, etc. for transmitting the RS signal) by one or more WTRUs associated with the unicast and/or multicast link, wherein the configuration may be indicated by transmitting an index of a predefined or configured or preconfigured configuration; a configuration of HARQ feedback channels/transmissions associated with the unicast and/or multicast links; a configuration for CQI or CSI feedback transmission (e.g., time, frequency, and/or beam resources for transmitting CQI feedback), wherein the configuration may be indicated by transmitting an index of a predefined or configured or preconfigured configuration; preempting the configuration of resources; BWP and/or the carrier on which resources are being reserved; and/or QoS related metrics taken at a WTRU, e.g., reflecting WTRU SL transmission over a period of time.

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

In some cases where the 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 preemption signals or messages that may be used to preempt an associated unicast and/or multicast link or one or more SLRBs associated with the link. The 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.

In some cases, measurements, averages and/or ratios of QoS metrics obtained at the WTRU are included in the UMUS, which may include: a measure, average and/or ratio of the number of transmissions required for the unicast and/or multicast link; a transmitted HARQ NACK; a successful resource selection process; LBT fallback operation during resource selection; increasing a RSCP/RSSI threshold value 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 transmitted/received in the PDB or required latency.

In some cases where attributes of resources required for data to be sent over unicast and/or multicast links are included in the UMUS, the attributes of the resources may include: a link identifier; resource density (e.g., amount of time and/or frequency resources per unit time); granularity of resources for the link; an average, maximum or minimum packet size and/or amount of time/frequency consecutive resources for the link; a priority; reliability of the link; beam patterns (e.g., whether a link is to be omni-directionally transmitted in a single beam, beam scanned, or beamformed, and transmitted over a subset of beams (and possibly which beams), and/or geographic locations indicating where resources are needed, e.g., geographic location references for area IDs, directionality, or resource reservations.

Some examples include the initiation and/or cancellation and multiplexing of information on the UMUS. For example, a WTRU may multiplex information for 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 at or after establishing the unicast and/or multicast link. Alternatively, the WTRU may initiate transmission of a new UMUS, or may add information for all links to the existing UMUS after establishing the first unicast and/or multicast link, and/or after establishing the additional link. In this case, the WTRU may cancel the UMUS transmission or after releasing one or all links at the WTRU.

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

In some examples, admission control may be based on information included in the UMUS. The WTRU may perform admission control (e.g., determine whether unicast and/or multicast links and/or radio bearers may be established) based on information in one or more UMUS, BWP, carrier frequency, etc., transmitted by other WTRUs in the same pool. 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 whether pending links and/or bearers may be added, e.g., given the resource capacity of the pool.

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 (e.g., of a VQI) and/or radio bearers. For example, the WTRU may make such association based on QoS attributes associated with the link, such as VQI; network configuration; and/or measured CBR in the correlation pool. For example, the WTRU may be configured with mapping of VQI and CBR to resource density or to number of resource blocks and time reference period. In another example, the WTRU may determine the number of resource blocks based on a rate-based QoS parameter derived from a VQI associated with the link.

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 QoS attributes associated with the link. For example, the WTRU may apply a multiplicative factor (e.g., greater than 1) to radio bearers/links for which the reliability requirement (or parameters thereof) is above a threshold. In another example, the WTRU may apply a multiplicative factor (e.g., greater than 1) to radio bearers/links whose latency requirements or parameters are shorter than a threshold.

In some examples, the WTRU may monitor/receive the UMUS for a period of time prior to link and/or bearer establishment. For example, the WTRU may make admission control decisions based on existing links and/or bearers established based on the UMUS detected over the time period, where the UMUS identifies the unique link/bearer. In some examples, the WTRU may consider only the established link/bearer (UMUS) for a subset of the UMUS in the decision, e.g., based on 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 another QoS parameter being exceeded. In some examples, the WTRU may apply multiple decisions or criteria to determine whether admission control was successful, e.g., where admission control depends on whether each criterion was successful. The decision or criterion may be performed based on a 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).

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

In some examples, the WTRU may determine the number of resources used by the existing link in a fixed period based on the following (e.g., the WTRU may have a mapping configured or preconfigured between VQI values and corresponding number of Resources (RBs) per time period): based on the VQI or similar QoS parameters (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 a packet size to resource amount mapping to determine the amount of resources used by the link).

In some examples, the WTRU may determine that admission control is successful if the combination of the number of resources that the UMUS has set aside (e.g., within 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 resources in the pool, or a configured or preconfigured threshold. In some examples, the configured or preconfigured threshold may depend on any of: QoS attributes (e.g., priority) of the link to be established, QoS attributes of the link already established (e.g., UMUS based), or CBR of the channel.

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

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 the particular link/radio bearer was successful. In some examples, the threshold may depend on: QoS attributes of the link to be established; QoS attributes of links present in 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 factors may be based on: a QoS attribute associated with the link; a 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 measured CBR.

In some examples, the measured CBR may be on resources reserved for only one type of transmission (e.g., only broadcast, unicast, and/or multicast transmissions).

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 multiplicative factor (e.g., greater than 1) to radio bearers/links whose reliability requirements or parameters are above the threshold. In some examples, the WTRU may apply a multiplicative factor (e.g., greater than 1) to radio bearers/links having latency requirements or parameters thereof that are shorter than a threshold. In some examples, the WTRU may apply a multiplication factor configured for use with VQI associated with a radio bearer/link.

In some examples, the WTRU may also apply a weight of 0 in the evaluation of the number of established links/bearers (i.e., without considering a particular link and/or bearer).

In some examples, a WTRU may perform admission control based on: transmitting the configured number based on the remaining available RS resources; allocating the remaining available preemption resources; 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 already in use, e.g., as determined by a UMUS signal received over a period of time. In some examples, 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 may be selected for the link and/or SLRB to establish that does not conflict with any existing configuration from the perspective of interference, capability, etc. (e.g., the WTRU may associate an RS transmit power with the QoS of the link to be established and the WTRU may further determine whether a configuration exists with an associated transmit power that does not exceed the allowed WTRU TX power), the WTRU may determine that admission control is successful.

In some examples, the WTRU may determine a time period for 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 mapping of VQI to average or worst-case PDBs. In some examples, the WTRU may determine the amount of resources to transmit in 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. Thus, 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 on all established links/bearers to determine the current resource availability density. In some examples, in this calculation, the WTRU may further apply a multiplicative factor associated with the 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 a given value of a network-derived parameter for reliability/range (e.g., from VQI). In some examples, admission control for a link and/or bearer may be considered successful if a total amount of available resources (including resources for the link and/or bearer to be established) over a configurable period of time is less than a threshold percentage (e.g., X%) of resources in the pool. In this example, the network may further configure X% for each pool, and the WTRU may select from one of a number threshold applicable to the pool based further on the measured CBR. For example, the WTRU may receive a threshold (X%) to apply to each CBR value range of the pool.

In some examples, the WTRU may perform admission control such that the number of active links/bearers with a particular type of rate requirement does not exceed the maximum number of bearers. In some examples, the maximum number of bearers may be determined based on latency related requirements. For example, a WTRU performing admission control for a link and/or bearer having 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 having 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 the minimum PDB associated with each link.

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 unicast and/or multicast links established in the resource selection procedure. In some examples, the WTRU may perform one or more actions during resource selection. The one or more actions may include: refraining from selecting a carrier if the number of links/bearers on the carrier or the amount of available resources for the link/bearer on the carrier is above a threshold; and/or scale or change certain resource selection parameters based on the presence/number of links or amount of available resources in all UMUS. Such parameters may include the number of allowed consecutive resource reservations; a probability of maintaining (e.g., renewing reservation) resources for each reservation period; a CBR threshold for selecting a carrier; an RSRP threshold for determining availability of resources based on detection of SCIs; LBT parameters such as backoff, sensing time, detection sensitivity; a minimum energy associated with a valid/acknowledged preemption signal; and/or based on sensing a percentage of resources deemed available, the WTRU may make a resource selection for that percentage.

In some examples, admission control is based on representative and/or past resource selection procedures. For example, the WTRU may perform a representative resource selection procedure or a series of such procedures to reserve resources for a particular link and/or bearer, and may determine the outcome of admission control based on the outcome of these resource selection procedures. In this case, the representative resource selection process may not be performed to actually reserve or select any resource, but may be performed in order to evaluate the occupancy of the channel. In this case, a 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 procedure may represent an expected result of active resource selection at a past time corresponding to the sensed result stored in the WTRU corresponding to that time. Alternatively, the resource selection procedure for admission control may comprise a resource selection procedure that is actually used to select for broadcast/unicast and/or multicast transmissions in the same pool, BWP and/or carrier, and the time for configuration or pre-configuration has been performed before admission control is performed. For example, the WTRU may maintain statistics (e.g., link establishment decisions) of resource selection procedures performed before the time of required admission control, and may perform admission control based on these statistics.

In some examples, the WTRU may be configured to perform multiple representative resource selection procedures, each with different resource selection parameters, such as different PDBs or wait times; different retransmission times; different MCS, power or related transmission parameters; different packet sizes; and/or different packet periodicity (or lack thereof; e.g., one-time resource selection).

In some examples, the WTRU may be configured to use a set (or multiple sets) of resource selection parameters, e.g., based on QoS characteristics of 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 particular VQI. After 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 was 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 procedure having a different set of parameters, in order to determine admission of a new link and/or bearer.

In some examples, the WTRU may be configured with certain criteria related to past resource selection procedures (e.g., such as those discussed herein) whose results the WTRU should consider. For example, for links with a particular VQI, the WTRU may be configured to consider only past resource selection procedures with PDBs below a threshold, retransmission times above a threshold, etc. as part of resource selection for admission control. After such configuration, the WTRU may perform admission control of the link based only on those past resource selection procedures that meet these particular criteria.

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

In some examples, the WTRU may determine the result of admission control based on a combination of results from past resource selection procedures and representative resource selection procedures. For example, a WTRU may need to base its admission control on a minimum number of resource selection procedures (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 procedures, it may perform a representative resource selection procedure to meet the configured minimum value at admission control.

FIG. 8 is a flow diagram illustrating an example process 800 for admission control based on representative resource selection. In step 810, bearer and/or link establishment can be initiated with QoS information associated with the bearer/link. In step 870, the WTRU may use the configuration, pre-configuration, and/or CBR to determine the number of resource selection attempts performed for admission control and parameters for the resource selection attempts (e.g., PDB-packet delay budget, periodicity, and/or packet size for resource selection, availability thresholds, etc.). These values may also be configured or preconfigured with per bearer QoS and/or CBR or may be predefined. In some examples, the WTRU may determine the number of successful resource selection procedures needed to declare successful admission control. The number of successful resource selection procedures required to declare a successful admission control may also be (pre-) configured or predefined. For example, if the number of successful resource selection procedures is above a configured amount, it may be determined that admission control was successful. The WTRU may determine the success of a single resource selection procedure based on a configured or preconfigured availability threshold (i.e., a percentage of resources available for use as determined by the sensing procedure). For example, if the available resources based on the sensing result are above an availability threshold, a single resource selection process is successful.

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 the 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. At step 830, the WTRU may determine resource selection pass/fail criteria, i.e., criteria for determining whether the representative resource selection procedure was successful, as discussed herein. The pass/fail criteria for the resource selection process may be defined in terms of the number of available resources above/below the percentage availability threshold determined in step 870 based on the sensing results. The pass/fail criteria for the resource selection process may be defined in terms of the percentage of successful resource selection processes above/below the fail percentage threshold determined in step 870. In step 840, the WTRU may perform a representative resource selection procedure using its stored sensing results. In particular, the UE may select resources among a set of shared resources (resource pool) using a set of (pre-) configured parameters (e.g. latency/PDB, periodicity, etc.) by determining available resources from the sensing result. The UE may perform the resource selection process using the number of attempts determined in step 870, potentially using different sensing results associated with different time instants. The representative resource selection process may be based on the sensing results as discussed herein. In particular, the UE may store sensing results taken at different time instants in the past, and may perform a resource selection procedure using sensing results associated with a particular time instant in the past. In some examples, the resource selection procedure may include the WTRU determining available resources based on input parameters.

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

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

In some examples, the admission control is based on the sensing result. For example, a WTRU may perform admission control based on: sensing or measurements that are continuously maintained at the WTRU and/or that are analyzed for 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 LBT procedures that succeed/fail over a configured time (e.g., based on its own access to the channel, or based on measurements transmitted in the UMUS); the number of preemption signals detected within a configured time; sensing results (e.g., information included in SCIs detected during sensing of one or more pools); metrics (e.g., average retransmission rate) related to other ongoing unicast links (e.g., links in the same pool) of the WTRU; measurements of channel quality (e.g., CQI, path loss) during a discovery process of a 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 UMUS).

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

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 link and/or bearer establishment for a bearer with a particular 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 CBR thresholds for each (or any) of the QoS related parameters of latency, reliability, priority, range, and rate. In some examples, the WTRU may determine applicable QoS parameters for the radio bearers to be established based on the relevant QoS parameters for the flows to be mapped to those radio bearers. In some examples, the WTRU may determine appropriate values (e.g., priority, reliability, etc.) for relevant QoS parameters associated with the bearer. In some examples, the WTRU may determine that admission control for a radio bearer is successful if the CBR is below each QoS parameter specific threshold for each relevant QoS parameter for the bearer.

In some examples, the WTRU performs admission control based on the sensing result. For example, the WTRU may determine the admission control rule based on sensing results of the transmissions of the determination from SCIs of other WTRUs over a period prior to the admission control decision. In some examples, the admission control decision may also depend on the QoS aspect 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 a time (T) prior to the admission control decision. In some examples, the sensing results for performing admission control may be derived from one or more pools, BWPs, and/or carriers. In some examples, the admission control decision may depend on a factor or a combination of factors. In some examples, the one or more factors include: observed aperiodic traffic, observed periodic traffic, a relative amount of periodic traffic to aperiodic traffic, observed unicast and/or multicast traffic, or a relative amount of observed unicast and/or multicast traffic compared to broadcast traffic; observed QoS characteristics of periodic, aperiodic, unicast, multicast, and/or broadcast traffic; and/or the amount of reserved resources of a particular granularity.

In some cases where the admission control decision depends on observed aperiodic traffic, the WTRU may measure the amount or percentage of resources associated with aperiodic traffic (e.g., one-time) and may allow establishment of a link and/or bearer if the value is above/below a threshold. In some cases, where admission control decisions depend on observed 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 establishment of a link and/or bearer if the value is above/below a threshold. In some cases where the admission control decision depends on the relative amount of periodic and aperiodic traffic, the WTRU may be configured to have an acceptable ratio of periodic to aperiodic traffic and allow establishment of a link and/or bearer if the measured ratio is above/below a threshold. In some cases (e.g., possibly in comparison to broadcast) where the admission control decision depends on observed unicast and/or multicast traffic, the WTRU may determine the number or percentage of unicast and/or multicast traffic based on: detecting a unicast indicator in the SCI; detection of HARQ process ID or similar in 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 the observed QoS characteristics of periodic, aperiodic, unicast, multicast, and/or broadcast traffic, the WTRU may determine the VQI, or any QoS-related parameter derived from the VQI (e.g., reliability, delay, priority, rate, range), for transmission from the SCI associated with the transmission. In some such cases, the WTRU may modify or select any of the above thresholds further based on the worst, average, best, sum, or majority QoS of the observed transmissions. In some cases where the admission control decision depends on the amount of reserved resources for a particular granularity, the WTRU may determine the amount or percentage of reserved symbol-based or slot-based resources and may perform admission control based on the value being above/below a threshold.

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 a method similar to the method associated with UMUS reception, and may make admission control decisions based on the determination of the percentage of resources used.

Some examples include admission control based on QoS-related measurements and/or metrics. For example, as described herein, a 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 by other WTRUs. For example, the WTRU may obtain such metrics from other WTRUs in the 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 restrict which WTRU metrics to consider in admission control decisions further based on geographic area, unicast and/or multicast relationships, and/or QoS or transmission type.

In some cases where the WTRU considers which WTRU's metrics in admission control decisions based on geographic area restrictions, 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 may limit which WTRUs' metrics to consider in admission control decisions 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 WTRUs that currently have an active unicast and/or multicast link/SLRB. In some cases where the WTRU restricts which WTRUs' metrics to consider in admission control decisions based on QoS or transmission type, the WTRU may only consider metrics received from WTRUs having 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.

In some examples, admission control criteria and/or WTRU measurements may depend on the prevailing QoS characteristics. For example, some transmissions may have strict latency requirements but less strict requirements for reliability (or no requirements at all). For example, the WTRU may determine the admission control measurements and/or criteria further 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 depending 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 according to the VQI of the associated link. In some examples, the WTRU may determine QoS characteristics (e.g., one or more dominant QoS characteristics, which may include delay, reliability, etc.) from VQI associated with the bearer/link to be established, and may make admission control decisions using configured measurements and/or criteria associated with the characteristics. For example, for latency dominated bearers/links (e.g., with latency-critical QoS requirements), the WTRU may use a measured amount of reserved resources at a certain granularity, and/or a measured amount of reserved periodic resources. For reliability dominated bearers/links, the WTRU may use a measured amount of aperiodic resources. For a range-dominant bearer/link, the WTRU may use channel measurements during discovery. Other combinations of measurements and/or criteria for a given QoS characteristic or VQI are also possible and will be clear to those skilled in the art.

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 so that admission control is successful. In some examples, preemption may be performed on links with which the WTRU has established, or may be performed on links between different sets of WTRUs.

In some examples, a 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, the WTRU may determine to preempt one or more existing unicast and/or multicast links if the WTRU decides to establish a new link that cannot currently be established due to the existence of the link (e.g., based on the techniques described herein), or if the establishment of a link results in a potential failure to meet QoS requirements for the link or other already established links (e.g., other links with higher priority). In some examples, a WTRU may be aware of 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 the unicast link.

Without loss of generality, although various examples of preemption may be discussed herein with respect to preemption of links or preemption of radio bearers, note that preemption may be applied to links or radio bearers or both, although for ease of description only examples, embodiments, scenarios and scenarios of one of the two are referenced.

In some examples, the WTRU may transmit a preemption signal to suspend unicast and/or multicast links for a period of time. For example, a WTRU may preempt one of its existing radio bearers in link setup signaling for establishing a new link or radio bearer with the same WTRU or WTRUs. In some examples, the WTRU may transmit a preemption signal to force unicast and/or multicast links to use different pools, BWPs, carriers, or similar resource sets. In some examples, the WTRU may determine whether it may perform preemption based on the QoS of the link to be established; a current occupancy of the channel; configuring; and/or there is a suitable unicast and/or multicast link(s) to preempt.

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 may perform preemption based on the current occupancy of the channel, the WTRU may be configured with a threshold of CBR, and the WTRU may perform preemption of unicast and/or multicast links only if the currently measured CBR is above the threshold. In some cases where the WTRU determines whether it is capable of performing 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 (e.g., VQI associated with a link/radio bearer) or pool/BWP/carrier-specific for the link to be established.

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

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

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

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 the set of active detected links, e.g., based on monitoring by 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 among those links it determines in the received UMUS signal) for which the priority is lower than the priority of the link to be established, possibly by the number of configured or preconfigured priority levels. The WTRU may transmit a preemption signal to preempt the selected unicast and/or multicast link.

In some cases where the WTRU selects one or more unicast and/or multicast links to preempt based on the satisfaction of the properties of the link to be established, for example, the WTRU may select the link(s) that reserve the most similar amount of resources or have the most similar QoS characteristics (e.g., packet size, reliability, etc.) as the link it needs to establish, or the WTRU may select the link(s) that minimize the number of links that need to preempt to meet the requirements of the link to be established. In another example, the WTRU may select the link(s) that minimize the number of links that need to be preempted in order to meet the requirements of the link to be established. In another example, the WTRU may select the unicast and/or multicast link with the estimated packet arrival time closest to the link to be established. For example, the WTRU may determine the packet arrival time of an existing unicast link transmitting 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 having the closest packet arrival time to the link to be established and having a lower priority than the link to be established.

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 a link, for example, the WTRU may preempt one of its own ongoing links, or preempt links with WTRUs with which it has an ongoing link. In some examples, the WTRU may consider its own SLRB or SLRBs between different WTRUs equally, e.g., for selecting SLRBs to be preempted, and/or for selecting criteria. In some examples, the WTRU may preempt its own SLRB before considering preempting other SLRBs. For example, selecting 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 of 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 would decide to bias towards its own SLRB or the SLRB of another WTRU (e.g., the threshold priority level below which to select an SLRB 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).

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 reserve resources in the same area (e.g., area, geographic location, and/or direction) as needed 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 proximate to one or more WTRUs with which the unicast and/or multicast link is to be established. In some examples, the WTRU may be based on detection of the location of the WTRU in SCI/UMUS or one or more similar transmissions by the WTRU (possibly in conjunction with speed/forward direction); and/or determine proximity of one or more unicast and/or multicast links in progress based on RSRP measurements of transmissions by WTRUs in 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.

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 the 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 patterns may also include transmission signatures such as scrambling codes, or frequency hopping sequences, etc. In some examples, the WTRU may choose to preempt WTRUs that have a lower priority than links established based on the same (or overlapping) pattern/signature.

In some examples, the link preemption selection may be performed at the WTRU transmitting the preemption signal or at the WTRU receiving the preemption signal. For example, the WTRU may first determine unicast and/or multicast links to be preempted and may indicate links associated with the unicast and/or multicast links in a preemption signal sent to one or more of the WTRUs. In some examples, a WTRU receiving preemption may preempt the unicast and/or multicast link and/or SLRB indicated in the preemption signal. Alternatively, the WTRU may choose to preempt the WTRU to which it is sent, and the WTRU receiving the preemption signal may use the rules discussed herein to decide with which unicast and/or multicast link and/or SLRB it is associated for preemption.

In some examples, the WTRU may consider all ongoing unicast and/or multicast links having a lower or same priority as the intended 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 value (i.e., other than priority) as the link to be established, and may select that link to be preempted.

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

In some examples, the WTRU may include information in the preemption signal. The information may include: a UE ID of the WTRU transmitting the preemption signal; the UE ID of the one or more WTRUs, the unicast and/or multicast link of the one or more WTRUs being preempted; a link ID to be preempted; a radio bearer ID to be preempted; one or more destination addresses identifying one or more WTRUs associated with the unicast and/or multicast link; a time period during which the link/radio bearer should be preempted; 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 links/bearers or packets whose admission results in preemption of the link and/or SLRB.

On a condition that the WTRU includes one or more QoS parameters associated with a link/bearer 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 set of VQI or VQI (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).

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

In some examples, the WTRU may select the time and/or frequency resources and/or preempt the periodicity of the resources based on a set or pool of allowable resources and/or a configuration or pre-configuration of the periodicity. For example, a resource pool 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 pre-emptive resource from the allowed set based on: one or more criteria such as QoS of the link to be established or SLRB(s); pre-defined modes in the pool are preempted; and/or resource availability.

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

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

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

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

Some examples may include transmitting a preemption message on preemption resources reserved for the link. For example, a WTRU deciding 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 the resources based on the detection of UMUS transmissions by other WTRUs. In some examples, the WTRU may decide whether to preempt and which unicast link and/or SLRB to preempt further based on decoding of the UMUS transmission received over time (T) prior to the preemption decision. For example, the WTRU may select the link and/or SLRB with the lowest priority among all established links it knows based on the UMUS received on T. In some examples, after selecting a link and/or SLRB, the WTRU may transmit a preemption message on the resources indicated in the UMUS for the link and/or SLRB.

Some examples include acknowledgement signaling. In some examples, the WTRU may wait to receive a preemption confirmation signal from one or more WTRUs associated with unicast and/or multicast links before it initiates/completes link establishment. In some examples, the WTRU may repeat transmission of the preemption signal if the WTRU does not receive a preemption confirmation within a threshold amount of time. In some examples, the WTRU may determine successful preemption of the link, and may therefore initiate/complete link establishment based on receipt of at least one preemption confirmation signal. Alternatively, the WTRU may determine successful preemption of the link based on receiving acknowledgements 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.

Some examples include receiving a preemption signal. In some examples, 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 for 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, the WTRU may determine that its received preemption signal applies to its currently established bearer/link.

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

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. The WTRU, upon receiving the preemption signal, may preempt all unicast and/or multicast links in the signal that have a lower priority than the threshold. The WTRU may then notify the upper layers of preemption and/or may initiate release signaling with the peer WTRU(s) in the link.

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

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

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 SLRBs 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.

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, 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 at the broadcast SLRB initiation, where the information in the UMUS reflects one, more, or all broadcast services active at the WTRU. Some procedures (e.g., initiation of reference signal transmission) may not be required for broadcast SLRB establishment.

Admission control of a single packet may result in one or more actions of the WTRU. Such actions may include: successful admission control, where a packet can be submitted for transmission to lower layers (e.g., MAC/PHY layers), subject to normal resource selection procedures; failed admission control, wherein the WTRU may initiate preemption of its own transmissions (e.g., by releasing SLRBs) or other WTRU transmissions (e.g., by transmitting a preemption signal); failed admission control, wherein the WTRU may notify an upper layer of the failure; and/or failed admission control, wherein 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.

Some examples include per-packet admission control. For example, the WTRU may perform per-packet admission control for transmission over the SL each time a packet is received from an upper layer. In some examples, admission control decisions for a single packet 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 the PDB or latency requirements associated with the packet to be transmitted; the WTRU measurements, metrics, and/or estimates of resource usage may use worst case values instead of averages; the decision criteria (e.g., threshold for comparison with WTRU measurements/metrics/resource usage) may be different for admission control per packet compared to link and/or SLRB admission control; based on the conditions described herein, such as with respect to temporary granting of packets despite admission control failures, the failed admission control can be tolerated, where an advantage of the failed admission control can be to avoid tearing down established links and/or SLRBs (e.g., as a result of preemption) in order to satisfy QoS for a single or small number of packets. In some such cases, one or more packets for which admission control failed may be temporarily allowed, e.g., because the desired service may temporarily exceed the QoS capabilities of the resources.

In some examples, the WTRU may perform one of a plurality of operations based on the outcome of admission control, such as: in the event admission control is successful, the packet may be submitted for transmission to lower layers (e.g., the MAC/PHY layer), subject to normal resource selection procedures; in the case of an admission control failure, the WTRU may initiate preemption of its own transmissions (e.g., by releasing the SLRB) or another WTRU transmission (e.g., by transmitting a preemption signal); in the case of admission control failure, the WTRU may notify the upper layer of the failure; on a condition that the admission control fails, the WTRU may negotiate and/or select a new QoS-related attribute for the broadcast service, wherein the WTRU may submit packets associated with a service having the new QoS-related attribute; and/or, in the event of an admission control failure, the WTRU may still transmit an admission control failed packet based on the rules discussed herein regarding temporary admission of the failed admission control packet.

Some examples include temporary granting of a packet despite a failed admission control of the packet. For example, the WTRU may be configured or preconfigured with rules to allow (i.e., grant) packets for which admission control fails. In some examples, if packet admission control fails, this may mean or indicate that the WTRU is unable to maintain QoS for the existing link while ensuring QoS for the service undergoing per packet admission control.

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

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

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

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

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

In some examples, factors for determining parameters related to the temporary grant may include the number of unicast and/or multicast and/or broadcast links/SLRBs currently established on the carrier, BWP, pool, and/or pool in which packet transmission is required. In some examples, factors for determining parameters related to temporary admission may include QoS attributes (e.g., VQI associated therewith) of one or more currently established links/SLRBs transmitted on the same pool, BWP, and/or carrier as the broadcast service. In some examples, factors for determining parameters related to temporary grants may include QoS attributes of packets to be transmitted (e.g., VQI associated therewith), such as latency of transmission, priority, PDB, reliability, and so forth. In some examples, factors for determining parameters related to temporary grants may include a measured CBR of a pool, carrier, and/or BWP over which services and/or packets may be sent. Such a determination (e.g., a relationship between the allowable failure rate and the VQI of the currently established SLRB or SLRBs) may further be configured or preconfigured at the WTRU.

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

In some examples, the WTRU may be configured to perform admission control of broadcast packets by determining a worst case resource usage, e.g., UMUS-based decoding, associated with all established SLRBs and comparing the percentage of resource usage to the total amount of resources to a threshold. In some examples, admission control for a broadcast packet may be considered to have failed if the calculated resource usage at the time the packet arrives is above a threshold. In some examples, the threshold may be determined by the WTRU based on a configured or pre-configured mapping of the VQI of the broadcast packet. In some examples, the WTRU may allow for a broadcast packet admission control failure rate, where the WTRU still performs transmission of such broadcast packets. 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., SLRB for worst case or best case) to an allowed failure rate, and such a rate may be used to temporarily allow packets for which admission control fails.

Some examples include methods, systems, and devices for unicast and/or multicast link maintenance. For example, a WTRU may be configured to transmit one or more reference signals at link setup. In some examples, a WTRU may be configured to transmit one or more reference signals when establishing a link for sidelink link maintenance. For example, the WTRU may start transmitting such reference signals after successful link establishment from the upper layers or from the RRC, and may stop transmitting these reference signals after link release. 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.

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 at the first link setup 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 properties) for each unicast and/or multicast link, and may start/stop reference signal transmission for the associated link when the link is established/released.

Some examples include reference signal reception. For example, the WTRU may monitor and/or measure reference signals for link monitoring after establishing unicast and/or multicast links. The WTRU may be configured (e.g., via RRC) with specific time, frequency, and/or beam resources associated with the location of the reference signal. In some examples, such a configuration may be provided to the WTRU by a peer WTRU or by the 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 a link release or after the WTRU's last active link release.

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 the shared resources. In some examples, a mode 2WTRU may determine the time, frequency, and/or beam position of reference signals that it needs to transmit, and/or the time, frequency, and/or beam position of reference signals transmitted by other WTRUs in unicast and/or multicast links. 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 the unicast and/or multicast group. In some examples, after the WTRU selects resources, the WTRU may transmit a long-term reservation signal to reserve such RS resources indefinitely. In some examples, such reservation signals may be sent on the PSCCH (e.g., SCI-like transmissions) and may include resource configurations for reference signals, e.g., from a configured or pre-configured set.

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

Some examples include determining a reference signal configuration based on a unique WTRU ID, a link ID, or a bearer ID. For example, a 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 pschs and PSCCHs. In some examples, a 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.

In some examples, to avoid collisions between reference signal transmissions, the WTRU may select a resource configuration for the reference signal transmissions. The WTRU may make this selection based on: based on the unicast and/or multicast link ID, the link ID may be assigned by the network or upper layers (e.g., where the ID is unique); based on 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 unicast and/or multicast links, if present; based on a destination ID associated with the service; a WTRU-based C-RNTI; based on the radio bearer ID.

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 position of those reference signals based on: configuring based on the reference signal; based on the unique ID associated with the unicast and/or multicast link, it may be equal to the L2 source ID, L2 destination ID, assigned unicast and/or multicast link ID from upper layers or from the network; based on the radio bearer ID; and/or based on WTRU IDs that are unique within unicast and/or multicast groups.

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

In some examples, the WTRU may be provided with a configuration of possible reference signal times, frequencies, and/or beam locations associated with the dedicated physical channel. In some examples, the WTRU may also be configured to have a mapping of resources (e.g., a definition of a set of resources) associated with each other. In some examples, the WTRU may select a set of resources to be used for transmission and/or reception of reference signals based on configured unicast and/or multicast link IDs using modulo arithmetic (e.g., where the reference set modulo the WTRU ID 0).

In another example, the WTRU may identify a reference signal or set of reference resources 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 (WTRUs) may correspond to the "xth" set of reference signals assigned for the multicast link.

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

Some examples include a process for changing a reference signal configuration due to an ID change. For example, the WTRU may need to change its source L2 ID, e.g., for security purposes, such as upper layer based decisions. In some examples, the transmit and receive reference signals of the WTRU may need to be synchronized during an ID change.

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 slot (n) relative to a reception time indicated by an upper layer. In subframe/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, the WTRUs monitoring the reference signal may operate in the same manner or substantially the same manner from a reception perspective. For example, in a subframe or slot (N), the WTRU may stop monitoring for reference signals according to the old configuration and may start monitoring for 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; changing the ID based on a defined time position after receiving the upper layer indication (e.g., subframe N may be a first occurrence of subframe 0 after receiving the upper layer indication, which is at least a threshold (k) subframe after the indication); and/or based on reception in RRC signaling (e.g., the source WTRU may determine the timing of the reference signal configuration change and indicate the timing to one or more other WTRUs in unicast and/or multicast links using RRC messages). In some examples, a receiving WTRU may be configured to discontinue monitoring for reference signals for a period of time immediately after receiving an 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 way as previously described.

In some examples, the WTRU may determine its sidelink monitoring parameters based on the active SL radio bearer. In some examples, the WTRU may perform a sidelink monitoring procedure based on measurements of reference signals transmitted by other WTRUs on sidelinks. In some examples, the WTRU may perform multiple independent SL monitoring procedures. Such a monitoring procedure 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 (e.g., BLER on RS-RSRP, PSCCH, or pscsch, etc.) from a reference signal transmitted by another WTRU and indicating to an upper layer when the metric is below a threshold for a threshold time.

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 VQI. In some examples, the WTRU may also be configured with RLM/RLF configuration for each VQI, and the associated configuration may be applied if the bearer with such VQI is active. In some examples, a bearer having multiple mapped VQIs may be associated with the VQI based on: a value of the VQI, wherein the WTRU selects the VQI with the lowest or highest number; and/or based on one or more QoS parameters derived from the VQI from which the WTRU may derive a set of QoS related parameters, such as priority, delay, 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 VQI with the most stringent of those requirements. In some examples, the WTRU may implicitly change its monitoring procedures and/or parameters when adding and/or removing bearers, e.g., based on the rules described above.

In some examples, the VQI-specific RLM/RLF configuration may include: target PSSCH/PSCCH BLER; a target RS-RSRP; the frequency of the RLM-like indication to the upper layers (e.g., RRC; e.g., how often the PHY layer may report RSRP below target); and/or a timer (e.g., a RLF-like timer).

Some examples include monitoring procedures and/or parameters for each unicast and/or multicast link. In some examples, the WTRU may determine its monitoring procedure and/or quality metrics based on 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 the set of currently active SL radio bearers for the 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, the WTRU performs monitoring based on the parameters of RB type 1 if both bearers are configured simultaneously. Otherwise, when a single bearer is active, the WTRU may apply the procedures and/or parameters associated with that bearer.

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 active radio bearer combinations, and the procedures and/or parameters may be applied if the bearer combinations are active. Otherwise, when a single bearer is active, the WTRU may apply the procedures and/or parameters associated with that bearer.

In some examples, the WTRU may maintain multiple procedures and/or parameters. For example, the WTRU may maintain parallel procedures (e.g., performed in parallel and independently) and sets of parameters 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 report measured reference signal quality (RS _ QUAL) < target independently for each radio bearer, where each SL radio bearer may be configured with a different set of reference signals. In another example, the same set of reference signals 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.

In some examples, the WTRU may maintain multiple procedures and/or parameters for a single SL radio bearer if the SL radio bearer is configured with different VQI, which may be associated with different VQI ranges. For example, the WTRU may be configured with 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.

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

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

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

In some examples, the WTRU may report 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).

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

Where the WTRU determines a particular subset of WTRUs based on upper layer configuration, the WTRU may be explicitly configured with the set of WTRUs for which a link failure should occur, or the WTRU may derive the subset of WTRUs based on another configuration aspect, such as relay configuration, queue configuration, and identity of each WTRU role, resource selection configuration (if WTRU-assisted resource selection is used), and/or synchronization source configuration. On a condition that the WTRU determines a particular subset of WTRUs based on relative location, the WTRU may indicate a link failure if a subset of WTRUs closest/farthest to the WTRU experience a link failure.

Some examples include additional triggers for link failure based on admission control metrics. For example, a WTRU with an established radio bearer may perform the same, or substantially similar, measurements as those of admission control 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, the WTRU may utilize any of the mechanisms described herein with respect to admission control, assuming that the bearer to be added is the bearer that is performing link monitoring. In some examples, the WTRU may perform such admission control independently for each established SL bearer. In some examples, the WTRU may perform the associated admission control procedure with different timing depending on the SLRB.

Without loss of generality, the WTRU may perform link monitoring by performing one or more admission control procedures as described herein, which are performed when 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, the tear down of a link and/or SLRB, and/or the preemption of another SLRB/link.

In some examples, the WTRU may be configured with a periodicity for deriving the admission control procedure. In some examples, the periodicity may be determined for each bearer. In some examples, based on a failure of a single admission control procedure, the WTRU may change the frequency of admission control procedure performance, or may perform multiple subsequent admission control procedures for the radio bearer until the procedure is successful, or until a maximum number of failed performances is reached. In some examples, the WTRU may trigger a link failure after a threshold number (N) of consecutive failures of the admission control procedure.

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

Some examples may include additional triggers for link failure 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 link failures for a particular link and/or bearer, the WTRU may consider an intermediate amount of resource selection algorithm results for resource selection specific to that link or bearer. In some examples, the WTRU may declare 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 continuously). Such events may include: resource selection cannot find a threshold amount of resources (X%) that are available with a constant resource availability threshold; resource selection cannot reserve a sufficient amount of resources to satisfy the QoS of a bearer on a single carrier/BWP; selecting a resource for transmission of the PSCCH and/or PSCCH to have an RSRP/RSSI above a threshold; by sensing that the percentage of "low latency" type resources (e.g., symbol-based resources) deemed available is below a threshold; the WTRU receiving a NACK for unicast and/or multicast transmission; the WTRU fails the LBT procedure; and/or wherein the WTRU receives the preemption signal for the radio bearer for a time that may last greater than a threshold (T).

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

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

In some examples, a WTRU detecting a link failure may perform one or more actions depending on the type of link failure. Such actions may include trigger group QoS negotiation/resource selection with new resources (e.g., if a link failure procedure is based on failure of a particular radio bearer or QoS target, the WTRU may choose to initiate a QoS re-negotiation procedure, similar to the procedure performed during initial link setup); notifying upper layers and/or other WTRUs to remove one or more WTRUs from a multicast group (e.g., if a link failure is associated with only one or a subset of WTRUs in the multicast group); initiate a temporary fallback to broadcast procedure as discussed herein; changing the resource selection mode from one type of mode to another (e.g., the WTRU may initiate a request to change the resource selection mode to mode 1 for a particular bearer); notifying an upper layer and/or a network of the failure to meet the QoS requirement; initiating a link release signaling; and/or release all resources associated with the link, including TX/RX of reference signals, infinitely reserved resources, and stop transmission of the UMUS.

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: declare a failed RLM/RLF procedure/procedure ID; one or more WTRUs failing in the multicast link; triggering the failed one or more specific bearers; and/or failure cause (e.g., CBR above threshold, etc.) and any associated values.

In some examples, the WTRU may initiate a temporary backoff to the broadcast-based transmission. In some examples, the WTRU may continue to transmit data received for a particular SL bearer, but may transmit such data in a broadcast manner, with lower layer AS parameters set to broadcast. For example, the WTRU may change from using a unicast address to a broadcast address; may be changed 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; transmission/monitoring of reference signals for RLM and/or beam management may be disabled; disabling 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 temporary fallback to broadcast, the WTRU may maintain unicast and/or multicast configurations for temporary fallback.

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

In some examples, if the WTRU detects a link failure that may be associated with certain causes; if the WTRU receives the preemption signal, the preemption signal is potentially associated with a preemption time value below a threshold (e.g., associated with a 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.

Some examples include methods, systems, and devices for SL unicast and/or multicast stream-to-bearer mapping. 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. The 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, WTRU-assisted usage, etc.); may include resource selection pools, carriers, BWs, and/or BWPs; 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 of resource configurations; may include the directionality and/or beam configuration of the transmission; may include pools, BWPs, etc.; PHY and/or MAC layer parameters (e.g., HARQ configuration, duplication); may include RLM/RLF configurations (e.g., RLF timer, RLM target BLER/RSRP); and/or may include QoS configurations such AS rules for mapping flows to bearers, QoS profile information, and mapping bearer types to AS configurations.

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

In some examples, the WTRU may be configured with a flow to radio bearer mapping 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 the bearer (e.g., rate-related 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 rates); and/or the WTRU may be configured for direction (e.g., flows having the same expected direction or geographic location may be mapped to the same radio bearer or flow as a subset of radio bearer directions).

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

Fig. 9 is a flow diagram illustrating an example method 900 for determining whether to establish a SLRB.

In step 910, the WTRU is configured with SLRB resource selection criteria. The resource selection criteria may include a quality of service indicator (VQI).

In step 920, the WTRU receives multiple SCI transmissions from at least one other WTRU in the pool during a time window.

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 procedure will fail based on the plurality of SCI transmissions and the SLRB resource selection criteria. In some examples, the WTRU determines whether SLRB resource selection will fail based only on a time period of the plurality of time periods in which 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 the time periods in which the number of retransmissions in the plurality of time periods is above a threshold.

In step 950, the WTRU determines the percentage of SLRB resource selection procedures that will fail. In some examples, determining the percentage of SLRB resource selection processes that are likely to fail includes determining what percentage of the time period within the time window includes SLRB resource selection processes that are likely to fail, or includes determining what percentage of SLRB resource selection processes within the time window will fail.

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

Fig. 10 is a flow diagram illustrating another example method 1000 for determining whether to establish a SLRB.

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

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

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 a plurality of other WTRUs in the pool.

On condition 1040, where the total resource density does not exceed the 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. In either condition 1040, the WTRU returns to step 1020 to start the procedure again, or end if appropriate.

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of the computer readable storage medium 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 in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, or any host computer.

Claims (22)

1. A method implemented in a wireless transmit/receive unit (WTRU) for determining whether to establish a sidelink radio bearer (SLRB), the method comprising:

Configuring the WTRU with SLRB resource selection criteria;

receiving, by the WTRU, a plurality of Sidelink Control Information (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 criteria; 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 WTRU in the pool on a condition that a percentage of a time period for which resource selection will fail is determined to be below a threshold percentage.

2. The method of claim 1, wherein the SLRB resource selection criteria is determined by a V2X quality of service indicator (VQI).

3. The method of claim 2, wherein the SLRB resource selection criteria includes a number of retransmissions.

4. The method of claim 2, wherein the SLRB resource selection criteria includes a packet delay budget to be used in resource selection.

5. The method of claim 1, wherein the WTRU determines whether SLRB resource selection will fail based only on a time period of the plurality of time periods for which an amount of available resources that meet the resource selection criteria is below a threshold.

6. The method of claim 1, wherein the new SLRB is to be established with one of a plurality of WTRUs in the pool.

7. The method of claim 1, wherein the plurality of SCI transmissions are received from each of a plurality of other WTRUs in the pool.

8. The method of claim 1, wherein the percentage of resource selection failures comprises a percentage of a time period in the time window during which resource selection will fail.

9. The method of claim 1, wherein the percentage of resource selection failures comprises a percentage of resource selection processes that will fail during the time window.

10. A wireless transmit/receive unit (WTRU) configured to determine whether to establish a sidelink radio bearer (SLRB), the WTRU comprising:

a processor operatively coupled to the transmitter and the receiver;

the processor is configured with SLRB resource selection criteria;

the receiver configured to receive a plurality of Sidelink Control Information (SCI) transmissions from another WTRU in a pool during a time window;

the processor is configured to determine, 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 criteria;

The processor is further configured to determine whether to establish a new SLRB based on a percentage of resource selection failures; and

the transmitter is configured to transmit a message with the other WTRU in the pool to establish the new SLRB on a condition that a percentage of a time period during which resource selection will fail is determined to be below a threshold percentage.

11. The WTRU of claim 10, wherein the message to establish the new SLRB includes a link establishment request message or a link establishment response message.

12. The WTRU of claim 10 wherein the SLRB resource selection criteria is determined by a V2X quality of service indicator (VQI).

13. The WTRU of claim 12, wherein the SLRB resource selection criteria includes a number of retransmissions.

14. The WTRU of claim 12, wherein the SLRB resource selection criteria includes a packet delay budget to be used in resource selection.

15. The WTRU of claim 10, wherein the processor is configured to determine that SLRB resource selection will fail based only on a time period of the plurality of time periods for which an amount of available resources that meet the resource selection criteria is below a threshold.

16. The WTRU of claim 10, wherein the new SLRB is to be established with one of a plurality of WTRUs in the pool.

17. The WTRU of claim 10 wherein the receiver is configured to receive each of the plurality of SCI transmissions from each of a plurality of other WTRUs in the pool.

18. The WTRU of claim 10, wherein the percentage of resource selection failures includes a percentage of a time period in the time window during which resource selection will fail.

19. The WTRU of claim 10, wherein the percentage of resource selection failures includes a percentage of resource selection procedures that will fail during the time window.

20. A method implemented in a wireless transmit/receive unit (WTRU) for determining whether to establish a sidelink radio bearer (SLRB), the method comprising:

configuring a mapping of bearer QoS to SLRB resource density to the WTRU;

receiving, by the WTRU, a broadcast transmission indicating a QoS for an SLRB of another WTRU in a pool;

determining, by the WTRU, a total SLRB resource density in the pool based on the QoS and the mapping; and

determining, by the WTRU, whether to establish a new sidelink bearer with another WTRU in the pool based on whether the total resource density exceeds a threshold, the threshold based on a QoS of the new sidelink bearer;

On a condition that the WTRU determines to establish the new sidelink bearer, establishing the new sidelink bearer with the other WTRU in the pool.

21. The method of claim 20 wherein the WTRU receives the broadcast transmission from a plurality of other WTRUs in the pool.

22. The method of claim 21 wherein the WTRU determines the total SLRB resource density based on the broadcast transmissions from the plurality of other WTRUs in the pool.

Images