Discontinuous reception configuration method, apparatus and device for sidelink, and readable storage medium

Abstract

This application discloses a method, apparatus, device, and readable storage medium for configuring discontinuous reception on a secondary link. The method includes obtaining SL DRX parameters from the network side. In the embodiments of this application, terminals with different transmission modes can obtain SL DRX parameters from the network side. These SL DRX parameters can effectively take into account different service characteristics, which is beneficial to ensuring network resource efficiency and greatly improving the power-saving performance of the terminal while ensuring system efficiency.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and specifically relates to a method, apparatus, device and readable storage medium for configuring discontinuous reception of a secondary link. Background Technology

[0002] The introduction of the Discontinuous Reception (DRX) mechanism in the Side Link (SL) is intended to save power for some terminals (such as User Equipment (UE)). SL multicast and broadcast services are also supported. However, due to the lack of a negotiation process between the Transmit (TX) UE and the Receive (RX) UE, configuring the SL DRX parameters of terminals in the Side Link is an urgent problem to be solved. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, device, and readable storage medium for configuring discontinuous reception in a secondary link, thereby solving the problem of how to configure the SL DRX parameters of a terminal in a secondary link.

[0004] Firstly, a method for configuring discontinuous reception on a secondary link is provided, executed by a terminal, including:

[0005] Obtain SL DRX parameters from the network side.

[0006] Secondly, a method for configuring discontinuous reception on a secondary link is provided, executed by a network-side device, including:

[0007] Send SL DRX parameters to the terminal in the secondary link.

[0008] Thirdly, a discontinuous reception configuration device for a secondary link is provided, applied to a terminal, comprising:

[0009] Acquisition module: Used to obtain SL DRX parameters from the network side.

[0010] Fourthly, a discontinuous reception configuration device for a secondary link is provided, applied to network-side equipment, comprising:

[0011] The sending module is used to send SL DRX parameters to the terminals in the secondary link.

[0012] Fifthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first or second aspect.

[0013] A sixth aspect provides a program product stored in a non-volatile storage medium, the program product being executed by at least one processor to implement the steps of the processing method as described in the first or second aspect.

[0014] In a seventh aspect, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the processing method as described in the first or second aspect.

[0015] In this embodiment, terminals with different transmission modes can obtain SL DRX parameters from the network side. These SL DRX parameters can well take into account the characteristics of different services, which is conducive to ensuring network resource efficiency and greatly improving the power saving performance of the terminal while ensuring system efficiency. Attached Figure Description

[0016] Figure 1 This is a block diagram of a wireless communication system applicable to embodiments of this application;

[0017] Figure 2 This is one of the flowcharts of the discontinuous reception configuration method for a secondary link provided in the embodiments of this application;

[0018] Figure 3 This is the second flowchart of the non-continuous reception configuration method for the secondary link provided in the embodiments of this application;

[0019] Figure 4 This is one of the schematic diagrams of a discontinuous reception configuration device for a secondary link provided in an embodiment of this application;

[0020] Figure 5 This is a second schematic diagram of a non-continuous reception configuration device for a secondary link provided in an embodiment of this application;

[0021] Figure 6 This is a schematic diagram of the terminal provided in an embodiment of this application;

[0022] Figure 7 This is a schematic diagram of the network-side device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specified order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. However, the following description describes New Radio (NR) systems for illustrative purposes, and the term NR is used in most of the following description, although these technologies can also be applied to applications other than NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0026] See Figure 1The figure shows a block diagram of a wireless communication system applicable to an embodiment of this application. The wireless communication system includes a terminal 11 and a network-side device 12. The terminals 11 can establish communication connections with each other through a Sidelink interface, and the terminals 11 can establish communication connections with the network-side device 12 through a Uu port. The terminal 11 can also be referred to as a terminal device or user equipment (UE). The terminal 11 can be a mobile phone, tablet computer, laptop computer, personal digital assistant (PDA), handheld computer, netbook, ultra-mobile personal computer (UMPC), mobile internet device (MID), wearable device, vehicle-mounted device (VUE), pedestrian terminal (PUE), etc. Wearable devices include wristbands, headphones, glasses, etc. It should be noted that the specific type of terminal 11 is not limited in this embodiment of the application.

[0027] Network-side device 12 can be a base station or a core network. The base station can be referred to as a node B, evolved node B, access point, base transceiver station (BTS), radio base station, radio transceiver, basic service set (BSS), extended service set (ESS), B node, evolved B node (eNB), home B node, home evolved B node, WLAN access point, WiFi node, transmitting and receiving point (TRP), radio access network node, or any other suitable term in the field. As long as the same technical effect is achieved, the base station is not limited to the specified technical terms. It should be noted that in this application embodiment, only the base station in the NR system is used as an example, but the specific type of base station is not limited.

[0028] To facilitate understanding of the embodiments of this application, the following technical points are introduced first:

[0029] 1. Introduction to secondary links.

[0030] Starting with release 12, the Long Term Evolution (LTE) system supports sidelinks, which are used for direct data transmission between UEs without going through network devices.

[0031] LTE sidelinks are designed for specific public safety applications (such as emergency communications in disaster areas like fires or earthquakes) or vehicle-to-everything (V2X) communications. V2X communications encompass various services, including basic safety communications, advanced (autonomous) driving, platooning, and sensor extensions. Because LTE sidelinks only support broadcast communications, they are primarily used for basic safety communications. Advanced V2X services with stringent Quality of Service (QoS) requirements regarding latency and reliability will be supported through New Radio (NR) sidelinks.

[0032] The 5th generation (5G) NR system can be used in operating frequency bands above 6GHz that are not supported by LTE, and supports a larger operating bandwidth. However, the current version of the NR system only supports the interface between the base station and the terminal, and does not yet support the Sidelink interface for direct communication between terminals.

[0033] The Sidelink interface can also be called the PC5 interface.

[0034] 2. Regarding the transmission format of Sidelink.

[0035] Current sidelink transmissions include broadcast, groupcast, and unicast. Unicast is a one-to-one transmission. Groupcast is a one-to-many transmission. Broadcast is also a one-to-many transmission, but it does not have the concept of UEs belonging to the same group.

[0036] Currently, Sidelink transmission supports unicast and multicast communication with a physical layer Hybrid Automatic Repeat reQuest (HARQ) feedback mechanism.

[0037] 3. Regarding DRX.

[0038] Discontinuous reception is used for power saving, as terminals in DRX state do not need to connect to the control channel. However, if a terminal does not listen to the control channel for an extended period, data arrival will increase data transmission latency. To balance power saving and latency, 5G Medium Access Control (MAC) supports two DRX cycles—long and short—depending on the duration of the terminal's channel listening. If the predicted terminal data volume is frequent or the service is latency-sensitive, the network can configure the terminal to use a short DRX cycle; if the predicted terminal data volume is sparse and latency is not critical, the network can configure the terminal to use only a long DRX cycle. To facilitate switching between long and short DRX cycles, the long DRX cycle must be an integer multiple of the short DRX cycle to ensure alignment of their onDuration.

