Summary based on the input provided by LG Electronics in RP-220521. 3GPP RAN technology for NR sidelink enhancement was specified through this WI to mainly define the means for power saving and enhanced reliability and reduced latency. This WI is the evolution of NR sidelink in Release 16. The key functionalities of NR sidelink enhancement are detailed below. Power Savings Resource Allocation The SL UE in Mode 2 can support partial sensing-based resource allocation and random resource selection as power saving resource allocation methods. A SL mode 2 TX resource pool can be (pre)configured to enable full sensing only, partial sensing only, random selection only, or any combination(s) thereof. A UE decides which resource allocation scheme(s) can be used in the AS based on its capability (for a UE in RRC_IDLE/RRC_INACTIVE/OOC) and the allowed resource schemes in the resource pool configuration. Random resource selection is applicable to both periodic and aperiodic traffic. A UE configured for partial sensing can perform periodic-based partial sensing and/or contiguous partial sensing for resource (re)selection. Periodic-based partial sensing can only be performed in a TX pool configured with partial sensing and periodic resource reservation. In periodic-based partial sensing, the UE monitors slots in periodic sensing occasion(s) for a given resource reservation periodicity. Contiguous partial sensing is performed by a UE configured for partial sensing when resource (re)selection is triggered by the UE in a TX pool configured with partial sensing. In contiguous partial sensing, the UE monitors slots in a contiguous sensing window which occur prior to the selected transmission resource. Inter-UE Coordination (IUC) The SL UE can support inter-UE coordination (IUC) in Mode 2, whereby a UE-A sends information about resources to UE-B, which UE-B then uses for resource (re)selection. The following schemes of inter-UE coordination are supported:

• IUC scheme 1, where the coordination information sent from a UE-A to a UE-B is the preferred and/or non-preferred resources for UE-B's transmission, and
• IUC scheme 2, where the coordination information sent from a UE-A to a UE-B is the presence of expected/potential resource conflict on the resources indicated by UE-B's SCI

