Method and device for configuring sidelink discontinuous reception in a wireless communication system

Abstract

Method and apparatus for configuring sidelink discontinuous reception in a wireless communication system. The method includes a user equipment assuming or considering a sidelink discontinuous reception configuration applied to sidelink multicast communication associated with a group, where the sidelink discontinuous reception configuration includes at least one of an active duration timer length for determining an active duration at the start of each sidelink discontinuous reception period and / or a period length for determining the length of each sidelink discontinuous reception period; deriving or determining a start time of the active duration for each sidelink discontinuous reception period or a start time of each sidelink discontinuous reception period based on at least one identifier associated with the group; and transmitting sidelink control information associated with the group on a sidelink control channel in a period, where the period is determined based on the sidelink discontinuous reception configuration and the start time of the active duration or the start time of each sidelink discontinuous reception period.

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication networks, and more particularly, to a method and apparatus for configuring sidelink discontinuous reception in a wireless communication system. Background Art

[0002] With the rapid growth of the communication demand for a large amount of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks that communicate Internet Protocol (IP) data packets. Such IP data packet communication can provide IP-borne voice, multimedia, multicast, and on-demand communication services for users of mobile communication devices.

[0003] An exemplary network structure is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput to enable the above-mentioned IP-borne voice and multimedia services. Currently, the 3GPP standard organization is discussing next-generation (e.g., 5G) new radio technologies. Therefore, changes to the current body of the 3GPP standard are currently being submitted and considered to evolve and complete the 3GPP standard. Summary of the Invention

[0004] Disclosed is a method and apparatus for sidelink discontinuous reception (DRX) for a user equipment (UE) for sidelink multicast communication associated with a group. In one embodiment, the method includes the UE assuming or considering a sidelink DRX configuration applied to sidelink multicast communication associated with the group, where the sidelink DRX configuration includes at least one of an on-duration timer length for determining an on-duration at the start of each sidelink DRX cycle and / or a cycle length for determining the length of each sidelink DRX cycle. The method further includes the UE deriving or determining a start time of the on-duration for each sidelink DRX cycle or a start time of each sidelink DRX cycle based on at least one identifier associated with the group. The method further includes the UE transmitting sidelink control information associated with the group on a sidelink control channel in a cycle, where the cycle is determined based on the SL DRX configuration and the start time of the on-duration for each sidelink DRX cycle or the start time of each sidelink DRX cycle. Brief Description of the Drawings

[0005] Figure 1 A diagram showing a wireless communication system according to an exemplary embodiment.

[0006] Figure 2It is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an exemplary embodiment.

[0007] Figure 3 It is a functional block diagram of a communication system according to an exemplary embodiment.

[0008] Figure 4 It is according to an exemplary embodiment of Figure 3 the functional block diagram of the program code.

[0009] Figure 5 It is a reproduction of Figure 11-1 in 3GPP TS 38.300 V16.3.0.

[0010] Figure 6 It is a reproduction of Figure 5 .3.5.1 - 1 in 3GPP TS 38.331 V16.2.0.

[0011] Figure 7 It is a reproduction of Figure 5 .8.5.1 - 1 in 3GPP TS 38.331 V16.2.0.

[0012] Figure 8 It is a reproduction of Figure 5 .8.5.1 - 2 in 3GPP TS 38.331 V16.2.0.

[0013] Figure 9 It is a reproduction of Figure 5 .8.9.1.1 - 1 in 3GPP TS 38.331 V16.2.0.

[0014] Figure 10 It is a reproduction of Figure 6 .3.3.1 - 1 in 3GPP TS 23.287 V16.4.0.

[0015] Figure 11 It is a reproduction of Figure 6 .2.2 - 1 in 3GPP TS 23.776 V1.0.0.

[0016] Figure 12 It is a reproduction of Figure 6 .5.1 - 1 in 3GPP TS 73.776 V2.0.0.

[0017] Figure 13 It is a reproduction of Figure 6 .5.1 - 2 in 3GPP TS 73.776 V2.0.0.

[0018] Figure 14is a diagram according to an exemplary embodiment.

[0019] Figure 15 is a flowchart according to an exemplary embodiment.

[0020] Figure 16 is a flowchart according to an exemplary embodiment.

[0021] Figure 17 is a flowchart according to an exemplary embodiment.

[0022] Figure 18 is a flowchart according to an exemplary embodiment.

[0023] Figure 19 is a flowchart according to an exemplary embodiment.

[0024] Figure 20 is a flowchart according to an exemplary embodiment.

[0025] Figure 21 is a flowchart according to an exemplary embodiment.

[0026] Figure 22 is a flowchart according to an exemplary embodiment.

[0027] Figure 23 is a flowchart according to an exemplary embodiment.

[0028] Figure 24 is a flowchart according to an exemplary embodiment.

[0029] Figure 25 is a flowchart according to an exemplary embodiment.

[0030] Figure 26 is a flowchart according to an exemplary embodiment.

[0031] Figure 27 is a flowchart according to an exemplary embodiment.

[0032] Figure 28 is a flowchart according to an exemplary embodiment. Detailed implementation

[0033] The exemplary wireless communication systems and devices described below employ a wireless communication system that supports broadcast services. Wireless communication systems are widely deployed to provide various types of communications such as voice, data, etc. These systems can be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP Long Term Evolution (LTE) radio access, 3GPP Long Term Evolution Advanced (LTE-A or LTE-Advanced), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation techniques.

[0034] Specifically, the exemplary wireless communication systems and devices described below can be designed to support one or more standards, such as those provided by the consortium named "3rd Generation Partnership Project" and referred to herein as 3GPP, including: RP-193231, "New WID on NR Sidelink Enhancements", LG Electronics; TS 38.300 V16.3.0, "NR; Overall Description of NR and NG-RAN; Phase 2 (Release 16)"; TS 38.321 V16.2.1, "NR Medium Access Control (MAC) Protocol Specification (Release 16)"; TS 38.331 V16.2.0, "NR; Radio Resource Control (RRC) Protocol Specification (Release 16)"; TS 23.287 V16.4.0, "5G System (5GS) Architecture Enhancements for Supporting Vehicle-to-Everything (V2X) Services (Release 16)"; TR 23.776 V1.0.0, "Study on Architecture Enhancements for 3GPP Support of Advanced Vehicle-to-Everything (V2X) Services, Phase 2 (Release 17)"; and TR 23.776 V2.0.0, "Study on Architecture Enhancements for 3GPP Support of Advanced Vehicle-to-Everything (V2X) Services; Phase 2 (Release 17)". The standards and documents listed above are hereby expressly incorporated by reference in their entirety.

[0035] Figure 1A multi - access wireless communication system according to an embodiment of the present invention is shown. The access network 100 (AN) includes multiple antenna groups, one group includes 104 and 106, another group includes 108 and 110, and an additional group includes 112 and 114. In Figure 1 each, only two antennas are shown for each antenna group. However, each antenna group may utilize more or fewer antennas. The access terminal 116 (AT) communicates with antennas 112 and 114, where antennas 112 and 114 transmit information to the access terminal 116 on the forward link 120 and receive information from the access terminal 116 on the reverse link 118. The access terminal (AT) 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to the access terminal (AT) 122 on the forward link 126 and receive information from the access terminal (AT) 122 on the reverse link 124. In an FDD system, the communication links 118, 120, 124, and 126 may use different frequencies for communication. For example, the forward link 120 may use a frequency different from the frequency used by the reverse link 118.

[0036] Each antenna group and / or the area in which they are designed to communicate is often referred to as a sector of the access network. In an embodiment, each antenna group is designed to communicate with access terminals in a sector of the area covered by the access network 100.

[0037] In the communication on the forward links 120 and 126, the transmitting antennas of the access network 100 may utilize beamforming to improve the signal - to - noise ratio of the forward links for different access terminals 116 and 122. Additionally, compared to an access network that transmits to all its access terminals through a single antenna, an access network that uses beamforming to transmit to access terminals randomly dispersed in its coverage area causes less interference to the access terminals in adjacent cells.

[0038] The access network (AN) can be a fixed station or a base station for communicating with terminals and can also be referred to as an access point, Node B, base station, enhanced base station, evolved Node B (eNB), network node, network, or some other term. The access terminal (AT) can also be referred to as a user equipment (UE), wireless communication device, terminal, access terminal, or some other term.

[0039] Figure 2is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an access terminal (AT) or user equipment (UE)) in a MIMO system 200. At the transmitter system 210, traffic data for several data streams is provided from a data source 212 to a transmit (TX) data processor 214.

[0040] In one embodiment, each data stream is transmitted via a respective transmit antenna. The TX data processor 214 formats, codes, and interleaves the traffic data of the data stream based on a particular coding scheme selected for each data stream to provide coded data.

[0041] The coded data of each data stream can be multiplexed with pilot data using OFDM techniques. Pilot data is typically a known data pattern that is processed in a known manner and can be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream are then modulated (i.e., symbol mapped) based on a particular modulation scheme selected for the data stream (e.g., BPSK, QPSK, M-PSK, or M-QAM) to provide modulated symbols. The data rate, coding, and modulation for each data stream can be determined by instructions executed by a processor 230.

[0042] Then, the modulated symbols of all data streams are provided to a TX MIMO processor 220, which can further process the modulated symbols (e.g., for OFDM). The TX MIMO processor 220 then provides N T streams of modulated symbols to N T transmitters (TMTRs) 222a through 222t. In some embodiments, the TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antennas from which the symbols are being transmitted.

[0043] Each transmitter 222 receives and processes the corresponding symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide modulated signals suitable for transmission over the MIMO channel. Then, N T modulated signals from transmitters 222a through 222t are transmitted from N T antennas 224a through 224t.

[0044] At the receiver system 250, the transmitted modulated signals are received via N Rare received by antennas 252a through 252r, and the signals received from each antenna 252 are provided to corresponding receivers (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and down-converts) the corresponding received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

[0045] The RX data processor 260 then receives and processes N R received symbol streams from the N R receivers 254 based on specific receiver processing techniques to provide N T "detected" symbol streams. The RX data processor 260 then demodulates, de-interleaves, and decodes each detected symbol stream to recover the traffic data of the data stream. The processing performed by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and the TX data processor 214 at the transmitter system 210.

[0046] The processor 270 periodically determines which precoding matrix (discussed below) to use. The processor 270 formulates a reverse link message that includes a matrix index portion and a rank value portion.

[0047] The reverse link message may include various types of information about the communication link and / or the received data stream. The reverse link message is then processed by the TX data processor 238, which also receives several data streams of traffic data from the data source 236, modulated by the modulator 280, conditioned by the transmitters 254a through 254r, and transmitted back to the transmitter system 210.

[0048] At the transmitter system 210, the modulated signals from the receiver system 250 are received by the antenna 224, conditioned by the receiver 222, demodulated by the demodulator 240, and processed by the RX data processor 242 to extract the reverse link message transmitted by the receiver system 250. The processor 230 then determines which precoding matrix to use to determine the beamforming weights and then processes the extracted message.

[0049] Steering Figure 3 , this figure shows an alternative simplified functional block diagram of a communication device according to an embodiment of the present invention. As Figure 3 shown, the UE (or AT) 116 and 122 in Figure 1 or Figure 1The base station (or AN) 100 in, and the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 through the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by a user through the input device 302 (such as a keyboard or keypad), and can output images and sounds through the output device 304 (such as a monitor or speaker). The transceiver 314 is used to receive and transmit wireless signals, transfer the received signals to the control circuit 306, and wirelessly output the signals generated by the control circuit 306. The communication device 300 in the wireless communication system can also be used to implement Figure 1 the AN 100 in.

[0050] Figure 4 is a simplified block diagram of the program code 312 shown in accordance with an embodiment of the present invention in Figure 3 Here. In this embodiment, the program code 312 includes an application layer 400, a layer 3 part 402, and a layer 2 part 404, and is coupled to a layer 1 part 406. The layer 3 part 402 generally performs radio resource control. The layer 2 part 404 generally performs link control. The layer 1 part 406 generally performs physical connection.

[0051] 3GPP RP-193231 describes the following:

[0052] 3 code rate adaptation

[0053] Since LTE, 3GPP has been developing standards for sidelinks as a tool for UE-to-UE direct communication required in various use cases. The first standard for NR sidelinks will be completed in Rel-16 by the work item "5G V2X with NR sidelinks", where the solution for NR sidelinks is mainly specified for vehicle-to-everything (V2X), and when service requirements can be met, the solution can also be used for public safety.

[0054] Meanwhile, the necessity of NR sidelink enhancements has been recognized. For V2X and public safety, due to time constraints, the service requirements and operational scenarios cannot be fully supported in Rel-16, and the SA is making some enhancements to Rel-17, such as the architecture enhancements for 3GPP to support advanced V2X services - Phase 2 (FS_eV2XARC_Ph2) and the system enhancements for proximity-based services in 5GS (FS_5G_ProSe). Additionally, in the SAWG, other commercial use cases related to NR sidelinks are being considered through several work / study items, such as Network Controlled Interactive Service (NCIS), Railway Gap Analysis (MONASTERYEND), Relays for Energy eFficiency and Extensive Coverage (REFEC), and Audio-Visual Service Production (AVPROD). To provide a wider NR sidelink coverage for these use cases and be able to offer radio solutions according to the progress in the SAWG, it is necessary to specify the enhancements to NR sidelinks in the TSG RAN.

[0055] The TSG RAN initiated discussions in RAN#84 to identify the detailed motivations and areas of work for NR sidelink enhancements in Rel-17. Based on the latest synopsis in RP-192745, there was a strong interest observed in several motivations, including:

[0056] ● Energy savings enable battery-constrained UEs to perform sidelink operations in a power-efficient manner. The Rel-16 NR sidelink was designed based on the assumption of "always-on" when the UE operates the sidelink, e.g., focusing only on UEs installed in vehicles with sufficient battery capacity. For vulnerable road users (VRUs) in V2X use cases and UEs in public safety and commercial use cases where it is necessary to minimize the power consumption in the UE, energy-saving solutions in Rel-17 are required.

[0057] ● Enhanced reliability and reduced latency allow the support of URLLC-type sidelink use cases in a wider range of operational scenarios. Communication conditions such as the radio channel state and the offered load affect the system-level reliability and latency performance of the sidelink, and in some cases, e.g., when the channel is relatively busy, the Rel-16 NR sidelink is expected to be limited in achieving high reliability and low latency. To continuously provide use cases that require low latency and high reliability under such communication conditions, solutions that can enhance reliability and reduce latency are needed.

[0058] While several working areas were identified in the discussion, some important principles regarding the 3GPP evolution of NR sidelink were also discussed. When dealing with different use cases in NR sidelink evolution, the WG should strive to achieve maximum commonality between commercial V2X and critical communication uses of the sidelink to avoid duplicate solutions and maximize economies of scale. Additionally, the enhancements introduced in Rel-17 should be based on the functions specified in Rel-16, rather than re-designing the basic NR sidelink functions in Rel-17.

[0059] 4 Objectives

[0060] 4.1 Objectives of SI or Core Part WI or Test Part WI

[0061] The objective of this work item is to specify radio solutions that can enhance the NR sidelink for V2X, public safety, and commercial use cases.