[0039] To support the DRX mechanism, the base station will configure DRX-related timers and parameters for the terminal, including:

[0040] (1) drx-LongCycleStartOffset: Used to configure the period and offset of the long DRX cycle. The units of the period and offset can be milliseconds.

[0041] (2) drx-ShortCycle: Used to configure the period and offset of the short DRX cycle. The units of the period and offset can be milliseconds.

[0042] (3) drx-ShortCycleTimer: Used to control the duration of short DRX cycles used by the terminal. The unit is an integer, indicating that once the terminal enters a short DRX cycle, it should maintain an integer multiple of short DRX cycles.

[0043] (4) drx-onDurationTimer: DRX continuous listening timer. During the execution of this timer, the terminal needs to continuously listen to the Physical Downlink Control Channel (PDCCH) control channel of the network. The unit of this timer can be milliseconds;

[0044] (5) drx-SlotOffset: The delay when the terminal starts drx-onDurationTimer. This parameter sets the offset of the start time of DRXonDuration relative to the start of the subframe. The offset can be an integer multiple of 1 / 32 milliseconds.

[0045] (6) drx-InactivityTimer: DRX inactivity timer. This timer starts on the first symbol after the terminal receives the PDCCH signaling for new uplink / downlink data scheduling. During the operation of this timer, the terminal needs to continuously listen to the control channel. The unit of this timer can be milliseconds.

[0046] (7) drx-HARQ-RTT-TimerDL: Downlink HARQ Round-Trip Time (RTT) timer, maintained for each downlink process. The timer length is the minimum time interval between the HARQ feedback time and the receipt of the HARQ retransmission for that process. The terminal will only start this timer on the first symbol after the HARQ NACK feedback of the downlink process if the data corresponding to that process has not been successfully decoded. If only drx-HARQ-RTT-TimerDL and / or drx-HARQ-RTT-TimerUL are running at the current terminal, the terminal does not need to listen to the PDCCH control channel, and the unit of this timer can be a symbol;

[0047] (7) drx-HARQ-RTT-TimerUL: Uplink HARQ RTT timer, maintained for each uplink process. The timer length is the minimum time interval between the transmission time of the uplink Physical Uplink Shared Channel (PUSCH) and the receipt of the HARQ retransmission for that process. After uplink PUSCH transmission, the terminal starts the uplink HARQ RTT timer for that uplink process. If PUSCH repetition is used during PUSCH transmission, the uplink HARQ RTT timer starts after the first PUSCH repetition to ensure that the base station can terminate the PUSCH repetition transmission in a timely manner after parsing the PUSCH in advance. The unit of this timer can be a symbol;

[0048] (8) drx-RetransmissionTimerDL: Downlink retransmission timer. This timer is started on the next symbol after drx-HARQ-RTT-TimerDL times out. During the operation of this timer, the terminal listens to the network control channel. If it receives downlink scheduling information or a downlink configuration grant for the process, it stops the timer. The unit of this timer can be a time slot.

[0049] (9) drx-RetransmissionTimerUL: Uplink retransmission timer. This timer is started on the next symbol after drx-HARQ-RTT-TimerUL expires. During the operation of this timer, the terminal listens to the network control channel. If it receives uplink scheduling information or an uplink configured grant for the process, it stops running. The unit of this timer is a time slot.

[0050] The existing DRX mechanism is used for the Uu interface and is configured by the network side through UE-specific RRC signaling for discontinuous reception between the network side and the UE. However, since the SL interface involves different methods of SL multicast, broadcast, and unicast between two or more UEs, there is currently no solution for configuring SL DRX.

[0051] The following description, in conjunction with the accompanying drawings, details a method, apparatus, device, and readable storage medium for configuring discontinuous reception of a secondary link provided in this application, through some embodiments and application scenarios.

[0052] See Figure 2 This application provides a method for configuring DRX in SL. The execution subject of this method can be a terminal, and the specific steps include: step 201.

[0053] Step 201: Obtain SL DRX parameters from the network side.

[0054] The SL DRX parameter (or SL DRX configuration parameter) is used to configure the terminal's DRX. The SL DRX parameter can include the DRX-related timers and parameters of the secondary link. The terminal can perform corresponding discontinuous reception operations according to the SL DRX parameter, so that the terminal can balance power saving and transmission delay.

[0055] In other words, for multicast and broadcast services, the network side can uniformly configure SL DRX parameters for the sending and receiving ends of the secondary link.

[0056] In one embodiment of this application, the step of obtaining SL DRX parameters from the network side includes any one of the following methods:

[0057] Method 1: When the transmitting end or receiving end of the secondary link is outside the coverage area (OOC), obtain the SL DRX parameters corresponding to multicast services, broadcast services and / or unicast services according to the pre-configuration message sent by the network side;

[0058] For example, when a TX UE or RX UE is offline and outside the coverage area, the TX UE or RX UE obtains the SL DRX parameters from the pre-configuration message.

[0059] Method 2: When the transmitting end or receiving end of the secondary link is in an idle state, an inactive state, or a connected state, obtain the SL DRX parameters corresponding to the multicast service and / or broadcast service according to the System Information Block (SIB) message sent by the network side;

[0060] Method 3: When the sending end or receiving end of the secondary link is in an idle or inactive state, obtain the SL DRX parameters corresponding to the unicast service according to the system information block message sent by the network side;

[0061] For example, when the TX UE or RX UE is in an idle or inactive state, the TX UE or RX UE obtains the specific SL DRX parameters from the SIB message;

[0062] Method 4: When the transmitting end or receiving end of the secondary link is in a connected state, the SL DRX parameters corresponding to the unicast service are obtained through dedicated Radio Resource Control (RRC) signaling.

[0063] Specifically, the sending end or receiving end of the secondary link in the connected state reports the service information of the sending end or receiving end to the network side.

[0064] For example, when the TX UE or RX UE is in connected state, the TX UE or RX UE sends all of its SL service information, such as QoS flow information, to the serving base station, which then sends specific SLDRX parameters to the TX UE or RX UE via a dedicated RRC message.

[0065] In one embodiment of this application, the method further includes:

[0066] When the transmitting end of the secondary link obtains the SL DRX parameters from the network side, it sends the SL DRX parameters to the receiving end of the secondary link.

[0067] For example, for unicast services, the sender of the secondary link obtains the SLDRX parameter through a pre-configured message or a system information block message, and the sender of the secondary link can send the SLDRX parameter to the receiver of the secondary link through the PC5 interface.

[0068] In one embodiment of this application, the method further includes:

[0069] When the receiving end of the secondary link obtains the SL DRX parameters from the network side, it sends the SL DRX parameters to the sending end of the secondary link.