In scheme 1, IUC can be triggered by an explicit request from UE-B, or by a condition at UE-A. UE-A determines the set of resources reserved by other UEs or slots where UE-A, when it is the intended receiver of UE-B, does not expect to perform SL reception from UE-B due to half-duplex operation. UE-A uses these resources as the set of non-preferred resources, or excludes these resources to determine a set of preferred resources and sends the preferred/non-preferred resources to UE-B. UE-B's resources for resource (re)selection can be based on both UE-B's sensing results (if available) and the coordination information received from UE-A, or it can be based only on coordination information received from UE-A. For scheme 1, MAC CE and second-stage SCI or MAC CE only can be used to send IUC. The explicit request and reporting for IUC in unicast manner is supported. In scheme 2, UE-A determines the expected/potential resource conflict within the resources indicated by UE-B's SCI as either resources reserved by other UEs and identified by UE-A as fully/partially overlapping with the resources indicated by UE-B's SCI, or as slots where UE-A is the intended receiver of UE-B and does not expect to perform SL reception on those slots due to half-duplex operation. UE-B uses the conflicting resources to determine the resources to be reselected and exclude the conflicting resources from the reselected resources. For scheme 2, PSFCH is used to send IUC. SL DRX Sidelink supports SL DRX for unicast, groupcast, and broadcast. Similar parameters as defined for Uu (on-duration, inactivity-timer, retransmission-timer, cycle) are defined for SL to determine the SL active time for SL DRX. During the SL active time, the UE performs SCI monitoring for data reception (i.e., PSCCH and 2nd stage SCI on PSSCH). The UE may skip monitoring of SCI for data reception during SL DRX inactive time. The SL active time of the RX UE includes the time in which any of its applicable SL on-duration timer(s), SL inactivity-timer(s) or SL retransmission timer(s) (for any of unicast, groupcast, or broadcast) are running. In addition, the slots associated with announced periodic transmissions by the TX UE and the time in which a UE is expecting CSI report following a CSI request (for unicast) are considered as SL active time of the RX UE. When data is available for transmission to one or more RX UE(s) configured with SL DRX, the TX UE selects resources taking into account the active time of the RX UE(s) determined by the timers maintained at the TX UE. For unicast, SL DRX is configured per pair of source L2 ID and destination L2 ID. The UE maintains a set of SL DRX timers for each direction per pair of source L2 ID and destination L2 ID. The SL DRX configuration for a pair of source/destination L2 IDs for a direction may be negotiated between the UEs in the AS layer. For SL DRX configuration of each direction, where one UE is the TX UE and the other is the RX UE. RX UE may send assistance information, which includes its desired on duration timer, SL DRX start offset, and SL DRX cycle, to the TX UE and the mode 2 TX UE may use it to determine the SL DRX configuration for the RX UE. Regardless of whether assistance information is provided or not, the TX UE in RRC_IDLE/RRC_INACTIVE/OOC, or in RRC_CONNECTED and using mode 2 resource allocation, determines the SL DRX Configuration for the RX UE. For a TX UE in RRC_CONNECTED and using mode 1 resource allocation, the SL DRX configuration for the RX UE is determined by the serving gNB of the TX UE. TX UE sends the SL DRX configuration to be used by the RX UE to the RX UE. The RX UE may accept or reject the SL DRX configuration. A default SL DRX configuration for groupcast/broadcast can be used for DCR messages. When the TX UE is in RRC_CONNECTED, the TX UE may report the received assistance information to its serving gNB and sends the SL DRX configuration to the RX UE upon receiving the SL DRX configuration in dedicated RRC signalling from the gNB. When the RX UE is in RRC_CONNECTED, the RX UE can report the received SL DRX configuration to its serving gNB, e.g. for alignment of the Uu and SL DRX configurations. SL on-duration timer, SL inactivity-timer, SL HARQ RTT timer, and SL HARQ retransmission timer are supported in unicast. SL HARQ RTT timer and SL HARQ retransmission timer are maintained per SL process at the RX UE. In addition to (pre)configured values for each of these timers, SL HARQ RTT timer value can be derived from the retransmission resource timing when SCI indicates more than one transmission resource. SL DRX MAC CE is introduced for SL DRX operation in unicast only. For groupcast/broadcast, SL DRX is configured commonly among multiple UEs based on QoS profile and Destination L2 ID. Multiple SL DRX configurations can be supported for each of groupcast/broadcast. SL on-duration timer, SL inactivity-timer, SL HARQ RTT and SL retransmission timers are supported for groupcast. Only SL on-duration timer is supported for broadcast. SL DRX cycle, SL on-duration, and SL inactivity timer (only for groupcast) are configured per QoS profile. The starting offset and slot offset of the SL DRX cycle is determined based on the destination L2 ID. The SL HARQ RTT timer (only for groupcast) and SL HARQ retransmission timer (only for groupcast) are not configured per QoS profile or per destination L2 ID. For groupcast, the RX UE maintains an SL inactivity timer for each destination L2 ID, and selects the largest SL inactivity timer value if multiple SL inactivity timer values associated with different QoS profiles are configured for that L2 ID. For groupcast and broadcast, the RX UE maintains a single SL DRX cycle (selected as the smallest SL DRX cycle of any QoS profile of that L2 ID) and single SL on-duration (selected as the largest SL on-duration of any QoS profile of that L2 ID) for each destination L2 ID when multiple QoS profiles are configured for that L2 ID. For groupcast, SL HARQ RTT timer and SL retransmission timer are maintained per SL process at the RX UE. SL HARQ RTT timer can be set to different values to support both HARQ enabled and HARQ disabled transmissions. A default SL DRX configuration, common between groupcast and broadcast, can be used for a QoS profile which is not mapped onto any non-default SL DRX configuration(s). For groupcast, the TX UE restarts its timer corresponding to the SL inactivity timer for the destination L2 ID (used for determining the allowable transmission time) upon reception of new data with the same destination L2 ID. TX profile is introduced to ensure compatibility for groupcast and broadcast transmissions between UEs supporting/not-supporting SL DRX functionality. A TX profile is provided by upper layers to AS layer and identifies one or more sidelink feature group(s). A TX UE only assumes SL DRX for the RX UEs when the associated TX profile corresponds to support of SL DRX. A RX UE determines that SL DRX is used if all destination L2 IDs of interest have an associated TX profile corresponding to the support of SL DRX. Alignment of Uu DRX and SL DRX for a UE in RRC_CONNECTED is supported for unicast, groupcast, and broadcast. Alignment of Uu DRX and SL DRX at the same UE is supported. In addition, for mode 1 scheduling, the alignment of Uu DRX of the TX UE and SL DRX of the RX UE is supported. For SL RX UEs in RRC_CONNECTED, alignment is achieved by the gNB.