[0062] 1. Update of sidelink evaluation method: Define the evaluation assumptions and performance metrics for energy savings by reusing TR 36.843 and / or TR 38.840 (to be completed by RAN#88) [RAN1]

[0063] ● Note: TR 37.885 is reused for other evaluation assumptions and performance metrics. For highway and urban grid scenarios, vehicle drop model B and antenna option 2 should be more realistic baselines.

[0064] 2. Enhancement of resource allocation:

[0065] ● Specify resource allocation to reduce the power consumption of the UE [RAN1, RAN2]

[0066] ■ The baseline is to introduce the principles of Rel-14 LTE sidelink random resource selection and partial sensing into the Rel-16 NR sidelink resource allocation mode 2.

[0067] ■ Note: Using Rel-14 as a baseline does not exclude introducing new solutions to reduce power consumption in cases where the baseline does not work properly.

[0068] ● Consider both PRR and PIR defined in TR37.885 (RAN#89), study the feasibility and benefits of enhancements for improving reliability and reducing latency in mode 2, and specify the identified solutions if considered feasible and beneficial [RAN1, RAN2]

[0069] ■ Coordinate between UEs in the following way until RAN#88 is run.

[0070] ◆Determine the resource set at UE-A. Send this set to UE-B in mode 2, and UE-B takes its own transmission into account when selecting resources.

[0071] ■Note: The scope of study after RAN#88 will be determined in RAN#88.

[0072] ■Note: The solution should be able to operate in in-coverage, partial-coverage, and out-of-coverage scenarios and be able to solve consecutive packet losses in all coverage scenarios.

[0073] ■Note: RAN2 work will start after RAN#89.

[0074] 3. Sidelink DRX for broadcast, multicast, and unicast [RAN2]

[0075] ●Define the on and off durations in the sidelink and specify the corresponding UE procedures

[0076] ●Specify mechanisms to align the sidelink DRX wake-up times between UEs communicating with each other ●Specify mechanisms to align the sidelink DRX wake-up time with the Uu DRX wake-up time of in-coverage UEs

[0077] 4. Support for new sidelink frequency bands for single-carrier operation [RAN4]

[0078] ●Support for new sidelink frequency bands should ensure coexistence between sidelinks and the Uu interface in the same and adjacent channels in the authorized spectrum.

[0079] ●Determine the exact frequency bands based on company inputs during the WI, taking into account both authorized and ITS-specific spectra in both FR1 and FR2.

[0080] 5. Define a mechanism to ensure that sidelink operations can be restricted to a predefined geographical area within a given frequency range in non-ITS frequency bands [RAN2].

[0081] ●This applies to areas where there is no network coverage.

[0082] 6. UE Tx and Rx RF requirements for new features introduced in this WI [RAN4]

[0083] 7. UE RRM core requirements for new features introduced in this WI [RAN4]

[0084] The enhancements introduced in Rel-17 should be based on the functions specified in Rel-16, and Rel-17 sidelinks should be able to coexist with Rel-16 sidelinks in the same resource pool. This does not exclude the possibility of operating Rel-17 sidelinks in dedicated resource pools.

[0085] The solution should cover the operation scenarios where the carrier is dedicated to ITS, as well as the operation scenarios where the carrier is licensed spectrum and is also used for NR Uu / LTE Uu operations.

[0086] The solution should support network control of NR side-links as in Rel-16, i.e., NR Uu uses layer 1 and layer 2 signaling to control NR side-links, while LTE Uu uses layer 2 signaling to control NR side-links.

[0087] In the ITS carrier, it is assumed that 3GPP will not define any co-channel coexistence requirements and mechanisms for NR side-links with non-3GPP technologies.

[0088] 3GPP TS 38.300 introduces the concept of discontinuous reception as follows:

[0089] 11 UE power saving

[0090] Monitoring of active PDCCHs for a UE in RRC connected mode is governed by DRX, BA, and DCP.

[0091] When DRX is configured, the UE does not have to continuously monitor the PDCCH. DRX is characterized by the following:

[0092] - On-duration: The duration for which the UE waits to receive the PDCCH after waking up. If the UE successfully decodes the PDCCH, the UE remains awake and starts the inactivity timer;

[0093] - Inactivity timer: The duration for which the UE waits to successfully decode the PDCCH since the last successful decoding of the PDCCH. If it fails, the UE can return to the sleep state. The UE should restart the inactivity timer only after a single successful decoding of the PDCCH for the first transmission (i.e., not for retransmission);

[0094] - Retransmission timer: The duration until a retransmission can be expected;

[0095] - Period: Specifies the periodic repetition of the on-duration followed by a possible inactivity period (see below Figure 11-1 );

[0096] - Active time: The total duration for which the UE monitors the PDCCH. This includes the "on-duration" of the DRX cycle, the time when the UE is performing continuous reception while the inactivity timer has not expired, and the time when the UE is performing continuous reception while waiting for a retransmission opportunity.

[0097] [The section titled "DRX cycle" in 3GPP TS 38.300 V16.3.0 is reproduced as Figure 11-1 followsFigure 5

[0098] 3GPP TS 38.321 specifies the operation of discontinuous reception as follows:

[0099] 5.7 Discontinuous reception (DRX)

[0100] The MAC entity can be configured by RRC with DRX functionality that controls the UE's PDCCH to monitor the activities of the MAC entity's C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, and AI-RNTI. When using DRX operation, the MAC entity shall also monitor the PDCCH according to the requirements present in other clauses of this specification. When in RRC_CONNECTED, if DRX is configured, then for all active serving cells, the MAC entity can use the DRX operation specified in this section to discontinuously monitor the PDCCH; otherwise, the MAC entity shall monitor the PDCCH as specified in TS 38.213 [6].

[0101] Note 1: If sidelink resource allocation mode 1 is configured by RRC, then DRX functionality is not configured.

[0102] RRC controls the DRX operation by configuring the following parameters:

[0103] - drx-onDurationTimer: The duration at the start of the DRX cycle;

[0104] - drx-SlotOffset: The delay before starting drx-onDurationTimer;

[0105] - drx-InactivityTimer: The duration after the PDCCH occasion that indicates a new UL or DL transmission to the MAC entity;

[0106] - drx-RetransmissionTimerDL (per DL HARQ process, except for the broadcast process): The maximum duration until a DL retransmission is received;

[0107] - drx-RetransmissionTimerUL (per UL HARQ process): The maximum duration until a grant for a UL retransmission is received;

[0108] ​-drx-LongCycleStartOffset: The long DRX cycle and the drx-StartOffset of the subframes that define the start of the long and short DRX cycles;

[0109] -drx-ShortCycle (optional): The short DRX cycle;

[0110] -drx-ShortCycleTimer (optional): The duration for which the UE will follow the short DRX cycle;

[0111] -drx-HARQ-RTT-TimerDL (for each DL HARQ process, except for the broadcast process): The minimum duration before the MAC entity expects a DL assignment for a HARQ retransmission;

[0112] -drx-HARQ-RTT-TimerUL (for each UL HARQ process): The minimum duration before the MAC entity expects a grant for a UL HARQ retransmission;

[0113] -ps-Wakeup (optional): Configuration to start the associated drx-onDurationTimer when listening but not detecting a DCP;

[0114] -ps-TransmitOtherPeriodicCSI (optional): Configuration to report periodic CSI other than L1-RSRP on the PUCCH during the duration indicated by the drx-onDurationTimer when a DCP is configured but the associated drx-onDurationTimer is not started;

[0115] -ps-TransmitPeriodicL1-RSRP (optional): Configuration to transmit periodic CSI for L1-RSRP on the PUCCH during the duration indicated by the drx-onDurationTimer when a DCP is configured but the associated drx-onDurationTimer is not started.

[0116] The serving cell of the MAC entity can be configured by RRC in two DRX groups with separate DRX parameters. When the secondary DRX group is not configured by RRC, there is only one DRX group and all serving cells belong to the one DRX group. When two DRX groups are configured, each serving cell is uniquely assigned to either of the two groups. The DRX parameters configured separately for each DRX group are: drx-onDurationTimer, drx-InactivityTimer. The DRX parameters common to the DRX groups are: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL and drx-HARQ-RTT-TimerUL.

[0117] When the DRX cycle is configured, the active time for the serving cells in a DRX group includes the time at the following times:

[0118] - The drx-onDurationTimer or drx-InactivityTimer configured for the DRX group is running; or

[0119] - The drx-RetransmissionTimerDL or drx-RetransmissionTimerUL is running on any serving cell in the DRX group; or

[0120] - The ra-ContentionResolutionTimer (as described in Clause 5.1.5) or msgB-ResponseWindow (as described in Clause 5.1.4a) is running; or

[0121] - A scheduling request is sent on the PUCCH and is pending (as described in Clause 5.4.4); or

[0122] - After successful reception of a random access response for a random access preamble not selected by the MAC entity among the contention-based random access preambles, no new transmission PDCCH indicating the C-RNTI addressed to the MAC entity is received (as described in Clauses 5.1.4 and 5.1.4a).

[0123] When DRX is configured, the MAC entity will:

[0124] 1> If a MAC PDU is received in a configured downlink assignment, then:

[0125] 2> Start the drx-HARQ-RTT-TimerDL of the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;

[0126] 2> Stop the drx-RetransmissionTimerDL of the corresponding HARQ process.

[0127] 1> If a MAC PDU is transmitted in a configured uplink grant and no LBT failure indication is received from the lower layer, then:

[0128] 2> Start the drx-HARQ-RTT-TimerUL of the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;

[0129] 2> Stop the drx-RetransmissionTimerUL of the corresponding HARQ process.

[0130] 1> If the drx-HARQ-RTT-TimerDL expires, then:

[0131] 2> If the data of the corresponding HARQ process is not successfully decoded, then:

[0132] 3> Start the drx-RetransmissionTimerDL of the corresponding HARQ process in the first symbol after the drx-HARQ-RTT-TimerDL expires.

[0133] 1> If the drx-HARQ-RTT-TimerUL expires, then:

[0134] 2> Start the drx-RetransmissionTimerUL of the corresponding HARQ process in the first symbol after the drx-HARQ-RTT-TimerUL expires.

[0135] 1> If a DRX command MAC CE or a long DRX command MAC CE is received, then:

[0136] 2> Stop the drx-onDurationTimer for each DRX group;

[0137] 2> Stop the drx-InactivityTimer for each DRX group.

[0138] 1> If the drx-InactivityTimer for a DRX group expires, then:

[0139] 2> If a short DRX cycle is configured, then:

[0140] 3> Start or restart the drx-ShortCycleTimer for this DRX group in the first symbol after the drx-InactivityTimer expires;

[0141] 3> Use the short DRX cycle for this DRX group.

[0142] 2> Otherwise:

[0143] 3> Use the long DRX cycle for this DRX group.

[0144] 1> If a DRX command MAC CE is received, then:

[0145] 2> If a short DRX cycle is configured, then:

[0146] 3> Start or restart the drx-ShortCycleTimer for each DRX group in the first symbol after the end of the reception of the DRX command MAC CE;

[0147] 3> Use the short DRX cycle for each DRX group.

[0148] 2> Otherwise:

[0149] 3> Use the long DRX cycle for each DRX group.

[0150] 1> If the drx-ShortCycleTimer for a DRX group expires, then:

[0151] 2> Use the long DRX cycle for this DRX group.

[0152] 1> If a long DRX command MAC CE is received, then:

[0153] 2> Stop the drx-ShortCycleTimer for each DRX group;

[0154] 2> Use the long DRX cycle for each DRX group.

[0155] 1> If the short DRX cycle is used for a DRX group and [(SFN × 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle), then:

[0156] 2> Start the drx-onDurationTimer for this DRX group after drx-SlotOffset from the start of the subframe.

[0157] 1> If a long DRX cycle is used for the DRX group and [(SFN × 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset, then:

[0158] 2> If DCP monitoring is configured for the active DL BWP as specified in clause 10.3 of TS 38.213 [6]:

[0159] 3> If a DCP indication that starts the drx-onDurationTimer associated with the current DRX cycle is received from a lower layer, as specified in TS 38.213 [6]; or

[0160] 3> If, as specified in TS 38.213 [6], all DCP occasions in the time domain associated with the current DRX cycle occur during the active time, considering 4 ms before the start of the last DCP occasion, or within the BWP switching interruption length, or during a measurement gap, or when the MAC entity listens for PDCCH transmissions on the search space indicated by the recoverySearchSpaceId of the SpCell identified by the C-RNTI when the ra-ResponseWindow is in operation and the grants / assignments / DRX command MAC CE / long DRX command MAC CE and the transmitted scheduling request (as specified in clause 5.1.4) are received; or

[0161] 3> If ps-Wakeup is configured with the value true and no DCP indication associated with the current DRX cycle is received from a lower layer, then:

[0162] 4> Start the drx-onDurationTimer after drx-SlotOffset from the start of the subframe.

[0163] 2> Otherwise:

[0164] 3> Start the drx-onDurationTimer for this DRX group after drx-SlotOffset from the start of the subframe.

[0165] Note 2: In the case of misaligned SFNs across carriers in a cell group, the SFN of the SpCell is used to calculate the DRX duration.

[0166] 1> If the DRX group is in the active time, then:

[0167] 2>Monitor the PDCCH on the serving cell in this DRX group as specified in TS 38.213 [6];

[0168] 2>If the PDCCH indicates a DL transmission, then:

[0169] 3>Start the drx-HARQ-RTT-TimerDL of the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;

[0170] Note 3: When the PDSCH-to-HARQ_feedback timing indicates a non-numerical k1 value as specified in TS38.213 [6], the corresponding transmission opportunity for sending the DL HARQ feedback is indicated in a later PDCCH that requests HARQ-ACK feedback.

[0171] 3>Stop the drx-RetransmissionTimerDL of the corresponding HARQ process.

[0172] 3>If the PDSCH-to-HARQ_feedback timing indicates a non-numerical k1 value as specified in TS38.213 [6], then:

[0173] 4>Start the drx-RetransmissionTimerDL in the first symbol after the PDSCH transmission for the corresponding HARQ process.

[0174] 2>If the PDCCH indicates a UL transmission, then:

[0175] 3>Start the drx-HARQ-RTT-TimerUL of the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;

[0176] 3>Stop the drx-RetransmissionTimerUL of the corresponding HARQ process.

[0177] 2>If the PDCCH indicates a new transmission (DL or UL) on the serving cell in this DRX group, then:

[0178] 3>Start or restart the drx-InactivityTimer for this DRX group in the first symbol after the end of the PDCCH reception.

[0179] 2>If a HARQ process receives downlink feedback information and indicates an acknowledgement, then:

[0180] 3>Stop the drx-RetransmissionTimerUL for the corresponding HARQ process.

[0181] 1>If DCP monitoring is configured for the active DL BWP as specified in clause 10.3 of TS 38.213 [6], then:

[0182] 1>If the current symbol n occurs within the drx-onDurationTimer duration; and

[0183] 1>If the drx-onDurationTimer associated with the current DRX cycle has not been started as specified in this clause, then:

[0184] 2>If, when evaluating all DRX active time conditions specified in this clause, taking into account the grants / assignments / DRX command MAC CE / long DRX command MAC CE received 4 ms before symbol n and the transmitted scheduling requests, the MAC entity would not be in an active time, then:

[0185] 3>Do not transmit the periodic SRS and semi-persistent SRS defined in TS 38.214 [7];

[0186] 3>Do not report semi-persistent CSI configured on the PUSCH;

[0187] 3>If ps-TransmitPeriodicL1-RSRP is not configured to have the value true, then:

[0188] 4>Do not report periodic CSI as L1-RSRP on the PUCCH.

[0189] 3>If ps-TransmitOtherPeriodicCSI is not configured to have the value true, then:

[0190] 4>Do not report periodic CSI that is not L1-RSRP on the PUCCH.

[0191] 1>Otherwise:

[0192] 2>In the current symbol n, if, when evaluating all DRX active time conditions specified in this clause, taking into account the grants / assignments and DRX command MACCE / long DRX command MAC CE scheduled on the serving cell in this DRX group received 4 ms before symbol n and the transmitted scheduling requests, the DRX group would not be in an active time, then:

[0193] 3>Do not transmit the periodic SRS and semi-persistent SRS defined in TS 38.214 [7] in this DRX group;

[0194] 3>Do not report CSI on PUCCH and semi-persistent CSI configured on PUSCH in this DRX group.

[0195] 2>If the CSI mask (csi-Mask) is set by the upper layer, then:

[0196] 3>In the current symbol n, if when evaluating all DRX active time conditions specified in this clause, considering the grants / assignments and DRX command MAC CE / long DRX command MAC CE scheduled on the serving cell in this DRX group received 4 ms before symbol n, the drx-onDurationTimer of the DRX group will not be running; and

[0197] 4>Do not report CSI on PUCCH in this DRX group.

[0198] Note 4: If the UE multiplexes CSI configured on PUCCH with other overlapping UCI according to the procedure specified in clause 9.2.5 of TS 38.213 [6], and this CSI multiplexed with other UCI will be reported on a PUCCH resource outside the DRX active time of the DRX group in which this PUCCH is configured, then whether to report this CSI multiplexed with other UCI depends on the UE implementation.

[0199] Regardless of whether the MAC entity monitors the PDCCH on the serving cell in the DRX group, the MAC entity shall transmit HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS 38.214 [7] on the serving cell in the DRX group when expecting such a situation.

[0200] If the PDCCH occasion is incomplete (e.g., the active time starts or ends in the middle of the PDCCH occasion), then the MAC entity does not need to monitor the PDCCH.

[0201] 3GPP TS 38.331 specifies the configuration of discontinuous reception as follows:

[0202] 5.3.5 RRC Reconfiguration

[0203] 5.3.5.1 General Provisions

[0204] [The title of 3GPP TS 38.331 V16.2.0 is "RRC Reconfiguration, Successful" Figure 5 .3.5.1-1 is reproduced as Figure 6

[0205] […]

[0206] ​The purpose of this procedure is to modify the RRC connection, for example, establish / modify / release RBs, perform reconfiguration using synchronous execution, set / modify / release measurement values, add / modify / release SCell and cell groups. As part of the procedure, NAS dedicated information can be transferred from the network to the UE.

[0207] […]

[0208] 5.8.5 Sidelink synchronization information transfer for NR sidelink communication

[0209] 5.8.5.1 General principles

[0210] [The content with the title of "Synchronization information transfer for NR sidelink communication in (partial) coverage" in 3GPP TS 38.331 V16.2.0 Figure 5 .8.5.1-1 is reproduced as Figure 7

[0211] [The content with the title of "Synchronization information transfer for NR sidelink communication outside coverage" in 3GPP TS 38.331 V16.2.0 Figure 5 .8.5.1-2 is reproduced as Figure 8

[0212] The purpose of this procedure is to provide synchronization information to the UE.

[0213] […]

[0214] 5.8.9 Sidelink RRC procedures

[0215] 5.8.9.1 Sidelink RRC reconfiguration

[0216] 5.8.9.1.1 General principles

[0217] [The content with the title of "Sidelink RRC reconfiguration, successful" in 3GPP TS 38.331 V16.2.0 Figure 5 .8.9.1.1-1 is reproduced as Figure 9

[0218] […]

[0219] The purpose of this procedure is to modify the PC5-RRC connection, for example, establish / modify / release sidelink DRBs, configure NR sidelink measurements and reporting, configure sidelink CSI reference signal resources and CSI reporting latency bounds.

[0220] In the following cases, the UE may initiate the sidelink RRC reconfiguration procedure and perform the operations in subsection 5.8.9.1.2 on the corresponding PC5-RRC connection:

[0221] ​​​- Release of the sidelink DRB associated with the peer UE, as specified in Subclause 5.8.9.1a.1;

[0222] - Establishment of the sidelink DRB associated with the peer UE, as specified in Subclause 5.8.9.1a.2;

[0223] - Modification of the parameters included in the SLRB-Config of the sidelink DRB associated with the peer UE, as specified in Subclause 5.8.9.1a.2;

[0224] - Configuration of the peer UE for performing NR sidelink measurements and reporting.

[0225] - Configuration of sidelink CSI reference signal resources and CSI reporting latency bounds.

[0226] In RRC_CONNECTED, the UE applies the NR sidelink communication parameters provided in RRCReconfiguration (if present). In RRC_IDLE or RRC_INACTIVE, the UE applies the NR sidelink communication parameters provided in the system information (if present). For other cases, the UE applies the NR sidelink communication parameters provided in SidelinkPreconfigNR (if present). When the UE performs a state transition between the above three cases, after obtaining the new configuration, the UE applies the NR sidelink communication parameters provided in the new state. Before obtaining the new configuration, the UE continues to apply the NR sidelink communication parameters provided in the old state.

[0227] […]

[0228] 6.3.2 Radio Resource Control Information Elements

[0229] […]

[0230] - DRX-Config

[0231] IEDRX-Config is used to configure DRX-related parameters.

[0232] DRX-Config Information Element

[0233]

[0234]

[0235]

[0236]

[0237]

[0238] […]

[0239] 3GPP TS 23.287 introduces the following:

[0240] 6.3.3 Unicast mode V2X communication via the PC5 reference point

[0241] 6.3.3.1 Layer 2 link establishment via the PC5 reference point

[0242] To perform unicast mode V2X communication via the PC5 reference point, the UE is configured with the relevant information as described in Clause 5.1.2.1.

[0243] Figure 6 .3.3.1-1 shows the layer 2 link establishment procedure for the unicast mode of V2X communication via the PC5 reference point.

[0244] [The title of 3GPP TS 23.287 V16.4.0 is "Layer 2 Link Establishment Procedures" Figure 6 .3.3.1-1 is reproduced as Figure 10

[0245] 1. As specified in Clause 5.6.1.4, the UE determines the destination layer 2 ID for signaling reception for PC5 unicast link establishment. The destination layer 2 ID is configured with the UE as specified in Clause 5.1.2.1.

[0246] 2. The V2X application layer in UE-1 provides application information for PC5 unicast communication. The application information includes the V2X service type and the application layer ID of the originating UE. The application layer ID of the target UE may be included in the application information.

[0247] The V2X application layer in UE-1 may provide V2X application requirements for this unicast communication. As specified in Clause 5.4.1.4, UE-1 determines the PC5 QoS parameters and PFI.

[0248] If UE-1 decides to reuse an existing PC5 unicast link as specified in Clause 5.2.1.4, then UE initiates a layer 2 link modification procedure as specified in Clause 6.3.3.4.

[0249] 3. UE-1 sends a direct communication request message to initiate the unicast layer 2 link establishment procedure. The direct communication request message includes:

[0250] - Source user information: the application layer ID of the originating UE (i.e., the application layer ID of UE-1).

[0251] - If the V2X application layer provides the application layer ID of the target UE in step 2, then it includes the following information:​

[0252] - Target user information: The application layer ID of the target UE (i.e., the application layer ID of UE-2).

[0253] - V2X service information: Information about the type of V2X service for which a layer 2 link establishment is requested.

[0254] - Security information: Information used to establish security.

[0255] Note 1: Security information and the necessary protection of source and target user information are defined in TS 33.536

[26] .

[0256] As specified in Sections 5.6.1.1 and 5.6.1.4, determine the source layer 2 ID and the destination layer 2 ID for sending the direct communication request message. The destination layer 2 ID can be a broadcast or unicast layer 2 ID. When using a unicast layer 2 ID, the target user information shall be included in the direct communication request message.

[0257] UE-1 sends the direct communication request message via PC5 broadcast or unicast using the source layer 2 ID and the destination layer 2 ID.

[0258] 4. Establish the security of UE-1 as follows:

[0259] 4a. If the target user information is included in the direct communication request message, the target UE (i.e., UE-2) responds by establishing security with UE-1.

[0260] 4b. If the target user information is not included in the direct communication request message, the UE that is interested in the notified type of V2X service via the PC5 unicast link with UE-1 responds by establishing security with UE-1.

[0261] Note 2: The signaling for the security procedures is defined in TS 33.536

[26] .

[0262] When security protection is enabled, UE-1 sends the following information to the target UE:

[0263] - If IP communication is used, then:

[0264] - IP address configuration: For IP communication, this link requires IP address configuration and it indicates one of the following values:

[0265] - "IPv6 router", if only the IPv6 address allocation mechanism is supported by the initiating UE, i.e., acting as an IPv6 router; or

[0266] - "IPv6 address allocation not supported", if the IPv6 address allocation mechanism is not supported by the initiating UE.

[0267] - Link-local IPv6 address: A link-local IPv6 address formed locally based on RFC 4862

[21] , if UE-1 does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration indicates "does not support IPv6 address allocation".

[0268] - QoS information: Information about the PC5 QoS flow to be added. For each PC5 QoS flow, PFI, the corresponding PC5 QoS parameters (i.e., PQI and optionally other parameters such as MFBR / GFBR, etc.), and the associated V2X service type.

[0269] As specified in Clauses 5.6.1.1 and 5.6.1.4, determine the source layer 2 ID for the security establishment procedure. The destination layer 2 ID is set to the source layer 2 ID of the received direct communication request message.

[0270] Once the security establishment procedure message is received, UE-1 obtains the layer 2 ID of the peer UE for signaling and data traffic for this unicast link for future communication.

[0271] 5. The target UE that has successfully established security with UE-1 sends a direct communication acceptance message to UE-1:

[0272] 5a. (Layer 2 link establishment for UE-oriented) If the direct communication request message contains target user information, then in the case of a match of the application layer ID for UE-2, the target UE, i.e., UE-2 responds with a direct communication acceptance message.

[0273] 5b. (Layer 2 link establishment for V2X service-oriented) If the direct communication request message does not contain target user information, the UE interested in the notified V2X service responds to the request by sending a direct communication acceptance message (for UE-2 and UE-4 in Figure 6 .3.3.1-1).

[0274] The direct communication acceptance message contains:

[0275] - Source user information: The application layer ID of the UE sending the direct communication acceptance message.

[0276] - QoS information: Information about the PC5 QoS flow requested by UE-1. For each PC5 QoS flow, PFI, the corresponding PC5 QoS parameters (i.e., PQI and optionally other parameters such as MFBR / GFBR, etc.), and the associated V2X service type.

[0277] - If using IP communication, then:

[0278] - IP address configuration: For IP communication, this link requires IP address configuration and indicates one of the following values:

[0279] - "IPv6 Router", acting as an IPv6 router if the IPv6 address allocation mechanism is supported by the target UE; or

[0280] - "IPv6 Address Allocation Not Supported", if the IPv6 address allocation mechanism is not supported by the target UE.

[0281] - Link-local IPv6 address: A link-local IPv6 address formed locally based on RFC 4862

[21] if the target UE does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration indicates "IPv6 Address Allocation Not Supported", and UE-1 includes the link-local IPv6 address in the direct communication request message. The target UE shall include a non-conflicting link-local IPv6 address.

[0282] If two UEs (i.e., the initiating UE and the target UE) are selected to use the link-local IPv6 address, they will deactivate the duplicate address detection defined in RFC 4862

[21] .

[0283] Note 3: When the initiating UE or the target UE indicates support for an IPv6 router, the corresponding address configuration procedure will be performed after the layer 2 link is established, and the link-local IPv6 address will be ignored.

[0284] The V2X layer of the UE that establishes the PC5 unicast link will pass the PC5 link identifier assigned to the unicast link and the information related to the PC5 unicast link down to the AS layer. The information related to the PC5 unicast link includes layer 2 ID information (i.e., the source layer 2 ID and the destination layer 2 ID) and the corresponding PC5 QoS parameters. This enables the AS layer to maintain the PC5 link identifier and the information related to the PC5 unicast link.

[0285] 6. Transmit V2X service data through the established unicast link as follows:

[0286] Provide the PC5 link identifier, the PFI, and the V2X service data to the AS layer.

[0287] Optionally, in addition, provide the layer 2 ID information (i.e., the source layer 2 ID and the destination layer 2 ID) to the AS layer.

[0288] Note 4: The UE implementation provides the layer 2 ID information to the AS layer.

[0289] UE-1 sends V2X service data using the source layer 2 ID (i.e., the layer 2 ID of UE-1 for this unicast link) and the destination layer 2 ID (i.e., the layer 2 ID of the peer UE for this unicast link).

[0290] Note 5: The PC5 unicast link is bi-directional, so the peer UE of UE-1 can send V2X service data to UE-1 via the unicast link with UE-1.

[0291] 3GPP TR 23.776 V1.0.0 introduces the following:

[0292] 6.2 Solution #2: PC5 DRX Configuration for QoS-Aware and Power-Efficient Communication for Pedestrian UEs

[0293] 6.2.1 Functional Description

[0294] This solution is for "Key Issue #1: Support for QoS-Aware NR PC5 Power Efficiency for Pedestrian UEs".

[0295] In road safety and public safety use cases, pedestrian UEs typically participate in PC5 multicast or broadcast communication in a connectionless manner. A pedestrian UE may need to listen to various nearby PC5 Tx UEs without prior knowledge of the Tx UE. Therefore, possible DRX operations for PC5 Rx UEs need to handle various and random Tx UEs present nearby. On the other hand, a PC5 Tx UE may not know or care about the presence of any particular Rx UE nearby. This makes per-pair PC5 DRX operations specific to PC5 Tx UEs and Rx UEs rather impractical, especially for PC5 multicast and broadcast.

[0296] In the case of connection-oriented PC5 unicast, DRX operations specific to a pair of Tx UE and Rx UE on PC5 can be pre-agreed between the Rx UE and the Tx UE. However, if, in addition to the PC5 unicast under discussion, the PC5 unicast Tx UE or Rx UE also has other PC5 unicast / multicast / broadcast communication services with the same or different peer UEs, then uncoordinated PC5 DRX configurations for each PC5 unicast communication may result in misaligned PC5 DRX patterns. This makes PC5 DRX generally less efficient in terms of energy saving.

[0297] To coordinate the PC5 DRX configuration not only between the peer PC5 Tx UE and Rx UE for a single SL application / service, but also between several PC5 UEs involved in nearby multiple PC5 communications, this solution is based on a set of common PC5 DRX modes configured in the PC5 UEs by the serving network for in-coverage operation or pre-configured for out-of-coverage operation. The PC5 DRX mode contains information about the on / off cycles to be used in the (AS layer) PC5 DRX scheduling, and each PC5 DRX mode can be associated with one or more V2X service types. It should be noted that there may be PC5 DRX modes that will quite match the combination of service types. Therefore, the (pre-)configured set of PC5 DRX modes can correspond to the combination of different use cases, service profiles, states or classes of the supported PC5 UEs. The (pre-)configured set of PC5 DRX modes can also be consistent with the resource pool configuration, since when the resource pool is configured, the modes can be known to the AS layer (or vice versa), such that the V2X layer does not need to process or understand the resource pool configuration. However, the resource pool configuration does not need to be performed in a way that guarantees dedicated radio resources for a specific V2X service type.

[0298] The content of the set of PC5 DRX modes (e.g., the length and period of the on / off cycle) can take into account the QoS requirements of the V2X service type, such as the pre-configured PC5 QoS parameters configured in the UE for each V2X service type, as described in clause 5.4.2.5 of TS 23.287 [5]. The fact that the QoS for a specific V2X service can be different on different UEs can be compensated for by the PC5 DRX scheduling selection and enforcement procedures that occur on the UE (see clause 6.2.2).

[0299] In this way, extensive coordination for determining and agreeing on the PC5 DRX mode between neighboring related PC5 UEs can be avoided. The related PC5 UEs only need to select one or more PC5 DRX modes from the limited set of the configured PC5 DRX modes, and adapt the SL transmissions and receptions to the selected modes of its own and other nearby PC5 UEs.

[0300] The PC5 DRX mode should only be activated when a matching PC5 DRX mode for the V2X service running on the UE is found. In addition, the V2X layer can enable the application layer to request the deactivation of the PC5 DRX mode. When and why the V2X application can request the deactivation of the PC5 DRX mode depends on the implementation of the V2X application and is outside the scope of the V2X layer.

[0301] Note: The solution applies to the management of a single AS layer DRX scheduling on the UE, which applies to all communication modes and all V2X services. In the case where the UE can have multiple different active DRX schedulings simultaneously (e.g., for broadcast and unicast), then the whole process can be applied separately and independently to each DRX scheduling, i.e., there are different sets of modes for each scheduling, etc. Since the goal of the DRX mode is to receive the P-UE, the transmission scheduling of the transmitting UE may need to be aligned with the DRX scheduling of the receiving UE.

[0302] Editor's note: The issue of having a single or two separate DRX schedulings for Uu and PC5 and any alignment between them (if required) remains open in the RAN WG as well.

[0303] 6.2.2 Procedures

[0304] Figure 6 .2.2-1 shows an example operation of a solution for power-efficient PC5 communication for a pedestrian UE based on a predefined PC5 DRX mode.

[0305] [The title of 3GPP TS 23.776 V1.0.0 is "PC5 DRX Configuration Procedures for QoS-Aware and Power-Efficient Communication for Pedestrian UEs" Figure 6 .2.2-1 is reproduced as Figure 11

[0306] 1a. The UE is (pre-)configured with PC5 DRX-related parameters, including the set of applicable PC5 DRX modes from which the UE can select. The PC5 DRX configuration can be provided by the PCF (or by the AF via the NEF / PCF) using the procedures specified in clause 6.2 of TS 23.287 [5], or pre-configured as specified in clause 5.1.1 of TS 23.287 [5].

[0307] 1b. If the UE is "served by NR" (as defined in TS 23.287 [5]), then the PC5 DRX configuration can alternatively be provided by the NG-RAN via broadcast or dedicated RRC signaling, potentially together with information about the Uu configuration. In this option, the AS layer can indicate the relevant configured PC5 DRX parameters to the V2X layer or apply the PC5 DRX configuration on the AS layer (also see the description of step 5).

[0308] Editor's note: It is up to the RAN WG to decide whether and how the NG-RAN provides the PC5 DRX configuration to the UE.

[0309] ​2. The V2X application layer provides application requirements to the V2X layer, which can be mapped to QoS parameters defined in clause 5.4.1.1 of TS 23.287 [5]. The V2X application layer can also provide application service mode information, which contains message periodicity / interval and message size / burst information (if available).

[0310] Note 1: The mentioned application service mode information can also be provided by the V2X application (via the V2X layer) to the AS layer, where they can be used as input when calculating the AS layer SL-TrafficPatternInfo (defined in TS 38.331 [9]), which in turn can have an impact on the final decision of the AS layer regarding the PC5 DRX configuration to be applied. In addition to message periodicity and message size, the AS layer SL-TrafficPatternInfo also contains more RAN-related parameters.

[0311] Editor's note: Whether and when to provide the application service mode information from the V2X layer to the AS layer needs to be coordinated with RANWG.

[0312] 3. The V2X layer of UE1 can select one or more PC5 DRX modes from the configured set of PC5 DRX modes. If more than one PC5 DRX mode is selected, this means that the V2X layer can accept any one of them for application. The selection takes into account the following: i) the requirements and application service mode information of all active V2X service types that UE1 currently has, ii) the Uu DRX configuration received by the NG-RAN (if any), and iii) the selected PC5 DRX modes applied and indicated by other relevant UEs.

[0313] Note 2: For example, after the expiration of a timer, after a change in V2X application requirements or DRX-related information about other UEs as defined in TS 23.287 [5], or in a similar situation, the trigger for selecting the PC5 DRX mode at the V2X layer depends on the implementation. The V2X layer does not consider the potential PC5 DRX negotiation performed in the context of a single unicast connection at this step, but during the AS layer decision to accept the V2X layer request for a PC5 DRX mode (step 5) or during the V2X layer independent decision to modify the applied PC5 DRX scheduling or apply a new one at the AS layer (see step 6).

[0314] 4. The V2X layer of UE1 requests to apply the selected PC5 DRX mode (one of them) to the AS layer for controlling PC5 transmission and reception according to the selected PC5 DRX mode.

[0315] 5. The AS layer of UE1 decides to apply or not apply the requested PC5 DRX mode (or one of the requested PC5 DRX modes), i.e., it configures (AS layer) the PC5 DRX scheduling based on the on / off cycle configuration indicated in the PC5 DRX mode.

[0316] Note 3: The selection and request of the PC5 DRX mode at the V2X layer are optional, and the PC5 DRX scheduling (and further related configurations) may be decided only at the AS layer, but ideally based on the knowledge of the V2X application requirements as defined in TS 23.287 [5] and the traffic pattern. The RAN WG will have the final confirmation of the usage guidelines in this case. In this case, the AS layer may know the set of applicable PC5 DRX modes (and all further inputs required thereof), and use the mechanism specified by the RAN WG to send an indication of the applied PC5 DRX scheduling to other UEs. Additionally, again depending on the RAN WG decision, the AS layer of UE1 may also potentially extend the on-duration of the selected (and applied) PC5 DRX scheduling based on AS layer information (e.g., full buffer, misalignment with the resource pool or AS layer signaling, monitored QoS, etc.).

[0317] 6. The AS layer informs the V2X layer of the success or failure of the application of the requested PC5 DRX mode, indicating which mode was applied in case multiple modes were provided in the request. In case the AS layer decides to apply a PC5 DRX schedule that does not correspond to any of the provided modes, it also indicates the applied PC5 DRX schedule to the V2X layer. This indication may be provided not only as a response to the PC5 DRX mode request (step 4), but also later (asynchronously) in case the AS layer modifies the PC5 DRX scheduling (or applies a new one) based on its own logic.

[0318] 7. The V2X layer of UE1 indicates (using broadcast or multicast communication on the PC5 interface) the applied PC5 DRX mode to other relevant UEs (e.g., UE2) to allow UE2 to select its PC5 DRX mode in a coordinated manner.

[0319] 8. The V2X application of UE2 may retrieve information about the PC5 DRX mode applied by one or more relevant UEs from the V2X layer and adjust its communication scheduling.

[0320] 9. The V2X layer of UE2 may provide V2X layer information about the PC5 DRX mode applied by one or more relevant UEs to the AS layer, and the AS layer adapts the PC5 transmission scheduling accordingly.

[0321] 6.2.3 Impact on Services, Entities, and Interfaces

[0322] The solution has the following impacts on existing entities:

[0323] - AF:

[0324] - It is necessary to perform the supply of PC5 DRX-related configurations, including the set of applicable PC5 DRX modes (if the V2X layer program is applied to the PC5 DRX parameter configuration).

[0325] - NEF:

[0326] - It is necessary to expose an API that can receive the configurations provided by the above-mentioned AF (if the V2X layer program is applied to the PC5 DRX parameter configuration).

[0327] - PCF:

[0328] - It is necessary to support, handle, and include the V2X policy of the set of applicable PC5 DRX modes (if the V2X layer program is applied to the PC5 DRX parameter configuration).

[0329] - NG-RAN:

[0330] - If the AS layer program for PC5 DRX parameter configuration is supported, then NG-RAN needs to support the signaling for PC5 (and Uu) DRX-related configurations that includes the set of PC5 DRX modes.

[0331] Editor's note: Whether to support the AS layer program for PC5 DRX parameter configuration is determined by RAN WG.

[0332] - UE:

[0333] - The V2X layer of the UE needs to be able to select the PC5 DRX mode from the (pre-)configured set based on the input included in the V2X policy.

[0334] - The AS layer of the UE needs to adapt its PC5 transmission and reception according to the selected PC5 DRX mode.

[0335] - It is possible to transmit to / receive from other UEs the applicable PC5 DRX configuration using unicast, broadcast, or multicast.

[0336] […]

[0337] 7.2 Conclusions on PC5 DRX Operations

[0338] For key issue #1 (support for QoS-aware NR PC5 power efficiency for pedestrian UEs), regarding NR PC5 DRX operations, the following principles are regarded as transitional conclusions:

[0339] - The V2X application layer provides input to the V2X layer to determine the PC5 DRX assistance information.

[0340] Editor's note: It remains to be further studied whether the inputs described in TS 23.287 [5] (e.g., V2X application requirements) are sufficient or whether additional inputs (e.g., business models) are required from the V2X application layer.

[0341] - The V2X layer can provide PC5 DRX assistance information to the AS layer.

[0342] Editor's note: It remains to be further studied whether the PC5 DRX assistance information provided by the V2X layer to the AS layer is defined in 3GPP and what the content of the PC5 DRX assistance information is.

[0343] Editor's note: It remains to be further studied whether the PC5 DRX assistance information is based on the communication mode (i.e., unicast / broadcast / multicast).

[0344] - The access stratum (AS) layer determines the PC5 DRX for V2X communication on the PC5 reference point to achieve energy savings for pedestrian UEs.

[0345] - The AS layer provides the applied PC5 DRX information to the V2X layer.

[0346] - For unicast, depending on the feedback from RAN2, the PC5 DRX can be negotiated between UEs in the AS layer.

[0347] Editor's note: The design principle needs to be evaluated by RAN WG.

[0348] Editor's note: It remains to be further studied whether DRX-related parameters are required and what the content is to be (pre)-configured on the UE to assist the V2X layer in determining the PC5 DRX assistance information.

[0349] 3GPP TR 23.776 V2.0.0 describes the following:

[0350] 6.5 Solution #5: Solution for applying PC5 DRX configuration to pedestrian UEs

[0351] 6.5.1 Functional description

[0352] This solution is for "Key issue #1: Support for QoS-aware NR PC5 power efficiency for pedestrian UEs".

[0353] The UE receives a PC5 DRX configuration from the network for transmitting / receiving V2X messages via the PC5. Considering the V2X service types supported by the network and the V2X application QoS requirements, the network applies the PC5 DRX configuration on the PC5 to configure the pedestrian UE.

[0354] Provide two options for the pedestrian UE to receive V2X configuration information:

[0355] - Option 1: Provide a preset PC5 DRX configuration by the AMF during the alignment procedure

[0356] - Option 2: The AF / PCF provides a mapping from PQI to PC5 DRX configuration

[0357] The PC5 DRX configuration information for PQI contains the following:

[0358] - Apply "ran2_offset", which defines which point in the SFN cycle is the DRX configuration

[0359] - DRX cycle configuration

[0360] Editor's note: Whether the AS layer requires a PC5 DRX configuration to determine PC5 DRX requires confirmation from the RAN.

[0361] In Option 1, the AMF can provide a preset PC5 DRX configuration to the UE during the alignment procedure. The preset PC5 DRX configuration provided to the UE is applicable to all traffic types and all V2X service types. When the UE is authorized to use V2X communication on the PC5 reference point as a pedestrian UE as defined in clause 6.5.2 of TS 23.287 [5], the AMF determines that the UE requires a PC5 DRX configuration based on the UE subscription and provides the PC5 DRX configuration to the UE if needed. The AMF ensures that all UEs registered in the same area receive the same PC5 DRX configuration. The preset PC5 DRX configuration provided to the UE is based on pre-configuration at the AMF. The network operator configures the preset PC5 DRX taking into account the QoS requirements of the V2X applications providing pedestrian services. Whether to use the same preset PC5 DRX configuration in all AMFs of the PLMN or different PC5 DRX configurations at each AMF is determined by the network operator's deployment.

[0362] In an inter-PLMN scenario, it is necessary to coordinate the preset PC5 DRX configuration among all PLMNs in the service specific area.

[0363] In Option 2, during the UE policy delivery procedure defined in clause 6.2 of TS 23.287 [5], the AF / PCF includes the PC5 DRX configuration within the V2X configuration information. The configuration information contains a mapping from PQI to a specific PC5 DRX configuration.

[0364] Editor's note: It is necessary to coordinate with the RAN to confirm whether the AS layer or the V2X layer derives the DRX for PC5.

[0365] The UE is as follows and Figure 6.5.1-1 shows the PC5 DRX configuration received by the application.

[0366] - Based on the received PC5 DRX configuration, the UE configures the "active time" and "inactive time" for V2X communication on PC5.

[0367] - When the UE is in the "inactive time", the UE enters a "sleep" state and does not transmit or listen for V2X messages on PC5.

[0368] - When the UE is in the "active time", the UE can transmit V2X messages through the V2X application layer or listen for V2X messages on PC5. If the V2X application provides data during the inactive state of the UE, the UE buffers the data and transmits the data during the active time period.

[0369] Editor's note: The exact procedure for the UE to apply the received DRX configuration needs to be coordinated with the RAN.

[0370] [The title of 3GPP TS 73.776 V2.0.0 is "Transmission / Reception of V2X Messages on PC5 Based on PC5 DRX Configuration" Figure 6 .5.1-1 is reproduced as Figure 12

[0371] In some scenarios, some V2X applications may provide a V2X layer with specific V2X application requirements as described in TS 23.287 [5] to send V2X messages on PC5 for the V2X service type as defined in clause 5.4.1.1.2 of TS 23.287 [5]. In these cases, the PC5 DRX configuration provided by the network may not be sufficient to maintain the QoS requirements of these V2X applications. The UE may add an offset in the configured PC5 DRX to extend the "active time" for transmitting data to support the QoS requirements of the application. This is shown in Figure 6 .5.1-2.

[0372] Editor's note: The method for the UE to determine the offset when providing a preset PC5 DRX configuration will be defined in the RAN

[0373] [The title of 3GPP TS 73.776 V2.0.0 is "Extended PC5 DRX to Support Required QoS" Figure 6 .5.1-2 is reproduced as Figure 13

[0374] ​​If the UE has received the PC5 DRX configuration for PQI as part of the V2X configuration information, then the V2X layer in the UE provides the PC5 DRX configuration to the AS layer as follows by derivation from the following PC5 QoS flows as described in TS 23.287 [5]:

[0375] - Based on the mapping of the QoS requirements provided by the V2X application or the V2X service type to the PC5 QoS parameters, the V2X layer determines the PC5 QoS parameters.

[0376] - Based on the PQI, the V2X layer determines the PC5 DRX configuration information from the V2X configuration information.

[0377] - The V2X layer determines the PC5 QoS flow (generating a new one or modifying an existing one) and passes the PC5 QoS requirements and the PC5 DRX configuration for the PC5 QoS flow to the AS layer.

[0378] - The AS layer applies the PC5 DRX configuration and determines the active time and offset.

[0379] For the receiving UE, the UE determines the PC5 DRX as follows:

[0380] - If provided by the AMF, then the UE applies the preset PC5 DRX, or

[0381] - For broadcast / multicast, the UE determines the destination layer 2 ID for broadcast / multicast reception based on the mapping of the V2X service type to the destination layer 2 ID as specified in clause 5.6.1.2 of TS 23.287 [5]. The receiving UE then determines the PC5 QoS parameters based on the mapping of the V2X service type to the PC5 QoS parameters as specified in clause 5.1.2.1 of TS 23.287 [5] or based on the QoS requirements provided by the application. The receiving UE then applies the PC5 DRX according to the mapping of the PQI to the PC5 DRX configuration.

[0382] In the case where the pedestrian UE has multiple active PC5 QoS flows, where different PC5 QoS parameters each have different PC5 DRX configurations, it is proposed that the AS layer configure a DRX cycle that combines all the PC5 DRX configurations. This ensures that the UE will be able to listen for and send V2X messages from all "active" V2X applications. Additionally, if there is no power efficiency by combining all the DRX configurations, then the AS layer may determine to switch the UE to the "always-on" mode.

[0383] In the case where the UE has received the preset PC5 DRX configuration information from the AMF and the PC5 DRX configuration information of the PQI from the AF / PCF, and thus the V2X layer provides both to the AS layer, the AS layer may also combine the PC5 DRX configurations.

[0384] Editor's note: The method of combining the AS layer with the PC5 DRX configuration needs to be defined / confirmed in the RAN group.

[0385] Once the UE determines the offset, the UE applies the offset to all V2X communications via unicast, multicast, or broadcast.

[0386] 6.5.2 Procedures

[0387] Figure 6 .5.2-1 provides procedures for applying the PC5 DRX configuration.

[0388] [The title of 3GPP TS 73.776 V2.0.0 is "UE Application of the Received PC5 DRX Configuration" Figure 6 .5.2-1 is reproduced as Figure 14

[0389] 1. The pedestrian UE registers to the 5G network using the standard procedures.

[0390] 2. The pedestrian UE receives the PC5 DRX configuration from the network (based on Option 1 and / or Option 2 described in Clause 6.5.1).

[0391] 3. Based on the received PC5 DRX configuration, the AS layer in the UE determines the active time and the inactive time. The UE transmits and / or listens for V2X messages on PC5 only during the DRX active time.

[0392] 4. The application in the UE requests to send V2X messages via PC5 with specific QoS requirements by providing the V2X application requirements to the V2X layer as described in TS 23.287 [5]. The V2X layer determines the PC5 QoS parameters based on the V2X application requirements and provides them to the AS layer as defined in Clause 5.4.1.1.3 of TS 23.287 [5]. If the UE has received the PC5 DRX configuration within the V2X configuration information from the AF / PCF, then the V2X layer also includes the PC5 DRX configuration for each applicable PC5 QoS flow.

[0393] 5. If the V2X layer provides a preset PC5 DRX configuration, then the AS layer in the UE determines that the configured PC5 DRX cannot support the QoS requirements and determines an additional offset in the configured PC5 DRX to support the required QoS.

[0394] ​If the V2X layer provides a PC5 DRX configuration for a PC5 QoS flow, the AS layer determines the PC5 DRX considering the PC5 DRX configuration for all PC5 QoS flows (the preset PC5 DRX configuration and / or the PC5 DRX configuration for each PC5 QoS flow).

[0395] 6. The AS layer applies PC5 DRX to all sidelink communications on PC5 for any V2X service.

[0396] 7. When a pedestrian UE establishes a unicast link with a UE for V2X communication, the UE may negotiate a new PC5 DRX according to the QoS requirements of the application that sends V2X messages via this unicast link as needed.

[0397] 6.5.3 Impact on Services, Entities, and Interfaces

[0398] UE:

[0399] AS layer:

[0400] - Apply the PC5 DRX configuration via PC5 for V2X transmission and reception.

[0401] - If the preset PC5 DRX configuration cannot maintain the QoS requirements, determine the DRX offset to support specific QoS requirements.

[0402] - Determine the DRX offset based on the PC5 DRX configuration provided by the V2X layer.

[0403] V2X layer:

[0404] - Determine the PC5 DRX configuration based on the V2X configuration information containing the mapping of PC5 DRX to the PQI provided by the AF / PCF.

[0405] AMF:

[0406] - Determine and provide the PC5 DRX configuration for the pedestrian UE.

[0407] AF / PCF

[0408] - Provide the mapping of PQI to the PC5 DRX configuration

[0409] […]

[0410] 7.2 Conclusion of PC5 DRX Operation

[0411] For Key Issue #1 (support for QoS-aware NR PC5 power efficiency of pedestrian UEs), regarding NR PC5 DRX operation, the following principles are considered conclusions:

[0412] - The Access Stratum (AS) determines the PC5 DRX parameter values for V2X communication on the PC5 reference point to achieve pedestrian UE energy saving.

[0413] - The existing PC5 QoS parameters provided by the V2X layer can be used by the AS to determine the PC5 DRX parameter values.

[0414] - For multicast and broadcast, the AS of the Rx UE requires the PC5 QoS parameters to determine the PC5 DRX parameter values for V2X communication on the PC5 reference point. Therefore, the V2X layer of the Rx UE determines the type of V2X service of interest and derives the corresponding PC5 QoS parameters based on the mapping of the V2X service type to the PC5 QoS parameters or the V2X application requirements (e.g., priority requirements, reliability requirements, latency requirements, range requirements) of the V2X service type provided by the application layer. The V2X layer of the Rx UE passes the PC5 QoS parameters together with the corresponding destination layer 2 ID for reception to the AS layer.

[0415] - The AS provides the applied PC5 DRX information to the V2X layer.

[0416] Note 1: For what purpose the PC5 DRX information is used through the V2X layer, e.g., whether the V2X layer exposes the transmission scheduling information to the V2X application layer (including why the PC5 DRX information needs to be exposed to the V2X application layer if the Uu DRX information is not provided from the NAS layer to the application layer, and what the content is for the transmission scheduling information) will be determined in the normative phase based on the imposed PC5 DRX information provided by the AS layer to the V2X layer to be defined in RAN2.

[0417] - For unicast, two UEs can negotiate the PC5 DRX configuration in the AS layer, and the PC5 DRX can be configured according to a pair of source / destination UE addresses in the AS layer.

[0418] - For broadcast and multicast, and for out-of-coverage scenarios (i.e., when the UE "is not served by E-UTRA" and "is not served by NR"), the AS layer of the UE uses the provided PC5 DRX configuration for PC5 DRX operation.

[0419] Note 2: The granularity / hierarchy of the provided PC5 DRX configuration for broadcast and multicast and for out-of-coverage scenarios (e.g., the mapping information for the PC5 DRX parameters) will be determined in the normative phase based on the RAN2 decision or through coordination with RAN2.

[0420] Note 3: The provided PC5 DRX configuration can come from different sources (e.g., via the PCF or via the V2X application server via the V1 reference point). The provided PC5 DRX configuration is expected to be consistent.

[0421] Note 4: For unicast, for out-of-coverage scenarios, it will be determined in the normative phase based on RAN2 decisions whether to use the provided PC5 DRX configuration.

[0422] According to 3GPP TS 38.300 and TS 38.321, NR Uu specifies a mechanism for saving power of the UE listening to the downlink control channel (e.g., the Physical Downlink Control Channel (PDCCH)). If the UE is configured with Discontinuous Reception (DRX) by its serving base station (e.g., gNB), the UE does not have to continuously listen to the downlink control channel. Basically, the DRX mechanism is characterized by the following:

[0423] - On Duration: The duration after waking up that the UE waits to receive the PDCCH. If the UE successfully decodes the PDCCH, the UE stays awake and starts the Inactivity Timer.

[0424] - Inactivity Timer: The duration from the last successful decoding of the PDCCH that the UE waits to successfully decode the PDCCH. If it fails, the UE can return to the sleep state. The UE shall restart the Inactivity Timer only after a single successful decoding of the PDCCH for the first transmission (i.e., not for retransmission).

[0425] - Retransmission Timer: The duration until a retransmission can be expected.

[0426] - Period: Specifies the periodic repetition of the On Duration followed by a possible Inactivity Period;

[0427] - Active Time: The total duration that the UE listens to the PDCCH. This includes the "On Duration" of the DRX cycle, the time when the UE is performing continuous reception while the Inactivity Timer has not expired, and the time when the UE is performing continuous reception while waiting for a retransmission opportunity.

[0428] According to 3GPP RP-193231, Rel-16 NR sidelink is designed based on the assumption of "always-on" when the UE operates the sidelink. For example, it only focuses on UEs installed in vehicles with sufficient battery capacity. For vulnerable road users (VRUs) in V2X use cases and UEs in public safety and commercial use cases where power consumption in the UE needs to be minimized, energy-saving solutions in Rel-17 are required. Generally, the DRX mechanism periodically repeats the on-duration after an inactive period. Therefore, the DRX mechanism can be applied to receive periodic traffic. In one embodiment, the DRX mode with the on-duration can be designed, applied, or assigned mainly based on the periodic traffic pattern.

[0429] In Uu, the DRX wake-up time is determined based on the system frame number and subframe number synchronized between the UE and the gNB. When operating sidelink communication, the timing for aligning the sidelink transmission time interval (TTI) for monitoring the sidelink control channel can be synchronized with the gNB, the Global Navigation Satellite System (GNSS), or a synchronized reference UE. For example, UE1 and UE2 communicate with each other. If UE1 is the synchronized reference UE, then UE2 monitors the sidelink signal or channel (e.g., Physical Sidelink Broadcast Channel (PSBCH), or the signal or channel containing Master Information Block Sidelink) sent by UE1 for synchronization. In the sidelink signal or channel for synchronization, information about the frame number (e.g., directFrameNumber) and / or time slot (e.g., slotIndex) used to send this sidelink signal or channel for synchronization can be included, so that the frame number and / or time slot of UE2 can be synchronized with those of UE1.

[0430] Basically, UE1 must transmit the sidelink packets to UE2 during the period or duration when UE2 wakes up to receive these sidelink packets. Otherwise, if UE1 transmits these sidelink packets when UE2 is in the "sleep" period, these sidelink packets may be lost at UE2. According to an alternative (discussed in 3GPP TR 23.776), each sidelink service can be associated with a sidelink DRX configuration. The association between the sidelink service and the sidelink DRX configuration can be predefined or preconfigured in the UE or supplied by the network through an authorization procedure. The association between the sidelink service and the sidelink DRX configuration can be applicable to unicast sidelink communication, broadcast sidelink communication, and / or multicast sidelink communication. For example, UE1 can initiate a sidelink service towards UE2 and establish a unicast link with UE2. As another example, UE1 and UE2 can perform a sidelink service that will initiate multicast sidelink communication. Therefore, UE1 and UE2 form a group for multicast sidelink communication.

[0431] Based on the sidelink DRX configuration for a given sidelink service, UE1 may know how long UE2 stays awake after waking up (i.e., the on-duration in each cycle of the sidelink DRX) and the time interval between each wake-up cycle (i.e., the cycle length of the sidelink DRX). More specifically, the sidelink DRX configuration (i.e., the on-duration in each cycle of the sidelink DRX and the cycle length of the sidelink DRX) may be determined or derived based on the traffic pattern of the given sidelink service. This can be shown in Figure 12 However, UE1 does not have information about the start time of this wake-up cycle of the sidelink DRX configuration (i.e., the startOffset of the on-duration in each cycle of the sidelink DRX), such that UE1 may send sidelink control information and / or sidelink transmissions to UE2 at the wrong time. Similarly, UE2 also does not have information about the start time of this wake-up cycle of the sidelink DRX configuration, such that UE2 may monitor sidelink control information and / or receive sidelink transmissions from UE1 at the wrong time. To solve this problem, some methods for determining when to start the wake-up cycle of the sidelink DRX configuration may be considered.

[0432] For multicast, each group may be associated with a group ID. Each group may also be associated with a multicast destination layer 2 ID (L2ID). The multicast destination L2ID may be derived from the group ID. Different groups may be associated with different group IDs or different multicast destination L2IDs.

[0433] The start time of the wake-up cycle of the sidelink DRX configuration for a group may be derivable from or determinable based on the group ID or the multicast destination L2ID associated with the group. In one embodiment, the start time of the wake-up cycle of the sidelink DRX configuration for a group may be derived from or determinable based on a vehicle-to-everything (V2X) layer ID or value associated with the group (e.g., the group ID, the multicast destination L2ID, or...) or an application layer ID or value (which may have been negotiated or exchanged among each member in the group via application layer signaling).

[0434] In one embodiment, an upper layer of the UE (e.g., the V2X layer) may provide the V2X layer ID or value or the application layer ID or value to a lower layer of the UE (i.e., the access stratum (AS) layer, e.g., the radio resource control (RRC) layer, the media access control (MAC) layer, or the physical (PHY) layer). The lower layer of the UE may then derive the start time of the wake-up cycle of the sidelink DRX configuration from the V2X layer ID or value or the application layer ID or value.

[0435] In one embodiment, the upper layer of the UE may directly provide the start time of the wake-up period of the sidelink DRX configuration to the lower layer of the UE. The lower layer of the UE may then apply the start time of the wake-up period of the sidelink DRX configuration. In this alternative, the upper layer of the UE may derive the start time of the wake-up period of the sidelink DRX configuration from the V2X layer ID or value or the application layer ID or value.

[0436] Since each member of the group knows / obtains the same V2X layer ID / value or the same application layer ID / value associated with the group, each member of the group will then derive / determine or apply the same start time of the wake-up period of the sidelink DRX configuration associated with the group. In one embodiment, for a sidelink group that includes at least UE1, UE1 may derive or determine the start time of the wake-up period of the sidelink DRX configuration for the sidelink group based on the group ID or destination learned from the limited and imperfect data (L2ID) associated with the group. UE1 may perform sidelink transmissions to the sidelink group (e.g., to other UEs within the sidelink group) based on the wake-up period or within the wake-up period. UE2 may perform sidelink receptions from the sidelink group (e.g., from other UEs within the sidelink group) based on the wake-up period or within the wake-up period.

[0437] In addition, the wake-up periods for different groups will be separated at different timings, such that resource conflicts will be reduced in the case where these sidelink transmissions occur in the same wake-up period across all groups. This benefit may also apply to sidelink unicast communication.

[0438] For unicast, each pair of UEs on the unicast link may be associated with a source L2ID and a destination L2ID. For example, UE1 and UE2 may establish a unicast link for sidelink communication. From the perspective of UE1, the source L2ID is the L2ID of UE1 and the destination L2ID may be the L2ID of UE2. When UE1 transmits a sidelink transmission to UE2, the source L2ID associated with the sidelink transmission may be (set to) the L2ID of UE1, and the destination L2ID associated with the sidelink transmission may be (set to) the L2ID of UE2. From the perspective of UE2, the source L2ID may be the L2ID of UE2 and the destination L2ID may be the L2ID of UE1. When UE2 transmits a sidelink transmission to UE1, the source L2ID associated with the sidelink transmission may be (set to) the L2ID of UE2 and the destination L2ID associated with the sidelink transmission may be (set to) the L2ID of UE1.

[0439] The start time of the wake-up period for the sidelink DRX configuration for a unicast link may be derivable from or determinable based on the source L2ID and / or destination L2ID associated with the unicast link. In one embodiment, for a unicast link established between UE1 and UE2, the start time of the wake-up period for the sidelink DRX configuration for the unicast link may be derivable from or determinable based on the L2ID of UE1 and / or the L2ID of UE2.

[0440] In one embodiment, for a unicast link between UE1 and UE2, UE1 may derive or determine the start time of the wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE1 and the L2ID of UE2. UE1 may perform sidelink transmissions to UE2 based on or within the wake-up period. UE1 may perform sidelink receptions from UE2 based on or within the wake-up period. In one embodiment, UE2 may derive or determine the start time of the wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE2 and the L2ID of UE1. UE2 may perform sidelink transmissions to UE1 based on or within the wake-up period. UE2 may perform sidelink receptions from UE1 based on or within the wake-up period.

[0441] In one embodiment, for a unicast link between UE1 and UE2, UE1 may derive or determine the first start time of the first wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE1 may perform sidelink receptions from UE2 based on or within the first wake-up period. UE2 may derive or determine the first start time of the first wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE2 may perform sidelink transmissions to UE1 based on or within the first wake-up period. In one embodiment, UE2 may derive or determine the second start time of the second wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE2 may perform sidelink receptions from UE1 based on or within the second wake-up period. UE1 may derive or determine the second start time of the second wake-up period for the sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE1 may perform sidelink transmissions to UE2 based on or within the second wake-up period.

[0442] In one embodiment, for a unicast link between UE1 and UE2, UE1 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE1 may perform a sidelink transmission to UE2 based on the first wake-up period or within the first wake-up period. UE2 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE2 may perform a sidelink reception from UE1 based on the first wake-up period or within the first wake-up period. In one embodiment, UE2 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE2 may perform a sidelink transmission to UE1 based on the second wake-up period or within the second wake-up period. UE1 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE1 may perform a sidelink reception from UE2 based on the second wake-up period or within the second wake-up period.

[0443] In one embodiment, for a unicast link between UE1 and UE2, UE1 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE1 may perform a sidelink reception from UE2 based on the first wake-up period or within the first wake-up period. UE2 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE2 may perform a sidelink transmission to UE1 based on the first wake-up period or within the first wake-up period. In one embodiment, UE2 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE2 may perform a sidelink reception from UE1 based on the first wake-up period or within the first wake-up period. UE1 may derive or determine a first start time of a first wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE1. UE1 may perform a sidelink transmission to UE2 based on the first wake-up period or within the first wake-up period.

[0444] In one embodiment, for a unicast link between UE1 and UE2, UE1 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE1 may perform a sidelink transmission to UE2 based on the second wake-up period or within the second wake-up period. UE2 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE2 may perform a sidelink reception from UE1 based on the second wake-up period or within the second wake-up period. In one embodiment, UE2 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE2 may perform a sidelink transmission to UE1 based on the second wake-up period or within the second wake-up period. UE1 may derive or determine a second start time of a second wake-up period of a sidelink DRX configuration for the unicast link based on the L2ID of UE2. UE1 may perform a sidelink reception from UE2 based on the second wake-up period or within the second wake-up period.

[0445] In one embodiment, some parameters in the possible sidelink DRX configuration other than the parameters for determining the start time of the wake-up period may be negotiated between the two UEs (via PC5-S messages, PC5-RRC messages, or MAC control elements), but the parameters for determining the start time of the wake-up period may be derived from or determined based on the source L2ID associated with the unicast link (e.g., the L2ID of UE1 or UE2) and / or the destination L2ID (e.g., the L2ID of UE2 or UE1).

[0446] Alternatively, the parameters for determining the start time of the wake-up period may be negotiated between the two UEs (e.g., UE1 and UE2 of the unicast link). For example, UE1 may provide one or more candidate values of the start time of the wake-up period to UE2 (via, e.g., PC5-S messages, PC5-RRC messages, or MAC control elements), and UE2 may then respond to UE1 with one of the determined values of the start time of the wake-up period (via, e.g., PC5-S messages, PC5-RRC messages, or MAC control elements). In response to receiving the determined value of the start time of the wake-up period, UE1 may apply / use the determined value of the start time of the wake-up period to start the wake-up period for the unicast link.

[0447] In one embodiment, UE1 may perform sidelink transmissions to UE2 based on or within a wake-up period. Alternatively, UE1 may perform sidelink receptions from UE2 based on or within a wake-up period. In response to the response, UE2 may also apply / use a determined value of the start time of the wake-up period to start a wake-up period for a unicast link. In one embodiment, UE2 may perform sidelink transmissions to UE1 based on or within a wake-up period. Alternatively, UE2 may perform sidelink receptions from UE1 based on or within a wake-up period.

[0448] To maximize power saving, the wake-up time for sidelink DRX may be aligned with the wake-up time for Uu DRX. If UE1 is configured with Uu DRX by its gNB, then UE1 may determine the start time of the wake-up period for sidelink DRX based on the start time of the wake-up period of Uu DRX. In one embodiment, if UE1 is configured with Uu DRX by its gNB, then UE1 may determine one or more candidate values of the start time of the wake-up period for sidelink DRX based on the start time of the wake-up period of UE1's Uu DRX. In one embodiment, if UE2 is configured with Uu DRX by its gNB, then UE2 may determine one of the one or more candidate values based on the start time of the wake-up period of UE2's Uu DRX. Alternatively, if UE1 is not configured with Uu DRX by its gNB or UE1 is out of coverage, then UE1 may determine the start time of the wake-up period for sidelink DRX based on the source L2ID (e.g., UE1's L2ID or UE2's L2ID) and / or destination L2ID (e.g., UE2's L2ID or UE1's L2ID) associated with the unicast link to UE2. UE1 may then configure UE2 to follow the determined start time of the wake-up period for sidelink DRX (e.g., via a PC5-S message, a PC5-RRC message, or a MAC control element).

[0449] More specifically, the association between a sidelink service and a sidelink DRX configuration may be that the identity of the sidelink service (e.g., PSID) or the identity of the application providing the sidelink service (e.g., AID) is associated with a sidelink DRX configuration. More specifically, the wake-up period may be determined based on the on-duration of the sidelink DRX period.

[0450] More specifically, the start time of the wake-up cycle can be based on the startOffset of the sidelink DRX cycle. The start time of the wake-up cycle can mean a slot offset (e.g., drx-SlotOffsetSL) for determining the delay before starting the on-duration timer. The start time of the wake-up cycle can mean a cycle start offset (e.g., drx-StartOffset) of the subframe in which the SL DRX cycle starts.

[0451] More specifically, the sidelink DRX configuration can configure at least one of the following: an on-duration timer (e.g., drx-onDurationTimerSL) for determining the duration at the start of the SL DRX cycle, an inactivity timer (e.g., drx-InactivityTimerSL) for determining the duration after a physical sidelink control channel (PSCCH) occasion in which sidelink control information indicates a sidelink transmission, a retransmission timer (e.g., drx-RetransmissionTimerSL) for determining the maximum duration before receiving a sidelink retransmission, a cycle length (e.g., drx-LongCycleStartOffsetSL) for determining the length of the SL DRX cycle, a short cycle length (e.g., drx-ShortCycleSL) for determining the length of a second SL DRX cycle shorter than the length of the SL DRX cycle, and / or a round-trip time timer (e.g., drx-HARQ-RTT-TimerSL) for determining the maximum duration before an expected sidelink HARQ retransmission grant. In one embodiment, the sidelink DRX configuration does not include the start time of the wake-up cycle of the sidelink DRX configuration.

[0452] More specifically, the unit of the start time of the wake-up cycle for sidelink DRX can be a slot, a symbol, or a subframe. The wake-up cycle for sidelink DRX can start at a specific sidelink frame number and / or a specific sidelink slot.

[0453] More specifically, if sidelink DRX is applied to sidelink multicast communication, then the specific sidelink frame number and / or the specific sidelink slot can be determined based on or derived from a V2X layer ID / value (e.g., a group ID, a multicast destination L2ID, or...) or an application layer ID / value. If sidelink DRX is applied to sidelink unicast communication, then the specific sidelink frame number and / or the specific sidelink slot can be determined based on or derived from a source L2ID and / or a destination L2ID associated with the unicast link. If sidelink DRX is applied to sidelink unicast communication, then the specific sidelink frame number and / or the specific sidelink slot can be determined based on or derived from an identifier identifying the unicast link.

[0454] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that a (portion of the) ID value is a derivation factor for (deriving / determining) the time. The cycle length of the sidelink DRX may also be a derivation factor for (deriving / determining) the time.

[0455] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) may mean that a (portion of the) ID1 value and a (portion of the) ID2 value are both derivation factors for (deriving / determining) the time. The cycle length of the sidelink DRX may also be a derivation factor for (deriving / determining) the time.

[0456] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that a (portion of the) ID value is in the formula for (deriving / determining) the time. The cycle length of the sidelink DRX may also be in the formula for (deriving / determining) the time.

[0457] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) may mean that a (portion of the) ID1 value and a (portion of the) ID2 value are both in the formula for (deriving / determining) the time. The cycle length of the sidelink DRX may also be in the formula for (deriving / determining) the time.

[0458] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value used for (deriving / determining) the time is equal to the value derived by taking the ID value of the sidelink DRX modulo the period length (portion).

[0459] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) may mean that the value used for (deriving / determining) the time is equal to the value derived by taking the sum of the ID1 value (portion) and the ID2 value (portion) of the sidelink DRX modulo the period length.

[0460] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value used for (deriving / determining) the time is derived as the ID value of the sidelink DRX modulo the period length (portion).

[0461] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) may mean that the value used for (deriving / determining) the time is derived as the sum of the ID1 value (portion) and the ID2 value (portion) of the sidelink DRX modulo the period length.

[0462] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value for (deriving / determining) the time is equal to the derived value of "(part of the ID value) modulo (the cycle length of the sidelink DRX)". In one embodiment, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value for (deriving / determining) the time is equal to the derived value of "(A * (part of the ID value) + B) modulo (the cycle length of the sidelink DRX)". A may be another derivation factor for (deriving / determining) the time. A may be a random number or a variable number or a configured number. B may be another derivation factor for (deriving / determining) the time. B may be a random number or a variable number or a configured number.

[0463] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or an L2ID of UE1 and an L2ID of UE2) may mean that the value for (deriving / determining) the time is equal to the derived value of “(a part of the ID1 value + a part of the ID2 value) modulo (the cycle length of the sidelink DRX)”. In one embodiment, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or an L2ID of UE1 and an L2ID of UE2) may mean that the value for (deriving / determining) the time is equal to the derived value of “(A1 * (a part of the ID1 value) + A2 * (a part of the ID2 value) + B) modulo (the cycle length of the sidelink DRX)”. A1 may be another derivation factor for (deriving / determining) the time. A1 may be a random number or a variable number or a configured number. A2 may be another derivation factor for (deriving / determining) the time. A2 may be a random number or a variable number or a configured number. A1 and A2 may be different or the same. B may be another derivation factor for (deriving / determining) the time. B may be a random number or a variable number or a configured number.

[0464] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value for (deriving / determining) the time is derived as "(a part of the ID value) modulo (the cycle length of the sidelink DRX)". In one embodiment, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a sidelink group, or the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on an ID (e.g., any one of a V2X layer ID / value, an application layer ID / value, a group ID, a multicast destination L2ID, a source L2ID, a destination L2ID, the L2ID of UE1, or the L2ID of UE2) may mean that the value for (deriving / determining) the time is derived as "(A * (a part of the ID value)+B) modulo (the cycle length of the sidelink DRX)". A may be another derivation factor for (deriving / determining) the time. A may be a random number or a variable number or a configured number. B may be another derivation factor for (deriving / determining) the time. B may be a random number or a variable number or a configured number.

[0465] More specifically, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) can mean that the value for (deriving / determining) said time is derived as “(part of ID1 value + part of ID2 value) modulo (the cycle length of the sidelink DRX)”. In one embodiment, deriving or determining a time (e.g., the start time of a wake-up period for a sidelink DRX configuration for a unicast link) based on ID1 and ID2 (e.g., a source L2ID and a destination L2ID, or the L2ID of UE1 and the L2ID of UE2) can mean that the value for (deriving / determining) said time is derived as “(A1 * (part of ID1 value) + A2 * (part of ID2 value) + B) modulo (the cycle length of the sidelink DRX)”. A1 can be another derivation factor for (deriving / determining) said time. A1 can be a random number or a variable number or a configured number. A2 can be another derivation factor for (deriving / determining) said time. A2 can be a random number or a variable number or a configured number. A1 and A2 can be different or the same. B can be another derivation factor for (deriving / determining) said time. B can be a random number or a variable number or a configured number.

[0466] In one embodiment, the ID value means the decimal value of the ID. The part of the ID can mean some (not all) of the LSB bits of the ID. The part of the ID value can mean the decimal value of some (not all) of the LSB bits of the ID.

[0467] In one instance, the ID is 24 bits. The part of the ID is the LSB 16 bits of the ID. The part of the ID value is the decimal value of the LSB 16 bits of the ID. The LSB part of the ID is the LSB 16 bits of the ID. The value part of the ID value is the decimal value of the LSB 16 bits of the ID.

[0468] In one embodiment, the part of the ID can mean some (not all) of the MSB bits of the ID. The part of the ID value can mean the decimal value of some (not all) of the MSB bits of the ID.

[0469] In one instance, the ID is 24 bits. The part of the ID is the MSB 16 bits of the ID. The part of the ID value is the decimal value of the MSB 16 bits of the ID. The MSB part of the ID is the MSB 16 bits of the ID. The value part of the ID is the decimal value of the MSB 16 bits of the ID.

[0470] Figure 16FIG. 1600 is a flowchart showing a method for a second UE to configure SL DRX in sidelink multicast communication. In step 1605, the second UE initializes a sidelink service for sidelink multicast communication. In step 1610, the second UE determines an SL DRX configuration based on an association between the sidelink service and the SL DRX configuration, where the SL DRX configuration is associated with the sidelink service. In step 1615, the second UE derives or determines a start time of an ON duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink multicast communication. In step 1620, the second UE listens for sidelink multicast communication on the sidelink control channel based on the start time of the ON duration for each sidelink DRX cycle and the SL DRX configuration.

[0471] Return reference Figure 3 and 4 In an exemplary embodiment of a method for a second UE to configure SL DRX in sidelink multicast communication, the second UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the second UE to: (i) initialize a sidelink service for sidelink multicast communication, (ii) determine an SL DRX configuration based on an association between the sidelink service and the SL DRX configuration, where the SL DRX configuration is associated with the sidelink service, (iii) derive or determine a start time of an ON duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink multicast communication, and (iv) listen for sidelink multicast communication on the sidelink control channel based on the start time of the ON duration for each sidelink DRX cycle and the SL DRX configuration. In addition, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0472] Figure 17 FIG. 1700 is a flowchart showing a method for a first UE to consider SL DRX in sidelink multicast communication. In step 1705, the first UE initializes a sidelink service for sidelink multicast communication. In step 1710, the first UE determines an SL DRX configuration based on an association between the sidelink service and the SL DRX configuration, where the SL DRX configuration is associated with the sidelink service. In step 1715, the first UE derives or determines a start time of an ON duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink multicast communication. In step 1720, the first UE transmits sidelink control information on the sidelink control channel in a cycle for sidelink multicast communication, where the cycle is determined based on the start time of the ON duration for each sidelink DRX cycle and the SL DRX configuration.

[0473] Return reference Figure 3 and 4 In an exemplary embodiment of a method for a first UE to consider SL DRX in sidelink multicast communication, the first UE 300 includes program code 312 stored in a memory 310. A CPU 308 may execute the program code 312 to enable the first UE to: (i) initialize a sidelink service for sidelink multicast communication, (ii) determine an SL DRX configuration based on an association between the sidelink service and the SL DRX configuration, where the SL DRX configuration is associated with the sidelink service, (iii) derive or determine a start time of an on-duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink multicast communication, and (iv) transmit sidelink control information on a sidelink control channel in a cycle for sidelink multicast communication, where the cycle is determined based on the start time of the on-duration for each sidelink DRX cycle and the SL DRX configuration. Additionally, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0474] In Figure 17 and 18In the context of the embodiments shown and described above, in one embodiment, the association between the sidelink service and the SL DRX configuration may be preconfigured or predefined in the first UE and the second UE or be provided by the network. The first UE or the second UE may select an entry from a list of associations between the sidelink service and the SL DRX configuration, and the entry may include the SL DRX configuration and the identity of the sidelink service or an index associated with the sidelink service. The SL DRX configuration may configure at least one of the following: an on-duration timer (e.g., drx-onDurationTimerSL) for determining the duration at the start of the SL DRX cycle, an inactivity timer (e.g., drx-InactivityTimerSL) for determining the duration after a PSCCH occasion in which sidelink control information indicates a sidelink transmission, a retransmission timer (e.g., drx-RetransmissionTimerSL) for determining the maximum duration before receiving a sidelink retransmission, a cycle length (e.g., drx-LongCycleStartOffsetSL) for determining the length of the SL DRX cycle, a short cycle length (e.g., drx-ShortCycleSL) for determining the length of a second SL DRX cycle that is shorter than the length of the SL DRX cycle, and / or a round-trip time timer (e.g., drx-HARQ-RTT-TimerSL) for determining the maximum duration before an expected sidelink HARQ retransmission grant.

[0475] In one embodiment, the first UE and the second UE may belong to a group for sidelink multicast communication. The identifier associated with the group or multicast sidelink communication may be the multicast destination layer 2 ID or a part of the group ID.

[0476] Figure 18FIG. 1800 is a flow chart showing a method for a (Rx) UE. In step 1805, the (Rx) UE initializes a sidelink service for sidelink multicast communication. In step 1810, the (Rx) UE receives an identifier (ID) associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. In step 1815, the (Rx) UE receives an SL DRX configuration associated with the sidelink service, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period. In step 1820, the (Rx) UE derives or determines an offset based at least on the identifier. In step 1825, the (Rx) UE determines a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period. In step 1830, the (Rx) UE listens for sidelink multicast communication on the sidelink control channel during the periodic activity time.

[0477] Return reference Figure 3 and 4 and, in one exemplary embodiment for a (Rx) UE, the (Rx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 may execute the program code 312 to enable the (Rx) UE to: (i) initialize a sidelink service for sidelink multicast communication, (ii) receive an identifier (ID) associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) receive an SL DRX configuration associated with the sidelink service, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period, (iv) derive or determine an offset based at least on the identifier, (v) determine a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period, and (vi) listen for sidelink multicast communication on the sidelink control channel during the periodic activity time. Additionally, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0478] Figure 19FIG. 1900 is a flow chart showing a method for a (Tx) UE. At step 1905, the (Tx) UE initializes a sidelink service for sidelink multicast communication. At step 1910, the (Tx) UE receives an identifier (ID) associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. At step 1915, the (Tx) UE receives an SL DRX configuration associated with the sidelink service, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period. At step 1920, the (Tx) UE derives or determines an offset based at least on the identifier. At step 1925, the (Tx) UE determines a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period. At step 1930, the (Tx) UE transmits data during the periodic activity time for sidelink multicast communication.

[0479] Return reference Figure 3 and 4 , in one exemplary embodiment for a (Tx) UE, the (Tx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the (Tx) UE to: (i) initialize a sidelink service for sidelink multicast communication, (ii) receive an identifier (ID) associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) receive an SL DRX configuration associated with the sidelink service, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period, (iv) derive or determine an offset based at least on the identifier, (v) determine a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period, and (vi) listen on the sidelink control channel for sidelink multicast communication during the periodic activity time. Additionally, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0480] Generally, UE1 may have to transmit sidelink packets to UE2 during the period or duration in which UE2 wakes up to receive these sidelink packets. Otherwise, if UE1 transmits these sidelink packets while UE2 is in a "sleep" period, these sidelink packets may be lost at UE2. According to an alternative (discussed in 3GPP TS 23.776 V2.0.0), one or more PC5 Quality of Service (QoS) flows for each sidelink service may be associated with a sidelink DRX configuration. The association between the PC5 QoS flow and the sidelink DRX configuration may be predefined or preconfigured in the UE or supplied by the network through an authorization procedure. The association between the PC5 QoS flow and the sidelink DRX configuration may apply to unicast sidelink communication, broadcast sidelink communication, and / or multicast sidelink communication. For example, UE1 may initiate a sidelink service towards UE2 and establish a unicast link with UE2. As another example, UE1 and UE2 may perform a sidelink service that will initiate multicast sidelink communication. Thus, UE1 and UE2 may form a group for multicast sidelink communication. For example, UE1 and UE2 may perform a sidelink service that will initiate broadcast sidelink communication.

[0481] Based on the sidelink DRX configuration for a given PC5 QoS flow for the sidelink service, UE1 may know how long UE2 stays awake after waking up (i.e., the on-duration in each cycle of the sidelink DRX) and the time interval between each wake-up cycle (i.e., the cycle length of the sidelink DRX). More specifically, the sidelink DRX configuration (i.e., the on-duration in each cycle of the sidelink DRX and the cycle length of the sidelink DRX) may be determined or derived based on the traffic pattern of the given PC5 QoS flow. This is shown in Figure 15 However, UE1 may not have information about the start time of this wake-up cycle of the sidelink DRX configuration (i.e., startOffset for starting each cycle of the sidelink DRX and / or slotOffset for starting the on-duration of each sidelink DRX cycle), such that UE1 may send sidelink control information and / or sidelink transmissions to UE2 at the wrong time. Similarly, UE2 may also not have information about the start time of this wake-up cycle of the sidelink DRX configuration, such that UE2 may listen for sidelink control information and / or receive sidelink transmissions from UE1 at the wrong time. To solve this problem, some methods for determining when to start the wake-up cycle of the sidelink DRX configuration may be considered.

[0482] Since each member in the group knows / obtains the same V2X layer ID / value or the same application layer ID / value associated with the group, each member in the group will then derive or determine or apply the start time of the wake-up period of the same sidelink DRX configuration associated with the group. In one embodiment, for a sidelink group including at least UE1 and UE2, UE1 may derive or determine the start time of the wake-up period of the sidelink DRX configuration for the sidelink group based on the group ID or the destination L2ID associated with the group. UE1 may perform sidelink transmissions to the sidelink group (e.g., to other UEs within the sidelink group) based on the wake-up period or within the wake-up period. UE2 may perform sidelink receptions from the sidelink group (e.g., from other UEs within the sidelink group) based on the wake-up period or within the wake-up period. Similarly, for broadcasting, each sidelink service using broadcast sidelink communication may be associated with one broadcast destination L2 ID. Each UE may initiate a sidelink service using broadcast sidelink communication and may use the same broadcast destination L2ID for sidelink reception. Therefore, the concepts discussed above may also be applied such that a UE may derive or determine the start time of the wake-up period of the sidelink DRX configuration for broadcast sidelink communication based on the broadcast destination L2ID associated with the broadcast sidelink communication.

[0483] In addition, it may separate the wake-up periods for different groups and / or different UEs when using broadcast sidelink communication at different timings, such that resource conflicts will be reduced in the case where these sidelink transmissions occur in the same wake-up period across all these UEs. This benefit may also apply to sidelink unicast communication.

[0484] More specifically, the association between a PC5 QoS flow and a sidelink DRX configuration may be that the identity of the PC5 QoS flow (e.g., QFI) or the identity for identifying the PC5 QoS requirements of a sidelink service (e.g., PQI) is associated with a sidelink DRX configuration.

[0485] Alternatively, the start time of the wake-up period of the sidelink DRX configuration may be specified or preconfigured in the UE. In other words, the start time of the wake-up period of the sidelink DRX configuration may not be provided in or derived from the sidelink DRX configuration. In this alternative, the start time of the wake-up period of the sidelink DRX configuration may be specified or preconfigured as, for example, the value '0' or a specific value. In this alternative, the UE may apply or use the sidelink DRX configuration configured in the system information broadcast by the base station or dedicated signaling sent from the base station to the UE or negotiated with a peer UE, and may derive or determine the start time of the wake-up period of the sidelink DRX configuration based on the specified or preconfigured value.

[0486] Figure 20FIG. 2000 is a flowchart showing a method for configuring SL DRX for a second UE in sidelink communication. In step 2005, the second UE initializes a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2010, the second UE determines an SL DRX configuration based on the association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow. In step 2015, the second UE derives or determines the start time of the on-duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink communication. In step 2020, the second UE listens for sidelink communication on the sidelink control channel based on the start time of the on-duration for each sidelink DRX cycle and the SL DRX configuration.

[0487] Return reference Figure 3 and 4 In an exemplary embodiment of a method for configuring SL DRX for a second UE in sidelink communication, the second UE 300 includes program code 312 stored in a memory 310. A CPU 308 may execute the program code 312 to enable the second UE to: (i) initialize a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) determine an SL DRX configuration based on the association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow, (iii) derive or determine the start time of the on-duration for each sidelink DRX cycle based at least on an identifier associated with the sidelink communication, and (iv) listen for sidelink communication on the sidelink control channel based on the start time of the on-duration for each sidelink DRX cycle and the SL DRX configuration. Additionally, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0488] Figure 21FIG. 2100 is a flow chart showing a method for a first UE to consider SL DRX in sidelink communication. In step 2105, the first UE initializes a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2110, the first UE determines an SL DRX configuration based on the association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow. In step 2115, the first UE derives or determines the start time of the on-duration for each sidelink DRX period based at least on an identifier associated with the sidelink communication. In step 2120, the first UE transmits sidelink control information on a sidelink control channel in a period for sidelink communication, where the period is determined based on the start time of the on-duration for each sidelink DRX period and the SL DRX configuration.