[0070] For example, for unicast services, the receiver of the secondary link obtains the SLDRX parameter through a pre-configured message or a system information block message, and the receiver of the secondary link can send the SLDRX parameter to the sender of the secondary link through the PC5 interface.

[0071] In one embodiment of this application, the pre-configured message or system information block message includes: a set of SL DRX parameters corresponding to QoS flow or a combination of QoS flow;

[0072] The SL DRX parameter set is used to determine the SL DRX parameters by combining them with the QoS flow of the terminal's unicast, multicast, or broadcast services.

[0073] In one embodiment of this application, the SL DRX parameters satisfy the service requirements of each QoS flow in the unicast, multicast, or broadcast services of the terminal.

[0074] In one embodiment of this application, the SL DRX parameter includes a DRX cycle, wherein the DRX cycle is a specified DRX cycle in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast service, multicast service, or broadcast service, and the specified DRX cycle is selected in the SL DRX parameter set according to a preset method.

[0075] For example, the specified DRX cycle is the smallest DRX cycle selected from the SL DRX parameter set based on the sorting results. It is understood that the selection method of the specified DRX cycle is not limited in this embodiment of the application. For example, one of the DRX cycles can be selected randomly.

[0076] For example, all QoS flows include: QoS flow1, QoS flow2 and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2 and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle1, SL DRX parameter set 2 includes DRX cycle2 and SL DRX parameter set 3 includes DRX cycle3. Assuming that DRX cycle1 is greater than DRX cycle2 and DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest, then the final DRX cycle is DRX cycle3.

[0077] In one embodiment of this application, the SL DRX parameters include: the length of the onDuration timer, which is the specified onDuration timer length in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast, multicast, or broadcast services (e.g., the maximum onDuration timer length or one of the onDuration timer lengths), or the length of the onDuration timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0078] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes onDuration timer length 1, SL DRX parameter set 2 includes onDuration timer length 2, and SL DRX parameter set 3 includes onDuration timer length 3. OnDuration timer length 1 is greater than onDuration timer length 2, and onDuration timer length 2 is greater than onDuration timer length 3. That is, onDuration timer length 1 is the largest. Therefore, the final SL DRX parameters include onDuration timer length 1.

[0079] For example, all QoS flows include: QoS flow1, QoS flow2 and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2 and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle1, SL DRX parameter set 2 includes DRX cycle2 and SL DRX parameter set 3 includes DRX cycle3. Assuming that DRX cycle1 is greater than DRX cycle2 and DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest, then the final DRX cycle includes the length 3 of the onDuration timer in SL DRX parameter set 3.

[0080] In one embodiment of this application, the SL DRX parameters include: the length of the inactivity timer, wherein the length of the inactivity timer is the specified inactivity timer length in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast, multicast, or broadcast services (e.g., the maximum inactivity timer length or one of the inactivity timer lengths), or the length of the inactivity timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0081] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes Inactivity timer length 1, SL DRX parameter set 2 includes Inactivity timer length 2, and SL DRX parameter set 3 includes Inactivity timer length 3. Assuming that Inactivity timer length 1 is greater than Inactivity timer length 2, and Inactivity timer length 2 is greater than Inactivity timer length 3, that is, Inactivity timer length 1 is the largest, then the final SL DRX parameters include Inactivity timer length 1.

[0082] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle 1, SL DRX parameter set 2 includes DRX cycle 2, and SL DRX parameter set 3 includes DRX cycle 3. Assume...

[0083] DRX cycle1 is greater than DRX cycle2, DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest. Therefore, the final DRX cycle includes the Inactivity timer length 3 in the SL DRX parameter set 3.

[0084] In one embodiment of this application, the SL DRX parameters include: the length of the HARQ RTT timer, wherein the length of the HARQ RTT timer is a specified HARQ RTT timer length (e.g., the minimum HARQ RTT timer length or one of the HARQ RTT timer lengths) in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast, multicast, or broadcast services, or the length of the HARQRTT timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0085] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes HARQ RTT timer length 1, SL DRX parameter set 2 includes HARQ RTT timer length 2, and SL DRX parameter set 3 includes HARQ RTT timer length 3. Assuming that HARQ RTT timer length 1 is greater than HARQ RTT timer length 2, and HARQ RTT timer length 2 is greater than HARQ RTT timer length 3, that is, HARQ RTT timer length 1 is the smallest, then the final SL DRX parameters include HARQ RTT timer length 1.

[0086] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle 1, SL DRX parameter set 2 includes DRX cycle 2, and SL DRX parameter set 3 includes DRX cycle 3. Assume...

[0087] DRX cycle1 is greater than DRX cycle2, DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest. Therefore, the final DRX cycle includes the length of the HARQ RTT timer in the SL DRX parameter set 3.

[0088] In one embodiment of this application, the SL DRX parameters include: the length of the retransmission timer, which is a specified retransmission timer length in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast, multicast, or broadcast services (e.g., the largest retransmission timer length or one of the retransmission timer lengths), or the length of the retransmission timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0089] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes a retransmission timer length of 1, SL DRX parameter set 2 includes a retransmission timer length of 2, and SL DRX parameter set 3 includes a retransmission timer length of 3. Retransmission timer length 1 is greater than retransmission timer length 2, and retransmission timer length 2 is greater than retransmission timer length 3. That is, retransmission timer length 1 is the largest. Therefore, the final SL DRX parameters include retransmission timer length 1.

[0090] For example, all QoS flows include: QoS flow1, QoS flow2, and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2, and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle 1, SL DRX parameter set 2 includes DRX cycle 2, and SL DRX parameter set 3 includes DRX cycle 3. Assume...

[0091] DRX cycle1 is greater than DRX cycle2, DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest, so the final DRX cycle includes the Retransmission timer length 3 in the SL DRX parameter set 3.

[0092] In one embodiment of this application, the SL DRX parameters include: parameters in the SL DRX parameter set that specify the DRX cycle (e.g., the smallest DRX cycle or one of the DRX cycles) in the SL DRX parameter set corresponding to all QoS flows of the terminal's unicast service, multicast service or broadcast service.

[0093] For example, all QoS flows include: QoS flow1, QoS flow2 and QoS flow3. QoS flow1 corresponds to SL DRX parameter set 1, QoS flow2 corresponds to SL DRX parameter set 2 and QoS flow3 corresponds to SL DRX parameter set 3. SL DRX parameter set 1 includes DRX cycle1, SL DRX parameter set 2 includes DRX cycle2 and SL DRX parameter set 3 includes DRX cycle3. Assuming that DRX cycle1 is greater than DRX cycle2 and DRX cycle2 is greater than DRX cycle3, that is, DRX cycle3 is the smallest, then the final SL DRX parameters include SL DRX parameter set 3.