Summary based on the input provided by OPPO, CMCC in RP-220211. This WI specifies solutions to enable single-hop, sidelink-based, L2 and L3 based UE-to-Network (U2N) relay. It specifies sidelink U2N relay supporting the following scenarios, i.e., for remote UE in and out of gNB coverage, in the same or different cell coverage as relay UE.

Common aspect for both L2 and L3 U2N Relay In order to enable remote UE and relay UE to identify each other and to establish sidelink connection, the scheme of sidelink discovery is introduced, including protocol stack design, interest report to network and etc. Further mechanism is adopted to enable network to configure the Uu RSRP threshold to (dis)allow remote / relay UE operation at specific cell location.

In order for remote UE to connection to the proper relay UE, relay (re)selection mechanism is introduced, in order for remote UE to base on the sidelink link quality to select proper relay UE. And relay UE can indicate the even of Uu link (e.g., Uu link disconnection or Uu link mobility) to remote UE, so that remote UE can decide whether to perform relay reselection. In order to support PC5 radio resource control in NG-RAN, ProSe service authorisation information and PC5 QoS parameters for ProSe need to be made available in NG-RAN. Beside the authorization for 5G ProSe direct discovery and 5G ProSe direct communication, authorization IEs are introduced to indicate whether the UE is authorised to use a 5G ProSe Layer-3 and/or Layer-2 UE-to-Network Relay and 5G ProSe Layer-2 UE-to-Network Remote UE. 5G ProSe PC5 QoS parameters are also supported. L2 U2N Relay specific aspect: User Plane In order to support bearer mapping between sidelink connection between remote and relay UE, and Uu connection between relay UE and gNB, an adaptation layer is introduced, between RLC (which is per-hop deployed) and PDCP (which is end-to-end deployed). The header of adaptation layer would carry the identity for remote UE identification and bearer identification, in order for relay UE to perform packet forwarding between the two sides.

L2 U2N Relay specific aspect: Control Plane In order for remote UE to acquire system information and paging message via relay UE, the SIB forwarding mechanism is designed, so that relay UE can base on the request and detailed parameter (for paging reception) from remote UE to forward the necessary SIB and paging information to remote UE, upon acquisition of SIB and paging message from network. Furthermore, in order to save relay UE power consumption, network can use dedicated signalling to delivery paging message to relay UE if it is in RRC_CONNECTED state. Based on that, remote UE mobility in RRC_IDLE and RRC_INACTIVE state can be supported. Furthermore, in order to support remote UE mobility in RRC_CONNECTED state, the switching between direct and indirect path for intra-gNB scenario is introduced. Via the newly introduced measurement event, remote UE can report the identified candidate connection (direct or indirect) to network, and network can correspondingly switch the UE to the connection (indirect or direct).

Summary based on the input provided by LG Electronics in SP-220357. This work item specifies some improvements for the advanced Vehicle-to-Everything (V2X) services. More precisely, it deals with V2X communication over NR PC5 reference point (device-to-device) with power efficiency for pedestrian UEs, i.e. UEs for Vulnerable Road Users. It results from a preliminary study (TR 23.776). The support of QoS-aware NR PC5 power efficiency for pedestrian UEs is specified in TS 23.287 as below:

• Overall description about support of QoS-aware NR PC5 power efficiency for pedestrian UEs regarding NR PC5 Discontinuous Reception (DRX) operations.
• PC5 DRX configuration, e.g. the mapping of PC5 QoS profile(s) to PC5 DRX cycle(s), default PC5 DRX configuration, for broadcast and groupcast when the UE is "not served by E-UTRA" and "not served by NR" as provisioned parameters for V2X communications over PC5 reference point.
• NR Tx Profile for broadcast and groupcast as provisioned parameters for V2X communications over PC5 reference point.