[0489] Return reference Figure 3 and 4 and, in an exemplary embodiment of a method for configuring SL DRX for a first UE in sidelink multicast communication, the first UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the first UE to: (i) initialize a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) determine an SL DRX configuration based on the association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow, (iii) derive or determine the start time of the on-duration for each sidelink DRX period based at least on an identifier associated with the sidelink communication, and (iv) transmit sidelink control information on a sidelink control channel in a period for sidelink communication, where the period is determined based on the start time of the on-duration for each sidelink DRX period and the SL DRX configuration. In addition, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0490] In Figure 20 and 21 In the context of the embodiments shown and described above, in one embodiment, the association between the PC5 QoS flow and the SL DRX configuration can be preconfigured or predefined in the first UE and the second UE or provided by the network. The first UE or the second UE can select an entry from a list of associations between the PC5 QoS flow and the SL DRX configuration, and the entry can include the SL DRX configuration and the identity of the PC5 QoS flow or an index associated with the PC5 QoS flow.

[0491] In one embodiment, the SL DRX configuration may configure at least one of the following: an on-duration timer (e.g., drx-onDurationTimerSL) for determining a duration at the start of an SL DRX cycle, an inactivity timer (e.g., drx-InactivityTimerSL) for determining a duration after a PSCCH occasion in which sidelink control information indicates a sidelink transmission, a retransmission timer (e.g., drx-RetransmissionTimerSL) for determining a maximum duration before receiving a sidelink retransmission, a cycle length (e.g., drx-LongCycleStartOffsetSL) for determining the length of an SL DRX cycle, a short cycle length (e.g., drx-ShortCycleSL) for determining the length of a second SL DRX cycle that is shorter than the length of the SL DRX cycle, and / or a round-trip time timer (e.g., drx-HARQ-RTT-TimerSL) for determining a maximum duration before an expected sidelink HARQ retransmission grant.