[0094] The above method for determining the final SL DRX parameters is as follows: if one of the SL DRX parameters is compared, the value of that parameter in the final SL DRX set can be determined based on the comparison result of that parameter, or the entire SLDRX set can be determined, that is, the SL DRX set containing that parameter is selected as the final SLDRX set based on the comparison of the values ​​of a parameter.

[0095] In one embodiment of this application, the method further includes:

[0096] The offset value of the SL DRX parameter is randomly selected based on the DRX cycle length and / or resource pool configuration.

[0097] It should be noted that randomly selecting an offset can employ existing random selection mechanisms to avoid all UEs selecting overlapping DRX patterns, which would increase the probability of collisions and lead to uneven resource utilization.

[0098] In this embodiment, terminals with different transmission modes can obtain SL DRX parameters from the network side. These SL DRX parameters can well take into account the characteristics of different services, which is conducive to ensuring network resource efficiency and greatly improving the power saving performance of the terminal while ensuring system efficiency.

[0099] See Figure 3 This application provides a method for configuring DRX of SL. The execution subject of this method can be a network-side device. The specific steps include: step 301.

[0100] Step 301: Send SL DRX parameters to the terminal in the secondary link.

[0101] The SL DRX parameter is used to configure the terminal's DRX, enabling the terminal to balance power saving and transmission latency.

[0102] In one embodiment of this application, the step of sending SL DRX parameters to the terminal includes:

[0103] The SL DRX parameters are sent to the sender or receiver of the secondary link via system information block messages, pre-configured messages, or dedicated RRC signaling.

[0104] The service types corresponding to the SL DRX parameters include one or more of the following: unicast service, multicast service, and broadcast service.

[0105] In one embodiment of this application, the pre-configured message or system information block message includes: a set of SL DRX parameters corresponding to QoS flow or a combination of QoS flow;

[0106] The SL DRX parameter set is used to determine the SL DRX parameters by combining them with the QoS flow of the transmitting end of the secondary link or the unicast, multicast or broadcast services of the secondary link.

[0107] In one embodiment of this application, the SL DRX parameters satisfy the service requirements of each QoS flow in the unicast, multicast, or broadcast services of the terminal.

[0108] In one embodiment of this application, the SL DRX parameter includes: DRX cycle, wherein the DRX cycle is a specified DRX cycle in the SL DRX parameter set corresponding to all QoS flows, and the specified DRX cycle is selected in the SL DRX parameter set according to a preset method;

[0109] In one embodiment of this application, the SL DRX parameters include: the length of the onDuration timer, wherein the length of the onDuration timer is the largest onDuration timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the onDuration timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0110] In one embodiment of this application, the SL DRX parameters include: the length of the Inactivity timer, wherein the length of the Inactivity timer is the largest Inactivity timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the Inactivity timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0111] In one embodiment of this application, the SL DRX parameters include: the length of the HARQ RTT timer, wherein the length of the HARQ RTT timer is the smallest HARQ RTT timer length in the SL DRX parameter set corresponding to all QoS flows, or the HARQ RTT timer length in the SL DRX parameter set corresponding to the specified DRX cycle.

[0112] In one embodiment of this application, the SL DRX parameters include: the length of the retransmission timer, wherein the length of the retransmission timer is the largest retransmission timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the retransmission timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0113] In one embodiment of this application, the SL DRX parameters include: parameters in a first SL DRX parameter set, wherein the first SL DRX parameter set is the SL DRX parameter set specifying the DRX cycle in the SL DRX parameter set corresponding to all QoS flows.

[0114] In this embodiment, terminals with different transmission modes can obtain SL DRX parameters from the network side. These SL DRX parameters can well take into account the characteristics of different services, which is conducive to ensuring network resource efficiency and greatly improving the power saving performance of the terminal while ensuring system efficiency.

[0115] The following describes several optional embodiments of this application, using the TX UE as the sending end and the RX UE as the receiving end as an example.

[0116] Example 1: Configure SL DRX parameters for multicast and broadcast services.

[0117] Because multicast and broadcast make it inconvenient to perform the interaction process between TX UE and RX UE to determine SL DRX parameters, a unified configuration method can be adopted to configure SL DRX parameters.

[0118] Optionally, the unified configuration of SL DRX parameters can include one or more combinations of the following:

[0119] (1) The standard specifies;

[0120] (2) Pre-configuration signaling;

[0121] (3) SIB signaling;

[0122] (4) V2X layer signaling.

[0123] Optionally, the granularity of the uniformly configured SL DRX parameters may include one or more of the following combinations:

[0124] (1) All broadcast and multicast services use SL DRX parameter set 0;

[0125] (2) Broadcast service, using SL DRX parameter set 1;

[0126] (3) Multicast services use SL DRX parameter set 2;

[0127] (4) In broadcast services, public safety or services of a specified type, use SL DRX parameter set 3;

[0128] (5) In broadcast services, commercial or specified types of services use SL DRX parameter set 4;

[0129] (6) In multicast services, for public safety or specified types of services, use SL DRX parameter set 5;

[0130] (7) In multicast services, for commercial or specified types of services, use SL DRX parameter set 6;

[0131] (8) In broadcast services, services that meet QoS flow type 1 use SL DRX parameter set 7;

[0132] (9) In broadcast services, services that meet QoS flow type 2 use SL DRX parameter set 8;

[0133] (10) In multicast services, services that meet QoS flow type 3 use SL DRX parameter set 9;

[0134] (11) In multicast services, services that meet QoS flow type 4 use SL DRX parameter set 10;

[0135] (12) Multicast or broadcast service, initiate a specified service, and use the SL DRX parameter set 11.

[0136] Essentially, the TX UE and RX UE obtain SL DRX parameter sets for multicast and broadcast services respectively. Then, the TX UE selects a suitable SL DRX parameter set based on the type of service it is about to initiate and sends the service. The RX UE selects one or more suitable SL DRX parameter sets based on the types of services it is interested in or needs to receive and listens for and receives the services. This allows the TX UE and RX UE to perform SL communication according to the same DRX pattern, which satisfies different service requirements and also saves power for the RX UE.

[0137] The method for uniformly configuring SL DRX parameters via V2X layer signaling is as follows:

[0138] Since this V2X layer signaling can be used for the negotiation of QoS requirements for groups and group services between TX UEs and RX UEs, specific SL DRX parameters can also be negotiated during this process. In other words, through the V2X layer signaling process, a group of UEs can negotiate their own SL DRX parameter configuration, and this group of TX UEs and RX UEs can obtain a set of SL DRX parameters that are different from those in the public signaling.

[0139] It should be noted that, due to broadcast or multicast services, the TX UE and RX UE need to have a completely consistent understanding of the SL DRX parameters. Therefore, all SL DRX parameter values ​​need to be unified between the two ends, including the offset, so that the TX UE and RX UE can perform transmit and receive operations in a unified manner.

