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

Abstract

To provide a system, method, and device for unicast and / or multicast link establishment and maintenance.SOLUTION: A wireless transmit receive unit (WTRU) transmits a link establishment request broadcast message. The link is for a multi-cast, an unicast, or a group cast. The WTRU receives a link establishment response broadcast message and a connectivity report. The WTRU transmits a link establishment confirmation broadcast message when the multi-cast or the unicast link is established, and then, transmits and receives a multi-cast message at a time point of an establishment of the link. The WTRU transmits a unicast and / or multi-cast usability signal (UMUS). The WTRU preempts the established multi-cast or the unicast link.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 736,251, filed September 25, 2018, U.S. Provisional Patent Application No. 62 / 752,865, filed October 30, 2018, U.S. Provisional Patent Application No. 62 / 783,952, filed December 21, 2018, and U.S. Provisional Patent Application No. 62 / 886,102, filed August 13, 2019, the contents of each of which are incorporated herein by reference. [Background technology]

[0002] background

[0002] Wireless communication use cases may address vehicular communications related to traffic, transportation, safety, navigation, and the like. For example, vehicle-to-everything (V2X) communications may involve the transmission and reception of wireless communications with vehicles. As wireless communication capabilities and requirements evolve, it may be desirable to provide systems, methods, and devices that operate in such environments. Summary of the Invention

[0003] overview Some embodiments provide a method, implemented in a wireless transmit / receive unit (WTRU), for determining whether to establish a sidelink radio bearer (SLRB). The method includes configuring a SLRB resource selection criterion in the WTRU, receiving, by the WTRU, a number of SCI transmissions from another WTRU in a pool during a time window, determining, by the WTRU, for each of a number of time periods in the time window, whether an SLRB resource selection would have failed based on the number of SCI transmissions and the SLRB resource selection criterion, determining, by the WTRU, whether to establish a new SLRB based on a rate of resource selection failures, and establishing the new SLRB with another WTRU in the pool in a situation where the rate of time periods during which resource selection would have failed is determined to be less than a threshold rate.

[0004]

[0004] Some embodiments provide a WTRU configured to determine whether to establish an SLRB. The WTRU includes a processor operably coupled to a transmitter and a receiver. The processor is configured with an SLRB resource selection criterion. The receiver is configured to receive a plurality of 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 an SLRB resource selection would have failed based on the plurality of SCI transmissions and the SLRB resource selection criterion. The processor is further configured to determine whether a new SLRB should be established based on a rate of resource selection failures. The transmitter is configured to transmit a message to establish a new SLRB with another WTRU in the pool in a situation where a rate of time periods during which resource selection would have failed is determined to be less than a threshold rate.

[0005]

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

[0006] Some embodiments provide a WTRU configured to determine whether to establish a 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 the 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 QoS-based threshold for the new sidelink bearer. The transmitter is configured to transmit a message to establish a new sidelink bearer with another WTRU in the pool in a situation where the processor determines to establish a new sidelink bearer.

[0007] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding of the drawings can be had from the following description, which is not intended to limit the scope of the embodiments, but serves merely as an example in conjunction with the accompanying drawings, in which like reference numbers indicate like elements. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]

[0009] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to an embodiment. [Figure 1C]

[0010] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Figure 1D]

[0011] FIG. 1B is a system diagram illustrating a further example RAN and a further example CN that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Diagram 2]

[0012] 1 is a message sequence chart illustrating an example link establishment procedure between two WTRUs. [Diagram 3]

[0013] FIG. 2 is a block diagram of a link establishment model illustrating an example of a procedure for connection establishment decision performed by the AS layer. [Figure 4]

[0014] FIG. 2 is a block diagram of a link establishment model illustrating an example procedure in which higher layers make connection establishment decisions based on information from the AS layer. [Diagram 5]

[0015] 13 is a message sequence chart illustrating an example sidelink link establishment procedure at the AS layer between WTRUs. [Figure 6]

[0016] 4 is a message sequence chart illustrating example multicast link establishment signaling and criteria. [Figure 7]

[0017] 1 is a message sequence chart illustrating an example multicast link establishment signaling. [Figure 8]

[0018] 11 is a flowchart illustrating a procedure for an example of admission control based on a representative resource selection. [Figure 9]

[0019] 1 is a flow chart illustrating an example method for determining whether to establish a sidelink radio bearer (SLRB). [Figure 10]

[0020] 11 is a flow chart illustrating another example method for determining whether to establish an SLRB. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Detailed Description

[0021] 1A illustrates 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, messages, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block-Filtered OFDM, and Filter Bank Multi-Carrier (FBMC).

[0010]

[0022] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automation processing chain context), consumer electronic devices, and devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0011]

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

[0012]

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

[0013]

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

[0014]

[0026] More specifically, as noted above, the communication system 100 may be a multiple access system and may utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base stations 114a and 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 ​​Uplink (UL) Packet Access (HSUPA).

[0015]

[0027] 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), and the radio technology may establish the air interface 116 using Long Term Evolution (LTE), LTE Advanced (LTE-A), and / or LTE Advanced Pro (LTE-A Pro).

[0016]

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

[0017]

[0029] 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 implement LTE radio access and NR radio access together, for example, using a dual connectivity (DC) principle. Thus, the radio interface utilized 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).

[0018]

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

[0019]

[0031] 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 utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a workplace, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., used by drones), and a roadway. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0020]

[0032] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. The CN 106 / 115 may provide call control, charging services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high level security functions, such as user authentication. Although not shown in FIG. 1A, it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RATs that utilize the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA or WiFi radio technology.

[0021]

[0033] 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communications protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may utilize the same RAT as the RAN 104 / 113 or a different RAT.

[0022]

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

[0023]

[0035] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements and still be consistent with an embodiment.

[0024]

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

[0025]

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

[0026]

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

[0027]

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

[0028]

[0040] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., 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. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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 the like. 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 as a server or home computer (not shown).

[0029]

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

[0030]

[0042] 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) regarding a 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 a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0031]

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0032]

[0044] The WTRU 102 may include a full-duplex radio, in which case the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be coincident and / or simultaneous. The full-duplex radio may include an interference management unit 139 and may reduce and / or substantially eliminate self-interference by hardware (e.g., a choke) or by signal processing by a processor (e.g., by a separate processor (not shown) or by processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that is the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for the UL (e.g., for transmission) or downlink (e.g., for reception)).

[0033]

[0045] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned 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 the CN 106.

[0034]

[0046] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas.

[0035]

[0047] Each of the eNodeBs 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, etc. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0036]

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

[0037]

[0049] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may handle authentication of users of the WTRUs 102a, 102b, 102c, activation / deactivation of bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0038]

[0050] The SGW 164 may connect to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data becomes available to the WTRUs 102a, 102b, 102c, as well as managing and storing the context of the WTRUs 102a, 102b, 102c.

[0039]

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

[0040]

[0052] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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 and / or wireless networks owned and / or operated by other service providers.

[0041]

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

[0042]

[0054] In an exemplary embodiment, the other network 112 may be a WLAN.

[0043]

[0055] 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 that AP. The AP may have access or interface to a distribution system (DS) or to another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic to a STA originating from outside the BSS may come through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be sent, for example, through the AP, where the source STA may deliver traffic to the AP and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source and destination STA in a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, but the STAs (e.g., all of the STAs) in or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" mode of communication.

[0044]

[0056] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set by signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish communication with the AP. In some representative embodiments, for example, an 802.11 system may implement carrier sense multiple access with collision avoidance (CSMA / CA). With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or identified as busy by a particular STA, the particular STA may be dropped. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0045]

[0057] High throughput (HT) STAs may use 40 MHz wide channels for communication, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0046]

[0058] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight adjacent 20 MHz channels or combining two non-adjacent 80 MHz channels, which may be called an 80+80 configuration. For the 80+80 configuration, after channel coding, the data may be passed through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration may be reversed and the combined data may be sent to the media access control (MAC).

[0047]

[0059] Sub 1 GHz operating modes are supported in 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have some functionality, such as limited functionality including support for (e.g., only support for) some and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0048]

[0060] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting can depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports a 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and be available for use.

[0049]

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

[0050]

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

[0051]

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

[0052]

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

[0053]

[0065] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without further access to another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement a DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as a mobility anchor 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, 102c.

[0054]

[0066] Each of the gNBs 180a, 180b, 180c 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, support for network slicing, dual connectivity, interconnection between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b and routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0055]

[0067] 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, 185b. Although each of the foregoing elements is shown as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056]

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and act as a control node. For example, the AMF 182a, 182b may handle authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling various PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN ports for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services utilizing Ultra-Reliable Low Latency (URLLC) access, services utilizing Enhanced Large Capacity Mobile Broadband (eMBB) access, and / or services for Machine Type Communications (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0057]

[0069] 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 the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning IP addresses for UEs, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification. The PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0058]

[0070] The UPFs 184a, 184b may connect to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. 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.

[0059]

[0071] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or 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 and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0060]

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

[0061]

[0073] The emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the emulation device or devices may perform one or more or all of the functions but are fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. The emulation device or devices may perform one or more or all of the functions but are temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device to perform the tests and / or may perform the tests using wireless communication over the air.

[0062]

[0074] The emulation device(s) may perform multiple functions, including one or all, but are not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device(s) may be utilized in a test lab and / or test scenarios in a non-deployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. The emulation device(s) may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0063]

[0075] Vehicle-to-everything (V2X) communications may pass information between vehicles and other entities, such as other vehicles, roadside units (RSUs), and pedestrian user devices (WTRUs, among others). In some cases, vehicular V2X communications include a communication mode in which WTRUs communicate directly with each other. V2X operations include in-coverage and out-of-coverage scenarios. In-coverage scenarios may include the WTRU receiving assistance from the network to begin transmitting and receiving V2X messages. Out-of-coverage scenarios may include the WTRU beginning transmitting and receiving V2X messages based on preconfigured parameters.

[0064]

[0076] V2X communication may be supported by LTE and may relate to functions in device-to-device (D2D) communication. V2X communication may include different types of services such as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P) services. V2V services may serve direct communication between vehicular WTRUs. V2I services may serve communication between vehicular WTRUs and RSUs and / or eNBs. V2N services may serve communication between vehicular WTRUs and a core network. V2P services may serve communication between vehicular WTRUs and a WTRU with special conditions such as low battery capacity.

[0065]

[0077] V2X communications may include different operation modes 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 resource scheduling assignment for V2X sidelink (SL) transmissions to the WTRU. Mode 4 operation may include the WTRU autonomously selecting resources from a configured or preconfigured resource pool. V2X (e.g., LTE V2X) may include two categories of resource pools: a receive pool and a transmit pool. The WTRU may monitor V2X resources (e.g., time and / or frequency) in the receive resource pool to receive V2X transmissions. The WTRU may select transmit resources from the V2X transmit resource pool, for example, in Mode 4 operation. In some implementations, a WTRU configured for Mode 3 operation may not use a transmit pool.

[0066]

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

[0067]

[0079] New Radio (NR) may support several use cases such as enhanced Mobile Broadband (eMBB), ultra-reliable low latency (URLLC) and other technologies. Enhanced V2X (eV2X) communications may be used in conjunction with NR systems. In NR, eV2X may provide new services for safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning and remote driving, etc.). Different eV2X services may require different performance requirements, such as scenarios requiring 3ms latency.

[0068]

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

[0069]

[0081] Vehicle platooning may allow vehicles to travel together and dynamically form a group. All vehicles in the platoon may receive periodic data from the lead vehicle to continue platooning. Such information may facilitate extremely small distances between vehicles (i.e., gap distances replaced by time, i.e., computational latency may be very small, e.g., latency less than 1 second). Platooning applications may help vehicles following the lead vehicle to drive autonomously.

[0070]

[0082] Advanced driving may enable semi-automated or fully automated driving for larger vehicle distances. For example, V2X devices may include vehicles or other mobile nodes and roadside units (RSUs) or other stationary nodes. Each vehicle and / or roadside unit (RSU) may share data acquired from local sensors with nearby vehicles, allowing the vehicles to adjust their trajectories or maneuvers. Additionally, each vehicle may share its driving intentions with nearby vehicles. For example, a vehicle may transmit messages to other vehicles containing various information, such as speed and / or direction changes, to indicate the vehicle's driving intentions. Advanced driving may help safer driving, collision avoidance, and improved traffic efficiency.

[0071]

[0083] The extended sensors may enable the exchange of raw or processed data collected through local sensors or live video data between vehicles, RSUs, pedestrian devices, and / or V2X application servers. Vehicles may enhance their perception of the environment beyond what their own sensors can detect, for example to provide a complete picture of the local situation.

[0072]

[0084] Remote driving may enable a remote driver or V2X application to operate a remote vehicle. This may be advantageous, for example, to provide vehicle operation to passengers who cannot drive themselves, or to provide remote operation to vehicles in hazardous environments. In some cases where variety is limited and routes are predictable, such as public transportation, driving based on cloud computation may be used to control or facilitate remote driving. A cloud-based back-end service platform may be used for remote derivation. For example, vehicles or other V2X devices may exchange messages with a central or cloud server to perform computations.

[0073]

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

[0074]

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

[0075]

[0087] WTRUs involved in decoupled (ie, non-relayed) point-to-point communication may negotiate an IP address allocation mechanism and, optionally, exchange link-local IPv6 addresses, if necessary, during the link establishment procedure.

[0076]

[0088] 2 is a message sequence chart illustrating an example procedure 200 for establishing a link between the WTRU 210 and the 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 content of the direct communication request message 230 may be referred to as user information. In a second step, the WTRU 220 initiates a mutual authentication procedure 240. Upon successful completion of the authentication procedure, the establishment of a secure Layer 2 link over PC5 is completed. As part of this step, the WTRU 220 includes the user information in a response message to the WTRU 210.

[0077]

[0089] The PC5 signaling protocol supports a keep-alive function that may be used to detect if the WTRU is not within ProSe communication range, and may proceed to an implicit Layer 2 link release if the WTRU is not within ProSe communication range.

[0078]

[0090] NR V2X may include link establishment enhancements (e.g., compared to D2D). For example, procedures may provide for establishment and maintenance of a secure L2 link over PC5. Such procedures may be enhanced and adapted for V2X use, or similar signaling may be defined at the RRC layer. V2X link / group handling may require further consideration. For example, not all WTRUs support or use unicast communication in V2X communication. To support link establishment, a WTRU may send service announcements to inform peers of its presence and, if present, its capability of unicast communication (e.g., channels on which the WTRU can operate for unicast, supported services, etc.). Such service announcements may be accessible to all WTRUs interested in using the service (e.g., application). For example, such announcements may be configured to be sent over a dedicated channel, similar to how WAVE Service Advertisements (WSAs) are handled, or may be configured to be piggybacked (e.g., added or attached) to periodic messages from a supporting WTRU.

[0079]

[0091] NR V2X may include QoS enhancements. For example, QoS over PC5 may be supported using ProSe Per-Packet Priority (PPPP). The application layer may be allowed to mark packets with PPPP to indicate the required QoS level. Other enhancements may also be added (e.g., allowing derivation of PDB from PPPP).

[0080]

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

[0081]

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

[0082]

[0094] A 5GS V2X-capable WTRU may support three different types of traffic: broadcast, multicast, and unicast.

[0083]

[0095] The same QoS model as Uu may be utilized for unicast traffic (i.e., each unicast link may be treated as a bearer and a QoS flow may be associated with it). All QoS characteristics and additional data rate parameters defined in 5QI may apply. Additionally, minimum required communication range may be treated as an additional parameter specific to PC5 usage.

[0084]

[0096] The same or similar considerations may apply to multicast traffic, which may be treated as a special case of unicast (ie, there are multiple defined recipients of the traffic).

[0085]