[0492] In one embodiment, the sidelink communication may be multicast sidelink communication, and the first UE and the second UE may belong to a group for multicast sidelink multicast communication. An identifier associated with the group or the multicast sidelink communication may be a multicast destination layer 2 ID or a part of the group ID. The sidelink communication may be broadcast sidelink communication, and the first UE and the second UE may initiate a sidelink service for the broadcast sidelink communication. An identifier associated with the broadcast sidelink communication may be a broadcast destination layer 2 ID (part) associated with the sidelink service.

[0493] Figure 22FIG. 2200 is a flow chart showing a method for a (Rx) UE. In step 2205, the (Rx) UE initializes a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2210, the (Rx) UE is configured, pre-configured, provided with, or receives an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. In step 2215, the (Rx) UE is configured, pre-configured, provided with, or receives an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period. In step 2220, the (Rx) UE derives or determines an offset based at least on the identifier. In step 2225, the (Rx) UE determines a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate / define where the period starts and the first length of the on-duration is the duration at the start of the period. In step 2230, the (Rx) UE listens for sidelink multicast communication on the sidelink control channel during the periodic activity time.

[0494] Return reference Figure 3 and 4 In one exemplary embodiment for a (Rx) UE, the (Rx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 may execute the program code 312 to enable the (Rx) UE to: (i) initialize a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) be configured, pre-configured, provided with, or receive an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) be configured, pre-configured, provided with, or receive an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period, (iv) derive or determine an offset based at least on the identifier, (v) determine a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period, and (vi) listen for sidelink multicast communication on the sidelink control channel during the periodic activity time. Additionally, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0495] Figure 23FIG. 2300 is a flowchart showing a method for a (Tx) UE. In step 2305, the (Tx) UE initializes a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2310, the (Tx) UE is configured, pre-configured, provided with, or receives an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. In step 2315, the (Tx) UE is configured, pre-configured, provided with, or receives an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period. In step 2320, the (Tx) UE derives or determines an offset based at least on the identifier. In step 2325, the (Tx) UE determines a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period. In step 2330, the (Tx) UE transmits data during the periodic activity time for sidelink multicast communication.