[0140] For both SIB and pre-configuration methods, the selection generally depends on whether the UE is in the TX or RX state.

[0141] (1) When the TX UE or RX UE is in OOC state, it can only select the pre-configuration method to obtain the SL DRX parameter. If there is no corresponding SL DRX parameter in the pre-configuration signaling, the RX UE can only listen frequently (always), while the TX UE is not restricted.

[0142] (2) When the TX UE or RX UE is in the Idle, inactive or Connected state, the SLDRX parameter is obtained from the SIB message. If there is no corresponding SLDRX parameter in the SIB message, the receiving RX UE can only listen always, while the TX UE is not restricted.

[0143] (3) From the network side, in order to ensure that multicast / broadcast services can communicate normally, the configuration of SL DRX parameters in the pre-configuration message and the SIB message of different cells must be consistent so that TX UE and RX UE can use the same DRX pattern for sending and receiving operations.

[0144] Example 2: DRX parameters for unicast services.

[0145] Unicast services have a one-to-one PC5 RRC process between TX UE and RX UE, which allows for mutual configuration and negotiation of SL DRX parameters between TX UE and RX UE, providing a more flexible DRX parameter configuration method compared to broadcast / multicast services.

[0146] In unicast services, either the TX UE or the RX UE can determine the SL DRX parameters, and then send these parameters to the RX UE or TX UE for unified operation. The TX UE or RX UE can obtain the SL DR configuration parameters through the following methods:

[0147] When the TX UE / RX UE is in an offline state, i.e. in an OOC state, the TX UE / RX UE obtains the specific SL DRX parameters from the pre-configuration message. Since the pre-configuration signaling is a common signaling, it needs to be fully configured for all types of services that the UE may initiate. The UE selects the appropriate SL DRX parameters according to the specific service it is currently initiating. If there are no corresponding SL DRX parameters, the default SL DRX parameters are selected.

[0148] When the TX UE or RX UE is in Idle or Inactive state, the TX UE / RX UE obtains the specific SLDRX parameters from the SIB message. Similarly, the SIB message is a common signaling message, and the SIB message also needs to include all types of services that the TX UE or RX UE may initiate for comprehensive configuration. The TX UE or RX UE selects the appropriate SLDRX parameters according to the specific service currently being initiated. If there are no corresponding SLDRX parameters, the default SLDRX parameters are selected.

[0149] When the TX UE or RX UE is in the Connected state, it sends all its SL service information, such as QoS flow information, to the serving base station. The serving base station then determines the DRX parameters based on the TX UE or RX UE's service status and sends the specific SL DRX parameters to the TX UE or RX UE via a dedicated RRC message. The SL DRX parameters configured in this way are the DRX parameters suitable for the current service, and the TX UE or RX UE does not need to make any further selections or decisions; it can generally use them directly.

[0150] Since pre-configuration messages and SIB messages can be common messages, it is necessary to configure the SL DRX parameter set corresponding to each QoS flow or similar QoS flow combination, for example:

[0151] -QoS flow 1, which corresponds to a set of SL DRX parameters, or DRX configuration is not allowed;

[0152] -QoS flow a (a is greater than 1), which corresponds to a set of SL DRX parameters, or DRX configuration is not allowed;

[0153] - QoS flow list (list1), which contains one or more QoS flows, corresponding to a set of DRX parameters, or DRX configuration is not allowed;

[0154] - QoS flow list 2, which contains one or more QoS flows, each corresponding to a set of DRX parameters, or DRX configuration is not allowed;

[0155] - Alternatively, QoS flow 1-m, DRX parameter set 1-n, each QoS flow may correspond to one set of DRX parameters or may not correspond to any set of DRX parameters;

[0156] - Mark one set of DRX parameters as default;

[0157] - Explicit or implicit indication of whether to use the default SL DRX parameters or disallow DRX for QoS flows without a corresponding SL DRX parameter set;

[0158] The TX UE or RX UE obtains the final SL DRX parameters based on the QoS flow combination of its own SL unicast service using the following methods:

[0159] - The final SL DRX parameters need to meet the service requirements of each QoS flow in the SL unicast service;

[0160] - If any QoS flow in an SL unicast service cannot be configured with DRX, then this SL link will not be configured with the SL DRX parameter.

[0161] - If there is a QoS flow that does not have a directly corresponding SL DRX parameter set, and the default SL DRX parameter set is allowed to be used, then in the following steps, the QoS flow corresponds to the default SL DRX parameter set.

[0162] - The UE performs at least one of the following operations on the multiple sets of SL DRX parameters obtained from multiple QoS flows to obtain the final SL DRX parameters:

[0163] (1) Take the smallest DRX cycle in the set of SL DRX parameters corresponding to all QoS flows as the final DRX cycle;

[0164] (2) Take the length of the longest onDuration timer in the SL DRX parameter set corresponding to all QoS flows or the length of the longest onDuration timer in the parameter set corresponding to the shortest DRX cycle as the length of the final onDuration timer.

[0165] (3) Take the length of the longest Inactivity timer in the SL DRX parameter set corresponding to all QoS flows or the length of the Inactivity timer in the parameter set corresponding to the shortest DRX cycle as the length of the final Inactivity timer.

[0166] (4) Take the length of the HARQ RTT timer with the smallest HARQ RTT timer in the SL DRX parameter set corresponding to all QoS flows or the length of the HARQ RTT timer in the parameter set corresponding to the smallest DRX cycle as the length of the final HARQ RTT timer.

[0167] (5) Take the length of the largest Retransmission timer in the SL DRX parameter set corresponding to all QoS flows or the length of the Retransmission timer in the SL DRX parameter set corresponding to the smallest DRX cycle as the length of the final Retransmission timer.

[0168] (6) Take the SL DRX parameter set containing the smallest DRX cycle in the SL DRX parameter set corresponding to all QoS flows as the final DRX parameter;

[0169] (7) The UE randomly selects an offset value based on the final DRX cycle length;

[0170] (8) The UE randomly selects an offset value based on the final DRX cycle length and / or resource pool configuration.

[0171] In unicast services, since TX UEs and RX UEs can notify each other of SL DRX parameters, after determining the SL DRX parameters according to the service type, it is best to adopt a certain random selection mechanism for the offset parameter to avoid all UEs selecting overlapping DRX patterns, which would increase the probability of collisions and cause uneven resource utilization. In other words, it would prevent all UEs from sending data in the same position, leaving a lot of non-active time resources unused by any UE.

[0172] After obtaining the SL DRX parameters, the TX UE or RX UE sends them to the RX UE or TX UE via PC5 RRC. Then, the TX UE and RX UE perform data transmission and reception according to the configured DRX pattern.

[0173] Example 3: Configure SL DRX parameters for multicast, broadcast and unicast services.