[0097] For broadcast traffic, there may be no bearer concept, i.e., there is no association between a packet and a logical link with specific configured parameters. Each broadcast message may have different characteristics according to the application requirements. Therefore, 5QIs may be used similarly to PPPP and / or ProSe Per-Packet Reliability (PPPR), i.e., each packet is associated (or "tagged") with a QoS value. 5QIs may have the ability to represent all characteristics required for PC5 broadcast operation (e.g., latency, priority, reliability, etc.). A V2X broadcast specific 5G Quality of Service Indicator (V2X 5QI) or group of (VQI) may be defined for PC5 usage.

[0086]

[0098] The PC5 QoS parameters may be negotiated during the establishment of the one-to-one communication procedure. Thus, the one-to-one communication establishment procedure may be enhanced to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation, the same QoS may be used in both directions of the one-to-one communication.

[0087]

[0099] 2 may be modified to negotiate 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 as an alternative to the user information. In a second step, the procedure 240 may include the allowed PC5 QoS parameters in a response message to the WTRU 210 in addition to or as an alternative to the user information.

[0088]

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

[0089]

[0101] Also, in some implementations, link establishment decisions (e.g., 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, speed, 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 not previously required and / or specified for D2D or V2X. For example, admission control procedures that are handled autonomously by the WTRU may be required for Uu (e.g., for Mode 4 operation), whereas typically this may have been performed by the network. In another example, link maintenance procedures for QoS over sidelink may require the AS layer to maintain a particular quality level for SL transmissions.

[0090]

[0102] Also, in some implementations, the QoS model may assume that a set of flows is mapped to a specific bearer (e.g., similar to Uu). In the case of Uu, the mapping may be done by the gNB based on the free DL / UL resources. In the case of SL, the decision may need to be performed by the WTRU (e.g., for Mode 4 operation) and may need to be based on the attributes of the free SL resources and the SL bearer characteristics that the WTRU may set up itself.

[0091]

[0103] Some embodiments may provide systems, methods, and devices for establishing and maintaining links. Link establishment and maintenance is discussed herein with respect to unicast or groupcast transmissions. Substantially similar link establishment and maintenance procedures may be applied to "broadcast links," whereby broadcast links may involve less or no admission control evaluation and / or link maintenance procedures. Nevertheless, link establishment signaling may still be applicable to broadcast transmission cases, as long as radio bearers may be established for broadcast services associated with transmissions to group destination IDs or L2 destination IDs. Thus, the techniques and approaches discussed herein may also be applicable to broadcast transmissions.

[0092]

[0104] The term "higher layers", as used herein, may refer to the NAS layer, the application layer, the V2X layer, or may indicate interactions between the NAS layer, the V2X layer, and the application layer. In some examples, the attachment (i.e., link) procedure 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. Figure 3 shows an example of such a model.

[0093]

[0105] Some embodiments provide a procedure for SL radio bearer link establishment. For example, Figure 3 is a block diagram of a link establishment model 300 illustrating example communication between a NAS layer and / or one or more higher layers 310 and an AS layer 320 to establish a connection between a WTRU and a peer WTRU. The link establishment model 300 illustrates a connection establishment decision performed by the AS layer 320.

[0094]

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

[0095]

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

[0096]

[0108] FIG. 4 is a block diagram of a link establishment model 400 illustrating an example of communication 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 determine based on information from the AS layer 420.

[0097]

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

[0098]

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

[0099]

[0111] In model 400, communications 430 and 440 and associated procedures for generating, transmitting, receiving and processing these communications may be optional or may 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 communicate upper layer discovery or service announcement messages and initiate connection establishment (i.e., corresponding to 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 further provide connectivity related information to the NAS and / or one or more upper layers 410 in communication 470.

[0100]

[0112] Some embodiments may provide AS / NAS layer signaling to support unicast, multicast link and / or SLRB communication. Some examples include interaction between higher layers and the AS layer to facilitate or guarantee QoS or flow (which may be mapped to SLRBs by the AS layer) of a service (e.g., a broadcast service that may or may not be transported as a SLRB). In some examples, such interaction may be used in any transmission mode (e.g., mode 1 or mode 2) and / or for any type of transmission (e.g., unicast, groupcast, or broadcast). In some examples, a WTRU performing an admission control procedure for a broadcast service may make its own admission control decision (i.e., in the case of mode 2) or may receive an admission control decision from the network (i.e., mode 1). The WTRU may inform higher layers of such a decision. Alternatively, in the case of unicast and / or multicast link and / or SLRB establishment, the WTRU may initiate link establishment signaling. Each WTRU associated with a unicast or multicast establishment may perform its own admission control, may inform its own upper layers of the admission control result, or may inform the peer WTRU of the admission control result, which is responsible for interacting with the upper layers based on the admission control results of all WTRUs. The examples described in the following scenarios may apply to any of the above cases without loss of generality.

[0101]

[0113] In some examples, a list of WTRUs may be provided by the NAS layer and / or higher layers to the AS layer (e.g., list 330 shown and described with respect to FIG. 3) or a connection establishment request may be made by the NAS layer and / or higher layers to the AS layer (e.g., connection establishment communication 450 shown and described with respect to FIG. 4). In some such examples, the NAS layer and / or higher 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 the unicast and / or multicast connection (e.g., one WTRU in the case of unicast), a unicast and / or multicast indication (e.g., an indication of whether the connection is unicast or multicast), data packets to transmit (e.g., higher layer service announcements), QoS requirements for the unicast and / or multicast links (e.g., VQI, QoS profile), expected time periods during which transmissions between two or more WTRUs may occur (e.g., to assist the AS layer in AS layer link establishment decisions), and / or L2 unicast and / or multicast link identifiers. Such a link identifier may include an L2 source ID of the peer WTRU, which the WTRU may include in a link establishment request message (e.g., connection establishment communication 450). Alternatively, in the case of a unicast, such a link identifier may include an L2 source ID of the peer WTRU as a destination of the unicast, and higher layers (e.g., the NAS and / or one or more higher layers 410) may identify the WTRU with another ID).

[0102]

[0114] In some examples, the AS layer may provide connectivity information. Figure 4 is a block diagram of a link establishment model illustrating an example procedure in which an upper layer determines link establishment based on information by the AS layer. For example, the AS layer 420 may provide connectivity information in communication 440 or communication 470 as shown and described with respect to Figure 4. 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 announced service or application; reachability of a particular WTRU (e.g., a yes / no indication of whether a WTRU can communicate (reach) another WTRU), which may be evaluated by the AS layer based on a VQI provided by a higher layer; measurements or levels (e.g., based on a configured mapping of RSRP to levels) associated with measured signals (e.g., PHY layer signals such as reference signals included in messages) transmitted between WTRUs, which measurements may be based on associated RRC messages transmitted in response to transmission of a discovery or service announcement message or connection establishment initiated by a higher layer; results of the higher layer service announcement (e.g., such results may be carried in a NAS packet); potential trends in discovery or message transmission results (e.g., information indicating an increase, decrease, or no change in the measured RSRP or a time period x during which the WTRU may be discovered or overheard by another WTRU); and / or vehicle trajectory information.

[0103]

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

[0104]

[0116] In some examples, the WTRU AS may send an indication of failed link establishment to upper layers. Such failure may be due to a requested service, packet, link, and / or SLRB admission control failure. Such an indication may occur at any time during the active time of the SLRB, such as when the SLRB fails link monitoring or is preempted by another WTRU. Such an indication may be sent by any WTRU associated with the procedure (e.g., in the initiating WTRU or a peer WTRU). The AS may provide such an indication to upper layers in the same message as any information or combination of information related to the failed link establishment, such as information (e.g., WTRU ID) indicating the WTRU for which QoS was not met or was unable to establish the link (e.g., an indication that the WTRU interacting with the upper layers or a peer WTRU was unable to establish the link), where the WTRU ID provided may be the source L2 ID; information indicating the WTRU that preempted the SLRB (e.g., WTRU ID); QoS parameters, SLRB ID or flow ID of the link and / or the packet that caused the preemption of the SLRB; the particular QoS parameters that could not be met; an indication of other currently established WTRUs (e.g., WTRU ID) and / or SLRBs (SLRB ID or QoS flow ID, etc.) that prevent or prevent the establishment of a new SLRB / link (e.g., an indication that the new SLRB conflicts with an existing unicast link and / or an indication of an existing unicast link that conflicts with the new SLRB); and / or a cause of failure. Examples of failure causes include admission control failure, inability to preempt ongoing services, performance failure (e.g., failure to establish link or failure to meet QoS), insufficient resources (e.g., Physical Sidelink Shared Channel (PSSCH), RS resources, feedback channel, preemption resources) to establish link, and / or SLRB / link preemption.

[0105]

[0117] In some examples, the WTRU falls back to best effort. For example, the WTRU AS layer may indicate to the WTRU NAS that a link has been established but that QoS requirements associated with the link may not be met. The WTRU AS layer may further be allowed to send such an indication to upper layers (e.g., depending on the WTRU configuration or the standard or specification) if instructed by the AS layer during link establishment initiation. The WTRU AS may indicate certain QoS parameters that it can meet (e.g., latency) and certain QoS parameters that will only be met as a best effort.

[0106]

[0118] In some examples, the WTRU AS layer may negotiate or renegotiate with the WTRU NAS layer to determine the appropriate QoS that can be supported by the AS layer link and / or SLRB. This negotiation or renegotiation may occur any time while the link is established, such as during link establishment / SLRB setup or when a failure is detected in link monitoring, following a trigger of an AS layer reconfiguration (e.g., as described herein), upon receipt of a link preemption indication or as indicated by higher layers, etc. This negotiation or renegotiation may be performed by any WTRU associated with the procedure (e.g., at the initiating WTRU or the peer WTRU).

[0107]

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

[0108]

[0120] 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 can be met instead. The AS layer may wait for the upper layer to provide approval 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 the upper layer for a period of time indicated by a configured, preconfigured, or defined timer value, and may indicate failure of the AS layer signaling associated with the link establishment or AS layer reconfiguration (e.g., by sending a rejection or failure RRC message) after the period of time indicated by the timer value. Alternatively, if the upper layer approves the new QoS parameters as acceptable, the AS layer signaling procedure (e.g., link establishment or AS layer reconfiguration) may proceed using the new QoS parameters.

[0109]

[0121] In the above-mentioned negotiation / renegotiation situation example where the AS layer indicates that the QoS cannot be satisfied, the upper layer may inform the AS layer as to whether AS layer signaling should continue for link establishment or AS layer renegotiation. For example, if the QoS negotiation is successful (e.g., the upper layer is able to configure a new QoS in the SLRB), the new QoS may need to be provided to other WTRUs associated with the link establishment or AS layer reconfiguration. The new QoS parameter(s) may be provided in RRC signaling (e.g., the upper layer may provide the new QoS parameter(s) to the AS layer, which may include the new QoS parameter(s) in an RRC message) or by upper layer signaling (e.g., the RRC signaling includes the new QoS parameter(s) in a transparent (e.g., encapsulated) message sent by the RRC). In either case, the higher layers may indicate to the AS layer to continue the RRC signaling exchange to send the new QoS parameter(s) to the other WTRU. If the QoS renegotiation procedure fails, the WTRU may initiate the transmission of an RRC failure message associated with the RRC signaling exchange, at which point it may consider the link establishment procedure or the AS layer reconfiguration procedure to have failed.

[0110]

[0122] In some examples, the QoS negotiation or renegotiation is conditional on the presence of higher layer PDUs. 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 higher layer PDUs (i.e., transparent, e.g., encapsulated messages) in a received RRC message. In some examples, the WTRU may receive a link establishment request RRC message. If the RRC message includes a higher layer PDU (or if the higher layer PDU is of a given size), the WTRU may determine that failed admission control and / or failed AS layer reconfiguration can initiate a QoS negotiation or renegotiation procedure with the higher layer. Alternatively, if such a PDU is not included in the RRC message, the WTRU may indicate a failed link establishment or reconfiguration procedure upon admission control failure. Without loss of generality, such higher layer PDUs may be included in any RRC message associated with link establishment and / or AS layer reconfiguration. Additionally, the WTRU may also maintain knowledge (e.g., stored information indicative of knowledge) of whether a QoS renegotiation procedure is possible if link monitoring fails based on whether higher layer PDUs were included in the signaling during SLRB link establishment.

[0111]

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

[0112]

[0124] The WTRU (e.g., the AS layer and / or higher layers) may maintain a list of responding WTRUs and certain quality measures associated with such WTRUs. For example, the WTRU may maintain a list of L2 source IDs that responded to a discovery broadcast message. The WTRU may further maintain certain trends to use during AS link establishment decisions, such as absolute quality values ​​of the measured discovery responses; consecutive numbers of responses and / or time periods during which the discovery response was above a threshold; and / or time periods or number of responses during which the discovery response quality did not change by more than a certain amount.

[0113]

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

[0114]

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

[0115]

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

[0116]

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

[0117]

[0129] The information necessary to perform link and / or bearer admission control included in the link establishment request message 530 may include information indicating the gNB and / or PLMN on which the WTRU 510 is camped / connected; an area ID of the SI currently being used by the WTRU 510; location information (e.g., geolocation information, zone ID, etc.) and / or motion related information regarding the WTRU 510 (e.g., speed, orientation, identity information of the scheduling WTRU or a head WTRU such as a platoon leader, an indication of whether the WTRU is part of a platoon or group based scheduling; QoS related measurements measured by the WTRU 510; and / or QoS related metrics measured by the WTRU 510.

[0118]

[0130] The information related to the higher layer link establishment included in the link establishment request message 530 may include higher layer QoS and / or service related information. Such information may be included in a transparent (e.g., encapsulated) message and sent directly (e.g., without decoding the message) by the WTRU 520 to the higher layer. Such information may include information necessary for QoS renegotiation, as discussed herein. In another example, the link establishment request message 530 may include a PC5 protocol or NAS protocol establishment message submitted by the higher layer to the lower layer to initiate the connection establishment, and the message may be carried as the payload of an RRC message that functions as the connection establishment request.

[0119]

[0131] The link establishment request message 530 may contain information regarding the AS configuration proposed 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 the AS configuration is provided herein.

[0120]

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

[0121]

[0133] The WTRU 510 may transmit a reference signal along with (e.g., within a message, e.g., at the PHY layer) the link establishment request message 530. Alternatively, the WTRU 510 may initiate repeated periodic transmissions of a reference signal after transmitting the link establishment request message 530.

[0122]

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

[0123]

[0135] 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. The WTRU 520 may also perform admission control using measurements at the WTRU 510, for example, as provided in the link establishment request message 530. If admission control is unsuccessful, the WTRU 520 may perform a QoS renegotiation procedure as discussed herein. In either the admission control or QoS renegotiation case, the WTRU 520 may send a link establishment response message 540 to the WTRU 510. The link establishment response message 540 may include any or all of: acceptance or rejection of the link; an indication of the success or failure of application of the configuration suggested by the WTRU 510; a suggested alternative AS configuration; suggested alternative QoS parameters for the link; a response message embedded in an RRC message (e.g., using the NAS or PC5 protocol); and / or performance information regarding the WTRU 520.

[0124]

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

[0125]

[0137] In some examples, if the WTRU 520 fails admission control and informs its higher layers, suggested alternative QoS parameters for the link may be included in the link establishment response message 540. In response, the higher layers may provide new QoS parameters or parameters, which may be provided to the WTRU 510 in the link establishment response message 540 (e.g., in an RRC message or as part of a NAS / PC5 message embedded in the RRC message).

[0126]

[0138] 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 additionally or alternatively make reachability decisions based on reference signals transmitted by the WTRU 510. Without loss of generality, the link establishment response message 540 may also include the content described in the link establishment request message 530.

[0127]

[0139] After receiving the link establishment response message 540 (e.g., based on the received message 540), the WTRU 510 may send a link establishment confirmation message 550 to the WTRU 520, which confirms or rejects the AS configuration change proposed in the link establishment response message 540. Upon or before sending the link establishment confirmation message 550, the WTRU 510 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 the AS layer configuration of the unicast and / or multicast links if the link establishment is successful. After 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 WTRU 510 and the WTRU 520. Without loss of generality, the link establishment confirmation message 550 may also include the contents described in the link establishment request message 530.

[0128]

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

[0129]

[0141] In some examples, the WTRU 510 may send a link establishment request to the WTRU 520 using a PC5-S (i.e., higher layer) message (e.g., as link establishment request 530). The WTRU 520 may receive the message and trigger lower layers (e.g., AS layer) to initiate an admission control procedure, as well as trigger an RRC message to transmit a link establishment response message 540. In response to the link establishment response message 540, the WTRU 510 RRC may perform an admission control procedure and transmit a link establishment confirm message 550 as an RRC message. After the admission control procedures at each of the WTRU 510 and WTRU 520 are successful and / or corresponding RRC messages are received at the WTRU 510 and WTRU 520, the WTRU's RRC may inform the higher layers of the successful AS link layer establishment, which may then 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 successful link establishment at the upper layer and may provide the lower layer with security keys to be used for messages sent by the AS over the secure link.

[0130]

[0142] The SLRB configuration may include L1 and / or L2 configuration and / or flow-to-bearer mapping configuration. The L1 and / or L2 configuration may include, without limitation, HARQ configuration; BWP configuration; number of carriers and / or specific carriers available for unicast and / or multicast links; LCH / LCG configuration; RS resource configuration; configuration of resource pools or resource patterns / signatures available for use by WTRUs communicating over unicast and / or multicast links; feedback configurations such as CQI reporting configurations, associated transmit powers, etc.; monitoring configurations such as rules for determining link failure and / or QoS maintenance failure as described herein (e.g., representative detection configurations or conditions for detection failure); and / or preemption resource configuration.

[0131]

[0143] In some examples, a WTRU may determine whether or not to perform admission control during and / or after link and / or SLRB establishment, or whether admission control should be performed by one or more other WTRUs in a unicast and / or multicast link. This determination may be made by a peer WTRU during a unicast and / or multicast link. Alternatively, an initiating WTRU may make this determination and inform a peer WTRU of the result of the determination, indicating that the initiating WTRU will perform admission control. Such a determination may be based on instructions by higher layers; based on NW configuration or pre-configuration; and / or based on received power of messages (e.g., discovery messages or link establishment messages) received from other WTRUs. In some cases where the decision is based on instruction by a higher layer, the higher layer of the initiating WTRU may decide whether admission control should be performed by the peer WTRU and may explicitly signal the result of this decision in inter-layer signaling, may signal the result of the decision implicitly (e.g., via the inclusion and / or size of a PDU to be sent by the initiating WTRU to the peer WTRU as part of link establishment), or the peer WTRU may determine the need for admission control based on the presence and / or size of a PDU in an AS layer message.

[0132]

[0144] A WTRU that determines that admission control should 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 higher layer information (e.g., user information, application layer information, QoS, etc.), which may be in the form of PDUs provided by higher layers during initiation of link establishment by the higher layers.

[0133]

[0145] The WTRU may maintain the admission control enabled state (i.e., whether the WTRU should perform admission control) determined during link establishment for the duration of the link. Alternatively, the WTRU may change its admission control enabled state (e.g., the WTRU may assume that it should perform admission control) and a trigger occurs. Examples of triggers may be when the WTRU velocity increases above a threshold; when the received power of a message from one or more other WTRUs is below a threshold; and / or when the distance between WTRUs in a link exceeds a threshold, such distance may be calculated based on receiving geographic information transmitted by a peer WTRU associated with the unicast link (e.g., a zone ID transmission in the SCI or an RRC message dedicated to exchanging geographic information between two WTRUs).

[0134]

[0146] Some examples include configuration negotiation between the WTRUs. FIG. 5 is a message sequence chart illustrating an example of a sidelink link establishment procedure at the AS layer between WTRUs. In some examples, an AS layer configuration that meets the required link QoS and does not exceed the AS layer capabilities of either WTRU may be selected. Such negotiation may be performed as part of the request / response / acknowledge (three-step) signaling procedure described above, as illustrated in procedure 500 shown and described with respect to FIG. 5. In some examples, the WTRU with which the higher layers initiated the link establishment may perform the configuration selection. In some examples, the WTRU that receives the connection establishment request message from the WTRU with which the higher layers initiated the link establishment may perform the configuration selection. Alternatively, both WTRUs may be associated with the configuration selection (e.g., the initiating WTRU makes the initial selection and the peer WTRU makes the alternate selection).

[0135]

[0147] The WTRU may select one or more AS layer configurations over which unicast and / or multicast links should be established based on the QoS of the link to be established; based on one or more capabilities of the WTRU; based on measurements of current sidelink resource usage measured by the WTRU; and / or based on the exchange of the above information between the WTRUs associated with the link establishment and / or preferred configurations.

[0136]

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

[0137]

[0149] For example, in some cases where the WTRU selects an AS layer configuration based on one or more capabilities of the WTRU, the WTRU may be limited to using a sub-ground of the AS configuration, or may be limited to a particular element of the AS configuration if any of the WTRUs associated with the link establishment support the configuration or element of the configuration. This may be determined at the time of link establishment (e.g., based on the number of carriers, resource selection mode, reference signal (RS) location / pattern / power configuration at the time of link establishment, etc.).

[0138]

[0150] For example, in some cases where the WTRU selects an AS layer configuration based on currently measured resource usage, the WTRU may select from one of several AS layer configurations based on measurements of current sidelink resource usage, e.g., to avoid conflicts with currently utilized resources.

[0139]

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

[0140]

[0152] In some examples, the initiating WTRU may determine which AS configuration to use based on QoS requirements (e.g., VQI) received from higher layers or the network. The decision may be based on a network-provided or pre-configured (e.g., stored in the WTRU) mapping of VQI to AS configurations, the WTRU's AS layer capabilities, and selection of specific resources of the configuration that minimizes and / or avoids collisions, contention and / or interference with existing unicast links (e.g., avoidance of RS patterns already in use by other WTRUs or links, preemption, etc.). The decision may also be made as part of an admission control procedure, such as the examples discussed herein. After the WTRU selects an AS configuration, the WTRU may transmit the selected AS configuration to the peer WTRU using AS layer signaling. This signaling may be included in the link establishment signaling. The peer WTRU may receive the selected AS configuration, 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 satisfied given the peer WTRU's ability to satisfy QoS based on measurements made at the peer WTRU's location (e.g., number of SL carriers, etc.). An indication to accept the alternative configuration or the initial configuration may be sent in the link establishment response. If the WTRU receives a link establishment response with an alternative configuration, it may decide whether to accept the configuration and send a link establishment confirmation message to the peer WTRU, or to reject the configuration and send a link establishment reject message to the peer WTRU. In either case, one or both of the WTRUs may inform higher layers of the result.

[0141]

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

[0142]

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

[0143]

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

[0144]

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

[0145]

[0157] In some examples, a WTRU may determine whether to transmit its capability information to another WTRU (e.g., during link establishment signaling) based on whether it has previously transmitted such information. For example, a WTRU may determine to include capability information in AS layer signaling based on whether it has previously transmitted capability information to the same WTRU (e.g., such a WTRU may be identified by an L2 Source ID, a NW Control ID (e.g., I-RNTI, S-TMSI, C-RNTI), or a combination thereof), based on whether it has transmitted capability information to the same WTRU within a past predetermined time period, and / or based on whether the capabilities have changed since it last transmitted capability information to the same WTRU. A WTRU may omit transmitting WTRU capabilities when performing link establishment to a WTRU that previously transmitted capabilities (e.g., assuming such capabilities have not changed).

[0146]

[0158] A WTRU may be configured to store performance information of another WTRU after a unicast link with that WTRU is terminated. The WTRU may receive such performance information during sidelink link establishment. The WTRU may be configured to perform appropriate AS layer configuration or link establishment selection based on the stored performance information. The WTRU may determine that it should use the stored performance information if the link establishment signaling from the other WTRU does not include the performance information.

[0147]

[0159] A WTRU may be configured to delete or clear any stored performance information of another WTRU based on one or more triggers, such as a timer expiring; an instruction from higher layers; receipt of new performance 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.

[0148]

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

[0149]

[0161] In some cases where the trigger includes a link monitoring failure, in some examples, the WTRU may determine that the QoS required for the link is no longer satisfied and may initiate an AS layer configuration update procedure based on that determination; in other examples, after a link monitoring failure, the WTRU may determine that it may select an alternative AS layer configuration 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 perform an AS layer reconfiguration to satisfy the new QoS for the unicast and / or multicast links.

[0150]

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

[0151]

[0163] Where the trigger includes receiving a preemption of a unicast and / or multicast link, in some examples, the WTRU may receive the preemption of the unicast and / or multicast link that provides further information regarding the conflicting static resources (e.g., via a reference signal feedback channel, etc.) or the limits of the utilized resources (e.g., pool, pattern, amount of resources, etc.). The WTRU may perform AS layer reconfiguration of the unicast link to facilitate continued operation with acceptable or sub-optimal QoS while avoiding the conflict indicated in the preemption signal.

[0152]

[0164] In some cases where the trigger includes an instruction from a higher layer, in some examples, the WTRU may receive an instruction from a higher layer to modify the QoS requirements (e.g., VQI) associated with a particular unicast and / or multicast link and / or SLRB, such an instruction may include the addition of a new QoS flow that maps to the same unicast and / or multicast link and / or SLRB.

[0153]

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

[0154]

[0166] In some examples, a WTRU initiating an AS layer reconfiguration may send a reconfiguration request message over the sidelink. The reconfiguration request message may include one or more selected AS layer configurations (e.g., configurations or an indication of such configurations) of the peer WTRU; may include new and / or updated performance information of the peer WTRU; and / or may include QoS-based measurements of the peer WTRU. The peer WTRU may send a reconfiguration response message to the initiator WTRU. The reconfiguration response message may include the selected or alternative AS layer configuration of the peer WTRU; may include new and / or updated performance information of the initiator WTRU; may include QoS-based measurements of the initiator WTRU; and / or may include an indication of acceptance or failure of the selected AS layer configuration for the peer WTRU. In response, the initiator WTRU may send a reconfiguration confirmation message. The reconfiguration confirmation message may confirm or indicate failure of the AS layer reconfiguration procedure; and / or may include the selected or alternative AS layer configuration to be used (e.g., configuration or an indication of such configuration). 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.

[0155]

[0167] Successful link establishment at a WTRU may be deemed to be completed at any of a variety of instants, possibly depending on whether the target WTRU is an initiating WTRU or a peer WTRU. For example, successful link establishment may occur upon transmission of a link establishment confirm message or transmission of the last RRC message associated with the establishment / reconfiguration RRC procedure; upon reception of a link establishment confirm message or reception of the last RRC message associated with the establishment / reconfiguration RRC procedure; upon reception of an acknowledgment of the link establishment confirm message or reception of an acknowledgment of the last RRC message associated with the establishment / reconfiguration RRC procedure; upon transmission of a link establishment success response message (e.g., response or reconfiguration response); upon reception of a success response message (establishment response or reconfiguration response); and / or upon reception of an acknowledgment of the link establishment success response message (establishment response or reconfiguration response).

[0156]

[0168] The WTRU (e.g., initiator or peer) may perform any action or combination of actions upon establishment and / or reconfiguration of a unicast and / or multicast link or SLRB (e.g., strictly upon success or at a time following success), or may perform at different moments during the link establishment procedure. Such operations may include, for example, notifying upper layers of completion of link establishment at the AS layer; notifying upper layers of upper layer authentication and initiation of security associations; initiating 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 resuming RS transmission based on the AS layer configuration; starting or resuming RS reception and / or SL CQI transmission based on the AS layer configuration; starting UMUS transmission, for example, as described herein; starting resource reservation signaling transmission for any resources (e.g., via the SCI); initiating resource selection or reselection procedures (e.g., taking into account service requirements of newly established logical channels and / or flows associated with the SLRB, associated with a unicast link or SLRB); and / or initiating group-based resource reservation procedure transmission.

[0157]

[0169] Some examples include actions related to the release of a unicast and / or multicast link or SLRB. For example, the WTRU may perform one or more of various actions during the release of a unicast and / or multicast link or SLRB. Such actions may include releasing all unicast resources associated with 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 specific to the unicast and / or multicast link; ceasing transmission and / or reception of only any RS, RLM signals, or similar signals associated with the unicast and / or multicast link or SLRB being released; canceling any ongoing resource selection procedure associated with the unicast link and / or SLRB being released; e.g., canceling SL resource selection taking into account current data in the SL buffer without a logical channel associated with the SLRB; triggering a selection procedure; transmitting residual data in a buffer associated with the SLRB using the 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 cancellation message to indicate the release of resources associated with the unicast link and / or SLRB; notifying higher layers of 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 one or more other WTRUs associated with the unicast and / or multicast link or SLRB.

[0158]

[0170] In some cases where the operation includes sending an RRC release message or an RRC failure message to one or more other WTRUs associated with a unicast and / or multicast link or SLRB, when higher layers notify the WTRU to release the SLRB, the WTRU may send 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.

[0159]

[0171] In some cases where the operation includes sending an RRC release message or an RRC failure message to one or more other WTRUs associated with a unicast and / or multicast link or SLRB, when the release is initiated due to a failure of the AS reconfiguration procedure, the WTRU may send a release message (e.g., if the configuration failed at the initiating WTRU) or may send a rejection or failure response to the request RRC message (e.g., if the reconfiguration failed at the WTRU receiving the reconfiguration request message or reconfiguration response message).

[0160]

[0172] In some examples, the WTRU may perform actions related to releasing a unicast and / or multicast link or SLRB as a result of one or more triggers. Such triggers may include an explicit indication from a higher layer or AS layer to release a flow, a set of flows, a unicast and / or multicast link or SLRB (e.g., higher layers may indicate release of a flow or set of flows, and the remaining flows are not carried by the SLRB, in which case the WTRU may initiate actions related to releasing the SLRB); failure of an AS layer link monitoring procedure, possibly following a failed QoS renegotiation procedure and / or a failed AS layer reconfiguration procedure; receipt of an indication to preempt a particular flow or SLRB from another WTRU; receipt of an SL release message or a rejection message; and / or failure of an AS layer reconfiguration procedure.

[0161]

[0173] In some cases where the trigger includes an AS layer reconfiguration procedure failure, the WTRU may initiate an AS layer reconfiguration procedure failure when it detects a QoS monitoring failure and is unable to renegotiate one or more new QoS parameters with upper layers and / or is unable to determine a new AS layer configuration that satisfies one or more QoS parameters currently configured in the SLRB. In some cases where the trigger includes an AS layer reconfiguration procedure failure, the WTRU may initiate an AS layer reconfiguration procedure failure when it receives a reconfiguration request message over the sidelink and is unable to apply the proposed AS layer configuration and / or is unable to renegotiate one or more new QoS parameters with upper layers and / or is unable to determine a new AS layer configuration that satisfies one or more QoS parameters currently configured in the SLRB. In some cases where the trigger includes an AS layer reconfiguration procedure failure, the WTRU may initiate an AS layer reconfiguration procedure failure when it 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 new one or more QoS parameters with upper layers and / or is unable to determine a new AS layer configuration that satisfies one or more QoS parameters currently configured in the SLRB.

[0162]

[0174] Some examples include an SL release message. For example, the WTRU may perform the transmission of the SL release message following one or more triggers, such as the trigger examples described above. In some examples, the SL release message may be an RRC message defined for that purpose. In some examples, the SL release message may be a general RRC message (e.g., a transparent container) or a higher layer message (e.g., a NAS or PC5-C message) included in an SL data message. The SL release message may include information regarding the QoS flow and / or SL bearer index of the flow or SLRB to be released; the cause of the release; one or more L2 IDs of one or more WTRUs to be 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 timescale associated with the release (e.g., an amount of time during which one or more WTRUs may not initiate a new link establishment and / or an amount of elapsed time during which the WTRUs should re-establish the same link with 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.

[0163]

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

[0164]

[0176] Some examples include higher layer SL bearer establishment or bearer reconfiguration. For example, the WTRU may initiate a new bearer establishment or a reconfiguration of an existing bearer based on one or more triggers. Such triggers may include a higher layer indication of the start of a new QoS flow, in which case the WTRU may decide to map the flow to an existing bearer or a new bearer; a higher layer indication of the end of a flow, in which case the WTRU may perform a bearer reconfiguration; and / or a higher layer indication of a change in one or more source and / or destination L2 IDs of an existing link, in which case the WTRU may associate a new L2 ID with an existing bearer. The WTRU may use the same or similar signaling as described above and herein to establish a new bearer. In some examples, the WTRU may use the same or similar signaling as described above and herein to establish a new bearer, without the step associated with reachability determination.

[0165]

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

[0166]

[0178] 6 is a message sequence chart illustrating an example procedure 600 of gNB control link establishment. The example procedure 600 includes the WTRU 610 sending a link establishment configuration request message 640 to the gNB 630, which responds with a link establishment configuration response message 650. After the link establishment configuration response message 650 is received by the WTRU 610, gNB configuration of reference signal transmission and reception is performed in step 660. After step 660, the WTRU 610 sends a link establishment request message 670 to the WTRU 620, which responds with a link establishment response message 680. After the link establishment response message 680 is received by the WTRU 610, SL transmission based on the established SL bearer is initiated between the WTRU 610 and the WTRU 620 in step 690.

[0167]

[0179] The WTRU 610 may use signaling with the gNB 630 (e.g., in a link establishment configuration request message 640 and / or a link establishment configuration response message 650) to determine the AS layer configuration to send in the link establishment request message 670. The WTRU 610 may send VQIs of links and / or bearers to the gNB 630 for use by the gNB 630 in determining the configuration. The WTRU 610 may also send measurements performed by the WTRU 610 of discovery responses sent by the WTRU 620 during previous discovery signaling.

[0168]

[0180] In another example, the configuration of the reference signal for reachability detection may be under gNB control. This may be the case regardless of whether the reachability detection is performed before or after the link establishment configuration request message 640.

[0169]

[0181] Some examples may include signaling to establish a multicast link, which may require knowledge of some or all of the connectivity between multiple / all pairs of WTRUs.

[0170]

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

[0171]

[0183] The source WTRU may perform resource reservation for multiple response messages. For example, the source WTRU may select multiple distinct time and / or frequency resources to be used by other WTRUs to respond to the request message. The source WTRU may reserve such resources by transmitting one or more reservation signals to the responding WTRU. Such one or more reservation signals may be transmitted over a physical sidelink control channel (PSCCH) (e.g., as an SCI) or by higher layers (e.g., MAC or RRC). The WTRU may transmit the reservation for response message in combination with the reservation or indication of the PSSCH transmission of the request message. For example, the WTRU may perform resource selection for the initial transmission (e.g., to be used for transmitting the request message) and the N response message transmissions, after which the WTRU may transmit an SCI indicating the time, frequency and / or beam resources to be used in the request message; the decoding parameters (e.g., MCS) of the PSSCH transmission that includes the request message; and / or the N (potentially distinct) time, frequency and / or beam resources to be used by the N different WTRUs transmitting the response messages with the SCI.

[0172]

[0184] The source WTRU may also send the required transmission parameters in a response message to the responding WTRU, in such a case the responding WTRU may send a limited size SCI including only a reservation signal or may not send an SCI at all.

[0173]

[0185] A WTRU receiving a message providing resources for a response message may determine a particular timing for its own response message. The timing decision may be based on an explicit order of the responding WTRUs in the request message (e.g., using a particular one of multiple reserved resources); an implicit order based on WTRU IDs (e.g., source L2 ID, C-RNTI, or group ID, etc.); and / or an implicit order based on information from the application layer and / or NAS layer. For example, the receiving WTRU may determine from higher layers whether or not to respond to the request message, and if so, which of the response resources to use based on the order provided by the application layer.

[0174]

[0186] In some examples, a responding WTRU may monitor and / or measure response messages from other responding WTRUs. A WTRU that receives a request message for a response may also monitor response messages from other WTRUs according to resources scheduled by the request message. The WTRU 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 messages based on a reference signal transmitted by each WTRU in the response resource.

[0175]

[0187] The WTRU may maintain a list of quality measurements for each responding WTRU, and the WTRU may send a "connectivity report", which includes a list of WTRU responses that the WTRU can decode along with the WTRU ID and the measured quality (e.g., RSRP, RSRQ, SINR, etc.) and / or the measured quality of the source WTRU (e.g., based on the transmitted request message and / or reference signal).

[0176]

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

[0177]

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

[0178]

[0190] 7 is a message sequence chart illustrating an example multicast link establishment procedure 700. The multicast link establishment procedure 700 includes a link establishment request 740 broadcast by the WTRU 710 to the WTRU 720 and the WTRU 730, a link establishment response message 750 broadcast by the WTRU 730 to the WTRU 710 and the WTRU 720, and a link establishment response message 760 broadcast by the WTRU 720 to the WTRU 710 and the WTRU 730. After the link establishment request and response, the WTRU 720 and the WTRU 730 send connectivity reports 770 and 780, respectively, to the WTRU 710. After receiving the connectivity reports 770 and 780, the WTRU 710 broadcasts a link establishment confirm message 790 to the WTRU 720 and the WTRU 730, after which multicast messages may be initiated between the WTRU 710, the WTRU 720, and the WTRU 730 in step 795.

[0179]

[0191] In the procedure 700, the link establishment request message and the link establishment response message are broadcast messages, and the link establishment confirmation is also a broadcast message, containing the WTRU IDs included in the group and the destination address to be used for further multicast messages.

[0180]

[0192] 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 IDs (i.e., source and destination) associated with each link used by each WTRU are different. In some cases, it may be advantageous for the Access Stratum (AS) layer (in each WTRU) to recognize that the unicast links are in fact between the same pair of WTRUs.

[0181]

[0193] In some examples, the WTRU determines a 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 unicast links at this WTRU are actually associated with the same physical peer WTRU. The WTRU may group multiple destination L2 IDs (i.e., source L2 IDs of a peer WTRU) to be used together while transmitting to different unicast links if the unicast link transmissions are associated with the same peer WTRU. The WTRU may group multiple source L2 IDs to use while transmitting to different unicast links if the unicast links are set up with the same peer WTRU. The WTRU may maintain a context associated with multiple unicast links that are grouped together using the methods described below.

[0182]

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

[0183]

[0195] For example, in some cases where the WTRU derives the AS SL UE ID based on a static or semi-static ID associated with the WTRU, the WTRU may send its IMSI to the peer WTRU to inform the peer WTRU that a unicast link is associated with the same paired WTRU. Similarly, the peer WTRU may also send its IMSI to the WTRU to inform the WTRU that a unicast link is associated with the same paired WTRU. 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 that value or a value based on that value to the peer WTRU. Additionally, the WTRU may select such a random value if a unicast link has not been established. For example, the WTRU may select a random value for the first unicast link established, and the WTRU may then send the same selected value (or a value based on that value) for subsequent RRC links established. In some examples, the WTRU may remove the randomly selected value if the WTRU no longer has a unicast link established (e.g., no longer has any type of unicast link). In some cases where the WTRU derives the AS SL UE ID based on values ​​associated with the location and / or selected resource, the WTRU may send to the peer WTRU its current geolocation at the time of link establishment or its current zone ID at the time of link establishment. In some examples, the WTRU may send an index or information (e.g., time, frequency, beam, etc.) to an associated resource selection procedure performed at some time. For example, the WTRU may send an index of the frequency resource the WTRU last time reserved before link establishment. In some cases where the WTRU derives the AS SL UE ID based on values ​​associated with the WTRU's encoding of the PSCCH and / or PSSCH and / or PSFCH, the value may include values ​​of scrambling code, RS pattern, etc.

[0184]

[0196] In some examples, a second WTRU in a potential group may receive an L2 source ID of a peer WTRU in PC5 RRC signaling or from higher layers (e.g., obtained during higher layer signaling between the WTRUs). Upon receiving such an ID, the WTRU may determine whether such an ID is associated (or grouped) with another ID (i.e., of another unicast link) based on the AS SL UE ID received from the peer WTRU. For example, the WTRU may group the L2 IDs of two unicast links if it receives an AS SL UE ID that matches an AS SL UE ID received from a peer WTRU associated with another ongoing unicast link at the WTRU; if the WTRU receives an AS SL UE ID associated with a geolocation that matches the last known geolocation 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 time / frequency resources that were used by a peer WTRU with which it has an already established unicast link.

[0185]

[0197] Such a procedure of grouping L2 source IDs may be performed by one or both WTRUs. For example, during and / or after link establishment, a first WTRU may send its SL UE ID to a second WTRU, which may determine whether to group the L2 ID of a unicast link with another L2 ID of an 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 performs a similar grouping decision.

[0186]

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

[0187]

[0199] For example, at T1 (i.e., during the first link establishment procedure initiated by the higher layers), the WTRU may receive from the higher layers an L2 source ID (ID1) of a peer WTRU with which it has no association and a unicast link. Based on knowledge of active unicast links, the WTRU may determine that it has only one unicast link with the peer WTRU. The WTRU may receive ID1' from the higher layers as its own source ID of the unicast link, which may be further provided by the higher layers.

[0188]

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

[0189]

[0201] In some examples, the WTRU may obtain an SLRB configuration for a particular PC5-5QI (PQI) and / or PC5 flow identifier (PFI) using on-demand SIB or dedicated signaling. For example, the WTRU may request an SLRB configuration associated with one or more PQIs / PFIs via a request to the network (e.g., gNB). In idle and / or inactive modes, the WTRU may request an 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 following the start of a flow that is not mapped to any SLRB that is part of the WTRU's SL configuration and / or if the SL SIB does not broadcast an SLRB configuration associated with the flow. The WTRU may respond to the request with the PQI / PFI associated with the flow; the range value associated with the flow; the GBR associated with the flow; an index into a table that gives all the QoS parameters or QoS profile, which may be predefined, configured or preconfigured; and / or a list of the current SLRBs stored in its own configuration.

[0190]

[0202] In some embodiments, a WTRU in connected mode may use a similar request for an SLRB configuration associated with one or more PQIs / PFIs using dedicated signaling. For example, the WTRU may send an RRC message (e.g., using UE sidelink information) following the initiation of an intra-flow mapping to a currently stored SLRB configuration.

[0191]

[0203] In some examples, the WTRU's SLRB configuration and / or mapping of flows to SLRBs may additionally 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 the SLRB (or flow) if the measured quality meets one or more first conditions, and may use a second configuration for the SLRB (or flow) if the measured quality meets one or more second conditions.

[0192]

[0204] In some examples, the WTRU uses a default SLRB configuration during a request for a SLRB configuration associated with one or more PQIs / PFIs. For example, the WTRU may use a default SLRB (i.e., map the new flow to the default SLRB) following initiation of a flow and there is no mapping of the flow to an SLRB in the WTRU's stored SLRB configuration. The default configuration may be configured or pre-configured or pre-defined. The default configuration may be configured by a network, such as a gNB. The default configuration may be pre-configured by V2X pre-configuration in the WTRU. The default configuration may be pre-defined in an appropriate specification. After receiving 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 the stored configuration), it may move the flow from the default SLRB configuration to the indicated stored SLRB configuration.

[0193]

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

[0194]

[0206] Some examples include systems, methods, and devices for unicast and / or multicast admission control on a sidelink. In some examples, the transmission mode decision may be based on QoS. For example, the WTRU may determine the transmission mode of a link to establish based on QoS attributes associated with the link. The WTRU may decide to establish a new link / radio bearer to accommodate unicast and / or multicast flows for a particular VQI and may determine the transmission mode of packets on that link and / or bearer based on the VQI, QoS parameters derived from the VQI. The WTRU may select from the NW-controlled mode and the WTRU-autonomous mode based on the VQI. Alternatively, if the WTRU selects the WTRU-autonomous mode or if the network allows the WTRU to use the WTRU-autonomous mode, the WTRU may further select from multiple resource selection modes based on the VQI. For example, the WTRU may determine whether to use fully autonomous resource selection, autonomous resource selection with assistance from another WTRU, use configured or pre-configured grants, and / or use WTRU scheduling resources of the link. For example, a WTRU may be configured or pre-configured with a table of VQIs and permissible resource transmission / resource selection modes, in which case the WTRU may select a mode from one of the permissible modes for a particular VQI.

[0195]

[0207] In some examples, the mode change is performed for admission control. For example, the WTRU may perform a mode change for admission control purposes (e.g., from WTRU autonomous resource selection to network-based resource selection). In some examples, a WTRU operating in WTRU autonomous mode may receive a new flow or decide to start a new sidelink bearer. In doing so, the WTRU may indicate this to the network and may implicitly change the operation mode to NW-controlled mode, at least during the admission control / link and / or bearer establishment phase. The WTRU may remain in NW-controlled mode until instructed by the network to return to WTRU autonomous mode.

[0196]

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

[0197]

[0209] In some cases where the information includes a VQI or related QoS parameter(s) associated with one or more flows for which a bearer is to be established, the WTRU may be provided with the VQI of the given flow from the NAS layer, and the WTRU may initiate a link establishment request including such VQI to the network. In some cases where the information includes identification information of one or more WTRUs associated with unicast and / or multicast links, the WTRU may include a source ID (e.g., L2 ID) of the WTRU with which the link is to be established. In some cases where the information includes discovery results, the WTRU may transmit any AS-related information associated with the discovery results and 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 indicative of supported WTRU capabilities; information indicative of synchronization sources of one or more WTRUs; information indicative of in-coverage or out-of-coverage of one or more WTRUs; and / or information indicative of WTRU capabilities such as resource selection capabilities, supported carriers, power class, etc.

[0198]

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

[0199]

[0211] In some examples, if WTRU autonomous admission control fails, the WTRU may use network-controlled admission control. For example, the WTRU may receive new unicast and / or multicast flows from higher layers and may decide to initiate WTRU autonomous admission control for new SL radio bearers of such flows (as described herein). If this WTRU autonomous admission control fails, e.g., for reasons described herein, the WTRU may initiate network-controlled admission control, e.g., by sending a unicast and / or multicast link establishment request to the network.

[0200]

[0212] In some examples, the WTRU may receive an admission control success acknowledgement along with the resource and measurement configuration message. For example, the WTRU may receive an admission control success acknowledgement by the network, and following the acknowledgement, the WTRU may start transmitting data associated with one or more flows mapped to the established link or bearer. The WTRU may further receive resource usage information along with such acknowledgement. The resource usage information may include an indication of a new or existing resource pool; a periodic set of resources; arbitration rules; WTRU-specific or cell-specific link and / or radio bearer identity information; and / or configuration of measurements to report to the network for link maintenance.

[0201]

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

[0202]

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

[0203]

[0215] In response to receiving such a configuration, the WTRU may begin measuring and reporting in accordance with the network configuration until the network releases the link and / or bearer from the network via a bearer release message.

[0204]

[0216] 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 reporting that may last only during the link establishment phase. For example, the WTRU may be configured with one or more source L2 addresses associated with messages for which the WTRU should report measurements; one or more message types (e.g., a particular 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 measurements.

[0205]

[0217] In some examples, a WTRU configured for measurement reporting may identify the RSRP of any message received from any of the specific L2 addresses configured in the measurement configuration, potentially any of the RRC message types configured as part of the measurement configuration. In some examples, the WTRU may report measurements to the network upon receipt of each message that meets the above criteria. In some examples, the WTRU may remove the configuration once it has completed link establishment with the WTRU indicated by the source L2 ID (e.g., in the measurement configuration).

[0206]

[0218] In some examples, the WTRU autonomously controls admission control. Some examples include WTRU autonomous admission control decisions. For example, during or before link 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. Higher layers may initiate unicast link establishment procedures as discussed herein. During such procedures, any AS layer in the WTRU may accept or reject the link and / or bearer establishment based on, for example, AS-related factors that may be transparent to higher layers.

[0207]

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

[0208]

[0220] The criteria may include, for example, the WTRU may accept or reject unicast / groupcast link or SLRB establishment based on whether the WTRU is in coverage of a gNB or whether the WTRU is in coverage of the same gNB or gNBs of other WTRUs that will be associated with the unicast link; the WTRU's network coverage or networks, e.g., the WTRU may accept or reject unicast / groupcast link or SLRB establishment based on the QoS requirements of the link and / or bearer to be established; the QoS requirements associated with the link; the QoS requirements of other existing links and the ability to preempt such existing links; for example, the WTRU may accept or reject unicast / groupcast link or SLRB establishment based on the QoS requirements of another WTRU associated with the unicast / groupcast link. This may include allowing or denying unicast / groupcast link or SLRB establishment based on the WTRU's movement (e.g., speed, orientation) and / or the WTRU's location, location, movement or relative location and / or relative movement, in conjunction with information regarding the movement of one or more WTRUs; and / or based on available resources (e.g., data, and / or reference signal, and / or feedback resources), for example, the WTRU may allow or deny unicast / groupcast link or SLRB establishment based on available resources potentially needed for the unicast / groupcast link or SLRB based on an identification of available resources, and / or the WTRU may predict resources needed for the link or SLRB based on QoS requirements for the link or SLRB.

[0209]

[0221] Some examples include admission control based on network coverage. In some examples, for a link requesting a particular QoS, the WTRU may decide to reject the link and / or SLRB if the WTRU is out of coverage, but may decide to allow the link and / or SLRB if the WTRU is in coverage. For example, a particular value of a VQI, PPPP, PPPR, or similar QoS parameter associated with the link may be configured or pre-configured to require a Mode 1 resource allocation mode, or may require the WTRU to be in coverage so as to fall back to Mode 1 in certain circumstances. In some examples, a WTRU receiving a request for a link and / or SLRB may reject the request if out of coverage. In some examples, the WTRU may be configured with a threshold Uu-based RSRP (e.g., for each VQI or QoS-related parameter value, as the case may be), below which the WTRU rejects the link and / or SLRB.

[0210]

[0222] In some examples, a WTRU may reject a link / SRLB for a given QoS if the gNB to which the WTRU is currently connected and / or camped is not associated with one or more gNBs to which other WTRUs may be camped. The relationships may include, for example, the same gNB, gNBs of the same PLMN, gNBs broadcasting system information that are part of the same coverage area. A link and / or SLRB may have one or more permissible relationships.

[0211]

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

[0212]

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

[0213]

[0225] Some examples include transmitting a unicast and / or multicast availability signal to assist other WTRUs in making admission control decisions in a shared resource pool (e.g., to identify or predict resource usage / availability). For example, a WTRU may transmit a unicast and / or multicast availability signal (UMUS) if it 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, the WTRU may transmit a single signal if at least one link is established, and the usage signal may include information about all established links / SLRBs.

[0214]

[0226] In some examples, UMUS may be transmitted to facilitate availability of resources on the sidelink, such as a resource pool, without reserving resources first. For example, UMUS for one or more links / SLRBs may indicate resources that a bearer / link may eventually need to use or reserve. In such a case, the purpose of UMUS may be to facilitate reservation of resources that meet the QoS of an established unicast and / or multicast link, if required by a WTRU with specific QoS requirements. Alternatively, the UMUS signal may be transmitted to reserve specific resources or channels to be used for unicast / groupcast transmissions specifically associated with this unicast link (e.g., HARQ feedback, RS transmissions, CQI feedback, and / or preemption resources). For example, UMUS may reserve specific resources or an amount of resources in the PSSCH, PSCCH, physical sidelink broadcast channel (PSBCH), and / or sidelink feedback channel.

[0215]

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

[0216]

[0228] In some examples, the WTRU may decode and store the UMUS during normal SL reception. For example, the WTRU may determine, for example, average resource utilization of unicast links, actual reserved resources, and similar information for the possible associations described above based on past reception of UMUS signals. The WTRU may assume that the contents of the UMUS are valid for a configured or pre-configured or defined period of time. For example, the WTRU may start a timer upon reception of a UMUS signal associated with a single unicast and / or multicast identifier, L2 source / destination address, or other identifier carried by the UMUS. Upon receiving a UMUS signal, the WTRU may consider the resources associated with the transmitted UMUS signal to be active. If the timer expires without receiving an updated UMUS signal, L2 source / destination address, or other identifier associated with the same unicast and / or multicast identifier, the WTRU may consider the associated resources to be no longer active. In some examples, the validity time may be determined based on the WTRU's movement, such as the WTRU's speed, orientation, and other related information.

[0217]

[0229] 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, when the WTRU moves to a new geographic area, such as a new zone, when the WTRU changes BWP, carrier, etc., when the WTRU joins or leaves a platoon, and / or when the WTRU receives a UMUS signal or similar signal indicating release and / or cancellation of previous resources / reservations.

[0218]

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

[0219]

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

[0220]

[0232] In some examples, the WTRU may transmit UMUS in addition to regular transmissions. For example, the WTRU may transmit UMUS in an SCI format that includes both scheduling information and information about unicast and / or multicast links. Alternatively or additionally, the WTRU may transmit only UMUS without combining it with data or scheduling information. For example, the WTRU may transmit UMUS periodically. Such periodic UMUS transmissions may be performed by an SCI using a particular format. The WTRU may determine when to transmit UMUS based on: a timer expiration since the last transmission of UMUS; based on the number of SCI transmissions since the last transmission of UMUS; based on QoS attributes of the unicast and / or multicast links on 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.); occupancy of the shared resource pool determined by the WTRU, such as a measure of CBR, number of free resources, or number of detected UMUS transmitted by other WTRUs; and / or based on the WTRU's movement (e.g., WTRU measures, orientation, etc.).

[0221]

[0233] The WTRU may include various information in the UMUS, such as, for example, VQIs (or other QoS related parameters) associated with the unicast and / or multicast link (e.g., obtained from higher layers); source and / or destination L2 addresses or addresses associated with one or more WTRUs; attributes of resources required for data to be transmitted on the unicast and / or multicast link; the number of QoS flows on that unicast and / or multicast link (or on each unicast and / or multicast link) or the ASs multiplexed on the unicast and / or multicast link. may include the number of SL radio bearers; a reference signal channel / transmission configuration by one or more WTRUs associated with the unicast and / or multicast links (e.g., minimum / maximum RS transmit power, time, frequency and / or beam resources for transmission of RS signals, RS signal sequences, etc.), which may be indicated by transmitting an index of a predefined, configured or preconfigured configuration; a HARQ feedback channel / transmission configuration associated with the unicast and / or multicast links; a CQI or CSI feedback transmission configuration (e.g., time, frequency and / or beam resources used for transmitting CQI feedback), which may be indicated by transmitting an index of a predefined, configured or preconfigured configuration; a preemption resource configuration; a BWP and / or carrier for which resources are reserved; and / or QoS related metrics performed at the WTRU, e.g., reflecting WTRU SL transmissions over a period of time.

[0222]

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

[0223]

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

[0224]

[0236] Some of the QoS metric measurements, averages and / or ratios made at the WTRU included in the UMUS may include the ratio of the number of transmissions required for unicast and / or multicast links; HARQ NACKs transmitted; success of the resource selection procedure; LBT backoff operation during resource selection; increase in specific RSCP / RSSI thresholds for resource availability during resource selection; preemption transmission or reception; carrier and / or resource reselection due to CBR or resource availability, etc.; and / or measurements, averages and / or ratios of packets successfully transmitted / received within the PDB or within the required latency.

[0225]

[0237] In some cases where attributes of resources needed to transmit data on unicast and / or multicast links are included in the UMUS, the resource attributes may include a link identifier; resource density (e.g., amount of time and / or frequency resources per time unit); one or more granularities of resources used for the link; average, maximum or minimum packet size of the link and / or amount of contiguous time / frequency resources of the link; priority; link reliability; beam pattern (e.g., whether the link is transmitted omnidirectionally on a single beam, beam swept, or beamformed and transmitted on a subset of beams (and possibly which beams)); and / or a geographic location indicating where the resources are needed, such as a zone ID, directionality, or geolocation criteria for which resources are reserved. Such attributes may be further associated with a profile or table identifier that may be configured or pre-configured in the WTRU and negotiated between WTRUs.

[0226]

[0238] Some examples include initiating and / or canceling and multiplexing information in a UMUS. For example, the WTRU may multiplex information of multiple unicast and / or multicast links and / or multiple radio bearers and / or multiple QoS flows into the same UMUS. In some examples, the WTRU may initiate a new UMUS transmission upon or after the establishment of a unicast and / or multicast link. Alternatively, the WTRU may initiate a new UMUS transmission upon or after the establishment of a first unicast and / or multicast link, or may add information of all links to an existing UMUS upon or after the establishment of additional links. In such a case, the WTRU may cancel the UMUS transmission upon or after the release of one or all links in the WTRU.

[0227]

[0239] In some examples, the WTRU may initiate a new UMUS transmission upon or after establishment of a new radio bearer associated with the link. The WTRU may determine whether to transmit a new UMUS upon or following establishment of the radio bearer depending on the QoS characteristics of the 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 those of the existing radio bearer.

[0228]

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

[0229]

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

[0230]

[0242] In some examples, the WTRU may apply a weighting factor to determine the amount of resources required for each link and / or SLRB based on the QoS attributes associated with the link. For example, the WTRU may apply a multiplicative factor (e.g., greater than 1) to radio bearers / links that have a reliability requirement (or a parameter thereof) that exceeds a threshold. In another example, the WTRU may apply a multiplicative factor (e.g., greater than 1) to radio bearers / links that have a latency requirement or a parameter thereof that is less than a threshold.

[0231]

[0243] In some examples, the WTRU may monitor / receive UMUS for a period of time prior to establishing the links and / or bearers. For example, the WTRU may perform admission control based on existing links and / or bearers established based on UMUS detected over a period of time that identifies unique links / bearers. In some examples, the WTRU may consider UMUS of only a subset of established links / bearers (UMUS) in its determination, for example, based on QoS attributes associated with the links and / or bearers and whether the links and / or bearers and their QoS affect the QoS of the link to be established. The WTRU may further perform admission control by considering only links / bearers that have common QoS parameters and ensuring that no combination of such links / bearers exceeds another QoS parameter. In some examples, the WTRU may apply multiple determinations or criteria in determining whether admission control is successful, for example, where the admission control depends on the success of each criterion. The decision or criteria may be performed based on the total amount of resources (eg, of a particular type) indicated in the UMUS; and / or the number of links / radio bearers established in the UMUS (eg, weighted).

[0232]

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

[0233]

[0245] In some examples, the WTRU may determine the number of resources used by an existing link within a certain period of time based on a VQI or similar QoS parameter (e.g., PPPP, PPPR) transmitted using the link (e.g., the WTRU may have a configured or pre-configured mapping between VQI values ​​and corresponding numbers of resources (RBs) for each time period); based on the number of SLRBs associated with the link in 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 transmitted packet size or data rate on the UMUS signal itself (e.g., the WTRU may determine the amount of resources used by the link using a mapping of a combination of VQI and packet size to the amount of resources).

[0234]

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

[0235]

[0247] In some examples, the WTRU may determine the total amount of resources of a particular type used from all UMUS transmissions and make admissions control decisions based on the total number of free resources in the resource pool of that type. The type may be associated with time granularity (e.g., whether the resource is a slot or a symbol; numerology; and / or direction (e.g., one or more directions associated with transmission on one or more antenna beams).

[0236]

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

[0237]

[0249] 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 having reliability requirements or parameters thereof that exceed 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 less than the threshold. In some examples, the WTRU may apply a multiplicative factor configured for use in conjunction with a VQI associated with the radio bearers / links.

[0238]

[0250] In some examples, the WTRU may apply a weight of 0 in the evaluation of the number of established links / bearers (ie, do not consider certain links and / or bearers).

[0239]

[0251] In some examples, the WTRU may perform admission control based on the number of remaining available RS resource transmission configurations; the remaining available preemption resource configurations; the remaining available HARQ resource transmission configurations; and / or the remaining available CQI resource transmission configurations. For example, the WTRU may determine the number of available configurations by filtering out configurations that are already in use, e.g., as identified by a received UMUS signal over a time period. In some examples, the WTRU may determine that the admission control is successful if the number of available (i.e., unused) configurations exceeds a configuration or pre-configuration or a predetermined threshold (e.g., 0); and / or if there exists a configuration that does not conflict with any existing configurations from an interference or capacity perspective, etc., and can be selected for establishing the link and / or SLRB (e.g., the WTRU may associate the RS transmit power with the QoS of the link to be established, and the WTRU may further determine whether there exists a configuration associated with a transmit power that does not exceed the allowable WTRU transmit power).

[0240]

[0252] In some examples, the WTRU may determine the time period to consider UMUS signals to determine which configuration is already in use based on latency-related aspects of the QoS. For example, the latency-related aspects may include mapping of the VQI to an average or worst-case PDB. In some examples, the WTRU may determine the amount of resources to transmit over that period based on rate-related aspects of the QoS, for example, by adjusting the rate requirements derived from the VQI towards the worst-case PDB. Thus, the WTRU may assume that the resource density, which is a configurable number of resources per period, is the amount of resources used in the PDB. In some examples, the WTRU may perform the same calculation for all established links / bearers to determine the current density of resource availability. 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, this factor may be configured by the network for a given value of the reliability / range derived parameter (e.g., from the VQI). In some examples, admission control of a link and / or bearer may be deemed successful if the total amount of available resources over a configurable time period, including resources of the link and / or bearer to be established, is less than a threshold percentage (e.g., X%) of the resources in the pool. In this example, X% may be further configured by the network for each pool, and the WTRU may further select from one of several thresholds applicable to that pool based on the measured CBR. For example, the WTRU may receive a threshold (X%) to apply to each range of CBR values ​​for that pool.

[0241]

[0253] In some examples, the WTRU may perform admission control such that the number of active links / bearers having a particular type of rate requirement does not exceed a maximum number of bearers. In some examples, the maximum number of bearers may be determined based on a latency-related requirement. For example, a WTRU performing admission control for links and / or bearers having a requirement for a larger data burst size (e.g., may be associated with one 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 within the time frame of the minimum PDB associated with each link.

[0242]

[0254] Some examples include modifying resource selection for broadcast transmissions based on UMUS. For example, the WTRU may perform resource selection (e.g., of broadcast resources) and may consider the number of established unicast and / or multicast links during the resource selection process. In some examples, the WTRU may perform one or more actions during resource selection. The one or more actions may include avoiding carrier selection if the number of links / bearers on that carrier or the amount of resources available for links / bearers on that carrier exceeds a threshold, and / or scaling or modifying certain resource selection parameters based on the presence / number of links or the amount of resources available in all UMUS. Such parameters may include the number of consecutive resource reservations allowed; the probability of maintaining (e.g., updating the reservation of) a resource at each reservation period; a CBR threshold for carrier selection; an RSRP threshold for identifying resource availability based on detection of SCI; LBT parameters such as backoff, detection time, detection sensitivity, etc.; the minimum energy associated with a valid / acknowledged preemption signal; and / or the percentage of resources deemed available based on detection that the WTRU can proceed with resource selection.

[0243]

[0255] In some examples, the 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 admission control result based on the results of these resource selection procedures. In this situation, the representative resource selection procedure may not be performed to actually reserve or select any resources, but rather to evaluate the occupancy of the channel. In this situation, the representative resource selection procedure may be performed on a set of stored sensing results from past moments. In this situation, each representative resource selection procedure may represent the resource selection actually performed at that moment had an expected result corresponding to the sensing results stored in the WTRU corresponding to the past moment. Alternatively, the resource selection procedure used for admission control may include a resource selection procedure actually utilized to select resources for broadcast / unicast and / or multicast transmissions in the same pool, BWP and / or carrier and performed for a configured or preconfigured time prior to the execution of admission control. For example, the WTRU may maintain statistics of resource selection procedures performed prior to the required admission control moment (eg, a link establishment decision) and may perform admission control based on those statistics.

[0244]

[0256] In some examples, the WTRU may be configured to perform multiple representative resource selection procedures, each having different resource selection parameters, such as a different PDB or latency; a different number of retransmissions; a different MCS, power or related transmission parameters; a different packet size; and / or a different packet periodicity (or no periodicity, e.g., one-shot resource selection).

[0245]

[0257] In some examples, the WTRU may be configured to use a set (or multiple sets) of resource selection parameters based, for example, on the QoS characteristics of the unicast and / or multicast links for which admission control is being performed. For example, the WTRU may be configured with a set of resource selection parameters to use for unicast and / or multicast links having 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 is successful. Alternatively, the WTRU may be provided with multiple sets of resource selection parameters for a particular VQI, and the WTRU may perform representative resource selection procedures in parallel or sequentially, each using a different set of parameters, to determine admission of a new link and / or bearer.

[0246]

[0258] In some examples, the WTRU may be configured with specific criteria (e.g., such as those described herein) related to past resource selection procedures for which the WTRU should take into account the results of such past resource selection procedures. For example, for a link having a particular VQI, the WTRU may be configured to consider only past resource selection procedures for which the PDB is below a threshold or the number of retransmissions is above a threshold as part of the admission control resource selection. After such configuration, the WTRU may perform admission control for the link based only on past resource selection procedures that meet these specific criteria.

[0247]

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

[0248]

[0260] In some examples, the WTRU may determine the outcome of admission control based on a combination of results from past and representative resource selection procedures. For example, the WTRU may be required to perform admission control based 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 during admission control to meet the configured minimum.

[0249]

[0261] FIG. 8 is a flow chart showing an example procedure 800 for performing admission control based on an exemplary resource selection. In step 810, QoS information associated with the bearer / link may be used to initiate bearer and / or link establishment. In step 870, the WTRU may use configuration or pre-configuration and / or CBR to determine the number of resource selections to be attempted in admission control and the parameters to use for the attempted resource selections (e.g., PDB-packet delay budget, periodicity and / or packet size of resource selection, availability threshold, etc.). These values ​​may be configured or pre-configured or predefined for each bearer QoS and / or CBR. In some examples, the WTRU may determine the number of successful resource selection procedures required to declare admission control successful. The number of successful resource selection procedures required to declare admission control successful may also be (pre-)configured or pre-defined. For example, admission control may be determined to be successful if the number of successful resource selection procedures exceeds a configured amount. The WTRU may determine the success of a resource selection procedure based on a configured or pre-configured availability threshold (i.e., the percentage of resources available for use as determined by the sensing procedure). For example, a resource selection procedure is successful if the available resources based on the sensing results exceed an availability threshold.

[0250]

[0262] In step 820, the WTRU may determine parameters of a representative resource selection based on the QoS of the bearers and / or links. The parameters may include the number of representative resource selection attempts made in procedure 800 and a number of parameters specific to each resource selection procedure to be performed, as discussed herein. In particular, the PDB (packet delay budget to be used in each resource selection procedure), the periodicity of the data, and the packet size to be used in each resource selection procedure may be determined in step 870. In step 830, the WTRU may determine resource selection success / failure criteria, i.e., criteria for judging whether the representative resource selection procedure is successful or not, as discussed herein. The success / failure criteria of the resource selection procedure may be defined in terms of the number of available resources based on the sensing results being above / below an availability percentage threshold determined in step 870. The admission control success / failure criteria may be defined in terms of the percentage of resource selection procedure success being above / below a failure percentage threshold determined in step 870. In step 840, the WTRU may perform a representative resource selection procedure using the stored sensing results. In particular, the UE may select resources from a set of shared resources (resource pool) using a set of (pre)configured parameters (e.g., latency / PDB, periodicity, etc.) by identifying free resources from sensing results. The UE may perform a resource selection procedure using the number of attempts determined in step 870, potentially using different sensing results associated with different instants. An exemplary resource selection procedure may be based on sensing results as discussed herein. In particular, the UE may store results of sensing performed at different instants in the past and perform the resource selection procedure using sensing results associated with particular instants in the past. In some examples, the resource selection procedure may include the WTRU identifying free resources based on input parameters.

[0251]

[0263] In step 850, the WTRU may evaluate the representative resource selection based on success / failure criteria as discussed herein. In particular, 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 exceeds a configured threshold to determine whether admission control was successful. In step 860, a bearer and / or link establishment decision based on the evaluation in step 850 is provided to the peer WTRU and / or higher layers of the WTRU. In particular, the WTRU may inform the higher layers that the bearer / link can be established if admission control is successful.

[0252]

[0264] In some examples, when a past resource selection procedure is used rather than a representative resource selection procedure, procedure 800 may be modified by ignoring the step of performing a resource selection procedure in step 840 and instead using the results of a past resource selection procedure that meets the criteria.

[0253]

[0265] In some examples, the admission control is based on sensing results. For example, the WTRU may perform admission control based on sensing or measurements, such as CBR measurements associated with one or more pools, carriers and / or BWPs, constantly maintained and / or analyzed by the WTRU over a period of time prior to triggering an admission control decision; number of LBT successes / failures over a configured time (e.g., based on its own access to the channel or on measurements sent in the UMUS); number of preemption signals detected over a configured time; sensing results (e.g., including information on SCIs detected during sensing of one or more pools); metrics (e.g., average transmission rate) associated with other ongoing unicast links of the WTRU (e.g., links in the same pool); measurements of channel quality (e.g., CQI, path loss) during discovery procedures of the procedure; and / or QoS related measurements or metrics at the WTRU or measurements or metrics received from other WTRUs (e.g., in the UMUS).

[0254]

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

[0255]

[0267] Some examples include CBR-based admission control. For example, the WTRU may be configured with a CBR threshold for each VQI. When the WTRU initiates link and / or bearer establishment for a bearer with a particular VQI, admission control may be deemed to have failed when the measured CBR exceeds the associated CBR threshold. In some examples, the WTRU may be configured with CBR thresholds for each (or any) of the following QoS related parameters: latency, reliability, priority, range, and rate. In some examples, the WTRU may determine QoS parameters applicable to the radio bearers to be established based on the associated QoS parameters of the flows that are mapped to those radio bearers. In some examples, the WTRU may determine the applicable values ​​(e.g., priority, reliability, etc.) for the associated 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 falls below a respective QoS parameter-specific threshold for each of the QoS parameters associated with the bearer.

[0256]

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

[0257]

[0269] In some cases where the admission control decision depends on the amount of observed aperiodic traffic, the WTRU may measure the amount or percentage of resources associated with aperiodic traffic (e.g., one-shot) and may allow establishment of a link and / or bearer if this value is above / below a threshold. In some cases where the admission control decision depends on the amount of observed periodic traffic, the WTRU may measure the amount or percentage of reserved resources (e.g., using forward booking or similar reservation methods) and may allow establishment of a link and / or bearer if this value is above / below a threshold. In some cases where the admission control decision depends on the relative amount of periodic to aperiodic traffic, the WTRU may be configured with an allowable ratio of periodic to aperiodic traffic and the WTRU may allow establishment of a link and / or bearer if the measured ratio is above / below a threshold. In some cases where the admission control decision depends on the amount of observed unicast and / or multicast traffic (e.g., possibly compared to broadcast), the WTRU may determine the amount or percentage of unicast and / or multicast traffic based on detection of a unicast indicator in the SCI; detection of a HARQ process ID, etc. in the SCI; detection of HARQ transmissions (or resources reserved for HARQ transmissions); and / or detection of a CSI reference signal 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, as appropriate. In some cases where the admission control decision depends on the QoS characteristics of observed periodic, aperiodic unicast, multicast and / or broadcast traffic, the WTRU may determine the VQI or any QoS related parameters derived from the VQI (e.g., reliability, latency, priority, rate, range) of the transmissions from the SCI associated with such transmissions. In some such cases, the WTRU may further modify or select any of the above thresholds based on the worst, average, best, overall and / or primary QoS of the observed transmission.In some cases where admissions control decisions depend on the amount of reserved resources of a particular granularity, the WTRU may identify an amount or percentage of reserved symbol-based or slot-based resources and perform admissions control based on this value being above / below a threshold.

[0258]

[0270] 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 identified from monitoring the SCI over a period of time. In some examples, the WTRU may further determine an estimated amount or density of resource usage using methods similar to those associated with receiving UMUS, and may make admission control decisions based on determining the percentage of resources used.

[0259]

[0271] Some examples include admission control based on QoS related measurements and / or metrics. For example, a WTRU may be configured with admission control rules based on QoS related measurements and / or metrics as discussed herein. In some examples, the WTRU may obtain such measurements and / or metrics based on metrics obtained from its own transmissions and / or from broadcasts by other WTRUs. For example, the WTRU may obtain such metrics from other WTRUs in UMUS or other inter-WTRU messages and / or the WTRU may obtain such metrics during RRC signaling associated with link and / or SLRB establishment. In some examples, the WTRU may further restrict the WTRUs that consider metrics for admission control decisions based on geographic area, unicast and / or multicast relationship and / or QoS or transmission type.

[0260]

[0272] In some cases where a WTRU restricts the WTRUs that consider metrics for its admission control decisions based on a geographical area, the WTRU may only consider metrics received from WTRUs in a geographical zone or other area associated with the WTRU for which it is performing admission control. In some cases where a WTRU restricts the WTRUs that consider metrics for its admission control decisions based on a unicast and / or multicast relationship, 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 with which the WTRU currently has an active unicast and / or multicast link / SLRB. In some cases where a WTRU restricts the WTRUs that consider metrics for its admission control decisions based on QoS or transmission type, the WTRU may only consider metrics received from WTRUs that have 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.

[0261]

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

[0262]

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

[0263]

[0275] In some examples, a WTRU may decide to preempt one or more established unicast and / or multicast links (e.g., either its own links or links between other WTRUs) during admission control for the establishment of its own unicast and / or multicast. For example, a WTRU may decide to preempt a unicast and / or multicast link when it decides to establish a new link (e.g., based on the techniques described herein) that cannot currently be established due to the presence of one or more existing unicast and / or multicast links, or when the establishment of a link would potentially result in the inability to meet the QoS requirements of that link or other already established links (e.g., other links with higher priority). In some examples, a WTRU may recognize an existing unicast and / or multicast link based on receiving a UMUS signal transmitted by another WTRU. Alternatively, a WTRU may decide to preempt a QoS flow multiplexed onto one or more radio bearers and / or unicast links.

[0264]

[0276] Without loss of generality, various examples of preemption may be discussed herein with respect to link preemption or radio bearer preemption, although examples, embodiments, situations and scenarios may refer to only one of the two for ease of explanation, it being noted that preemption may be applied to either links or radio bearers, or both links and radio bearers.

[0265]

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

[0266]

[0278] 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 and / or a threshold priority associated with one of the QoS characteristics above which the WTRU can preempt another link. In some cases where the WTRU determines whether it can perform preemption based on the current occupancy of the channel, the WTRU may be configured with a CBR threshold, and the WTRU may preempt the unicast and / or multicast link only if the current measured CBR is above the threshold. In some cases where the WTRU determines whether it can perform preemption based on a configuration configured to allow it to perform preemption, the configuration may be WTRU specific, specific to the QoS class of the link to be established (e.g., VQI associated with the link / radio bearer), or pool / BWP / carrier specific.

[0267]

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

[0268]

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

[0269]

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

[0270]

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

[0271]

[0283] In some cases where the WTRU selects one or more unicast and / or multicast links to preempt based on the satisfaction of attributes of the link to be established, e.g., the WTRU may select the link that reserves the most similar amount of resources or has the most similar QoS characteristics (e.g., packet size, reliability, etc.) as the link that needs to be established, or the WTRU may select the link that minimizes the number of links that need to be preempted to meet the requirements of the link to be established). In another example, the WTRU may select the link that minimizes the number of links that need to be preempted to meet the requirements of the link to be established. In another example, the WTRU may select the unicast and / or multicast link that has a packet arrival time that is closest to the estimated packet arrival time of the link to be established. For example, the WTRU may identify the packet arrival time of an existing unicast link that is transmitting periodic traffic. Such identification may be done by detecting SCI over a period of time. The WTRU may select the unicast link to be preempted as having the closest packet arrival time to the link to be established and having a lower priority than the link to be established.

[0272]

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

[0273]

[0285] 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 consider preemption only on links for which resources are reserved in the same area (e.g., zone, geographic location and / or direction) as the zone required for the new unicast link. In some examples, the WTRU may select the unicast and / or multicast link with which the communicating WTRU(s) are closest to the one or more WTRUs associated with the unicast and / or multicast link to be established. In some examples, the WTRU may determine the proximity of the ongoing one or more unicast and / or multicast links based on measurements such as the RSRP of the transmissions by the WTRU on the unicast link, possibly in combination with detection of the WTRU location on the SCI / UMUS or similar transmission(s) by the WTRU. 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 such measurements.

[0274]

[0286] 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 unicast and / or multicast links that use a resource usage pattern (e.g., a pool or a pattern of time / frequency resources 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 a pattern may also include a transmission signature, such as a scrambling code or a hopping sequence. In some examples, the WTRU may select to preempt a WTRU that has a lower priority than the link to be established based on the same (or overlapping) pattern / signature.

[0275]

[0287] In some examples, link preemption selection may be performed in the WTRU transmitting the preemption signal or in the WTRU receiving it. For example, the WTRU may first determine which unicast and / or multicast links to preempt and indicate that link in the preemption signal transmitted to one or more of the WTRUs associated with the unicast and / or multicast links. In some examples, the WTRU receiving the preemption may preempt the unicast and / or multicast links and / or SLRBs indicated in the preemption signal. Alternatively, the WTRU may select the WTRU to which the preemption is transmitted, and the WTRU receiving the preemption signal may determine which unicast and / or multicast links and / or SLRBs to associate with for preemption using the rules discussed herein.

[0276]

[0288] In some examples, the WTRU may consider all ongoing unicast and / or multicast links with a priority equal to or less than the planned unicast and / or multicast link to be established, and based on these links, for example, the WTRU may first determine to preempt an existing link with the same or substantially similar QoS profile or the same or substantially similar values ​​of QoS attributes (i.e., other than priority) as the link to be established, and may select that link for preemption.

[0277]

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

[0278]

[0290] In some examples, the WTRU may include information in the preemption signal, which may include: a UE ID of the WTRU transmitting the preemption signal; UE IDs of one or more WTRUs for which unicast and / or multicast links are being preempted; a link ID of the link to be preempted; a radio bearer ID of the radio bearer to be preempted; one or more destination addresses identifying one or more of the WTRUs associated with the unicast and / or multicast links; a time period for which the link / radio bearer should be preempted; QoS parameters associated with the link / bearer to be preempted and / or one or more QoS parameters and / or link / bearer IDs associated with the link / bearer or packets whose admission will cause preemption of the link and / or SLRB.

[0279]

[0291] If the WTRU includes one or more QoS parameters associated with the link / bearer to be preempted, the one or more parameters may include one or more priorities associated with the link to be preempted (e.g., the WTRU may preempt all unicast links having a priority lower than a certain priority level); and / or may include a VQI or set of VQIs (e.g., the WTRU may transmit a preemption signal that may be associated with one VQI value or a set / range of VQI values ​​to which preemption applies).

[0280]

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

[0281]

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

[0282]

[0294] In some cases where the WTRU selects a particular preemption resource from the allowed set based on the QoS of the link or SLRB being established, the WTRU may select a set of resources for more frequent link preemption if the link or SLRB has a higher priority or if the latency of the link or SLRB is lower. In some examples, this provides more opportunities to preempt a link or associated SLRB if the link / SLRB is associated with high priority and / or low latency. In some examples, such greater opportunities may be consistent with a situation where a higher priority link and / or SLRB may only be preempted by an even higher priority link / SLRB.

[0283]

[0295] In some cases where the WTRU selects a particular preemption resource from the allowed set based on a preemption pattern in the preemption pool, the WTRU may only select preemption resources for the associated link and / or SLRB based on a certain preemption pattern (e.g., RB1 in subframe 1 repeated every N subframes as one example preemption pattern).

[0284]

[0296] In some cases where the WTRU selects a particular preemption resource from the allowed set based on resource availability (e.g., based on sensing and measurements), the WTRU may perform sensing procedures (e.g., SCI decoding, RSSI measurements, etc.) to identify free or occupied resources and may select a preemption resource from the set of free resources. Alternatively, the WTRU may exclude preemption resources associated with already existing unicast links (e.g., identified by all received UMUS from other WTRUs) and select preemption resources for the link to be established and / or the SLRB from the remaining permissible resources.

[0285]

[0297] In some examples, there may be a set of pre-defined patterns of pre-emption resources, each associated with one or more VQIs. For example, the WTRU may select from the pre-defined patterns associated with the VQI associated with the link to be established or the highest VQI. In some examples, the WTRU may filter out any patterns currently in use by other WTRUs based on detection of UMUS transmissions by other WTRUs over a period of time. In some examples, the WTRU may randomly select a pattern of pre-emption resources (e.g., from the remaining set of patterns) or may select the pattern with the lowest RSSI measured over a period of time. In some examples, after a pattern is selected, the WTRU may transmit an index or identifier associated with such pattern in a reservation signal or UMUS.

[0286]

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

[0287]

[0299] Some examples include acknowledgment signaling. In some examples, the WTRU may wait to receive a preemption acknowledgment signal from one or more of the WTRUs associated with the unicast and / or multicast links before initiating / completing link establishment. In some examples, the WTRU may repeat transmitting a preemption signal if it does not receive a preemption acknowledgment for a threshold amount of time. In some examples, the WTRU may determine preemption success of the link based on receiving at least one preemption acknowledgment signal and thus initiate / complete link establishment. Alternatively, the WTRU may determine preemption success of the link based on receiving acknowledgments from a threshold number (N) of WTRUs. In some examples, N may be a value equal to the number of WTRUs associated with the unicast and / or multicast links (e.g., 2 for unicast), or N may be configured or preconfigured.

[0288]

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

[0289]

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

[0290]

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

[0291]

[0303] Some examples include admission control of broadcast transmissions. For example, admission control may be performed at service establishment and / or service initiation. In some examples, the WTRU may perform admission control according to an instruction of establishment or initiation of a broadcast service by higher layers. In some examples, the WTRU may receive an instruction of initiation of such a service from higher layers. The instruction may include information such as a desired QoS, a period and / or duration of the service, and / or an admission control policy. If the instruction includes a desired QoS, the instruction may include a worst case QoS attribute or a range of QoS attributes of each packet transmitted for the associated service, such as VQI / VQI range, PPPP / PPPP range, PPPR / PPPR range, etc. If the instruction includes a period / duration of the service, the instruction may include an expected duration of the service at a certain moment in time. If the instructions include an admission control policy, the admission control policy may include an indication of guaranteed QoS or better effort QoS, whether the AS layer should indicate to upper layers when and / or whether the QoS of such services can be met, or whether admission control and / or monitoring should be performed; and / or whether preemption of existing broadcast services and / or unicast and / or multicast links / SLRBs for initiation of a service is allowed, and / or rules associated with such preemption (e.g., which services or priority levels can be preempted).

[0292]

[0304] In some examples, the WTRU may perform admission control decisions using the same or substantially similar methods as the unicast link and / or SLRB establishment cases described herein. Without loss of generality, admission control for broadcast transmission services may follow the unicast methods, but admission control decisions may be made entirely at the WTRU receiving an indication from higher layers rather than based on signaling associated with link establishment.

[0293]

[0305] In some examples, the WTRU may decide to preempt an ongoing broadcast or unicast and / or multicast SLRB to accommodate a broadcast service. The rules for determining whether to preempt an SLRB may be determined based on higher layer policy information and may be similar to the rules for initiating unicast and / or multicast link and / or bearer establishment.

[0294]

[0306] In some examples, the WTRU may initiate the creation of a broadcast SLRB upon instruction from higher layers and an admission control success decision in the WTRU. Without loss of generality, the SLRB establishment may be performed in the WTRU using methods similar to those described for unicast and / or multicast link and / or SLRB establishment. For example, the WTRU may start transmitting a UMUS upon broadcast SLRB initiation, with information in the UMUS reflecting one or more or all of the broadcast services active in the WTRU. Some procedures (e.g., initiation of reference signal transmission) may not be required for the establishment of a broadcast SLRB.

[0295]

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

[0296]

[0308] Some examples include per-packet admission control. For example, the WTRU may perform per-packet admission control on each reception of a packet from higher layers for transmission on the SL. In some examples, the admission control decision for a single packet may be based on the methods described for unicast and / or multicast link establishment admission control, possibly with certain modifications and / or constraints. Such modifications and / or constraints may include: WTRU measurements, metrics and / or resource usage estimates used for admission control may be limited to PDB or latency requirements associated with the transmitted packets; WTRU measurements, metrics and / or resource usage estimates may use worst-case values ​​rather than averages; criteria (e.g., thresholds for comparison with WTRU measurements / metrics / resource usage) may be different for per-packet admission control compared to link and / or SLRB admission control; admission control failure may be tolerated based on conditions described herein such as those regarding temporary admission of packets despite admission control failure, where the benefit of admission control failure may be to avoid an established link and / or SLRB collapsing (e.g., as a result of preemption) to meet the QoS of a single or a few packets. In some such cases, for example, one or more packets that fail admission control may be temporarily tolerated because it is expected that the service may temporarily exceed the QoS performance of the resource.

[0297]

[0309] In some examples, the WTRU may perform one of several actions depending on the result of the admission control, such as: if admission control is successful, the packet may undergo a normal resource selection procedure and be submitted for transmission to a lower layer (e.g., the MAC / PHY layer); if admission control fails, the WTRU may initiate preemption of its own transmission (e.g., by releasing an SLRB) or another WTRU transmission (e.g., by sending a preemption signal); if admission control fails, the WTRU may notify upper layers of the failure; if admission control fails, 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 having the new QoS-related attributes; and / or if admission control fails, the WTRU may still transmit the admission control-failed packet based on the rules discussed herein for temporary admission of admission control-failed packets.

[0298]

[0310] Some examples include temporarily accepting a packet despite the packet's admission failure. For example, the WTRU may be configured or pre-configured with rules to tolerate (i.e., accept) the packet that has failed admission control. In some examples, if a packet fails admission control, this may mean or indicate that the WTRU cannot maintain the QoS of the existing link while guaranteeing the QoS of the service that is being admission controlled on a per-packet basis.

[0299]

[0311] In some examples, the per-packet admission control rules may be based on the total number of admitted packets that fail admission control that are allowed for a given service. For example, the WTRU may determine the total number (i.e., maximum number) of packets that fail admission control over the duration of the service, and if this number is exceeded during the service period, the WTRU can no longer accept such packets that fail admission control.

[0300]

[0312] In some examples, the per-packet admission control rules may be based on the rate of admission control failure packets that may be transmitted or a certain number of admissions allowed in any predefined time period or window, where the rate / number / window may be defined per broadcast service or across all broadcast services. For example, the WTRU may determine a rate, such as the number of failed packets that may be tolerated per second, and additional admission control failure packets beyond the rate may not be transmitted and / or may initiate an indication to higher layers and / or may initiate a preemption procedure.

[0301]

[0313] In some examples, the per-packet admission control rules may be based on a maximum number of consecutive broadcast packets potentially associated with a given service that have failed admission control, e.g., the WTRU may determine the number of consecutive packets that have failed admission control before instructing higher layers and / or performing preemption.

[0302]

[0314] In some examples, per-packet admission control rules may be based on an acceptable time between packets that fail admission control, possibly associated with a single broadcast service or across all broadcast services. For example, the WTRU may determine a required minimum time between packets that fail admission control, and may continue to transmit such packets without taking any failure action, e.g., as long as the time difference between admission control failures is greater than the calculated minimum.

[0303]

[0315] Some examples may include factors for determining parameters related to temporary admission. For example, the WTRU may determine any of the parameters described above for temporary admission of a packet that fails admission control based on one or several factors.

[0304]

[0316] In some examples, factors determining the parameters related to temporary admission may include the number of unicast and / or multicast and / or broadcast links / SLRBs currently established on the carrier, carriers, BWP, BWP, pool and / or pools to which packet transmission is requested. In some examples, factors determining the parameters related to temporary admission may include one or more QoS attributes (e.g., associated VQI) of the links / SLRBs currently established on the same pool, BWP and / or carrier as the transmission of the broadcast service. In some examples, factors determining the parameters related to temporary admission may include QoS parameters (e.g., associated VQI) of the transmitted packets, such as the latency, priority, PDB and reliability of the transmission. In some examples, factors determining the parameters related to temporary admission may include the measured CBR of the pool, carrier and / or BWP from which the service and / or packet may be transmitted. Such determination (e.g., the relationship between the acceptable failure rate and VQI of the currently established SLRB or SLRBs) may be further configured or pre-configured in the WTRU.

[0305]

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

[0306]

[0318] In some examples, the WTRU may be configured to perform broadcast packet admission control by determining a worst case resource utilization rate associated with all established SLRBs, e.g., based on UMUS decoding and comparison of lease utilization percentage across the total amount of resources to a threshold. In some examples, admission control may be considered to have failed for a packet if the calculated resource utilization rate exceeds a threshold upon arrival of the broadcast packet. In some examples, the threshold may be determined by the WTRU based on a configured or preconfigured mapping of the VQI of the broadcast packet. In some examples, the WTRU may tolerate a broadcast packet admission control failure rate if it still proceeds with transmission of such a broadcast packet. The tolerated broadcast packet admission control failure rate may be configured or preconfigured based on the VQI of the worst case or best case QoS of any active SLRBs as determined by the UMUS. For example, the WTRU may be configured or preconfigured with a mapping of the VQI (e.g., of the worst case or best case SLRB) to an acceptable failure rate, and the WTRU may use such rate to temporarily tolerate packets that have failed admission control.

[0307]

[0319] Some examples include methods, systems, and devices for maintaining unicast and / or multicast links. For example, a WTRU may be configured to transmit one or more reference signals upon link establishment. In some examples, a WTRU may be configured to transmit one or more reference signals upon link establishment for sidelink link maintenance. For example, the WTRU may start transmitting one or more such reference signals following successful establishment of the link from higher layers or RRC, and may stop transmitting these reference signals following release of the link. In some examples, the WTRU may change the reference signal configuration based on the number and / or type of radio bearers established for the link.

[0308]

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

[0309]

[0321] Some examples include reference signal reception. For example, a WTRU may monitor and / or measure reference signals for link monitoring following unicast and / or multicast link establishment. 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 configuration may be provided by a peer WTRU or a gNB during link establishment signaling. In some examples, a WTRU may stop monitoring / measuring reference signals of a particular unicast and / or multicast link following release of the link or following release of the WTRU's last active link.

[0310]

[0322] Some examples include determining a reference signal, unicast configuration, and / or monitoring a multicast link. For example, the WTRU may select a reference signal configuration from shared resources. In some examples, a Mode 2 WTRU may determine the time, frequency, and / or beam location of a reference signal it needs to transmit, and / or the time, frequency, and / or beam location of reference signals transmitted by other WTRUs in the unicast and / or multicast link. For example, the WTRU may perform resource selection to reserve a set of time, frequency, and / or beam resources for reference signal transmissions by itself and possibly other WTRUs in a 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 a reservation signal may be transmitted on the PSCCH (e.g., an SCI-like transmission) and may include, for example, a resource configuration for the reference signal from a configured or pre-configured set.

[0311]

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

[0312]

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

[0313]

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

[0314]

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

[0315]

[0327] Some examples may include configuring reference signals for a multicast link (e.g., a link including three or more 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 a transmission from a different WTRU. In some examples, a transmitting WTRU may transmit a set of link-based reference signals associated with its own transmission.

[0316]

[0328] In some examples, the WTRU may be provided with a configuration of time, frequency and / or beam locations of possible reference signals associated with a dedicated physical channel. In some examples, the WTRU may further be configured with a mapping of resources associated with each other (e.g., definition of resource sets). In some examples, the WTRU may select a resource set to use for transmitting and / or receiving a reference signal based on a configured unicast and / or multicast link ID using modulo arithmetic (e.g., reference set modulo WTRU ID=0).

[0317]

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

[0318]

[0330] Some examples include bearer-specific reference signal configurations. For example, the WTRU may be configured with different sets of resources for reference signal transmission and / or reception for different radio bearers in the same multicast link. In some examples, the transmitting and / or receiving WTRU may transmit and / or receive a denser resource signal for a radio bearer with stricter reliability requirements. In some examples, the 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 a radio bearer with worst-case performance requirements. In such cases, the WTRU may change the reference signal configuration (e.g., from configuration 1 to configuration 2) when a radio bearer is established or torn down or when the WTRU maintains the same configuration. In some examples, the decision of whether to change or maintain the configuration may depend on the QoS characteristics associated with the bearer. In some examples, the WTRU may be configured with a mapping of radio bearers (e.g., radio bearer types) to reference signal configurations.

[0319]

[0331] Some examples include procedures for changing reference signal configurations due to ID changes. For example, a WTRU may need to change source L2 ID based on a decision by a higher layer, for example, for security purposes. In some examples, the WTRU's reference signal transmission and reception may need to be synchronized during an ID change.

[0320]

[0332] In some examples, a WTRU that receives an instruction to change the ID used to identify a reference signal location may identify a subframe and / or slot (n) relative to the time of receipt of the higher layer instruction. In subframe / slot n, the WTRU may stop transmitting reference signals using the old configuration and start transmitting reference signals using the new configuration. In some examples, WTRUs monitoring reference signals may behave the same or nearly the same from a reception perspective. For example, in subframe or slot (N), the WTRU may stop monitoring reference signals according to the old configuration and start monitoring reference signals according to the new configuration. In such a case, the transmitting and / or receiving WTRU may determine the value of N based on an instruction from higher layers; based on a defined time location following receipt of a higher layer instruction to change the ID (e.g., subframe N may be the first occurrence of subframe 0 after receipt of the higher layer instruction that is at least a threshold (k) subframes following the instruction); and / or based on receipt of RRC signaling (e.g., the source WTRU may determine the timing of the reference signal configuration change and indicate this to other WTRUs in the unicast and / or multicast link using an RRC message). In some examples, the receiving WTRU may be configured to immediately suspend monitoring of reference signals for a period of time following receipt of the higher layer instruction. In some examples, following receipt of the instruction, it may begin monitoring based on the new configuration in subframe N, where N may be determined using the same methods as described above.

[0321]

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

[0322]

[0334] The WTRU may determine its RLM / RLF parameters and procedures based on a VQI associated with the bearer. For example, an SL bearer may be associated with one or more VQIs. In some examples, the WTRU may further configure the RLM / RLF configuration for each VQI, and the WTRU may apply the associated configuration if a bearer with such VQI is active. In some examples, a bearer with multiple VQIs mapped to it may be associated with a VQI based on the VQI's numerical value, in which case the WTRU may select the VQI with the lowest or highest numerical value, and / or may be associated with a VQI based on one or more QoS parameters derived from the VQI, in which case the WTRU may derive a set of QoS related parameters, such as priority, latency, and reliability, from the VQI. In some examples, the WTRU may determine one or more derived QoS parameters (e.g., reliability only) and decide to use the VQI with the most stringent value of those requirements. In some examples, the WTRU may implicitly modify monitoring procedures and / or parameters when bearers are added and / or deleted, eg, based on the above rules.

[0323]

[0335] In some examples, the VQI-specific RLM / RLF configuration may include a target PSSCH / PSCCH BLER; a target RS-RSRP; a frequency of RLM-like indications to higher layers (e.g., RRC; e.g., how frequently the PHY layer can report an RSRP below the target); and / or a timer (e.g., an RLF-like timer).

[0324]

[0336] Some examples include monitoring procedures and / or parameters per unicast and / or multicast link. In some examples, the WTRU may determine its monitoring procedures and / or quality metrics based on one or more QoS characteristics of its active SL bearers. For example, the WTRU may perform a single monitoring procedure with a single set of parameters and may select such procedures / monitoring parameters based on the set of currently active SL radio bearers of 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, the WTRU may be configured with RB type 1 and RB type 2, each with its own procedures / parameters, with RB type 1 being considered higher priority than RB type 2. In some examples, when both bearers are configured simultaneously, the WTRU may perform monitoring based on parameters of RB type 1. In other cases, when a single bearer is active, the WTRU may apply the procedures and / or parameters associated with that bearer.

[0325]

[0337] In some examples, the WTRU may be configured with a parameter derivation function (e.g., average BLER, weighted average BLER, etc.) that derives monitoring procedures and / or parameters for a combination of active radio bearers, and the WTRU may apply the procedures and / or parameters when that combination of bearers is active. In other examples, when a single bearer is active, the WTRU may apply the procedures and / or parameters associated with that bearer.

[0326]

[0338] In some examples, the WTRU may maintain multiple procedures and / or parameters. For example, the WTRU may maintain parallel procedures (e.g., run independently in parallel) and parameter sets for each SL radio bearer associated with potentially the same or different unicast and / or multicast links or sets of radio bearers. For example, the WTRU may report a measured quality (RS_QUAL) of reference signals below a target for each radio bearer independently, and may configure a different set of reference signals for each SL radio bearer. In another example, the same set of reference signals may be transmitted on all radio bearers, but the WTRU may monitor based on different target qualities and report events for each of the different qualities independently.

[0327]

[0339] In some examples, the WTRU may maintain multiple procedures and / or parameters for a single SL radio bearer when the SL radio bearer is configured with different VQIs, possibly 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, when a radio bearer is established that includes flows from different VQI ranges, the WTRU may perform multiple monitoring procedures with independent parameters associated with each range of the bearer.

[0328]

[0340] In some examples, the WTRU may be configured with different link failure timers (e.g., T1 and T2) that may be used to monitor different qualities. Depending on the monitored quality that fails, the WTRU may start an appropriate timer and indicate a link failure to higher layers (e.g., NAS) or the network when or after such timer expires. The WTRU may further indicate which link timer has expired when a link failure is declared.

[0329]

[0341] In some examples, the WTRU may maintain independent procedures and / or parameters for each WTRU in a multicast link. In some examples, the WTRU may report RLM-like events to higher layers independently for each WTRU in a multicast link. In some examples, the WTRU may determine a 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 a value derived from the measured quality of discovery or link establishment message transmissions during unicast and / or multicast link establishment.

[0330]

[0342] In some examples, a WTRU associated with a multicast link may require a link failure procedure associated with that multicast link, hi some examples, link failure may be associated with various conditions, such as a determination that the link quality based on reference signal monitoring is below a target for several potentially consecutive periods of time.

[0331]

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

[0332]

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

[0333]

[0345] If the WTRU determines a particular subset of WTRUs based on higher layer configuration, the WTRU may be explicitly configured with the subset of WTRUs for which link failure should have occurred, or the WTRU may derive the subset of WTRUs based on another configuration aspect, such as relay configuration, platoon configuration and identification of the role of each WTRU, resource selection configuration and / or synchronization source configuration if WTRU assistance based resource selection is used. If the WTRU identifies a particular subset of WTRUs based on relative location, the WTRU may indicate a link failure when a subset of WTRUs closest / farthest from the WTRU experience a link failure.

[0334]

[0346] Some examples include additional triggering of link failure based on admission control metrics. For example, a WTRU with established radio bearers may perform the same, substantially the same, or substantially similar measurements on the admission control ones and may declare a link failure based on the failure of one or successive admission control evaluations associated with the SL radio bearer. In some such cases, the WTRU may utilize any of the mechanisms described herein for admission control, assuming that the bearer to be added is the bearer for which it 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 associated admission control procedures at different times depending on the SLRB.

[0335]

[0347] Without loss of generality, the WTRU may perform link monitoring by performing one or more admission control procedures described herein that are performed while the link or SLRB is active. In some examples, a link failure may further result in any of the failure actions described with respect to admission control, such as an indication to higher layers, collapse of the link and / or SLRB, and / or preemption of another SLRB / link.

[0336]

[0348] In some examples, the WTRU may be configured with a periodicity for the derivation of admission control procedures. In some examples, this periodicity may be determined on a per-bearer basis. In some examples, based on the failure of a single admission control procedure, the WTRU may change the frequency of admission control procedure executions or may execute several subsequent admission control procedures for a radio bearer until the procedure is successful or a maximum number of execution failures is reached. In some examples, the WTRU may then trigger a link failure if the admission control procedure fails for a threshold number (N) of consecutive times.

[0337]

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

[0338]

[0350] Some examples may include additional triggers of link failure based on resource selection metrics. For example, the WTRU may declare link failure based on failure of resource selection or based on a particular aspect related to the results or intermediate quantity related to the resource selection algorithm. In some examples, when considering link failure for a particular link and / or bearer, the WTRU may consider resource selection algorithm results of intermediate quantities of 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 such link based on a particular event occurring at one or more potentially consecutive times. Such events may include: if resource selection fails to find a threshold amount (X%) of available resources without changing the resource availability threshold; if resource selection fails to reserve a sufficient amount of resources to meet the QoS of the bearer on a single carrier / BWP; if the resources selected for PSCCH and / or PSSCH transmission have an RSRP / RSSI above a threshold; if the percentage of "low latency" type resources (e.g., symbol-based resources) detected as available falls below a threshold; if the WTRU receives a NACK for unicast and / or multicast transmission; if the WTRU fails the LBT procedure; and / or if the WTRU receives a preemption signal for a radio bearer, possibly for a time longer than a threshold (T).

[0339]

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

[0340]

[0352] Some examples may include additional triggers for link failure based on CBR. For example, the WTRU may declare link failure based on a measurement of CBR. In particular, the WTRU may monitor the CBR on a pool / carrier / BWP used for unicast and / or multicast links. The WTRU may be configured with a per-radio bearer CBR target or a per-VQI / QoS CBR target. The WTRU may declare link failure for a measured CBR on a pool / carrier / BWP exceeding a configured threshold. The WTRU may further declare link failure if such target is exceeded for a configurable time period.

[0341]

[0353] In some examples, a WTRU that detects a link failure may perform one or more actions depending on the type of link failure. Such actions may include triggering a group QoS negotiation / resource selection with new resources (e.g., if the link failure procedure is based on failure of a particular radio bearer or QoS target, the WTRU may choose to initiate a QoS renegotiation procedure, similar to that performed during initial link establishment); informing upper layers and / or other WTRUs of one or more removals of the WTRU from the multicast group (e.g., if the link failure is associated with only one or a subset of the WTRUs in the multicast group); initiating a temporary fallback to a broadcast procedure as discussed herein); changing the resource selection mode from one mode type to another (e.g., the WTRU may initiate a request to change the resource selection mode to Mode 1 for a particular bearer); informing upper layers and / or the network that the QoS requirements cannot be met; initiating link release signaling; and / or releasing all resources associated with the link, including transmission / reception of reference signals, indefinitely reserved resources, and ceasing UMUS transmissions.

[0342]

[0354] In some examples, the WTRU may include information with any link failure declaration signaling to higher layers, other WTRUs in the link, or the network. Such information may include the RLM / RLF process / procedure ID that declared the failure, the failed WTRU or WTRUs in the multicast link, the specific bearer or bearers that triggered the failure, and / or the reason for the failure (e.g., CBR exceeding a threshold, etc.) and any associated values.

[0343]

[0355] In some examples, the WTRU may initiate a temporary fallback to a broadcast-based transmission. In some examples, the WTRU may continue to transmit data received for a particular SL bearer, but 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 change from radio bearer-based resource selection / reservation to non-radio bearer-based resource selection / reservation; may change from using HARQ-based transmission to HARQ-less / blind retransmission; may change from beam-based transmission to omni-directional or beam-swept transmission; may disable reference signal transmission / monitoring for RLM and / or beam management; may disable encryption and / or integrity protection on transmitted data; and / or may change the AS layer configuration of any other parameters from a unicast-based configuration to a broadcast-based configuration. During the temporary fallback to broadcast, the WTRU may maintain the unicast and / or multicast configurations throughout the temporary fallback.

[0344]

[0356] In some examples, the WTRU may initiate any part or parts of the link establishment procedure during fallback. Alternatively, the WTRU may initiate a link establishment procedure or a link re-establishment procedure, whereby at least some parts of the current configuration (e.g., QoS, AS, etc.) are maintained. In some examples, the WTRU may notify higher layers of the fallback immediately. Alternatively, the WTRU may notify higher layers at a time (T) after the fallback occurs if the link establishment and / or re-establishment is not successful.

[0345]

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

[0346]

[0358] Some examples include methods, systems, and devices for flow-to-bearer mapping for SL unicast and / or multicast. For example, in SL bearer modeling, when one or more flows are initiated, an 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 the AS layer configuration may be associated with an amount of resources required; may include resource selection and / or reservation methods (e.g., LBT, detection, periodic resources, use of WTRU assistance, etc.); may include resource selection pool, carrier, BW and / or BWP; may include resource selection parameters, such as resource selection window (T2), LBT back-off timer, detection threshold, resource periodicity, amount of resources per period, number of repetitions, number of beams, etc.; may include carrier; may include indication of preemption usage capability and preemption resource configuration; may include transmission directionality and / or beam configuration; may include pool or BWP, etc.; may include PHY and / or MAC layer parameters (e.g., HARQ configuration, duplication); may include RLM / RLF configuration (e.g., RLF timer, RLM target BLER / RSRP); and / or QoS configuration, such as rules for mapping flows to bearers, QoS profile information and mapping of bearer types to AS configurations.

[0347]

[0359] In some examples, the WTRU may be configured to initiate or create a bearer with a particular configuration or range of configurations when 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., a flow with a particular VQI or VQI range may require a bearer with a particular configuration). In some examples, the WTRU may be configured with a mapping from bearer type or bearer configuration to VQI.

[0348]

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

[0349]

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

[0350]

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

[0351]

[0363] The WTRU may be configured with SLRB resource selection criteria at step 910. The resource selection criteria may include a quality of service indicator (VQI).

[0352]

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

[0353]

[0365] For each of a number of time periods within the time window at step 930, the WTRU determines whether the SLRB resource selection procedure would have failed based on a number of SCI transmissions and the SLRB resource selection criteria at step 940. In some examples, the WTRU determines whether the SLRB resource selection would have failed based only on the time periods among the number of time periods during which the packet delay budget (PDB) is below a threshold. In some examples, the WTRU determines whether the SLRB resource selection would have failed based only on the time periods among the number of time periods during which the number of retransmissions is above a threshold.

[0354]

[0366] At step 950, the WTRU determines a percentage of SLRB resource selection procedures that would have failed. In some examples, determining a percentage of SLRB resource selection procedures that would have failed includes determining what percentage of time periods within a time window include SLRB resource selection procedures that would have failed or determining what percentage of SLRB resource selection procedures within a time window would have failed.

[0355]

[0367] In situation 960, where the percentage of time periods within the time window during which SLRB resource selection would have failed is below a threshold percentage, the WTRU establishes a new SLRB with another WTRU in the pool, or in situation 960, the WTRU returns to step 920 and starts the procedure again in the next time window or terminates it if appropriate.

[0356]

[0368] FIG. 10 is a flow chart illustrating another example method 1000 for determining whether to establish an SLRB.

[0357]

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

[0358]

[0370] In step 1020, the WTRU receives a broadcast (e.g., a periodic broadcast) indicating the QoS of the SLRB of another WTRU in the pool that the WTRU is in. In some examples, the broadcasts are from multiple other WTRUs in the pool, each indicating the QoS of the SLRB of the originating WTRU.

[0359]

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

[0360]

[0372] In situation 1040 where the total resource density does not exceed a threshold, which may be based on the QoS of the new SLRB, the WTRU establishes a new SLRB with another WTRU in the pool in step 1050. In either situation 1040, the WTRU returns to step 1020 and either starts the procedure again or terminates it, if appropriate.

[0361]

[0373] Although the functions and elements are described above in particular combinations, one skilled in the art will understand that each function or element may be used alone or in any combination with the other functions and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and removable disks, magnetic media such as magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). The processor, in conjunction with software, may be used to implement a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. 1. A method, implemented in a wireless transmit / receive unit (WTRU), for determining whether to establish a sidelink radio bearer (SLRB), comprising: configuring a SLRB resource selection criterion in the WTRU; receiving, by the WTRU, a plurality of sidelink control information (SCI) transmissions from other WTRUs in a pool during a time window; determining, for each of a plurality of time periods within the time window, by the WTRU whether a SLRB resource selection would have failed based on the plurality of SCI transmissions and the SLRB resource selection criteria; determining, by the WTRU, whether to establish a new SLRB based on a rate of resource selection failures; establishing the new SLRB with another WTRU in the pool in a situation where the percentage of the time periods during which resource selection would have failed is determined to be less than a threshold percentage; The method includes:

2. 2. The method of claim 1, wherein the SLRB resource selection criterion is determined by a V2X Service Quality 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 used in resource selection.

5. 2. The method of claim 1, wherein the WTRU determines whether a SLRB resource selection would have failed based only on time periods among the multiple time periods during which an amount of free resources that meets the resource selection criteria is below a threshold.

6. The method of claim 1 , wherein the new SLRB is 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 the time periods within the time window during which resource selection would have failed.

9. The method of claim 1 , wherein the rate of resource selection failures comprises a rate of resource selection procedures that would have failed during the time window.

10. 1. A wireless transmit / receive unit (WTRU) configured to determine whether to establish a sidelink radio bearer (SLRB), comprising: A processor operably coupled to the transmitter and the receiver. Including, The processor is configured with SLRB resource selection criteria; The receiver is 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 a SLRB resource selection would have failed 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 rate of resource selection failures; and A wireless transmit / receive unit (WTRU), wherein the transmitter is configured to transmit a message establishing the new SLRB with another WTRU in the pool in a situation where the percentage of the time periods in which resource selection would have failed is determined to be less than a threshold percentage.

11. The WTRU of claim 10 , wherein the message establishing the new SLRB comprises 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 service quality 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 used in resource selection.

15. 11. The WTRU of claim 10, wherein the processor is configured to determine that a SLRB resource selection would have failed based only on time periods among the plurality of time periods during which an amount of free resources that meets the resource selection criteria is below a threshold.

16. The WTRU of claim 10 , wherein the new SLRB is 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 comprises a percentage of the time periods within the time window during which resource selection would have failed.

19. The WTRU of claim 10 , wherein the rate of resource selection failures comprises a rate of resource selection procedures that would have failed during the time window.

20. 1. A method, implemented in a wireless transmit / receive unit (WTRU), for determining whether to establish a sidelink radio bearer (SLRB), comprising: configuring the WTRU with a mapping of bearer QoS to SLRB resource density; receiving, by the WTRU, a broadcast transmission indicating a QoS of a 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; determining, by the WTRU, whether to establish the new sidelink bearer with another WTRU in the pool based on whether the total resource density exceeds the QoS based threshold for the new sidelink bearer; in a situation where the WTRU determines to establish the new sidelink bearer, establishing the new sidelink bearer with another WTRU in the pool; The method includes:

21. The method of claim 20, wherein the WTRU receives the broadcast transmission from a number 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