[0496] Return reference Figure 3 and 4 In one exemplary embodiment for a (Tx) UE, the (Tx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the (Tx) UE to: (i) initialize a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) be configured, pre-configured, provided with, or receive an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) be configured, pre-configured, provided with, or receive an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an on-duration and a second length of a period, (iv) derive or determine an offset based at least on the identifier, (v) determine a periodic activity time based at least on the first length of the on-duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the on-duration is the duration at the start of the period, and (vi) transmit data during the periodic activity time for sidelink multicast communication. Additionally, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0497] It is possible that each PC5 5QI (PQI) can be associated with one or more SL DRX configurations. In one embodiment (for one or more SL DRX configurations associated with a PQI), an SL DRX configuration can include a value regarding the start time / time offset of the wake-up period of SL DRX. Different SL DRX configurations can include corresponding (which can be the same or different) values regarding the start time or time offset of the wake-up period of SL DRX. Different SL DRX configurations can include corresponding (which can be the same or different) DRX cycle lengths or on-duration cycle lengths. Therefore, the UE initiating the service of interest can select, pick, or derive (apply) the SL DRX configuration according to the PQI of the service.

[0498] For example, an SL DRX configuration can include a parameter set for determining the mode of SL DRX (including, for example, the DRX cycle length and / or the on-duration cycle) and a parameter for determining the start time or time offset of the wake-up time of SL DRX. The parameter for determining the start time or time offset of the wake-up time of SL DRX can include, for example, startOffset and / or slotOffset. Each of one or more SL DRX configurations can be associated with an index. The UE can use, for example, the multicast destination L2ID, group ID, V2X layer ID, or the L2ID associated with the service to determine or derive the index (indicating its value) for the SL DRX configuration.