[0174] The two examples above illustrate SL DRX configuration methods for different service types. It can be seen that SIB messages and pre-configuration messages are common methods for obtaining SL DRX parameters across different transmission modes.

[0175] This example illustrates how SIB messages and pre-configuration messages perform DRX configuration for different service types.

[0176] The first approach involves configuring multicast / broadcast services and unicast services independently within the SIB message and / or pre-configuration message.

[0177] For example, the SL DRX parameter configuration for multicast services, the SL DRX parameter configuration for broadcast services, and the SLDRX parameter configuration for unicast services can be performed independently. When a UE wants to send or receive a certain type of service, it searches for the appropriate SL DRX parameter in the corresponding SLDRX parameter configuration set and performs the receiving or sending operation according to the SL DRX parameter.

[0178] Alternatively, the SL DRX parameters for multicast and broadcast services can be configured jointly, while the SL DRX parameters for unicast services can be configured independently. The only difference between this and the previous method is that multicast and broadcast services are configured together. When the UE wants to send or receive a certain multicast / broadcast service, it will look for the appropriate SL DRX parameters in the unified SL DRX parameter configuration set and then perform the receiving or sending operation accordingly.

[0179] The second approach involves configuring multicast / broadcast services and unicast services in a combined manner within SIB messages and / or pre-configuration messages.

[0180] In this approach, since unicast services are configured according to the correspondence between QoS flow and SL DRX parameter sets, multicast / broadcast services can also adopt the same structure, which can be done in the following ways:

[0181] - For a specified set of SL DRX parameters, mark it as being used for multicast or broadcast services;

[0182] - Select the corresponding SL DRX parameter set according to the specific QoS requirements of multicast or broadcast services;

[0183] - Based on the default SL DRX parameter set, it is used for multicast or broadcast services.

[0184] See Figure 4 This application provides an SL DRX configuration device for a terminal, the device 400 including:

[0185] Acquisition module 401: Used to acquire SL DRX parameters from the network side.

[0186] In one embodiment of this application, the acquisition module 401 is further configured to:

[0187] When the transmitting end or receiving end of the secondary link is outside the coverage area, the SL DRX parameters corresponding to the multicast service, broadcast service and / or unicast service are obtained according to the pre-configuration message sent by the network side.

[0188] or,

[0189] When the transmitting end or receiving end of the secondary link is in an idle state, an inactive state, or a connected state, the SL DRX parameters corresponding to the multicast service and / or broadcast service are obtained according to the system information block message sent by the network side.

[0190] or,

[0191] When the sending end or receiving end of the secondary link is in an idle or inactive state, the SL DRX parameters corresponding to the unicast service are obtained according to the system information block message sent by the network side.

[0192] or,

[0193] When the transmitting end or receiving end of the secondary link is in a connected state, the SL DRX parameters corresponding to the unicast service are obtained through dedicated RRC signaling.

[0194] In one embodiment of this application, the acquisition module 401 is further configured to: report the service information of the sending end or the receiving end of the secondary link in the connected state to the network side.

[0195] In one embodiment of this application, the device 400 further includes: a transmitting module, configured to:

[0196] When the transmitting end of the secondary link obtains the SL DRX parameters from the network side, it sends the SL DRX parameters to the receiving end of the secondary link.

[0197] or,

[0198] When the receiving end of the secondary link obtains the SL DRX parameters from the network side, it sends the SL DRX parameters to the sending end of the secondary link.

[0199] In one embodiment of this application, the pre-configured message or system information block message includes: a set of SL DRX parameters corresponding to QoS flow or a combination of QoS flow;

[0200] The SL DRX parameter set is used to determine the SL DRX parameters by combining them with the QoS flow of the terminal's unicast, multicast, or broadcast services.

[0201] In one embodiment of this application, the SL DRX parameters satisfy the service requirements of each QoS flow in the unicast, multicast, or broadcast services of the transmitting end or the receiving end of the secondary link.

[0202] In one embodiment of this application, the SL DRX parameter includes: DRX cycle, wherein the DRX cycle is a specified DRX cycle in the SL DRX parameter set corresponding to all QoS flows, and the specified DRX cycle is selected in the SL DRX parameter set according to a preset method;

[0203] In one embodiment of this application, the SL DRX parameters include: the length of the onDuration timer, wherein the length of the onDuration timer is the largest onDuration timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the onDuration timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0204] In one embodiment of this application, the SL DRX parameters include: the length of the Inactivity timer, wherein the length of the Inactivity timer is the largest Inactivity timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the Inactivity timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0205] In one embodiment of this application, the SL DRX parameters include: the length of the HARQ RTT timer, wherein the length of the HARQ RTT timer is the smallest HARQ RTT timer length in the SL DRX parameter set corresponding to all QoS flows, or the HARQ RTT timer length in the SL DRX parameter set corresponding to the specified DRX cycle.

[0206] In one embodiment of this application, the SL DRX parameters include: the length of the retransmission timer, wherein the length of the retransmission timer is the largest retransmission timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the retransmission timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0207] In one embodiment of this application, the SL DRX parameters include: parameters in a first SL DRX parameter set, wherein the first SL DRX parameter set is the SL DRX parameter set specifying the DRX cycle in the SL DRX parameter set corresponding to all QoS flows.

[0208] In one embodiment of this application, the device 400 further includes:

[0209] The selection module is used to randomly select the offset value of the SL DRX parameter based on the DRX cycle length and / or resource pool configuration.

[0210] The apparatus provided in this application embodiment can achieve... Figure 2 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0211] See Figure 5 This application provides a DRX configuration device for an SL (Server-Side Array) network, applied to a network-side device. The device 500 includes:

[0212] The sending module 501 is used to send SL DRX parameters to the terminal in the secondary link.

[0213] In one embodiment of this application, the sending module 501 is further configured to: send SL DRX parameters to the sending end or receiving end of the secondary link via system information block messages, pre-configuration messages, or dedicated RRC signaling; wherein the service type corresponding to the SL DRX parameters includes one or more of the following: unicast service, multicast service, and broadcast service.

[0214] In one embodiment of this application, the pre-configured message or system information block message includes: a set of SL DRX parameters corresponding to QoS flow or a combination of QoS flow;

[0215] The SL DRX parameter set is used to determine the SL DRX parameters by combining them with the QoS flow of unicast, multicast, or broadcast services at the transmitting end or receiving end of the secondary link.

[0216] In one embodiment of this application, the SL DRX parameters satisfy the service requirements of each QoS flow in the unicast, multicast, or broadcast services of the terminal.

[0217] In one embodiment of this application, the SL DRX parameter includes: DRX cycle, wherein the DRX cycle is a specified DRX cycle in the SL DRX parameter set corresponding to all QoS flows, and the specified DRX cycle is selected in the SL DRX parameter set according to a preset method;