For NR-based unicast, groupcast and broadcast mode communication over PC5 reference point, PC5 DRX operations are supported to enable pedestrian UE power saving. The V2X layer determines the respective V2X service types, and derives the corresponding PC5 QoS parameters based on either the mapping of V2X service types to PC5 QoS parameters, or the V2X Application Requirements for the V2X service type provided by the application layer. The V2X layer passes the PC5 QoS parameters and destination Layer-2 ID to the AS layer. For broadcast and groupcast, the V2X layer also determines the NR Tx Profile for the respective V2X service type based on the mapping of V2X service types to NR Tx Profiles and provides the NR Tx Profile to the AS layer. When the PC5 DRX operation is needed, e.g. based on the NR Tx Profile in case of broadcast or groupcast, the AS layer determines the PC5 DRX parameter values for V2X communication over PC5 reference point, taking into account, e.g., PC5 QoS parameters and/or destination Layer-2 ID provided by the V2X layer. For unicast, two UEs may negotiate the PC5 DRX configuration in the AS layer, and the PC5 DRX parameter values can be configured per pair of source and destination Layer-2 IDs and per direction in the AS layer. For broadcast and groupcast when the UE is "not served by E-UTRA" and "not served by NR", the UE uses the provisioned PC5 DRX configuration for PC5 DRX operation. Based on the Stage 2 requirements to support NR PC5 DRX operations, Stage 3 normative works are specified in TS 24.587, TS 24.588 and TS 31.102.

Summary based on the input provided by Huawei in SP-220653. This is an enhancement to the features specified for the application layer support for V2X applications in TS 23.286. The enhancement features support advanced V2X services (e.g. Tele-Operated Driving, HD Maps) considering the existing stage 1 and stage 2 work within 3GPP related to V2X enhancements in TS 22.185, TS 22.186, TS 23.285 and TS 23.287, as well as V2X application requirements defined outside 3GPP (e.g. 5GAA, ETSI ITS, SAE). To support the enhancement features to support V2X applications, some enhancements to SEAL were specified using the eSEAL WI (see corresponding section). The following capabilities are added in the V2X Application Enabler (VAE) layer:

1. Assistance for V2V communication mode switching enables provisioning the V2X UE to apply V2V communication modes switching policies from the V2X application specific layer.
2. V2X service discovery across multiple V2X service providers enables the V2X UEs to discover V2X services from partner V2X service providers serving in different geographic areas.
3. Obtaining dynamic local service information by a V2X UE from a partner V2X service provider operating in the service area where the V2X UE is currently located.
4. Dynamic group information update considering the consent of the user to support V2X platooning.
5. Support for PC5 provisioning considering multi-operator scenario to enable V2V/V2I communications.
6. Support for HD map dynamic information enables the V2X application server (HD map server) to obtain dynamic object information (e.g. V2X UEs in certain proximity range as decided by the V2X application server). Such information supports HD map based automated driving or remote driving scenarios.
7. UE-to-UE Groupcast/Broadcast configuration and message delivery enables V2X application server to utilize the VAE layer entities (VAE server and VAE clients) to distribute UE-to-UE Groupcast/Broadcast policy configurations and also distribute the V2X messages as per the configured policies.
8. VAE layer supported V2X communication using local MBMS is enabled.
9. Session-oriented services supports the session management requirements of ToD applications where the ToD controller may reside in a UE or in the application server.
10. Service adaptation and extended QoS monitoring and reporting provides a simplified service requirements adaptation service towards the V2X application server by abstracting the details of 3GPP system interactions.

The following capabilities are enhanced in the VAE layer:

1. The VAE server's service API exposure is conformed to CAPIF framework.
2. File distribution is enabled with Local MBMS.
3. Network monitoring by the V2X UE is enhanced with 5GC analytics and RAT type.

The protocol aspects for the above capabilities are specified in TS 24.486. The openAPI specifications for the VAE server services (northbound APIs) exposed to V2X application specific servers over Vs reference point are specified in TS 29.486. To support the HD map dynamic information, the SEAL location management service is enhanced to enable tracking of a host vehicle and the nearby V2X UEs in the proximity range of the host vehicle and further obtaining dynamic information from the V2X UEs in proximity range of the host vehicle. For more details, please refer to eSEAL WI (see corresponding section). The feasibility study for enhancements to application layer support for V2X services is specified in TR 23.764.