[0499] For example, the SL DRX configuration including the first set of startOffset and / or slotOffset can be associated with index 1, the SL DRX configuration including the second set of startOffset and / or slotOffset can be associated with index 2, and the SL DRX configuration including the third set of startOffset and / or slotOffset can be associated with index 3. If the UE can initiate the broadcast or multicast service of interest, then the UE can use the L2ID associated with the broadcast or multicast service or the V2X layer ID or group ID associated with the multicast service to determine or derive the index (indicating its value).

[0500] For example, if the determined or derived index is 3 or the determined or derived value indicates index 3, then this UE can apply the parameters startOffset and / or slotOffset in the SL DRX configuration associated with index 3. The UE can apply the parameters startOffset and / or slotOffset in the third set of startOffset and / or slotOffset to determine the start time or time offset of the wake-up period of SL DRX of the SL DRX configuration corresponding to the PQI of the broadcast or multicast service.

[0501] In one embodiment (for one or more SL DRX configurations associated with a PQI), each SL DRX configuration may include one or more values regarding the start time or time offset of the wake-up period of the SL DRX. Thus, a UE initiating a service of interest may apply an SL DRX configuration based on the PQI of the service and may select, pick, or derive a value from the one or more values to determine the start time or time offset of the wake-up period of the SL DRX for this SL DRX configuration.