[0218] In one embodiment of this application, the SL DRX parameters include: the length of the onDuration timer, wherein the length of the onDuration timer is the largest onDuration timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the onDuration timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0219] In one embodiment of this application, the SL DRX parameters include: the length of the Inactivity timer, wherein the length of the Inactivity timer is the largest Inactivity timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the Inactivity timer in the SL DRX parameter set corresponding to the specified DRX cycle.

[0220] In one embodiment of this application, the SL DRX parameters include: the length of the HARQ RTT timer, wherein the length of the HARQ RTT timer is the smallest HARQ RTT timer length in the SL DRX parameter set corresponding to all QoS flows, or the HARQ RTT timer length in the SL DRX parameter set corresponding to the specified DRX cycle.

[0221] In one embodiment of this application, the SL DRX parameters include: the length of the retransmission timer, wherein the length of the retransmission timer is the largest retransmission timer length in the SL DRX parameter set corresponding to all QoS flows, or the length of the retransmission timer in the SL DRX parameter set corresponding to the specified DRX cycle;

[0222] In one embodiment of this application, the SL DRX parameters include: parameters in a first SL DRX parameter set, wherein the first SL DRX parameter set is the SL DRX parameter set specifying the DRX cycle in the SL DRX parameter set corresponding to all QoS flows.

[0223] The apparatus provided in this application embodiment can achieve... Figure 4 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0224] Figure 6 To realize the hardware structure diagram of a terminal according to an embodiment of this application, the terminal 600 includes, but is not limited to, components such as: radio frequency unit 601, network module 602, audio output unit 603, input unit 604, sensor 605, display unit 606, user input unit 607, interface unit 608, memory 609, and processor 610.

[0225] Those skilled in the art will understand that the terminal 600 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 610 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 6 The terminal structure shown does not constitute a limitation on the terminal. The terminal may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0226] It should be understood that, in this embodiment, the input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042. The GPU 6041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 606 may include a display panel 6061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 607 includes a touch panel 6071 and other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include a touch detection device and a touch controller. Other input devices 6072 may include, but are not limited to, a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0227] In this embodiment, the radio frequency unit 601 receives downlink data from the network-side device and processes it for the processor 610; additionally, it sends uplink data to the network-side device. Typically, the radio frequency unit 601 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc.

[0228] The memory 609 can be used to store software programs or instructions and various data. The memory 609 may primarily include a program or instruction storage area and a data storage area. The program or instruction storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 609 may include high-speed random access memory and non-volatile memory, wherein the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. For example, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0229] Processor 610 may include one or more processing units; optionally, processor 610 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications or instructions, and the modem processor mainly handles wireless communication, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 610.

[0230] The terminal provided in this application embodiment can achieve... Figure 2 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0231] This application also provides a network-side device. For example... Figure 7 As shown, the network-side device 700 includes an antenna 701, a radio frequency (RF) device 702, and a baseband device 703. The antenna 701 is connected to the RF device 702. In the uplink direction, the RF device 702 receives information through the antenna 701 and transmits the received information to the baseband device 703 for processing. In the downlink direction, the baseband device 703 processes the information to be transmitted and sends it to the RF device 702. The RF device 702 processes the received information and transmits it through the antenna 701.

[0232] The aforementioned frequency band processing device can be located in the baseband device 703. The method executed by the network-side device in the above embodiments can be implemented in the baseband device 703, which includes a processor 704 and a memory 705.

[0233] The baseband device 703 may, for example, include at least one baseband board on which multiple chips are disposed, such as... Figure 7As shown, one of the chips, for example, is a processor 704, which is connected to a memory 705 to call the program in the memory 705 and execute the network device operations shown in the above method embodiment.

[0234] The baseband device 703 may also include a network interface 706 for exchanging information with the radio frequency device 702, such as a common public radio interface (CPRI).

[0235] Specifically, the network-side device in this application embodiment further includes: instructions or programs stored in memory 705 and executable on processor 704, wherein processor 704 calls the instructions or programs in memory 705 to execute. Figure 5 The methods executed by each module shown achieve the same technical effect, and to avoid repetition, they will not be described in detail here.

[0236] This application embodiment also provides a program product, which is stored in a non-volatile storage medium and executed by at least one processor to implement, as described above. Figure 2 or Figure 3 The steps of the processing method described above.

[0237] This application embodiment also provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the above-described functionality. Figure 2 or Figure 3 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0238] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0239] This application embodiment also provides a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run network-side device programs or instructions to achieve the above-mentioned... Figure 3 or Figure 4 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0240] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0241] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0242] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0243] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for configuring discontinuous reception DRX on a secondary link (SL), characterized in that, The method is performed by a terminal and comprises: In a case where a transmission end of a sidelink or a reception end of the sidelink is in an idle state or an inactive state, acquiring SL DRX parameters corresponding to multicast services and / or broadcast services according to a system information block message transmitted by a network side; The system information block message comprises: a set of SL DRX parameters corresponding to a quality of service (QoS) flow or a QoS flow combination; The set of SL DRX parameters is used to determine the SL DRX parameters in combination with a QoS flow of the multicast services or the broadcast services of the transmission end of the sidelink or the reception end of the sidelink.

2. The method of claim 1, wherein, The method further comprises: The transmission end of the sidelink or the reception end of the sidelink in a connected state reports service information of the transmission end or the reception end to the network side.

3. The method of claim 1, wherein, The method further comprises: In a case where the transmission end of the sidelink acquires SL DRX parameters from the network side, the transmission end transmits the SL DRX parameters to the reception end of the sidelink; Or, In a case where the reception end of the sidelink acquires SL DRX parameters from the network side, the reception end transmits the SL DRX parameters to the transmission end of the sidelink.

4. The method of claim 1, wherein: The SL DRX parameters meet service requirements of each QoS flow in the multicast services or the broadcast services of the terminal; Or, The SL DRX parameters comprise: a DRX cycle, the DRX cycle being a specified DRX cycle in a set of SL DRX parameters corresponding to all QoS flows; Or, The SL DRX parameters comprise: a length of an on-duration timer, the length of the on-duration timer being a specified length of an on-duration timer in a set of SL DRX parameters corresponding to all QoS flows or in a set of SL DRX parameters corresponding to a specified DRX cycle; Or, The SL DRX parameters comprise: a length of an inactivity timer, the length of the inactivity timer being a specified length of an inactivity timer in a set of SL DRX parameters corresponding to all QoS flows or in a set of SL DRX parameters corresponding to a specified DRX cycle; Or, The SL DRX parameters comprise: a length of a hybrid automatic repeat request round trip time timer, the length of the hybrid automatic repeat request round trip time timer being a specified length of a hybrid automatic repeat request round trip time timer in a set of SL DRX parameters corresponding to all QoS flows or in a set of SL DRX parameters corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of a Retransmission timer, the length of the Retransmission timer being a length of a Retransmission timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of a Retransmission timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a parameter in a first SL DRX parameter set, the first SL DRX parameter set being a SL DRX parameter set in which a specified DRX cycle is located in a SL DRX parameter set corresponding to all QoS flows.

5. The method of claim 4, wherein, The method further includes: Randomly selecting an offset value of the SL DRX parameter according to the length of the DRX cycle and / or the resource pool configuration. 6.A method for configuring a discontinuous reception of a sidelink, comprising: Executed by a network side device, including: Sending, through a system information block message, a SL DRX parameter to a transmission end of a sidelink or a reception end of the sidelink; The service type corresponding to the SL DRX parameter includes one or more of the following: groupcast service and broadcast service; The system information block message includes: a SL DRX parameter set corresponding to a QoS flow or a QoS flow combination; The SL DRX parameter set is used to determine the SL DRX parameter in combination with a QoS flow of a groupcast service or a broadcast service of the transmission end of the sidelink or the reception end of the sidelink.

7. The method of claim 6, wherein The SL DRX parameter meets the service requirement of each QoS flow in the groupcast service or the broadcast service of the terminal; Or, The SL DRX parameter includes: a DRX cycle, the DRX cycle being a specified DRX cycle in a SL DRX parameter set corresponding to all QoS flows; Or, The SL DRX parameter includes: a length of an onDuration timer, the length of the onDuration timer being a length of an onDuration timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of an onDuration timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of an Inactivity timer, the length of the Inactivity timer being a length of an Inactivity timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of an Inactivity timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of a HARQ RTT timer, the length of the HARQ RTT timer being a length of a HARQ RTT timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of a HARQ RTT timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of a Retransmission timer, the length of the Retransmission timer being a length of a Retransmission timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of a Retransmission timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a parameter in a first SL DRX parameter set, the first SL DRX parameter set being a SL DRX parameter set corresponding to a specified DRX cycle in a SL DRX parameter set corresponding to all QoS flows. 8.A DRX configuration apparatus of a SL, applied to a terminal, characterized in that, Including: An acquisition module is configured to acquire SL DRX parameters corresponding to a multicast service and / or a broadcast service according to a system information block message sent by a network side, in a case where a transmission end of a sidelink or a reception end of the sidelink is in an idle state or an inactive state. The system information block message includes: a SL DRX parameter set corresponding to a quality of service QoS flow or a QoS flow combination. The SL DRX parameter set is used to determine the SL DRX parameter in combination with a QoS flow of the multicast service or the broadcast service of the transmission end of the sidelink or the reception end of the sidelink.

9. The apparatus of claim 8, wherein, The acquisition module is further configured to report service information of the transmission end or the reception end to the network side in a connected state.

10. The apparatus of claim 8, wherein The SL DRX parameter meets a service requirement of each QoS flow in the multicast service or the broadcast service of the terminal; Or, The SL DRX parameter includes: a DRX cycle, the DRX cycle being a specified DRX cycle in a SL DRX parameter set corresponding to all QoS flows; Or, The SL DRX parameter includes: a length of an onDuration timer, the length of the onDuration timer being a length of an onDuration timer specified in a SL DRX parameter set corresponding to all QoS flows or a length of an onDuration timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of an Inactivity timer, the length of the Inactivity timer being a length of an Inactivity timer in a SL DRX parameter set corresponding to all QoS flows or a length of an Inactivity timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of a HARQ RTT timer, the length of the HARQ RTT timer being a length of a HARQ RTT timer in a SL DRX parameter set corresponding to all QoS flows or a length of a HARQ RTT timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a length of a Retransmission timer, the length of the Retransmission timer being a length of a Retransmission timer in a SL DRX parameter set corresponding to all QoS flows or a length of a Retransmission timer in a SL DRX parameter set corresponding to a specified DRX cycle; Or, The SL DRX parameter includes: a parameter in a first SL DRX parameter set, the first SL DRX parameter set being a SL DRX parameter set corresponding to a specified DRX cycle in a SL DRX parameter set corresponding to all QoS flows. 11.A DRX configuration apparatus of a SL, applied to a network side device, characterized in that, Including: The sending module is used for sending SL DRX parameters to a sending end of a sidelink or a receiving end of the sidelink through a system information block message; wherein, the SL DRX parameters correspond to a service type including one or more of the following: groupcast service and broadcast service; The system information block message includes: a SL DRX parameter set corresponding to a quality of service QoS flow or a QoS flow combination; Wherein, the SL DRX parameter set is used for determining the SL DRX parameter with a QoS flow combination of the groupcast service or the broadcast service of the sending end of the sidelink or the receiving end of the sidelink.

12. The apparatus of claim 11, wherein The SL DRX parameter meets a service requirement of each QoS flow in the groupcast service or the broadcast service of the terminal; Or, The SL DRX parameter includes: a DRX cycle, the DRX cycle being a specified DRX cycle in a SL DRX parameter set corresponding to all QoS flows; Or, The SL DRX parameter includes: a length of the onDuration timer, the length of the onDuration timer being a length of the onDuration timer specified in the SL DRX parameter set corresponding to all QoS flows or a length of the onDuration timer in the SL DRX parameter set corresponding to the specified DRX cycle; Or, The SL DRX parameter includes: a length of the Inactivity timer, the length of the Inactivity timer being a length of the Inactivity timer specified in the SL DRX parameter set corresponding to all QoS flows or a length of the Inactivity timer in the SL DRX parameter set corresponding to the specified DRX cycle; Or, The SL DRX parameter includes: a length of the HARQ RTT timer, the length of the HARQ RTT timer being a length of the HARQ RTT timer specified in the SL DRX parameter set corresponding to all QoS flows or a length of the HARQ RTT timer in the SL DRX parameter set corresponding to the specified DRX cycle; Or, The SL DRX parameter includes: a length of the Retransmission timer, the length of the Retransmission timer being a length of the Retransmission timer specified in the SL DRX parameter set corresponding to all QoS flows or a length of the Retransmission timer in the SL DRX parameter set corresponding to the specified DRX cycle; Or, The SL DRX parameter includes: a parameter in the first SL DRX parameter set, the first SL DRX parameter set being the SL DRX parameter set corresponding to the specified DRX cycle in the SL DRX parameter set corresponding to all QoS flows.

13. A terminal, characterized by comprising: Including: A processor, a memory, and a program stored on the memory and executable on the processor, the program being executed by the processor to implement the steps of the method of any one of claims 1 to 5.

14. A network-side device, comprising: Including: A processor, a memory, and a program stored on the memory and executable on the processor, the program being executed by the processor to implement the steps of the method of any one of claims 6 to 7.

15. A readable storage medium, characterized by, The readable storage medium stores a program or instructions, the program or instructions being executed by the processor to implement the steps of the method of any one of claims 1 to 7.

Images