[0502] For example, an SL DRX configuration may include a set of parameters for determining the mode of the SL DRX (including, for example, the DRX cycle length and / or the on-duration period) and one or more (sets) of parameters for determining the start time or time offset of the wake-up time of the SL DRX. Each (set) of parameters for determining the start time or time offset of the wake-up time of the SL DRX may include, for example, startOffset and / or slotOffset. Each (set) of parameters for determining the start time of the wake-up time of the SL DRX may be associated with an index. The UE may use, for example, the multicast destination L2ID, group ID, V2X layer ID, or L2ID associated with the service to determine or derive which (set) of parameters for determining the start time or time offset of the wake-up time of the SL DRX is applied to the SL DRX. For example, an SL DRX configuration may include a first set of startOffset and / or slotOffset associated with index 1, a second set of startOffset and / or slotOffset associated with index 2, and a third set of startOffset and / or slotOffset associated with index 3.

[0503] If the UE can initiate a broadcast or multicast service of interest, the UE may use the L2ID associated with the broadcast or multicast service to determine or derive an index (indicating its value). For example, if the determined or derived index is 3 or the determined or derived value indicates index 3, then this UE may apply the parameters startOffset and / or slotOffset in the third set of startOffset and / or slotOffset to determine the start time or time offset of the wake-up period of the SL DRX for the SL DRX configuration corresponding to the PQI of the broadcast or multicast service.

[0504] If the UE can initiate the multicast service of interest, the UE can use the V2X layer ID or group ID associated with the multicast service to determine or derive an index (indicating its value). For example, if the determined or derived index is 1 or the determined or derived value indicates index 1, then this UE can apply the parameters startOffset and / or slotOffset in the first set of startOffset and / or slotOffset to determine the start time or time offset of the wake-up period of the SL DRX configuration corresponding to the multicast service.

[0505] For example, in the foregoing ID (such as L2ID, V2X layer ID, destination ID of the group, group ID associated with the multicast service), it can be X, and the number of parameter sets can be N (for example, the index of the parameter set is from 0 to N - 1). All UEs in this group or initiating the same (unicast, broadcast, or multicast) service can use the same SL DRX configuration or parameter set with index = (X mod N). Alternatively, all UEs in this group or initiating the same (unicast, broadcast, or multicast) service can use the same SL DRX configuration or parameter set with index = ((X + m) mod N), where m can be other values, such as a (pre-)configured or specified value, or a value associated with the group member number, or a value or ID associated with scheduling the UE.

[0506] Figure 24 FIG. 2400 is a flowchart showing a method for configuring SL DRX for a second UE in sidelink communication. In step 2405, the second UE initializes a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2410, the second UE determines an SL DRX configuration based on the association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow and contains information indicating the start time of the on-duration for one or more (each) sidelink DRX periods. In step 2415, the second UE derives or determines the start time of the on-duration for each sidelink DRX period from the information based at least on an identifier associated with the sidelink communication. In step 2420, the second UE listens for sidelink control channels for sidelink communication based on the start time of the on-duration for one or more (each) sidelink DRX periods and the SL DRX configuration.

[0507] Return reference Figure 3 and 4, in an exemplary embodiment of a method for a second UE to configure SL DRX in sidelink communication, the second UE 300 includes program code 312 stored in a memory 310. The CPU 308 may execute the program code 312 to enable the second UE to: (i) initialize a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) determine an SL DRX configuration based on an association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow and includes information indicating a start time of an on-duration for one or more (each) sidelink DRX cycles, (iii) derive or determine, at least based on an identifier associated with the sidelink communication, the start time of the on-duration for (each) sidelink DRX cycle from the information, and (iv) listen for sidelink control channels for sidelink communication based on the start time of the on-duration for (each) sidelink DRX cycle and the SL DRX configuration. In addition, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0508] Figure 25 FIG. 2500 is a flowchart showing a method for a first UE to consider SL DRX in sidelink communication. In step 2505, the first UE initializes a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow. In step 2510, the first UE determines an SL DRX configuration based on an association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow and includes information indicating a start time of an on-duration for one or more (each) sidelink DRX cycles. In step 2515, the first UE derives or determines, at least based on an identifier associated with the sidelink communication, the start time of the on-duration for each sidelink DRX cycle from the information. In step 2520, the first UE transmits sidelink control information on a sidelink control channel in a cycle for sidelink communication, where the cycle is determined based on the start time of the on-duration for each sidelink DRX cycle and the SL DRX configuration.

[0509] Return to reference Figure 3 and 4, in an exemplary embodiment of a method for a first UE to consider SL DRX in sidelink communication, the first UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the first UE to: (i) initialize a sidelink service for sidelink communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) determine an SL DRX configuration based on an association between the PC5 QoS flow and the SL DRX configuration, where the SL DRX configuration is associated with the PC5 QoS flow and includes information indicating a start time of an on-duration for one or more (each) sidelink DRX cycles, (iii) derive or determine, at least based on an identifier associated with the sidelink communication, a start time of the on-duration for each sidelink DRX cycle from the information, and (iv) transmit sidelink control information on a sidelink control channel in a cycle for sidelink communication, where the cycle is determined based on the start time of the on-duration for each sidelink DRX cycle and the SL DRX configuration. In addition, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0510] In Figure 24 and 25 In the context of the embodiments shown and described above, in one embodiment, the association between the PC5 QoS flow and the SL DRX configuration can be preconfigured or predefined in the first UE and the second UE or provided by the network. The first UE or the second UE can select an entry from a list of associations between the PC5 QoS flow and the SL DRX configuration, and the entry can include the SL DRX configuration and a PQI associated with the PC5 QoS flow, an identity of the PC5 QoS flow, or an index associated with the PC5 QoS flow.

[0511] In one embodiment, the SL DRX configuration may configure at least one of the following: an on-duration timer (e.g., drx-onDurationTimerSL) for determining a duration at the start of an SL DRX cycle, an inactivity timer (e.g., drx-InactivityTimerSL) for determining a duration after a PSCCH occasion in which sidelink control information indicates a sidelink transmission, a retransmission timer (e.g., drx-RetransmissionTimerSL) for determining a maximum duration before receiving a sidelink retransmission, a cycle length (e.g., drx-LongCycleStartOffsetSL) for determining the length of an SL DRX cycle, a short cycle length (e.g., drx-ShortCycleSL) for determining the length of a second SL DRX cycle that is shorter than the length of the SL DRX cycle, and / or a round-trip time timer (e.g., drx-HARQ-RTT-TimerSL) for determining a maximum duration before an expected sidelink HARQ retransmission grant.

[0512] In one embodiment, the sidelink communication may be multicast sidelink communication, and the first UE and the second UE may belong to a group for multicast sidelink multicast communication. An identifier associated with the group or the multicast sidelink communication may be a multicast destination layer 2 ID or a part of a group ID. The sidelink communication may be broadcast sidelink communication, and the first UE and the second UE may initiate sidelink services for the broadcast sidelink communication.

[0513] In one embodiment, an identifier associated with the broadcast sidelink communication may be a broadcast destination layer 2 ID (part of) associated with the sidelink service. The information may include at least one drx-SlotOffset for determining a start time for an on-duration of (each) sidelink DRX cycle, and each drx-SlotOffset is associated with an index. The information may further include at least one drx-StartOffset for determining a start time for an on-duration of (each) sidelink DRX cycle, and each drx-StartOffset is associated with an index.

[0514] In one embodiment, the first or second UE may use an identifier associated with the sidelink communication to determine or derive an index of the drx-SlotOffset and / or drx-StartOffset in the information. The first or second UE may use the drx-SlotOffset and / or drx-StartOffset to derive or determine a start time for an on-duration of (each) sidelink DRX cycle.

[0515] Figure 26 FIG. 2600 is a flowchart showing a method for a (Rx) UE. At step 2605, the (Rx) UE initializes a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow. At step 2610, the (Rx) UE is configured, pre-configured, provided with, or receives an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. At step 2615, the (Rx) UE is configured, pre-configured, provided with, or receives an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an active duration and a second length of a period and includes one or more offsets. At step 2620, the (Rx) UE derives or determines an offset from one or more offsets based at least on an identifier. At step 2625, the (Rx) UE determines a periodic active time based at least on the first length of the active duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the active duration is the duration at the start of the period. At step 2630, the (Rx) UE listens on the sidelink control channel for sidelink multicast communication during the periodic active time.

[0516] Return reference Figure 3 and 4 , in an exemplary embodiment for a (Rx) UE, the (Rx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the (Rx) UE to: (i) initialize a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) be configured, pre-configured, provided with, or receive an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) be configured, pre-configured, provided with, or receive an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an active duration and a second length of a period and includes one or more offsets, (iv) derive or determine an offset from one or more offsets based at least on an identifier, (v) determine a periodic active time based at least on the first length of the active duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the active duration is the duration at the start of the period, and (vi) listen on the sidelink control channel for sidelink multicast communication during the periodic active time. Additionally, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0517] Figure 27FIG. 2700 is a flowchart showing a method for a (Tx) UE. At step 2705, the (Tx) UE initializes a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow. At step 2710, the (Tx) UE is configured, pre-configured, provided with, or receives an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication. At step 2715, the (Tx) UE is configured, pre-configured, provided with, or receives an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an ON duration and a second length of a period and includes one or more offsets. At step 2720, the (Tx) UE derives or determines an offset from one or more offsets based at least on an identifier. At step 2725, the (Tx) UE determines a periodic active time based at least on the first length of the ON duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the ON duration is the duration at the start of the period. At step 2730, the (Tx) UE transmits data during the periodic active time for sidelink multicast communication.

[0518] Return reference Figure 3 and 4 , in one exemplary embodiment for a (Tx) UE, the (Tx) UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the (Tx) UE to: (i) initialize a sidelink service for sidelink multicast communication, where the sidelink service is associated with at least a PC5 QoS flow, (ii) be configured, pre-configured, provided with, or receive an ID associated with the sidelink multicast communication, where the ID is used for data transmission and reception in the sidelink multicast communication, (iii) be configured, pre-configured, provided with, or receive an SL DRX configuration associated with the PC5 QoS flow, where the SL DRX configuration includes at least a first length of an ON duration and a second length of a period and includes one or more offsets, (iv) derive or determine an offset from one or more offsets based at least on an identifier, (v) determine a periodic active time based at least on the first length of the ON duration, the second length of the period, and the offset, where the offset is used to indicate or define where the period starts and the first length of the ON duration is the duration at the start of the period, and (vi) transmit data during the periodic active time for sidelink multicast communication. Further, the CPU 308 can execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0519] Figure 28FIG. 2800 is a flow chart showing a method for a UE to consider SL DRX for sidelink multicast communication associated with a group. In step 2805, the UE adopts or considers a sidelink DRX configuration applied to sidelink multicast communication associated with a group, where the sidelink DRX configuration includes at least one of an on-duration timer (length) for determining an on-duration at the start of (each) sidelink DRX cycle and / or a cycle length for determining the length of (each) sidelink DRX cycle. In step 2810, the UE derives or determines a start time of the on-duration of (each) sidelink DRX cycle or a start time of (each) sidelink DRX cycle based at least on an identifier associated with the group. In step 2815, the UE transmits sidelink control information associated with the group on a sidelink control channel in a cycle, where the cycle is determined based on the SL DRX configuration and the start time of the on-duration of (each) sidelink DRX cycle or the start time of (each) sidelink DRX cycle.

[0520] In one embodiment, the sidelink DRX configuration may not include a start time of the on-duration of (each) sidelink DRX cycle or a start time of (each) sidelink DRX cycle. The start time of the on-duration of (each) sidelink DRX cycle or the start time of (each) sidelink DRX cycle may be a startOffset, and / or the unit of the start time of the on-duration of (each) sidelink DRX cycle or the start time of (each) sidelink DRX cycle may be a subframe.

[0521] In one embodiment, the derived or determined start time of the on-duration of (each) sidelink DRX cycle or the start time of (each) sidelink DRX cycle may (equal) be a derived value of “(part of the identifier) modulo (cycle length)”. Modulo (mod) represents the modulus or the modulus number.

[0522] In one embodiment, the UE may have information indicating a start time of the on-duration of (each) sidelink DRX cycle or a start time of (each) sidelink DRX cycle, and / or the UE derives or determines a start time of the on-duration of (each) sidelink DRX cycle or a start time of (each) sidelink DRX cycle based at least on an identifier associated with the group and the information. The UE may determine or derive an index based at least on an identifier associated with the group, and the UE may derive or determine a start time of the on-duration of (each) sidelink DRX cycle or a start time of (each) sidelink DRX cycle from one or more start times of the on-duration of (each) sidelink DRX cycle or start times of (each) sidelink DRX cycle based on the index.

[0523] In one embodiment, the identifier associated with the group may be (part of) a multicast destination layer 2 ID. The period may be at least the active time during which the on-duration timer is running.

[0524] Return reference Figure 3 and Figure 4 and, in an exemplary embodiment of a method for a first UE to consider SL DRX for sidelink multicast communication associated with a group, the UE 300 includes program code 312 stored in a memory 310. The CPU 308 may execute the program code 312 to enable the UE to: (i) adopt or consider a sidelink DRX configuration applied to sidelink multicast communication associated with the group, where the sidelink DRX configuration includes at least one of an on-duration timer (length) for determining an on-duration at the start of (each) sidelink DRX period and / or a period length for determining the length of (each) sidelink DRX period, (ii) derive or determine a start time of the on-duration for (each) sidelink DRX period or a start time of (each) sidelink DRX at least based on an identifier associated with the group, and (iii) transmit sidelink control information associated with the group on a sidelink control channel in a period, where the period is determined based on the SL DRX configuration and the start time of the on-duration for (each) sidelink DRX period or the start time of (each) sidelink DRX period. In addition, the CPU 308 may execute the program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0525] Various aspects of the present disclosure have been described above. It should be understood that the teachings herein may be implemented in a wide variety of forms, and any specific structure, function, or both disclosed herein are merely representative. Based on the teachings herein, those skilled in the art should understand that the aspects disclosed herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of the aspects set forth herein may be used to implement a device or practice a method. Additionally, such a device may be implemented or such a method may be practiced using other structures, functions, or structures and functions in addition to or different from one or more of the aspects set forth herein. As examples of some of the above concepts, in some aspects, parallel channels may be established based on a pulse repetition frequency. In some aspects, parallel channels may be established based on a pulse position or offset. In some aspects, parallel channels may be established based on a time-hopping sequence. In some aspects, parallel channels may be established based on a pulse repetition frequency, a pulse position or offset, and a time-hopping sequence.

[0526] Those skilled in the art will understand that any of a variety of different technologies and techniques can be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0527] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, processors, components, circuits, and algorithmic steps described in connection with the aspects disclosed herein can be implemented as electronic hardware (e.g., digital implementations, analog implementations, or a combination of both, which can be designed using source decoding or some other technique), incorporated into various forms of program or design code with instructions (which may be referred to herein for convenience as “software” or “software modules”), or a combination of the two. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been generally described in terms of their functionality above. Whether this functionality is implemented as hardware or software depends on the particular application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in different ways for each particular application, but such implementation decisions should not be construed as causing a departure from the scope of the present disclosure.

[0528] In addition, the various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein can be implemented within an integrated circuit (“IC”), an access terminal, or an access point, or executed by an integrated circuit, an access terminal, or an access point. The IC can include a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination designed to perform the functions described herein, and can execute code or instructions residing within the IC, outside the IC, or in both cases. The general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0529] It should be understood that any specific order or hierarchy of steps in a disclosed process is an instance of a sample method. It should be understood that, based on design preferences, the specific order or hierarchy of steps in a process can be rearranged while remaining within the scope of the present disclosure. The appended method claims present the elements of the various steps in an example order, and are not meant to be limited to the specific order or hierarchy presented.

[0530] The steps of a method or algorithm described in connection with the aspects disclosed herein can be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. Software modules (e.g., including executable instructions and related data) and other data can reside in a data memory, such as a RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. The exemplary storage medium can be coupled to a machine, such as a computer / processor (for convenience, the machine may be referred to herein as a "processor"), such that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. The exemplary storage medium can be integral with the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user device. In an alternative, the processor and the storage medium can reside in the user device as discrete components. Additionally, in some aspects, any suitable computer program product can include a computer-readable medium that includes code related to one or more aspects of the present disclosure. In some aspects, the computer program product can include packaging material.

[0531] Although the invention has been described in connection with various aspects, it should be understood that the invention is capable of further modification. This application is intended to cover any changes, uses, or adaptations of the invention, which generally follow the principles of the invention and include such departures from the present disclosure as come within the known and customary practice in the art to which the invention pertains.

[0532] Cross - Reference to Related Applications

[0533] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 123,976, filed December 10, 2020, U.S. Provisional Patent Application No. 63 / 165,997, filed March 25, 2021, and U.S. Provisional Patent Application No. 63 / 175,208, filed April 15, 2021, the entire disclosures of which are incorporated herein by reference in their entirety.

Claims

1. A method for side - link discontinuous reception in a user equipment for side - link multicast communication associated with a group, characterized in that, Comprising: Obtaining or being configured to apply a sidelink discontinuous reception configuration for the sidelink multicast communication associated with the group, where the sidelink discontinuous reception configuration includes at least one of an on-duration timer length for determining an on-duration at the start of each sidelink discontinuous reception period and / or a period length for determining the length of each sidelink discontinuous reception period; Deriving or determining a start time of the on-duration for each sidelink discontinuous reception period or a start time of each sidelink discontinuous reception period, at least based on an identifier associated with the group; And Transmitting sidelink control information associated with the group on a sidelink control channel in a period, where the period is determined based on the sidelink discontinuous reception configuration and the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period; where the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is derived or determined based on a derived value of "(a part of the identifier) modulo (the period length)" or a derived value of "(the identifier) modulo (the period length)".

2. The method according to claim 1, characterized in that, The sidelink discontinuous reception configuration does not include the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period.

3. The method according to claim 1, characterized in that, The start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is startOffset, and / or The unit of the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is a subframe.

4. The method according to claim 1, characterized in that, The user equipment has information indicating a start time of the on-duration for one or more sidelink discontinuous reception periods or a start time of each sidelink discontinuous reception period, and / or where the user equipment derives or determines the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period, at least based on the identifier associated with the group and the information.

5. The method according to claim 4, characterized in that, The user equipment determines or derives an index, at least based on the identifier associated with the group, and where the user equipment derives or determines the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period from the start time of the on-duration for one or more sidelink discontinuous reception periods or the start time of each sidelink discontinuous reception period, based on the index.

6. The method according to claim 1, characterized in that, The identifier associated with the group is a part of the multicast destination layer 2 identifier, or where the identifier associated with the group is the multicast destination layer 2 identifier.

7. The method according to claim 1, characterized in that, The period is at least the active time when the on-duration timer is running.

8. A user equipment, characterized in that, Comprising: A control circuit; A processor installed in the control circuit; and a memory, which is installed in the control circuit and operatively coupled to the processor; wherein the processor is configured to execute program code stored in the memory to: Obtain or be configured to apply a sidelink discontinuous reception configuration for sidelink multicast communication associated with a group, wherein the sidelink discontinuous reception configuration includes at least one of an on-duration timer length for determining an on-duration at the start of each sidelink discontinuous reception period and / or a period length for determining the length of each sidelink discontinuous reception period; Derive or determine a start time of the on-duration for each sidelink discontinuous reception period or a start time of each sidelink discontinuous reception period at least based on an identifier associated with the group; and Transmit sidelink control information associated with the group on a sidelink control channel in a period, wherein the period is determined based on the sidelink discontinuous reception configuration and the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period; wherein the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is derived or determined based on a derived value of "(a part of the identifier) modulo (the period length)" or a derived value of "(the identifier) modulo (the period length)".

9. The user equipment according to claim 8, characterized in that, The sidelink discontinuous reception configuration does not include the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period.

10. The user equipment according to claim 8, characterized in that, The start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is startOffset, and / or The unit of the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period is a subframe.

11. The user equipment according to claim 8, characterized in that,The user equipment has information indicating one or more start times of the on-duration for each sidelink discontinuous reception period or start times of each sidelink discontinuous reception period, and / or wherein the user equipment derives or determines the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period at least based on the identifier associated with the group and the information.

12. The user equipment according to claim 11, wherein, The user equipment determines or derives an index at least based on the identifier associated with the group, and wherein the user equipment derives or determines the start time of the on-duration for each sidelink discontinuous reception period or the start time of each sidelink discontinuous reception period from the one or more start times of the on-duration for each sidelink discontinuous reception period or start times of each sidelink discontinuous reception period based on the index.

13. The user equipment according to claim 8, wherein, The identifier associated with the group is a part of a multicast destination layer 2 identifier, or The identifier associated with the group is a multicast destination layer 2 identifier.

14. The user equipment according to claim 8, wherein, The period is the active time during which at least the turn-on duration timer is running.

Images