Lateral communication method and terminal equipment

Abstract

The invention relates to a sidewalk communication method and terminal equipment. The method comprises the following steps: a first terminal determines sidewalk communication resources of the first terminal based on a terminal type; according to the embodiment of the invention, more suitable sidewalk communication resources can be determined for the terminal based on the terminal type, and the sidewalk communication performance is improved.

Description

Sideline communication method and terminal device Technical Field

[0001] The present application relates to the field of communications, and more specifically, to a sideline communication method and terminal equipment. Background Art

[0002] With the increasing demand for speed, latency, high-speed mobility, and energy efficiency, coupled with the increasing diversity and complexity of future services, the 3rd Generation Partnership Project (3GPP), an international standards organization, has begun developing fifth-generation mobile communication technology (5G). Key 5G application scenarios include enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC). In 5G, terminals can be categorized according to their capabilities.

[0003] Summary of the Invention

[0004] The embodiments of the present application provide a sideline communication method and terminal device.

[0005] An embodiment of the present application provides a sideline communication method, including: a first terminal determining a sideline communication resource of the first terminal based on a terminal type.

[0006] An embodiment of the present application provides a sidelink communication method, including: a first terminal determining a sidelink SL discontinuous reception (DRX) configuration based on a terminal type.

[0007] An embodiment of the present application provides a first terminal, including: a processing unit, configured to determine a sideline communication resource of the first terminal based on a terminal type.

[0008] An embodiment of the present application provides a first terminal, including: a processing unit, configured to determine an SL DRX configuration based on a terminal type.

[0009] An embodiment of the present application provides a terminal device, comprising a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the terminal device executes the above-mentioned sideline communication method.

[0010] The embodiment of the present application provides a chip for implementing the above-mentioned sideline communication method. Specifically, the chip includes: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes the above-mentioned sideline communication method.

[0011] An embodiment of the present application provides a computer-readable storage medium for storing a computer program. When the computer program is executed by a device, the device executes the above-mentioned sideline communication method.

[0012] An embodiment of the present application provides a computer program product, including computer program instructions, which enable a computer to execute the above-mentioned sideline communication method.

[0013] An embodiment of the present application provides a computer program, which, when executed on a computer, enables the computer to execute the above-mentioned sideline communication method.

[0014] In the embodiments of the present application, more suitable sideline communication resources and / or sideline transmission modes can be determined for the terminal based on the terminal type, thereby improving the sideline communication performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG1 is a schematic diagram of a timer start mechanism according to an embodiment of the present application.

[0016] FIG2 is a schematic flowchart of a sideline communication method according to an embodiment of the present application.

[0017] FIG3 is a schematic flowchart of a sideline communication method according to an embodiment of the present application.

[0018] FIG4 is a schematic flowchart of a sideline communication method according to another embodiment of the present application.

[0019] FIG5 is a schematic diagram of a specific SL DRX configuration according to an embodiment of the present application.

[0020] FIG6 is a schematic block diagram of a first terminal according to an embodiment of the present application.

[0021] FIG7 is a schematic block diagram of a first terminal according to an embodiment of the present application.

[0022] FIG8 is a schematic block diagram of a first terminal according to another embodiment of the present application.

[0023] FIG9 is a schematic structural diagram of a communication device according to an embodiment of the present application.

[0024] FIG10 is a schematic block diagram of a chip according to an embodiment of the present application.

[0025] FIG11 is a schematic block diagram of a communication system according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0027] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as: Global System of Mobile communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, Advanced Long Term Evolution (LTE-A) system, New Radio (NR) system, NR system evolution system, LTE on unlicensed spectrum (LTE-U) system, NR on unlicensed spectrum (NR-U) system, Non-Terrestrial Networks (NTN) system, Universal Mobile Telecommunication System (UMTS), Wireless Local Area Networks (WLAN), Wireless Fidelity (Wireless Fidelity) system. Fidelity, WiFi), fifth-generation communication (5th-Generation, 5G) system or other communication systems, etc.

[0028] Generally speaking, traditional communication systems support a limited number of connections and are easy to implement. However, with the development of communication technology, mobile communication systems will not only support traditional communications, but will also support, for example, device-to-device (D2D) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), vehicle-to-vehicle (V2V) communication, or vehicle-to-everything (V2X) communication, etc. The embodiments of the present application can also be applied to these communication systems.

[0029] In one embodiment, the communication system in the embodiment of the present application can be applied to a carrier aggregation (CA) scenario, a dual connectivity (DC) scenario, and a standalone (SA) networking scenario.

[0030] In one embodiment, the communication system in the embodiment of the present application can be applied to an unlicensed spectrum, wherein the unlicensed spectrum can also be considered as a shared spectrum; or, the communication system in the embodiment of the present application can also be applied to an authorized spectrum, wherein the authorized spectrum can also be considered as an unshared spectrum.

[0031] The embodiments of the present application describe various embodiments in conjunction with network devices and terminal devices, wherein the terminal device may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device, etc.

[0032] The terminal device can be a station (STAION, ST) in a WLAN, a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA) device, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, a terminal device in a next-generation communication system such as an NR network, or a terminal device in a future evolved Public Land Mobile Network (PLMN) network, etc.

[0033] In an embodiment of the present application, the terminal device can be deployed on land, including indoors or outdoors, handheld, wearable or vehicle-mounted; it can also be deployed on the water surface (such as ships, etc.); it can also be deployed in the air (such as airplanes, balloons and satellites, etc.).

[0034] In an embodiment of the present application, the terminal device may be a mobile phone, a tablet computer, a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, or a wireless terminal device in a smart home, etc.

[0035] As an example and not a limitation, in the embodiment of the present application, the terminal device may also be a wearable device. Wearable devices may also be called wearable smart devices, which are a general term for wearable devices that are intelligently designed and developed using wearable technology for daily wear, such as glasses, gloves, watches, clothing, and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are fully functional, large in size, and can achieve complete or partial functions without relying on smartphones, such as smart watches or smart glasses, as well as those that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0036] In an embodiment of the present application, the network device may be a device for communicating with a mobile device. The network device may be an access point (AP) in WLAN, a base station (BTS) in GSM or CDMA, a base station (NodeB, NB) in WCDMA, an evolved base station (eNB or eNodeB) in LTE, or a relay station or access point, or a vehicle-mounted device, a wearable device, and a network device (gNB) in an NR network, or a network device in a future evolved PLMN network or a network device in an NTN network, etc.

[0037] As an example and not a limitation, in an embodiment of the present application, the network device may have a mobile feature, for example, the network device may be a mobile device. Alternatively, the network device may be a satellite or a balloon station. For example, the satellite may be a low earth orbit (LEO) satellite, a medium earth orbit (MEO) satellite, a geostationary earth orbit (GEO) satellite, a high elliptical orbit (HEO) satellite, etc. Optionally, the network device may also be a base station set up in a location such as land or water.

[0038] In an embodiment of the present application, the network device can provide services for a cell, and the terminal device communicates with the network device through the transmission resources used by the cell (for example, frequency domain resources, or spectrum resources). The cell can be a cell corresponding to the network device (for example, a base station). The cell can belong to a macro base station or a base station corresponding to a small cell. The small cells here may include: metro cells, micro cells, pico cells, femto cells, etc. These small cells have the characteristics of small coverage and low transmission power, and are suitable for providing high-speed data transmission services.

[0039] It should be understood that the terms "system" and "network" are often used interchangeably herein. The term "and / or" is simply a description of an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " generally indicates that the related objects are in an "or" relationship.

[0040] It should be understood that the "indication" mentioned in the embodiments of this application can be a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association between A and B.

[0041] In the description of the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and being indicated, configuration and being configured, etc.

[0042] To facilitate understanding of the technical solutions of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below. The following relevant technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the protection scope of the embodiments of the present application.

[0043] In 5G, NR can be deployed independently. To reduce air interface signaling and quickly restore wireless connections and data services in 5G networks, a new Radio Resource Control (RRC) state, RRC_INACTIVE, is defined. This state is different from RRC_IDLE and RRC_ACTIVE states.

[0044] RRC_IDLE: Mobility is based on UE cell reselection. Paging is initiated by the Core Network (CN), and the paging area is configured by the CN. There is no UE Access Stratum (AS) context on the base station side. No RRC connection exists.

[0045] RRC_CONNECTED: An RRC connection exists, and a UE AS context exists between the eNodeB and the UE. The network knows the UE's location at the cell level. Mobility is controlled by the network. Unicast data can be transmitted between the UE and the eNodeB.

[0046] RRC_INACTIVE: Mobility is based on UE cell reselection. A CN-RAN connection exists. The UE AS context exists on a base station. Paging is triggered by the Radio Access Network (RAN). RAN-based paging areas are managed by the RAN. The network knows the UE's location at the RAN paging area level.

[0047] Low-Capability (RedCap) Terminal Application Scenarios

[0048] In addition to the application scenarios supported by Release 15 / R16 NR, such as eMBB and URLLC, IoT use cases such as industrial wireless sensors, video surveillance, and wearable devices are placing new demands on 5G terminals, including reduced complexity and cost, smaller size, and lower energy consumption. To address this, Release 17 NR introduces low-capability (RedCap) devices. RedCap devices are primarily used in the following scenarios.

[0049] Industrial Wireless Sensors: Compared to URLLC, these devices have relatively low latency and reliability requirements. Furthermore, their cost and power consumption are lower than those of URLLC and eMBB. Key requirements and features for this type of terminal include: 99.99% communication reliability, end-to-end latency <100ms, a reference data rate of less than 2Mbps with uplink services as the primary focus, stationary devices, and a battery life of several years. For safety-related sensors, latency requirements are even lower, for example, 5-10ms.

[0050] Video surveillance is primarily used in smart cities, industrial factories, and other areas for visual monitoring. Data collection and processing in smart cities facilitates more efficient monitoring and control of urban resources, providing more effective services to residents. Video surveillance primarily relies on uplink services, with other key requirements including: a reference rate of 2-4 Mbps for standard-resolution video, latency below 500ms, and communication reliability of 99%-99.9%. High-definition video requires a rate of 7.5-25 Mbps.

[0051] Wearables include smartwatches, smart bracelets, electronic health devices, and some medical monitoring equipment. These devices share a common characteristic: small size. Key performance requirements for these terminal devices include downlink and uplink reference rates of 5-50 Mbps and 2-5 Mbps, respectively; downlink and uplink peak rates of 150 Mbps and 50 Mbps, respectively. Battery life is required to last for several days or even one to two weeks.

[0052] Technical solutions to reduce terminal complexity and costs

[0053] To achieve higher peak rates, frequency efficiency, and network capacity for eMBB applications, the 3GPP standard places high demands on eMBB UEs. For example, for NR Frequency Range 1 (FR1), eMBB UEs must support 100MHz carrier bandwidth, four receive links (4Receive, 4Rx), four-stream Multiple-Input Multiple-Output (MIMO) transmission, 256-bit Quadrature Amplitude Modulation (QAM), and peak rates exceeding 1Gbps. This places high demands on the terminal's RF components and baseband chip processing capabilities, leading to higher complexity and cost for eMBB UEs.

[0054] For RedCap UE, in the R17 RedCap System Information (SI) stage, the terminal capability requirements can be reduced in the following aspects, thereby reducing complexity and cost.

[0055] 1. Reduce the maximum UE bandwidth

[0056] To enable coexistence between RedCap and non-RedCap UEs sharing the same Synchronization Signal / Physical Broadcast Channel (SS / PBCH) blocks, Control Resource Set (CORESET) 0, and System Information Block (SIB) 1, 3GPP has agreed to reduce the maximum bandwidth for RedCap UEs in the FR1 band from 100 MHz to 20 MHz. Simultaneously, the maximum bandwidth for RedCap UEs in the FR2 band has been reduced to 100 MHz.

[0057] 2. Reduce the number of UE Rx antennas

[0058] On frequency bands that require normal NR UEs to support at least 2 receive antenna ports, the minimum number of receive antennas supported by RedCap UEs is 1. On these frequency bands, the number of receive antennas supported by RedCap UEs can also be 2.

[0059] On frequency bands where a standard NR UE is required to support at least four receive antenna ports, the minimum number of receive antennas supported by a RedCap UE is 1. On these frequency bands, the number of receive antennas supported by a RedCap UE can also be 2.

[0060] 3. Reduce the number of UE MIMO layers

[0061] For RedCap UEs with one receiving antenna, one layer of downlink (DL) MIMO is supported.

[0062] For RedCap UEs with 2 receive antennas, 2-layer DL MIMO is supported.

[0063] 4. Reduce the maximum modulation order

[0064] Using a lower modulation order can reduce the requirements for RF devices and baseband chip processing capabilities. During the SI phase, the following options were studied to relax the maximum modulation order:

[0065] (1) For the uplink (UL):

[0066] FR1: The highest modulation order is reduced from 64QAM to 16QAM;

[0067] FR2: The highest modulation order is reduced from 64QAM to 16QAM.

[0068] (2) For DL:

[0069] FR1: The highest modulation order is reduced from 256QAM to 64QAM;

[0070] FR2: The highest modulation order is reduced from 64QAM to 16QAM.

[0071] 5. Half-duplex Frequency Division Duplex (FDD)

[0072] Compared with full-duplex FDD, half-duplex FDD mode allows RedCap UE to transmit and receive at different frequencies at different times. In terms of implementation, cheaper transceiver switches and low-pass filters can be used instead of more expensive duplexers.

[0073] In LTE, two Half-Duplex (HD)-FDD modes are defined for UEs: Type A and Type B. Considering that HD-FDD Type B is too complex, 3GPP RAN decided to support HD-FDD Type B operation through Rel-17 FDD RedCap UE.

[0074] 6. Relax terminal processing time

[0075] A certain amount of processing time is required between the UE receiving the Physical Downlink Shared Channel (PDSCH) and sending uplink Hybrid Automatic Repeat-reQuest (HARQ) feedback, and between receiving the Physical Downlink Control Channel (PDCCH) indicating uplink scheduling and sending the Physical Uplink Shared Channel (PUSCH). Higher UE hardware processing capabilities shorten this processing time. Relaxing UE processing time requirements—allowing longer processing time—can reduce requirements on the receiver processing module and reduce UE costs.

[0076] 7. Reduce the maximum number of Data Resource Blocks (DRBs) that the terminal must support

[0077] In Rel-15 / Rel-16, the maximum number of DRBs supported by a UE is 8, and this capability is mandatory. Based on the three major application scenarios currently supported by RedCap, UEs generally do not handle multiple concurrent services. Furthermore, the number of DRBs directly affects the UE's buffer and memory size. Therefore, reducing the maximum number of DRBs supported by a UE can be considered to reduce terminal costs.

[0078] 8. Reduce the size of the layer 2 cache

[0079] The Layer 2 buffer size depends primarily on the peak uplink and downlink traffic and the Radio Link Control (RLC) round-trip time (RTT). Compared to Rel-15 / Rel-16NR UEs, RedCap UEs require lower peak rates, and their Layer 2 buffer size can be reduced accordingly.

[0080] 9. Reduce the Packet Data Convergence Protocol (PDCP) / RLC sequence number (Serial

[0081] Number, SN) length

[0082] The RLC / PDCP SN length is related to the sliding window length that the RLC / PDCP layer must support. In Rel-15 / Rel-16, an 18-bit SN length is supported for PDCP and RLC Access Module (AM) mode. If the buffer size of a RedCap UE is reduced compared to Rel-15 / Rel-16, then the 18-bit RLC / PDCP SN length is not mandatory for RedCap UEs.

[0083] 10. Paging for Redcap UE in Uu

[0084] A UE in RRC_IDLE or RRC_INACTIVE state monitors paging in the paging search space of the DL initial bandwidth (Bandwidth Part, BWP). The network broadcasts the configuration information of the DL initial BWP via SIB1, including the DL initial BWP bandwidth and the paging search space. For a 15kHz subcarrier spacing, the maximum configurable bandwidth of the DL initial BWP is 20MHz, which means that the frequency domain bandwidth (CORESET bandwidth) corresponding to the paging search space of the DL initial BWP can support a maximum of 20MHz.

[0085] In the FR1 band, standard NR UEs support a maximum bandwidth of 100 MHz, while RedCap UEs introduced in Rel-17 support a maximum bandwidth of 20 MHz. Both UEs can operate normally in the DL initial BWP bandwidth.

[0086] In order to further reduce the terminal cost of RedCap, lower bandwidth capabilities can be introduced for RedCap UE in Rel-18. For example, the maximum bandwidth supported by some low-end RedCap UEs can be further reduced to 10MHz or 5MHz. For this type of low-bandwidth RedCap UE, if the DL initial BWP bandwidth or paging search space bandwidth broadcast by the network is 20MHz, these UEs will not be able to work normally on the DL initial BWP or will not be able to receive paging normally. One solution is to separately configure the DL initial BWP bandwidth or paging search space / CORESET for this type of low-bandwidth RedCap UE.

[0087] 5G NR paging mechanism

[0088] The main function of Paging is to enable the network to page the UE through a paging message when the UE is in the RRC_IDLE or RRC_INACTIVE state, or to notify the UE of system message changes or earthquake, tsunami / public warning information through a short message (applicable to all RRC states of the UE, including the connected state).

[0089] Paging consists of a PDCCH scrambled by a Paging Radio Network Temporary Identity (P-RNTI) and a PDSCH scheduled by the PDCCH. Paging messages are transmitted on the PDSCH. Short messages are 8 bits long and are carried on the PDCCH.

[0090] For UEs in RRC_IDLE or RRC_INACTIVE states, since there is no other data communication between the UE and the network, in order to save power, the UE can monitor the paging channel discontinuously, that is, adopt the paging discontinuous reception (DRX) mechanism. Under the paging DRX mechanism, the UE only needs to monitor paging during one paging occasion (PO) in each DRX cycle. In some regulations, a PO is composed of multiple PDCCH monitoring occasions in the paging search space. A PO contains X PDCCH monitoring occasions, where X is equal to the number of SSBs actually sent as broadcast in the MIB. There is also the concept of a paging frame (PF). PF refers to a radio frame (fixed 10ms), which can contain multiple POs or the starting positions of multiple POs.

[0091] The paging DRX cycle is determined by the common cycle in the system broadcast and the dedicated cycle configured in the higher-layer signaling (Non-Access Stratum (NAS) signaling). The UE takes the minimum of the two as the paging cycle. From the network perspective, a paging DRX cycle can have multiple POs. The position where the UE monitors the PO is related to the UE ID. The PF and PO of a specific UE in a paging DRX cycle are determined as follows:

[0092] The PF system frame number (SFN) is determined by the following formula:

[0093] (SFN+PF_offset)mod T=(T div N)*(UE_ID mod N)

[0094] The index (i_s) of a PO within a PF is determined by the following formula:

[0095] i_s=floor(UE_ID / N)mod Ns

[0096] The explanations of some of the above parameters are as follows:

[0097] T: The DRX cycle during which the UE receives paging. The network broadcasts a default DRX cycle. If the RRC / higher layers configure a UE-specific DRX cycle for the UE, the minimum of the network-broadcast DRX cycle and the RRC / higher layer-configured UE-specific DRX cycle is used as the UE's DRX cycle. If the RRC / higher layers do not configure a UE-specific DRX cycle for the UE, the network-broadcast DRX cycle is used as the UE's DRX cycle.

[0098] N: Number of PFs in a DRX cycle

[0099] Ns: Number of POs contained in a PF

[0100] PF_offset: A time domain offset used to determine PF.

[0101] UE_ID:5G-S-TMSI mod 1024

[0102] An example configuration of the above parameters is as follows:

[0103] After the UE calculates the PF, the index of the PO, and the number of PDCCH monitoring occasions in the PO using the above formula, it only needs to determine the starting position of the first PDCCH monitoring occasion in the PO through relevant configuration parameters. This starting position is configured through higher-layer signaling. The UE performs blind detection of paging messages based on the determined PO.

[0104] NR Sidelink

[0105] There is no paging process in the sidelink. UEs discover other UEs through the discovery process or unicast connection establishment request (Direct Communication Request (DCR) message), as follows:

[0106] 1. Model A discovery (“I am here”):

[0107] This mode defines two roles for UEs participating in discovery.

[0108] Notification UE: The UE announces certain information, which can be used by neighboring UEs with discovery rights.

[0109] Monitoring UE: A monitoring UE that is advertising certain information of interest in the vicinity of the UE.

[0110] In this mode, an advertising UE broadcasts discovery messages at predefined discovery intervals, and monitoring UEs that are interested in these messages read and process the discovery messages.

[0111] This mode is equivalent to "I am here" in that the announcing UE will broadcast information about itself.

[0112] 2. Model B discovery (“Who’s there?” / “Are you there?”):

[0113] This mode defines two roles for UEs participating in discovery.

[0114] Discovering UEs: The UE sends a request containing certain information about what it is interested in discovering.

[0115] Discovered UE: The UE that receives the request message can respond with some information related to the discoverer's request.

[0116] This mode is equivalent to "Who's there / Are you there?" because the discovering UE sends information about other discovered UEs. This information can be a Proximity Based Service (ProSe) application identifier corresponding to a group, and the members of the group can respond.

[0117] 3. Based on DCR message solution:

[0118] In this solution, UEs do not use discovery messages to discover target UEs. Instead, they utilize the existing DCR message. The source UE broadcasts a DCR message containing information about the target UE. The relay UE receives the message and forwards it to the target UE, completing the discovery process.

[0119] SL DRX

[0120] The sidelink discontinuous reception (DRX) mechanism satisfies the power saving requirement in sidelink communication by controlling the "activation" and "inactivation" of the UE's receiving behavior on the sidelink.

[0121] Similar to the discontinuous reception technology in the downlink, some similar timers are also defined in the sidelink to control the DRX behavior in SL communication. The following examples are given:

[0122] 1. SL DRX duration (sl-drx-onDurationTimer): Periodic DRX activation timer, the length of time the UE waits to receive PSCCH / PSSCH after activation. If the UE successfully decodes the PSCCH / PSSCH, the UE starts the inactivation timer and remains in the active state;

[0123] 2.SL DRX inactivity timer (sl-drx-InactivityTimer): Before this timer expires, the UE remains active and waits to receive the next new PSCCH / PSSCH transmission. Each time a new data transmission is received, the UE restarts the timer.

[0124] 3.SL DRX Retransmission Timer (sl-drx-RetransmissionTimer): The maximum time that the UE remains active and waits to receive the next retransmitted PSCCH / PSSCH for a specific sidelink transmission process;

[0125] 4.SL DRX Round Trip Timer (sl-drx-HARQ-RTT-Timer): Before this timer expires, the UE does not expect to receive retransmissions for a specific sidelink transmission process;

[0126] 5. SL DRX cycle (sl-drx-Cycle): The length of time between the start of one DRX duration and the start of the next DRX duration.

[0127] The SL DRX timer start mechanism is shown in Figure 1:

[0128] At T1: the receiving UE is in the DRX active state, receives a new transmission message, and opens the sl-drx-InactivityTimer. Data reception can be performed during the running of the sl-drx-InactivityTimer.

[0129] Time T2: The receiving UE fails to decode the message and feedback is negative acknowledgment (NACK). The sl-drx-HARQ-RTT-Timer is turned on after the corresponding PSFCH.

[0130] T3: After the sl-drx-HARQ-RTT-Timer times out, the corresponding sl-drx-RetransmissionTimer is opened to wait for the retransmission message;

[0131] Time T4: The retransmitted message is received.

[0132] In addition to the above timers, the SL also defines some additional active times, such as the time slot for periodic transmission announced by the transmitting UE.

[0133] In the sidelink scenario, Redcap UE is supported. Since Redcap UE has weak capabilities, referring to the enhancements for paging on Uu, when UE discovers other UEs / is discovered by other UEs, certain enhancements are also needed to reduce the requirements for UE capabilities and / or reduce UE energy consumption. For example, Redcap terminals can be used in the following scenarios:

[0134] 1. Both the sending and receiving terminals are Redcap terminals;

[0135] 2. The sending terminal is a normal terminal and the receiving terminal is a Redcap terminal

[0136] 3. The sending terminal is a Redcap terminal and the receiving terminal is a normal terminal

[0137] The ordinary terminal in the embodiment of the present application is a terminal type opposite to the Redcap terminal, and the ordinary terminal can also be called a non-Redcap terminal.

[0138] FIG2 is a schematic flow chart of a sideline communication method 200 according to an embodiment of the present application. The method can optionally be applied to the system shown in FIG1 , but is not limited thereto. The method includes at least part of the following contents.

[0139] S210. The first terminal determines a sideline communication resource of the first terminal based on the terminal type.

[0140] In a sidelink scenario, terminals can be categorized into types such as normal terminals and low-capability (RedCap) terminals based on their capabilities. Appropriate sidelink communication resources can be determined for the first terminal based on its terminal type. For example, RedCap terminals typically have weaker capabilities than normal terminals. Sidelink communication resources, such as transmit and / or receive resources, configured for RedCap terminals can relax requirements on RedCap terminal capabilities, thereby further conserving power.

[0141] In an embodiment of the present application, the first terminal may determine the sideline communication resources of the first terminal based on the terminal type of the first terminal, or may determine the sideline communication resources of the first terminal based on the terminal type of the opposite terminal, such as the second terminal.

[0142] In one embodiment, the sidelink communication resources include a sidelink resource pool. In this embodiment of the present application, the sidelink resource pool may include time domain resources and / or frequency domain resources that the first terminal is allowed to use for sidelink transmission. The sidelink resource pool may include a sidelink transmit resource pool and / or a sidelink receive resource pool.

[0143] In one embodiment, the sideline resource pool includes a specific resource pool, which may be a specific resource pool for RedCap terminals.

[0144] In one embodiment, the specific resource pool is protocol-specified, default, or network-configured. For example, a specific resource pool for RedCap terminals may be specified in the protocol of the first terminal. For another example, a default specific resource pool for RedCap terminals may be pre-set in the first terminal. For another example, the first terminal may receive resource pool configuration information from a network device, where the resource pool configuration information indicates information about the specific resource pool for RedCap terminals.

[0145] In one embodiment, the specific resource pool is configured in at least one of an RRC, a SIB, and a pre-configuration. For example, the first terminal receives RRC, SIB, or pre-configuration information from a network device, where the RRC, SIB, or pre-configuration information indicates a specific resource pool for a RedCap terminal. In one embodiment, the specific resource pool may also be configured by another terminal.

[0146] In one embodiment, the specific resource pool is used to transmit at least one of the following: data associated with a Redcap terminal; data not associated with a Redcap terminal. For example, the specific resource pool may be used only to transmit data associated with a Redcap user. For another example, the specific resource pool may be used to transmit both data associated with a Redcap user and data not associated with a Redcap user.

[0147] In one embodiment, the first terminal determines at least one of the following based on the first information:

[0148] Whether the first terminal and / or the opposite terminal is a Redcap terminal;

[0149] Whether the first terminal and / or the opposite terminal supports Redcap terminal;

[0150] Whether the first terminal and / or the opposite terminal supports the Redcap service;

[0151] Whether the first terminal and / or the opposite terminal uses the specific resource pool.

[0152] In one embodiment, the first information includes at least one of the following:

[0153] The layer 2 (Layer, L2) identifier (ID), upper layer (such as NAS) indication, service type, service ID, quality of service (QoS) flow and transmission profile (Tx Profile) of the first terminal and / or the opposite terminal.

[0154] For example, the first terminal determines whether to use a specific resource pool for Redcap terminals based on its own L2 ID. For another example, the first terminal determines whether to use a specific resource pool for Redcap terminals based on the L2 ID of the opposite terminal, such as the second terminal.

[0155] In one embodiment, the service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted. For example, the first terminal determines whether to use a specific resource pool for Redcap terminals based on the service ID and / or service type of the data to be transmitted. For another example, the first terminal determines whether to use a specific resource pool for Redcap terminals based on the QoS flow of the data to be transmitted.

[0156] In one embodiment, the first terminal determines whether to use a specific resource pool for Redcap terminals based on a configuration file. For example, a configuration file associated with the data to be sent or associated with a service of the data to be sent may indicate whether the first terminal uses a specific resource pool for Redcap terminals.

[0157] In the embodiments of the present application, the first terminal may be a transmitting terminal or a receiving terminal. The transmitting terminal may also be referred to as a transmitting end or a sender. The receiving terminal may also be referred to as a receiving end or a receiver. The first terminal may be a Redcap terminal or a non-Redcap terminal. The resource configuration methods corresponding to different types of terminals are described below.

[0158] In one embodiment, the specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

[0159] For example, if the transmitting terminal is a Redcap terminal, the transmitting terminal may use resources in its own specific transmitting resource pool to transmit the side information. In this case, the transmitting terminal may not distinguish the terminal type of the receiving terminal.

[0160] In one embodiment, the specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal or a non-Redcap terminal, and the first terminal is a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

[0161] For example, if both the transmitting terminal and the receiving terminal are Redcap terminals, the transmitting terminal may use the transmission resources in its own specific transmission resource pool to transmit the sideline information. For another example, if the transmitting terminal is a non-Redcap terminal and the receiving terminal is a Redcap terminal, and the transmitting terminal is able to obtain the terminal type of the receiving terminal, the transmitting terminal may use the resources in the specific transmission resource pool for the receiving terminal to transmit the sideline information.

[0162] In one embodiment, the specific resource pool includes a specific receiving resource pool, the first terminal is a Redcap terminal and a receiving terminal, the sending terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the receiving terminal for reception are in the specific receiving resource pool.

[0163] For example, if the receiving terminal is a RedCap terminal, it can use resources in its own specific receiving resource pool to receive sideline information. In this case, the receiving terminal may not distinguish the terminal type of the transmitting terminal. Furthermore, the receiving terminal can also determine the receiving resource pool to use based on the type of the transmitting terminal. For example, if the transmitting terminal is a RedCap terminal, the receiving terminal can use a specific receiving resource pool to receive information from the transmitting terminal; if the transmitting terminal is not a RedCap terminal, the receiving terminal can use all receiving resource pools to receive information from the transmitting terminal.

[0164] In one embodiment, the sidelink resource pool includes all configured resource pools. For example, the first terminal uses resources in all configured resource pools to send and / or receive sidelink information.

[0165] In one embodiment, all configured resource pools include all configured sending resource pools, the first terminal is a non-Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in all configured sending resource pools.

[0166] For example, if the transmitting terminal is a non-Redcap terminal, or a normal terminal, and the transmitting terminal knows that the other terminal is a Redcap terminal, the transmitting terminal can use all configured transmission resource pools to transmit the sidelink information. Thus, if all configured transmission resource pools of the first terminal include a transmission resource pool for Redcap terminals, the other terminal, i.e., the receiving terminal, can receive the sidelink information to the greatest extent possible, thereby improving the Redcap terminal's reception success rate.

[0167] In one embodiment, all configured resource pools include all configured receiving resource pools, the first terminal is a non-Redcap terminal and a receiving terminal, and the sideline communication resources used by the receiving terminal for reception are in all configured resource pools.

[0168] For example, if the receiving terminal is a non-Redcap terminal, in order to improve the reception success rate, the resources of all configured receiving resource pools can be used to receive the sideline information.

[0169] In one embodiment, if all configured resource pools do not include a specific resource pool configured by the network, the resource pool used by the receiving terminal is a non-specific resource pool or the receiving terminal does not support the Redcap service within the coverage area of ​​the network. The receiving terminal may not receive signaling and / or data related to the Redcap service.

[0170] In one embodiment, a specific resource pool is mapped to at least one of a terminal, an L2 ID, and a service. In this embodiment of the present application, a specific resource pool may be used for different terminals, for different L2 IDs, or for different services.

[0171] In one embodiment, the L2 ID includes a source L2 ID and / or a target L2 ID. In this embodiment of the present application, specific resource pools may be used for different source L2 IDs. For example, if source L2 ID or target L2 ID X is mapped to resource pool 1, the terminal may use resource pool 1 to send data to target L2 ID X or receive data from source L2 ID X.

[0172] In one embodiment, the mapping relationship is specified by a protocol, defaulted, or configured by a network.

[0173] In one embodiment, the mapping relationship is configured in at least one of an RRC, an SIB, and a pre-configuration. For example, the first terminal receives RRC, SIB, or pre-configuration information from a network device, where the RRC, SIB, or pre-configuration information indicates a mapping relationship between a specific resource pool and at least one of a terminal, an L2 ID, and a service.

[0174] In one embodiment, the data to be transmitted by the first terminal is specific data for a Redcap terminal, and a specific resource pool for the specific data is configured.

[0175] In an embodiment of the present application, a specific resource pool may be configured for specific data of a Redcap terminal. In the first terminal, different specific resource pools may be configured for specific data of different Redcap terminals. For example, the specific resource pool configured for specific data Data1 is S1, and the specific resource pool configured for specific data Data2 is S2.

[0176] In one embodiment, the resource pool used by the transmitting terminal is a specific resource pool for the specific data. For example, a first terminal is a transmitting terminal, and a second terminal is a receiving terminal and a Redcap terminal. If the first terminal's to-be-transmitted data, Data1, is specific data for the second terminal, and a specific resource pool, S1, is configured for Data1, the first terminal can use the resources in S1 to send Data1 to the second terminal.

[0177] In one embodiment, the current resource of the sending terminal is a resource in a specific resource pool for the Redcap terminal, and the sending terminal sends the specific data on the current resource.

[0178] For example, the current resource of the transmitting terminal may be a currently used transmitting resource. If the current resource of the transmitting terminal is within a specific resource pool of the Redcap terminal, the specific data for the Redcap terminal may continue to be sent using the current resource.

[0179] In one embodiment, the specific data includes data for the L2 ID of the Redcap terminal.

[0180] For example, when assembling a data packet associated with the specific resource, the L2 ID for the Redcap terminal may be selected as the target address for assembling data according to the terminal capability of the Redcap terminal.

[0181] In one embodiment, the specific data includes data in a specific logical channel.

[0182] In one embodiment, the data in the specific logical channel includes data associated with at least one of a DCR message, a discovery message, a multicast message, and a broadcast message. The DCR message and / or the discovery message does not include a QoS flow. The multicast message and / or the broadcast message does include a QoS flow. The first terminal may use a specific transmission resource pool to transmit data associated with at least one of the DCR message, the discovery message, the multicast message, and the broadcast message in the specific logical channel.

[0183] In embodiments of the present application, more appropriate sideline communication resources can be determined for a terminal based on the terminal type. For example, based on the terminal type of the first terminal and / or the second terminal, a more appropriate sideline transmit resource pool and / or sideline receive resource pool can be determined for the first terminal, thereby improving system transmission performance and, in some scenarios, reducing energy consumption of terminals, particularly RedCap terminals.

[0184] FIG3 is a schematic flow chart of a sideline communication method 300 according to an embodiment of the present application. The method can optionally be applied to the system shown in FIG1 , but is not limited thereto. The method includes at least part of the following contents.

[0185] S310. The first terminal determines a sideline transmission mode based on the terminal type. In an embodiment of the present application, the sideline transmission mode may include an SL DRX configuration and / or an SL discontinuous transmission (DTX) configuration. Based on the SL DRX configuration, the power saving requirements of a terminal, such as a receiving terminal, can be achieved by "activating" and "deactivating" the sideline reception behavior. The sideline transmission mode may include an SL DRX configuration.

[0186] In one embodiment, the SL DRX configuration includes SL DRX parameters and / or SL eDRX mechanism. For example, the SL DRX parameters may include the terminal's DRX cycle, DRX activation duration, DRX retransmission timer, DRX activation timer, SL eDRX cycle, etc. The SL eDRX mechanism may include waking up at a specific time within the SL eDRX cycle according to the configuration to monitor the peer data.

[0187] In one embodiment, the SL DTX configuration includes SL DTX parameters and / or SL eDTX mechanism. For example, the SL DTX parameters may include the terminal's DTX cycle, DTX activation duration, DTX retransmission timer, DTX activation timer, SL eDTX cycle, etc. The SL eDTX mechanism may include waking up at a specific time according to the configuration within the SL eDTX cycle and sending data to the other end.

[0188] In one embodiment, the first terminal is a Redcap terminal or a terminal communicating with a Redcap terminal. For example, if the first terminal is a receiving terminal, the first terminal and / or the second terminal of the opposite terminal is a Redcap terminal. The first terminal can determine the SL DRX configuration of the first terminal based on the terminal type of the first terminal. The first terminal can also determine the SL DTX configuration of the second terminal based on the terminal type of the first terminal. If the first terminal is a transmitting terminal, the first terminal can also determine the SL DTX configuration of the first terminal based on the terminal type of the second terminal. The first terminal can also determine the SL DRX configuration of the second terminal based on the terminal type of the second terminal.

[0189] In one embodiment, the SL DRX configuration includes a specific SL DRX configuration for the Redcap terminal. For example, the first terminal is a Redcap terminal, and the Redcap terminal can determine a specific SL DRX configuration for itself.

[0190] In one embodiment, the SL DTX configuration includes a specific SL DTX configuration for the Redcap terminal. For example, the first terminal may determine a specific SL DTX configuration for the Redcap terminal of the opposite end.

[0191] In one embodiment, the specific SL DRX configuration for the Redcap terminal includes a SL eDRX cycle. In this embodiment of the present application, the terminal can be awakened at a specific time during the SL eDRX cycle to monitor peer data according to the configuration. The SL eDRX cycle can be longer than a normal DRX cycle. The SL eDRX cycle can relax the requirements for Redcap terminal capabilities.

[0192] In one embodiment, the specific SL DTX configuration for the Redcap terminal includes a SL eDTX period. In the embodiment of the present application, the terminal can wake up at a specific time according to the configuration and send data to the other end during the SL eDTX period.

[0193] Figure 4 is a schematic flow chart of a sideline communication method 400 according to another embodiment of the present application. The method 400 may include one or more features of the above-mentioned sideline communication method. In one embodiment, the SL eDRX cycle includes a listening window.

[0194] In an embodiment of the present application, a listening window can be set according to a normal DRX cycle within a SL eDRX cycle, or the listening window can be reset. The length of the listening window can be shorter than the SL eDRX cycle, or longer than a normal SL DRX cycle. For example, the length of the listening window is greater than N SL DRX cycles, where N is greater than 1. Within the listening window, activation or inactivation of a receiving terminal can be controlled according to the SL DRX cycle. If the length of the listening window is greater than three SL DRX cycles, activation of the receiving terminal can be controlled three times within the listening window.

[0195] In an embodiment of the present application, the listening window may not be set in the SL eDRX cycle, but the activation or inactivation of the receiving terminal may be controlled according to the SL eDRX cycle. The eDRX cycle may be a newly introduced cycle independent of the DRX cycle, or may be defined in the same manner as the original DRX cycle but with a larger value.

[0196] In one embodiment, the time domain position of the lower edge of the listening window is related to the identifier of the Redcap terminal, and the time domain position of the upper edge of the listening window is determined based on the time domain position of the lower edge of the listening window and the window size.

[0197] In an embodiment of the present application, the time domain position of the lower edge of the listening window (hereinafter referred to as the lower edge position) may include a frame, a subframe, a time slot, a character, etc. The lower edge position may be determined based on the identifier of the Redcap terminal, for example, the Redcap UE L2 ID. The time domain position of the upper edge of the listening window (hereinafter referred to as the upper edge position) may be determined based on the blind position and the window size. For example, if the lower edge position is time slot n, the window size is W time slots, and the upper edge position is slot n+W.

[0198] In one embodiment, the SL eDTX period includes a sending window. The sending window of the first terminal and the listening window of the opposite terminal are set in a similar manner, so that the opposite terminal can receive information sent by the first terminal in the listening window.

[0199] In one embodiment, the time domain position of the lower edge of the sending window is related to the identifier of the opposite terminal, and the time domain position of the upper edge of the sending window is determined based on the time domain position and window size of the sending window.

[0200] In one embodiment, the window size is specified by the protocol, default, or network configured.

[0201] In one embodiment, the window size is configured in at least one of RRC, SIB, and pre-configuration. For example, the first terminal receives RRC, SIB, or pre-configuration information from a network device, where the RRC, SIB, or pre-configuration information indicates the size of the listening window within the SL eDRX cycle.

[0202] In the embodiments of the present application, by setting a longer SL eDRX cycle and / or SL eDTX cycle, it is helpful to relax the DRX mechanism's requirements on terminal capabilities, making the terminal, especially the Redcap terminal, more power-efficient. By flexibly setting the listening window within the SL eDRX cycle and / or SL eDTX cycle, the terminal's listening duration and / or number of listening times can be more flexibly controlled, which is conducive to adapting to a wider range of communication scenarios.

[0203] In one implementation, if the receiving terminal is a Redcap terminal, as shown in FIG4 , the method 400 further includes: S410 , the Redcap terminal performs monitoring within the monitoring window.

[0204] In one embodiment, the Redcap terminal monitors within the monitoring window, including:

[0205] The Redcap terminal determines a duration timer and / or a listening period according to a first SL DRX mechanism within the listening window;

[0206] The Redcap terminal monitors the first signaling based on the duration timer and / or the monitoring period.

[0207] For example, the first SL DRX mechanism may be a DRX mechanism of a common terminal, such as a common (Legacy) SL DRX. The Redcap terminal determines a duration timer T1 based on the Legacy SL DRX, and may monitor the first signaling based on T1. For another example, the Redcap terminal determines a monitoring period C1 based on the Legacy SL DRX, and may periodically monitor the first signaling based on C1.

[0208] In one embodiment, if the sending terminal is a Redcap terminal, the method further includes: the Redcap terminal sending within the sending window.

[0209] In one embodiment, the Redcap terminal sends within the sending window, including:

[0210] The Redcap terminal determines a duration timer and / or a transmission period according to a first SL DTX mechanism within the transmission window;

[0211] The Redcap terminal sends the first signaling based on the duration timer and / or the sending cycle.

[0212] The example of the sending process is similar to the receiving process. Please refer to the relevant description of the receiving process.

[0213] In one embodiment, the first signaling includes at least one of a DCR message, a discovery message, a broadcast message, and a multicast message. The broadcast message and the multicast message include a QoS flow, while the DCR message and the discovery message do not include a QoS flow.

[0214] In one embodiment, the specific SL DRX configuration for the Redcap terminal includes a default SL DRX. For example, Legacy SL DRX may be a complete set of SL DRX mechanisms in R17. The default DRX configuration may simply be a configuration of DRX parameters for certain transmissions in this set of mechanisms.

[0215] In one embodiment, the specific SL DTX configuration for the Redcap terminal includes a default SL DTX. The default SL DTX can be obtained based on the default SL DTX of the opposite terminal.

[0216] In one embodiment, the specific SL DRX configuration for the Redcap terminal is associated with a QoS flow. For example, if the first signaling sent or received by the Redcap terminal includes a QoS flow, a specific SL DRX configuration may be set for each QoS flow.

[0217] In one embodiment, the specific SL DTX configuration for the Redcap terminal is associated with a QoS flow. For example, if the first signaling sent or received by the Redcap terminal includes a QoS flow, a specific SL DTX configuration may be set for each QoS flow.

[0218] In one embodiment, the specific SL DRX configuration for the Redcap terminal is longer than the monitoring period of the first SL DRX configuration, and / or the specific SL DRX configuration for the Redcap terminal is shorter than the duration timer of the first SL DRX configuration. For example, the first SL DRX is Legacy SL DRX. The SL eDRX period in the specific SL DRX configuration is longer than the SL DRX period of the Legacy SL DRX configuration. This is conducive to relaxing the requirements of the DRX mechanism on the terminal capabilities, making the terminal, especially the Redcap terminal, more power-saving. For another example, the duration timer of the specific SL DRX configuration for the Redcap terminal is T1, and the duration timer of the Legacy SL DRX configuration is T2, and T1 is less than T2. ​​This can reduce the active time of the terminal, making the terminal more power-saving.

[0219] In one embodiment, the specific SL DTX configuration for the Redcap terminal is longer than the listening period of the first SL DTX configuration, and / or the specific SL DTX configuration for the Redcap terminal is shorter than the duration timer of the first SL DTX configuration. The first SL DTX configuration can be determined based on the first SL DTX configuration of the opposite end.

[0220] In one embodiment, the Redcap terminal ignores and / or skips the time slots and / or duration of part of the activation time in the activation time of the terminal defined by the protocol. In an embodiment of the present application, the activation time may not be the activation time controlled by the on duration timer. The activation time may be a periodic transmission time slot associated with the announced periodic transmission(s) by the UE transmitting SL-SCH Data. For example, if an activation time includes 3 time slots, the Redcap terminal can be activated only in 2 time slots and ignore 1 time slot. If an activation time includes 4 time slots, the Redcap terminal can be activated once every 1 time slot. If an activation time includes 5ms (milliseconds), the Redcap terminal can be activated in the first 3ms and ignore the last 2ms.

[0221] In one embodiment, at least one of the following is determined based on the second information:

[0222] SL DRX configuration and / or SL DTX configuration used for sideline data transmission of the Redcap terminal;

[0223] Whether to use SL eDRX and / or SL eDTX;

[0224] Whether the first terminal and / or the opposite terminal is a Redcap terminal;

[0225] Whether the first terminal and / or the opposite terminal supports Redcap terminal;

[0226] Whether the first terminal and / or the opposite terminal supports the Redcap service.

[0227] In one embodiment, the second information includes at least one of the following: an L2 ID of the first terminal and / or the peer device, an upper layer indication, a service type, a service ID, a QoS flow, and a transmission profile. In an embodiment of the present application, a data transmission for a Redcap terminal includes sending and / or receiving the data.

[0228] In one implementation, the service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

[0229] In one embodiment, the SL DRX configuration used for sidelink data transmission of the Redcap terminal includes a first SL DRX configuration and / or a specific SL DRX configuration.

[0230] In one embodiment, the SL DTX configuration used for sideline data transmission of the Redcap terminal includes a first SL DTX configuration and / or a specific SL DTX configuration.

[0231] In one embodiment, the sidelink data has a QoS flow, and each QoS flow of the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration. For example, if the sidelink data of the Redcap terminal has m QoS flows, corresponding SL DRX configurations and / or SL DTX configurations can be set for each of the m QoS flows.

[0232] In one embodiment, if the sidelink data does not have a QoS flow, the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration. For example, if the sidelink data of the Redcap terminal does not have a QoS flow, a corresponding SL DRX configuration and / or SL DTX configuration can be set for the sidelink data as a whole.

[0233] In one embodiment, the first terminal is a transmitting terminal, the transmitting terminal is a Redcap terminal, and the receiving terminal is a non-Redcap terminal. The method further includes: the transmitting terminal transmitting according to a first DTX configuration or a specific DTX configuration for the Redcap terminal. For example, the Redcap terminal transmits sidelink information to the non-Redcap terminal according to the first DTX configuration or the specific DTX configuration for the Redcap terminal.

[0234] In one embodiment, the first terminal is a transmitting terminal, the transmitting terminal is a non-Redcap terminal, and the receiving terminal is a Redcap terminal. The method further includes: the transmitting terminal transmitting according to a specific DTX configuration for the Redcap terminal. For example, the non-Redcap terminal transmits sidelink information to the Redcap terminal according to the specific DTX configuration for the Redcap terminal of the opposite end.

[0235] In one embodiment, the transmitting terminal transmits according to a specific DTX configuration for the Redcap terminal, including: the transmitting terminal continuously or repeatedly transmits according to the specific DTX configuration for the Redcap terminal during the activation time of the receiving terminal. For example, a non-Redcap terminal continuously or repeatedly transmits sidelink information to the Redcap terminal during the activation time of the receiving terminal according to the specific DTX configuration for the Redcap terminal of the opposite end.

[0236] In one embodiment, the first terminal is a transmitting terminal, the receiving terminal is a Redcap terminal, and the transmitting terminal is a non-Redcap terminal. The method further includes: the receiving terminal receiving according to a specific DRX configuration for the Redcap terminal. For example, the Redcap terminal receives sidelink information from the non-Redcap terminal according to the specific DRX configuration for the Redcap terminal.

[0237] In one embodiment, the first terminal is a transmitting terminal, the receiving terminal is a non-Redcap terminal, and the transmitting terminal is a Redcap terminal. The method further includes: the receiving terminal receiving according to a first DRX configuration or a specific DRX configuration for the Redcap terminal. For example, the non-Redcap terminal receives sidelink information from the Redcap terminal according to the first DRX configuration or the specific DRX configuration for the Redcap terminal of the opposite end.

[0238] The sidelink communication method provided in the embodiments of the present application can enhance support for Redcap UEs to discover or communicate with other UEs in the sidelink. By defining special resource / DRX configurations, the requirements for the transmit / receive capabilities of Redcap UEs can be relaxed, further achieving power savings. For example, a resource pool specifically for Redcap UEs can be defined. In another example, DRX and / or DTX can be defined specifically for Redcap UEs.

[0239] Example 1:

[0240] Different transmission and / or reception resources, such as beams and / or resource pools, are configured and / or used for UEs with different capabilities.

[0241] The following is an example of resource pool enhancement:

[0242] 1. Set up a specific resource pool for Redcap UE (specific resource pool), or set up a common resource pool. The specific resource pool may include a specific sending resource pool and / or a specific receiving resource pool. The common resource pool may include a common sending resource pool and / or a common receiving resource pool.

[0243] (1) The specific resource pool is protocol-specified, default, or network-configured. For example, the network configures the specific resource pool using RRC, SIB, or pre-configuration.

[0244] (2) The specific resource pool can be used only to transmit data associated with Redcap UE; or, the specific resource pool can be used to transmit data associated with Redcap UE and data not associated with Redcap.

[0245] (3) For a specific transmission resource pool, the UE transmission method refers to at least one of the following situations:

[0246] If the sending UE (also referred to as a sending end UE, Tx UE, sending end, sender, etc.) is a Redcap UE, the sending is performed in a specific sending resource pool.

[0247] If the receiving UE (also referred to as receiving end UE, Rx UE, receiving end, receiver, etc.) is a Redcap UE, the sending UE transmits in a specific transmit resource pool. In this case, the sending UE can determine whether to transmit in a specific resource pool based on the receiving UE's L2 identifier, upper layer (NAS layer) indication, service type, service ID, and transmission profile (Tx profile).

[0248] If the network is not configured with a specific resource pool, the sending UE can send in the general resource pool; or the sending UE believes that the Redcap service is not supported within the network range, and thus does not send related signaling and / or data; or the sending UE repeats sending in all configured sending resource pools.

[0249] (4) For a specific receiving resource pool, the UE receiving method refers to at least one of the following situations:

[0250] If the receiving UE is a Redcap UE, the reception is performed in a specific receiving resource pool.

[0251] If the receiving UE is a common UE, the receiving UE performs reception on all configured resource pools (common receiving resource pools and / or specific receiving resource pools).

[0252] If the network is not configured with a specific resource pool, the receiving UE receives in a common resource pool; or the receiving UE believes that the Redcap service is not supported within the network range, and thus does not receive related signaling and / or data.

[0253] 2. Set a resource pool configuration for at least one of each UE (per-UE), L2 ID, and service for Redcap UE.

[0254] (1) The per-UE, L2 ID, or service resource pool configuration is specific to at least one of different UEs, source L2 IDs, target L2 IDs, and services. The UE uses a specific resource pool based on a mapping relationship and / or rule. For example, if the source L2 ID and / or target L2 ID X is mapped to resource pool 1, the UE uses resource pool 1 to send data for target L2 ID X or receive data for source L2 ID X. The mapping relationship or rule is specified by the protocol, indicated by an upper layer (NAS), or configured by the network (RRC / SIB / Preconfiguration).

[0255] In general, for Redcap UE, due to its limited sending / receiving capabilities, an example of the process of discovering other UEs is as follows:

[0256] For example, if both the sending UE and the receiving UE are Redcap UEs, the capability requirements of both the sending and receiving ends can be relaxed through the above enhancements. As mentioned above, transmission or reception is only performed on specific, agreed resources.

[0257] For example, if the sending UE is a Redcap UE and the receiving UE is a standard UE, the enhancement is primarily on the sending side. That is, the sending side can send only on specific resources, while the receiving side can receive on all resources or on specific agreed-upon resources, thus ensuring successful transmission.

[0258] For another example, if the sending UE is a normal UE and the receiving UE is a Redcap UE, the enhancement is mainly on the receiving side. That is, the sending side can send (repeatedly) on all resources or send on specific agreed resources, while the receiving side receives on specific resources, thus ensuring successful transmission.

[0259] Example 2

[0260] Configure different DRX parameters and / or DRX parameters for UEs with different capabilities. Configure whether to use the SL eDRX mechanism and / or SL eDTX mechanism for UEs with different capabilities. For example, set specific SL DRX parameters and / or DRX parameter configurations for Redcap UEs. Another example is using the SL eDRX mechanism and / or SL eDTX mechanism. The following uses DRX as an example for explanation; the following DRX can also be replaced with DTX.

[0261] 1. The specific SL DRX configuration is protocol-specified, default, or network-configured (RRC / SIB / Pre-config).

[0262] 2. Specific SL DRX configurations include the following examples:

[0263] (1) Configuring the SL eDRX cycle for Redcap UE:

[0264] As shown in FIG5 , a listening window is set in the eDRX cycle, and the UE does not monitor outside the listening window. For example, the UE does not monitor DCR messages or discovery messages outside the listening window.

[0265] The listening window is defined by the upper and lower edges of the window. The time domain position (frame, subframe, timeslot, character, etc.) of the lower edge of the window is related to the UE ID (Redcap UE L2 ID). The upper and lower edges are related to the window size. The window size can be protocol-defined, default, or network-configured (RRC / SIB / Pre-config).

[0266] Within the monitoring window, the UE may determine an on-duration timer, a cycle, etc. according to the Legacy SL DRX mechanism, and monitor DCR messages or discovery messages, etc.

[0267] (2) Default DRX configuration for Redcap UE: The default DRX configuration may be part of the Legacy SL DRX configuration.

[0268] (3) DRX parameter configuration for each QoS (per-QoS) of Redcap UE.

[0269] (4) Specific SL DRX configurations can include a longer cycle, a shorter on-duration timer, or the ability to ignore or skip certain active time slots / times, for example, periodic active time.

[0270] 3. The UE determines the SL DRX configuration used for a certain data transmission (send / receive) in the following manner, which may include a normal SL DRX configuration or a specific SL DRX configuration for Redcap UE.

[0271] The UE determines the SL DRX configuration to use and / or whether to use SL eDRX based on its own and / or the other party's L2 identity, upper layer (NAS layer) indication, service type, service ID, QoS flow, Tx profile, etc.

[0272] 4. In particular, examples of configuration methods for different situations are as follows:

[0273] (1) If the data has QoS (such as data plane data), the UE performs SL DRX configuration according to per-QoS.

[0274] (2) If the data does not have QoS (such as signaling: discovery message / DCR), then the normal default DRX can be configured, and the DRX specifically for Redcap UE can be configured.

[0275] The following is a transmission example based on the above configuration:

[0276] For example, the transmitting end is a Redcap UE and the receiving end is a common UE. For a certain transmission, the transmitting end may transmit according to the common default DTX or the DTX specifically for the Redcap UE.

[0277] For another example, the sending end is a common UE and the receiving end is a Redcap UE. For a certain transmission, the sending end can send according to the DTX specifically for the Redcap UE. The sending end can also send continuously / repeatedly multiple times according to the specific DTX when the other party's UE is active to ensure successful data transmission.

[0278] For another example, the receiving end is a Redcap UE and the sending end is a common UE. For a certain transmission, the receiving end is received according to the DRX reception specifically for the Redcap UE.

[0279] For another example, the receiving end is a common UE and the transmitting end is a Redcap UE. For a certain transmission, the receiving end may receive according to the common default DRX or the DRX specifically for the Redcap UE.

[0280] Example 3

[0281] The impact of specific resource configuration on UE transmission behavior.

[0282] 1. Impact of resource selection:

[0283] If the data to be transmitted is specific data for the Redcap UE and a resource pool for the specific data is configured, the Tx UE selects the corresponding specific resource pool.

[0284] 2. Impact of Logical Channel Prioritization (LCP):

[0285] If the current resource is a resource in a specific resource pool (e.g., a resource pool specifically defined for Redcap UE), the UE can only send corresponding specific data on this resource. The specific data may include at least one of the following:

[0286] Data for a specific L2 ID, such as data corresponding to the L2 ID of a Redcap UE.

[0287] The data in the specific logical channel is, for example, data associated with at least one of a DCR message, a discovery message, a broadcast message, and a multicast message.

[0288] The sidelink communication method of an embodiment of the present application can be an enhanced method for supporting Redcap UEs in discovering other UEs in a sidelink. By defining special resources, DRX configurations, and DTX configurations, this method relaxes the requirements for Redcap UE capabilities and further achieves power savings. Furthermore, the embodiment of the present application analyzes different UE behaviors in different scenarios and their impact on the protocol.

[0289] FIG6 is a schematic block diagram of a first terminal 600 according to an embodiment of the present application. The first terminal 600 may include:

[0290] The processing unit 610 is configured to determine the sidelink communication resource of the first terminal based on the terminal type.

[0291] In one embodiment, the sideline communication resources include a sideline resource pool.

[0292] In one embodiment, the sideline resource pool includes a specific resource pool.

[0293] In one embodiment, the specific resource pool is specified by a protocol, is default, or is configured by a network.

[0294] In one implementation, the configuration mode of the specific resource pool includes at least one of RRC, SIB, and pre-configuration.

[0295] In one embodiment, the specific resource pool is used to transmit at least one of the following: data associated with a Redcap terminal; and data not associated with a Redcap terminal.

[0296] In one embodiment, the first terminal determines at least one of the following based on the first information:

[0297] Whether the first terminal and / or the opposite terminal is a Redcap terminal;

[0298] Whether the first terminal and / or the opposite terminal supports Redcap terminal;

[0299] Whether the first terminal and / or the opposite terminal supports the Redcap service;

[0300] Whether the first terminal and / or the opposite terminal uses the specific resource pool.

[0301] In one embodiment, the first information includes at least one of the following:

[0302] The L2 identification ID, upper layer indication, service type, service ID, QoS flow and transmission configuration file of the first terminal and / or the opposite terminal.

[0303] In one implementation, the service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

[0304] In one embodiment, the specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

[0305] In one embodiment, the specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal or a non-Redcap terminal, and the first terminal is a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

[0306] In one embodiment, the specific resource pool includes a specific receiving resource pool, the first terminal is a Redcap terminal and a receiving terminal, the sending terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the receiving terminal for reception are in the specific receiving resource pool.

[0307] In one embodiment, the sideline resource pool includes all configured resource pools.

[0308] In one embodiment, all configured resource pools include all configured sending resource pools, the first terminal is a non-Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in all configured sending resource pools.

[0309] In one embodiment, all configured resource pools include all configured receiving resource pools, the first terminal is a non-Redcap terminal and a receiving terminal, and the sideline communication resources used by the receiving terminal for reception are in all configured resource pools.

[0310] In one embodiment, the specific resource pool has a mapping relationship with at least one of a terminal, an L2 ID, and a service.

[0311] In one embodiment, the L2 ID includes a source L2 ID and / or a target L2 ID.

[0312] In one embodiment, the mapping relationship is specified by a protocol, defaulted, or configured by a network.

[0313] In one implementation, the mapping relationship is configured in at least one of RRC, SIB, and pre-configuration.

[0314] In one embodiment, the data to be transmitted by the first terminal is specific data for a Redcap terminal, and a specific resource pool for the specific data is configured.

[0315] In one embodiment, the resource pool used by the transmitting terminal for sending is a specific resource pool for the specific data.

[0316] In one embodiment, the current resource of the sending terminal is a resource in a specific resource pool for the Redcap terminal, and the sending terminal sends the specific data on the current resource.

[0317] In one embodiment, the specific data includes data for the L2 ID of the Redcap terminal.

[0318] In one embodiment, the specific data includes data in a specific logical channel.

[0319] In one embodiment, the data in the specific logical channel includes data associated with at least one of a DCR message, a discovery message, a multicast message, and a broadcast message.

[0320] The first terminal 600 of the embodiment of the present application can implement the corresponding functions of the first terminal in the embodiment of the aforementioned method 200. The processes, functions, implementation methods and beneficial effects corresponding to each module (sub-module, unit or component, etc.) in the first terminal 600 can be found in the corresponding description in the above-mentioned method embodiment, and will not be repeated here. It should be noted that the functions described by each module (sub-module, unit or component, etc.) in the first terminal 600 of the embodiment of the application can be implemented by different modules (sub-modules, units or components, etc.) or by the same module (sub-module, unit or component, etc.).

[0321] Fig. 7 is a schematic block diagram of a first terminal 700 according to an embodiment of the present application. The first terminal 700 may include: a processing unit 710, configured to determine a sidelink transmission mode based on a terminal type.

[0322] In one embodiment, the sideline transmission mode may include SL DRX configuration and / or SL DTX configuration.

[0323] In one embodiment, the SL DRX configuration includes SL DRX parameters and / or SL eDRX mechanism.

[0324] In one embodiment, the SL DTX configuration includes SL DTX parameters and / or SL eDTX mechanism.

[0325] In one embodiment, the first terminal is a Redcap terminal or a terminal communicating with a Redcap terminal.

[0326] In one embodiment, the SL DRX configuration includes a specific SL DRX configuration for the Redcap terminal.

[0327] In one embodiment, the SL DTX configuration includes a specific SL DTX configuration for the Redcap terminal.

[0328] In one embodiment, the specific SL DRX configuration for the Redcap terminal includes a SL eDRX cycle.

[0329] In one embodiment, the specific SL DTX configuration for the Redcap terminal includes a SL eDTX period.

[0330] In one implementation, the SL eDRX cycle includes a listening window.

[0331] In one embodiment, the time domain position of the lower edge of the listening window is related to the identifier of the Redcap terminal, and the time domain position of the upper edge of the listening window is determined based on the time domain position of the lower edge of the listening window and the window size.

[0332] In one embodiment, the SL eDTX period includes a sending window. The sending window of the first terminal and the listening window of the opposite terminal are set in a similar manner, so that the opposite terminal can receive information sent by the first terminal in the listening window.

[0333] In one embodiment, the time domain position of the lower edge of the sending window is related to the identifier of the opposite terminal, and the time domain position of the upper edge of the sending window is determined based on the time domain position and window size of the sending window.

[0334] In one embodiment, the window size is specified by the protocol, default, or network configured.

[0335] In one implementation, the window size is configured in at least one of RRC, SIB, and pre-configuration.

[0336] FIG8 is a schematic block diagram of a first terminal 800 according to another embodiment of the present application. The terminal may include one or more features of the first terminal described above. In one embodiment, the first terminal 800 further includes a monitoring unit 810 configured to monitor within the monitoring window.

[0337] In one embodiment, as shown in FIG8 , the monitoring unit 810 is configured to determine a duration timer and / or a monitoring period according to a first SL DRX mechanism within the monitoring window; and monitor the first signaling based on the duration timer and / or the monitoring period.

[0338] In one implementation, the first terminal 800 further includes: a first sending unit 810, configured to send within the sending window.

[0339] In one embodiment, the first sending unit 810 is also used for the Redcap terminal to determine a duration timer and / or a sending cycle according to the first SL DTX mechanism within the sending window; the Redcap terminal sends a first signaling based on the duration timer and / or the sending cycle.

[0340] In one implementation, the first signaling includes at least one of a DCR message, a discovery message, a broadcast message, and a multicast message.

[0341] In one embodiment, the specific SL DRX configuration for the Redcap terminal includes a default SL DRX.

[0342] In one embodiment, the specific SL DTX configuration for the Redcap terminal includes a default SL DTX. The default SL DTX can be obtained based on the default SL DTX of the opposite terminal.

[0343] In one embodiment, a specific SL DRX configuration for the Redcap terminal is associated with a QoS flow.

[0344] In one embodiment, a specific SL DTX configuration for the Redcap terminal is associated with a QoS flow.

[0345] In one embodiment, the specific SL DRX configuration for the Redcap terminal has a longer listening period than the first SL DRX configuration, and / or the specific SL DRX configuration for the Redcap terminal has a shorter duration timer than the first SL DRX configuration.

[0346] In one embodiment, the specific SL DTX configuration for the Redcap terminal has a longer listening period than the first SL DTX configuration, and / or the specific SL DTX configuration for the Redcap terminal has a shorter duration timer than the first SL DTX configuration.

[0347] In one embodiment, the Redcap terminal ignores and / or skips a time slot and / or duration of part of the activation time of the terminal defined in the protocol.

[0348] In one embodiment, the processing unit is further configured to determine at least one of the following based on the second information:

[0349] SL DRX configuration and / or SL DTX configuration used for sideline data transmission of the Redcap terminal;

[0350] Whether to use SL eDRX and / or SL eDTX;

[0351] Whether the first terminal and / or the opposite terminal is a Redcap terminal;

[0352] Whether the first terminal and / or the opposite terminal supports Redcap terminal;

[0353] Whether the first terminal and / or the opposite terminal supports the Redcap service.

[0354] In one embodiment, the second information includes at least one of the following: an L2 ID of the first terminal and / or the opposite device, an upper layer indication, a service type, a service ID, a QoS flow, and a transmission profile.

[0355] In one implementation, the service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

[0356] In one embodiment, the SL DRX configuration used for sidelink data transmission of the Redcap terminal includes a first SL DRX configuration and / or a specific SL DRX configuration.

[0357] In one embodiment, the SL DTX configuration used for sideline data transmission of the Redcap terminal includes a first SL DTX configuration and / or a specific SL DTX configuration.

[0358] In one embodiment, the sidelink data has a QoS flow, and each QoS flow of the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

[0359] In one embodiment, if the sidelink data does not have a QoS flow, the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

[0360] In one embodiment, the first terminal is a transmitting terminal, the transmitting terminal is a Redcap terminal, and the receiving terminal is a non-Redcap terminal. As shown in FIG8 , the first terminal 800 further includes:

[0361] The second sending unit 830 is configured to send according to the first DTX configuration or a specific DTX configuration for the Redcap terminal.

[0362] In one embodiment, the first terminal is a transmitting terminal, the transmitting terminal is a non-Redcap terminal, and the receiving terminal is a Redcap terminal. As shown in FIG8 , the first terminal 800 further includes:

[0363] The third sending unit 840 is configured to send according to a specific DTX configuration for the Redcap terminal.

[0364] In one embodiment, as shown in FIG8 , the third sending unit 840 is configured to send continuously or repeatedly multiple times at the activation time of the receiving terminal according to a specific DTX configuration for the Redcap terminal.

[0365] In one embodiment, the first terminal is a transmitting terminal, the receiving terminal is a Redcap terminal, and the transmitting terminal is a non-Redcap terminal. As shown in FIG8 , the first terminal 800 further includes:

[0366] The first receiving unit 850 is configured to receive data according to a specific DRX configuration for the Redcap terminal.

[0367] In one embodiment, the first terminal is a transmitting terminal, the receiving terminal is a non-Redcap terminal, and the transmitting terminal is a Redcap terminal. As shown in FIG8 , the first terminal 800 further includes:

[0368] The second receiving unit 860 is configured to receive according to the first DRX configuration or a specific DRX configuration for the Redcap terminal.

[0369] The first terminals 700 and 800 of the embodiments of the present application can implement the corresponding functions of the first terminals in the aforementioned methods 300 and 400. The processes, functions, implementation methods, and beneficial effects corresponding to the various modules (sub-modules, units, or components, etc.) in the first terminals 700 and 800 can be found in the corresponding descriptions in the above-mentioned method embodiments and will not be repeated here. It should be noted that the functions described in the various modules (sub-modules, units, or components, etc.) in the first terminals 700 and 800 of the embodiments of the application can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0370] Figure 9 is a schematic structural diagram of a communication device 900 according to an embodiment of the present application. The communication device 900 includes a processor 910, which can call and run a computer program from a memory to enable the communication device 900 to implement the method in the embodiment of the present application.

[0371] In one embodiment, the communication device 900 may further include a memory 920. The processor 910 may call and execute a computer program from the memory 920 to enable the communication device 900 to implement the method in the embodiment of the present application.

[0372] The memory 920 may be a separate device independent of the processor 910 , or may be integrated into the processor 910 .

[0373] In one embodiment, the communication device 900 may further include a transceiver 930 , and the processor 910 may control the transceiver 930 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices.

[0374] The transceiver 930 may include a transmitter and a receiver. The transceiver 930 may further include an antenna, and the number of antennas may be one or more.

[0375] In one embodiment, the communication device 900 may be the first terminal or the second terminal of the embodiment of the present application, and the communication device 900 can implement the corresponding processes implemented by the first terminal or the second terminal in each method of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0376] 10 is a schematic structural diagram of a chip 1000 according to an embodiment of the present application. The chip 1000 includes a processor 1010, which can call and execute a computer program from a memory to implement the method according to the embodiment of the present application.

[0377] In one embodiment, the chip 1000 may further include a memory 1020. The processor 1010 may call and execute a computer program from the memory 1020 to implement the method executed by the first terminal or the second terminal in the embodiment of the present application.

[0378] The memory 1020 may be a separate device independent of the processor 1010 , or may be integrated into the processor 1010 .

[0379] In one embodiment, the chip 1000 may further include an input interface 1030. The processor 1010 may control the input interface 1030 to communicate with other devices or chips, and specifically, may obtain information or data sent by other devices or chips.

[0380] In one embodiment, the chip 1000 may further include an output interface 1040. The processor 1010 may control the output interface 1040 to communicate with other devices or chips, and specifically, may output information or data to other devices or chips.

[0381] In one embodiment, the chip can be applied to the first terminal or the second terminal in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the first terminal or the second terminal in each method of the embodiment of the present application. For the sake of brevity, it will not be repeated here.

[0382] The chip used in the first terminal and the second terminal may be the same chip or different chips.

[0383] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0384] The processor mentioned above may be a general-purpose processor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. The general-purpose processor mentioned above may be a microprocessor or any conventional processor, etc.

[0385] The memory mentioned above may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM).

[0386] It should be understood that the above-mentioned memories are exemplary but not restrictive. For example, the memories in the embodiments of the present application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM RAM (DR RAM), etc. In other words, the memories in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

[0387] 11 is a schematic block diagram of a communication system 1100 according to an embodiment of the present application. The communication system 1100 includes a first terminal 1110 and a second terminal 1120. The second terminal 1120 is a communication peer of the first terminal 1110.

[0388] In one implementation, the first terminal 1110 is configured to determine the sidelink communication resource of the first terminal based on the terminal type.

[0389] In one embodiment, the first terminal 1110 is configured to determine the SL DRX configuration based on the terminal type.

[0390] The first terminal 1110 can be used to implement the corresponding functions implemented by the first terminal in the above method. The second terminal 1120 can be used to implement the corresponding functions implemented by the second terminal in the above method. For the sake of brevity, no further details are given here.

[0391] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function in accordance with the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode to another website, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0392] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0393] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0394] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A sideline communication method, comprising: The first terminal determines a sideline communication resource of the first terminal based on the terminal type.

2. The method according to claim 1, wherein: The sidewalk communication resources include a sidewalk resource pool.

3. The method according to claim 2, wherein: The sideline resource pool includes a specific resource pool.

4. The method according to claim 3, wherein: The specific resource pool is specified by the protocol, default or network configured.

5. The method according to claim 3 or 4, wherein: The configuration method of the specific resource pool includes at least one of radio resource control RRC, system information block SIB, and pre-configuration.

6. The method according to any one of claims 3 to 5, wherein: The specific resource pool is used to transmit at least one of the following: data associated with a low-capability Redcap terminal; data not associated with a Redcap terminal.

7. The method according to claim 6, wherein: The first terminal determines at least one of the following based on the first information: Whether the first terminal and / or the opposite terminal is a Redcap terminal; Whether the first terminal and / or the opposite terminal supports Redcap terminal; Whether the first terminal and / or the opposite terminal supports the Redcap service; whether the first terminal and / or the opposite terminal uses the specific resource pool; The first information includes at least one of the following: The layer 2 L2 identification ID, upper layer indication, service type, service ID, quality of service QoS flow and transmission configuration file of the first terminal and / or the opposite terminal.

8. The method according to claim 7, wherein: The service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

9. The method according to any one of claims 3 to 8, wherein: The specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

10. The method according to any one of claims 3 to 9, wherein: The specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal or a non-Redcap terminal, and the first terminal is a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

11. The method according to claim 3, wherein: The specific resource pool includes a specific receiving resource pool, the first terminal is a Redcap terminal and a receiving terminal, the sending terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the receiving terminal for reception are in the specific receiving resource pool.

12. The method according to claim 2, wherein: The sideline resource pool includes all configured resource pools.

13. The method according to claim 12, wherein: The said all configured resource pools include all configured sending resource pools, the first terminal is a non-Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the said sending terminal for sending are in the said all configured sending resource pools.

14. The method according to claim 12, wherein: All the configured resource pools include all the configured receiving resource pools, the first terminal is a non-Redcap terminal and a receiving terminal, and the sideline communication resources used by the receiving terminal for reception are in all the configured resource pools.

15. The method according to any one of claims 3 to 11, wherein: The specific resource pool has a mapping relationship with at least one of a terminal, an L2 ID, and a service.

16. The method according to claim 15, wherein: The L2 ID includes a source L2 ID and / or a target L2 ID.

17. The method according to claim 15 or 16, wherein: The mapping relationship is specified by the protocol, default or network configuration.

18. The method according to any one of claims 15 to 17, wherein: The configuration mode of the mapping relationship includes at least one of RRC, SIB, and pre-configuration.

19. The method according to any one of claims 1 to 18, wherein: The data to be transmitted of the first terminal is specific data for the Redcap terminal, and the specific data is configured with a specific resource pool for the specific data.

20. The method according to claim 19, wherein: The resource pool used by the transmitting terminal for sending is a specific resource pool for the specific data.

21. The method according to claim 20, wherein: The current resources of the sending terminal are resources in a specific resource pool for the Redcap terminal, and the sending terminal sends the specific data on the current resources.

22. The method according to any one of claims 19 to 21, wherein: The specific data includes data for the L2 ID of the Redcap terminal.

23. The method according to any one of claims 19 to 21, wherein: The specific data includes data within a specific logical channel.

24. The method according to claim 23, wherein: The data in the specific logical channel includes data associated with at least one of a direct communication request DCR message, a discovery message, a multicast message, and a broadcast message.

25. A sideline communication method, comprising: The first terminal determines the sideline transmission mode based on the terminal type.

26. The method according to claim 25, wherein: The side transmission mode includes SL DRX configuration and / or SL DTX configuration; wherein the SL DRX configuration includes SL DRX parameters and / or SL eDRX mechanism; and / or the SL DTX configuration includes SL DTX parameters and / or SL eDTX mechanism.

27. The method according to claim 25 or 26, wherein: The first terminal is a Redcap terminal or a terminal communicating with a Redcap terminal.

28. The method according to claim 27, wherein: The SL DRX configuration includes a specific SL DRX configuration for the Redcap terminal; and / or the SL DTX configuration includes a specific SL DTX configuration for the Redcap terminal.

29. The method according to claim 28, wherein: The specific SL DRX configuration for the Redcap terminal includes a SL eDRX cycle; and / or the specific SL DTX configuration for the Redcap terminal includes a SL eDTX cycle.

30. The method of claim 29, wherein: The SL eDRX cycle includes a listening window; and / or the SL eDTX cycle includes a sending window.

31. The method according to claim 30, wherein: The time domain position of the lower edge of the listening window is related to the identifier of the Redcap terminal, and the time domain position of the upper edge of the listening window is determined based on the time domain position of the lower edge of the listening window and the window size; and / or, The time domain position of the lower edge of the sending window is related to the identifier of the opposite terminal, and the time domain position of the upper edge of the sending window is determined based on the time domain position of the sending window and the window size.

32. The method according to claim 31, wherein: The window size is specified by the protocol, default or network configuration.

33. The method according to claim 31 or 32, wherein: The configuration mode of the window size includes at least one of RRC, SIB, and pre-configuration.

34. The method according to any one of claims 30 to 33, wherein: The method further comprises: The Redcap terminal monitors within the monitoring window; and / or the Redcap terminal sends within the sending window.

35. The method of claim 34, wherein: The Redcap terminal monitors within the monitoring window, including: the Redcap terminal determines a duration timer and / or a monitoring period according to a first SL DRX mechanism within the monitoring window; the Redcap terminal monitors the first signaling based on the duration timer and / or the monitoring period; and / or, The Redcap terminal sends within the sending window, including: the Redcap terminal determines a duration timer and / or a sending cycle within the sending window according to a first SL DTX mechanism; the Redcap terminal sends a first signaling based on the duration timer and / or the sending cycle.

36. The method of claim 35, wherein: The first signaling includes at least one of a DCR message, a discovery message, a broadcast message, and a multicast message.

37. The method of claim 28, wherein: The specific SL DRX configuration for the Redcap terminal includes a default SL DRX; and / or the specific SL DTX configuration for the Redcap terminal includes a default SL DTX.

38. The method of claim 28, wherein: A specific SL DRX configuration for the Redcap terminal is associated with a QoS flow; and / or a specific SL DTX configuration for the Redcap terminal is associated with a QoS flow.

39. The method of claim 28, wherein: The specific SL DRX configuration for the Redcap terminal has a longer listening period than the first SL DRX configuration, and / or, the specific SL DRX configuration for the Redcap terminal has a shorter duration timer than the first SL DRX configuration; and / or, The specific SL DTX configuration for the Redcap terminal has a longer listening period than the first SL DTX configuration, and / or the specific SL DTX configuration for the Redcap terminal has a shorter duration timer than the first SL DTX configuration.

40. The method according to any one of claims 27 to 39, wherein: The Redcap terminal ignores and / or skips the time slot and / or duration of part of the activation time of the terminal defined in the protocol.

41. A method according to any one of claims 27 to 40, wherein: Determine at least one of the following based on the second information: SL DRX configuration and / or SL DTX configuration used for sideline data transmission of the Redcap terminal; Whether to use SL eDRX and / or SL eDTX; Whether the first terminal and / or the opposite terminal is a Redcap terminal; Whether the first terminal and / or the opposite terminal supports Redcap terminal; Whether the first terminal and / or the opposite terminal supports the Redcap service; The second information includes at least one of the following: L2 ID of the first terminal and / or the opposite terminal device, upper layer indication, service type, Service ID, QoS flow and transport profile.

42. The method according to claim 41, wherein: The service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

43. The method according to any one of claims 27 to 41, wherein: The SL DRX configuration used for the sideline data transmission of the Redcap terminal includes a first SL DRX configuration and / or a specific SL DRX configuration; and / or, the SL DTX configuration used for the sideline data transmission of the Redcap terminal includes a first SL DTX configuration and / or a specific SL DTX configuration.

44. A method according to any one of claims 41 to 43, wherein: The sidelink data has a QoS flow, and each QoS flow of the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

45. The method according to any one of claims 41 to 44, wherein: If the sidelink data does not have a QoS flow, the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

46. ​​The method according to any one of claims 25 to 45, wherein: The first terminal is a transmitting terminal, the transmitting terminal is a Redcap terminal, and the receiving terminal is a non-Redcap terminal, and the method further includes: The transmitting terminal sends according to the first DTX configuration or a specific DTX configuration for the Redcap terminal.

47. The method according to any one of claims 25 to 45, wherein: The first terminal is a transmitting terminal, the transmitting terminal is a non-Redcap terminal, and the receiving terminal is a Redcap terminal, and the method further includes: The transmitting terminal transmits according to a specific DTX configuration for the Redcap terminal.

48. The method of claim 47, wherein: The transmitting terminal sends according to a specific DTX configuration for the Redcap terminal, including: The transmitting terminal transmits continuously or repeatedly multiple times at the activation time of the receiving terminal according to the specific DTX configuration for the Redcap terminal.

49. The method according to any one of claims 25 to 45, wherein: The first terminal is a transmitting terminal, the receiving terminal is a Redcap terminal, and the transmitting terminal is a non-Redcap terminal, and the method further includes: The receiving terminal receives according to the specific DRX configuration for the Redcap terminal.

50. The method according to any one of claims 25 to 45, wherein: The first terminal is a transmitting terminal, the receiving terminal is a non-Redcap terminal, and the transmitting terminal is a Redcap terminal, and the method further includes: The receiving terminal receives according to the first DRX configuration or the specific DRX configuration for the Redcap terminal.

51. A first terminal, comprising: A processing unit is used to determine the sideline communication resources of the first terminal based on the terminal type.

52. The first terminal according to claim 51, wherein: The sidewalk communication resources include a sidewalk resource pool.

53. The first terminal according to claim 52, wherein: The sideline resource pool includes a specific resource pool.

54. The first terminal according to claim 53, wherein: The specific resource pool is specified by the protocol, default or network configured.

55. The first terminal according to claim 53 or 54, wherein: The configuration method of the specific resource pool includes at least one of RRC, SIB, and pre-configuration.

56. The first terminal according to any one of claims 53 to 55, wherein: The specific resource pool is used to transmit at least one of the following: data associated with the Redcap terminal; data not associated with the Redcap terminal.

57. The first terminal according to claim 56, wherein: The first information of the first terminal determines at least one of the following: Whether the first terminal and / or the opposite terminal is a Redcap terminal; Whether the first terminal and / or the opposite terminal supports Redcap terminal; Whether the first terminal and / or the opposite terminal supports the Redcap service; whether the first terminal and / or the opposite terminal uses the specific resource pool; The first information includes at least one of the following: L2 ID, upper layer indication, service type, service ID, QoS flow and transmission profile of the first terminal and / or the opposite terminal.

58. The first terminal according to claim 57, wherein: The service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

59. The first terminal according to any one of claims 53 to 58, wherein: The specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

60. The first terminal according to any one of claims 53 to 59, wherein: The specific resource pool includes a specific sending resource pool, the first terminal is a Redcap terminal or a non-Redcap terminal, and the first terminal is a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the sending terminal for sending are in the specific sending resource pool.

61. The first terminal according to claim 53, wherein: The specific resource pool includes a specific receiving resource pool, the first terminal is a Redcap terminal and a receiving terminal, the sending terminal is a Redcap terminal or a non-Redcap terminal, and the side communication resources used by the receiving terminal for reception are in the specific receiving resource pool.

62. The first terminal according to claim 52, wherein: The sideline resource pool includes all configured resource pools.

63. The first terminal according to claim 62, wherein: The said all configured resource pools include all configured sending resource pools, the first terminal is a non-Redcap terminal and a sending terminal, the receiving terminal is a Redcap terminal, and the side communication resources used by the said sending terminal for sending are in the said all configured sending resource pools.

64. The first terminal according to claim 62, wherein: All the configured resource pools include all the configured receiving resource pools, the first terminal is a non-Redcap terminal and a receiving terminal, and the sideline communication resources used by the receiving terminal for reception are in all the configured resource pools.

65. The first terminal according to any one of claims 53 to 61, wherein: The specific resource pool has a mapping relationship with at least one of a terminal, an L2 ID, and a service.

66. The first terminal according to claim 65, wherein: The L2 ID includes a source L2 ID and / or a target L2 ID.

67. The first terminal according to claim 65 or 66, wherein: The mapping relationship is specified by the protocol, default or network configuration.

68. The first terminal according to any one of claims 65 to 67, wherein: The configuration mode of the mapping relationship includes at least one of RRC, SIB, and pre-configuration.

69. The first terminal according to any one of claims 51 to 68, wherein: The data to be transmitted of the first terminal is specific data for the Redcap terminal, and the specific data is configured with a specific resource pool for the specific data.

70. The first terminal according to claim 69, wherein: The resource pool used by the transmitting terminal for sending is a specific resource pool for the specific data.

71. The first terminal according to claim 70, wherein: The current resources of the sending terminal are resources in a specific resource pool for the Redcap terminal, and the sending terminal sends the specific data on the current resources.

72. The first terminal according to any one of claims 69 to 71, wherein: The specific data includes data for the L2 ID of the Redcap terminal.

73. The first terminal according to any one of claims 69 to 71, wherein: The specific data includes data within a specific logical channel.

74. The first terminal according to claim 73, wherein: The data in the specific logical channel includes data associated with at least one of a DCR message, a discovery message, a multicast message, and a broadcast message.

75. A first terminal, comprising: The processing unit is used to determine the side transmission mode based on the terminal type.

76. The first terminal according to claim 75, wherein: The side transmission mode includes SL DRX configuration and / or SL DTX configuration; wherein the SL DRX configuration includes SL DRX parameters and / or SL eDRX mechanism; and / or the SL DTX configuration includes SL DTX parameters and / or SL eDTX mechanism.

77. The first terminal according to claim 75 or 76, wherein: The first terminal is a Redcap terminal or a terminal communicating with a Redcap terminal.

78. The first terminal according to claim 77, wherein: The SL DRX configuration includes a specific SL DRX configuration for the Redcap terminal; and / or the SL DTX configuration includes a specific SL DTX configuration for the Redcap terminal.

79. The first terminal according to claim 78, wherein: The specific SL DRX configuration for the Redcap terminal includes a SL eDRX cycle.

80. The first terminal according to claim 79, wherein: The SL eDRX cycle includes a listening window; and / or the SL eDTX cycle includes a sending window.

81. The first terminal according to claim 80, wherein: The time domain position of the lower edge of the listening window is related to the identifier of the Redcap terminal, and the time domain position of the upper edge of the listening window is determined based on the time domain position of the lower edge of the listening window and the window size; and / or, The time domain position of the lower edge of the sending window is related to the identifier of the opposite terminal, and the time domain position of the upper edge of the sending window is determined based on the time domain position of the sending window and the window size.

82. The first terminal according to claim 81, wherein: The window size is specified by the protocol, default or network configuration.

83. The first terminal according to claim 81 or 82, wherein: The configuration mode of the window size includes at least one of RRC, SIB, and pre-configuration.

84. The first terminal according to any one of claims 80 to 83, wherein: The first terminal further includes a monitoring unit and / or a first sending unit; wherein the monitoring unit is used to monitor within the monitoring window; and the first sending unit is used to send within the sending window.

85. The first terminal according to claim 84, wherein: The monitoring unit is configured to determine a duration timer and / or a monitoring period within the monitoring window according to a first SL DRX mechanism; monitor the first signaling based on the duration timer and / or the monitoring period; and / or, The first sending unit is used to determine a duration timer and / or a sending cycle within the sending window according to a first SL DTX mechanism; the Redcap terminal sends a first signaling based on the duration timer and / or the sending cycle.

86. The first terminal according to claim 85, wherein: The first signaling includes at least one of a DCR message, a discovery message, a broadcast message, and a multicast message.

87. The first terminal according to claim 78, wherein: The specific SL DRX configuration for the Redcap terminal includes a default SL DRX; and / or the specific SL DTX configuration for the Redcap terminal includes a default SL DTX.

88. The first terminal according to claim 78, wherein: A specific SL DRX configuration for the Redcap terminal is associated with a QoS flow; and / or a specific SL DTX configuration for the Redcap terminal is associated with a QoS flow.

89. The first terminal according to claim 78, wherein: The specific SL DRX configuration for the Redcap terminal has a longer listening period than the first SL DRX configuration, and / or, the specific SL DRX configuration for the Redcap terminal has a shorter duration timer than the first SL DRX configuration; and / or, The specific SL DTX configuration for the Redcap terminal has a longer listening period than the first SL DTX configuration, and / or the specific SL DTX configuration for the Redcap terminal has a shorter duration timer than the first SL DTX configuration.

90. The first terminal according to any one of claims 77 to 89, wherein: The Redcap terminal ignores and / or skips the time slot and / or duration of part of the activation time of the terminal defined in the protocol.

91. The first terminal according to any one of claims 77 to 90, wherein: The processing unit is further configured to determine at least one of the following based on the second information: SL DRX configuration and / or SL DTX configuration used for sideline data transmission of the Redcap terminal; Whether to use SL eDRX and / or SL eDTX; Whether the first terminal and / or the opposite terminal is a Redcap terminal; Whether the first terminal and / or the opposite terminal supports Redcap terminal; Whether the first terminal and / or the opposite terminal supports the Redcap service; The second information includes at least one of the following: L2 ID of the first terminal and / or the opposite device, upper layer indication, service type, service ID, QoS flow and transmission profile.

92. The first terminal according to claim 91, wherein: The service is a service of data to be transmitted and / or the QoS flow is a QoS flow of data to be transmitted.

93. The first terminal according to any one of claims 77 to 91, wherein: The SL DRX configuration used for the sideline data transmission of the Redcap terminal includes a first SL DRX configuration and / or a specific SL DRX configuration; and / or, the SL DTX configuration used for the sideline data transmission of the Redcap terminal includes a first SL DTX configuration and / or a specific SL DTX configuration.

94. The first terminal according to any one of claims 91 to 93, wherein: The sidelink data has a QoS flow, and each QoS flow of the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

95. The first terminal according to any one of claims 91 to 94, wherein: If the sidelink data does not have a QoS flow, the sidelink data has a corresponding SL DRX configuration and / or SL DTX configuration.

96. The first terminal according to any one of claims 75 to 95, wherein: The first terminal is a transmitting terminal, the transmitting terminal is a Redcap terminal, and the receiving terminal is a non-Redcap terminal, and the first terminal further includes: The second sending unit is used to send according to the first DRX configuration or the specific DRX configuration for the Redcap terminal.

97. The first terminal according to any one of claims 95 to 95, wherein: The first terminal is a transmitting terminal, the transmitting terminal is a non-Redcap terminal, and the receiving terminal is a Redcap terminal, and the first terminal further includes: The third sending unit is used to send according to the specific DRX configuration for the Redcap terminal.

98. The first terminal according to claim 97, wherein: The third sending unit is used for continuously or repeatedly sending multiple times at the activation time of the receiving terminal according to the specific DRX configuration for the Redcap terminal.

99. The first terminal according to any one of claims 75 to 95, wherein: The first terminal is a transmitting terminal, the receiving terminal is a Redcap terminal, and the transmitting terminal is a non-Redcap terminal, and the first terminal further includes: The first receiving unit is used to receive according to the specific DRX configuration for the Redcap terminal.

100. The first terminal according to any one of claims 75 to 95, wherein: The first terminal is a transmitting terminal, the receiving terminal is a non-Redcap terminal, and the transmitting terminal is a Redcap terminal, and the first terminal further includes: The second receiving unit is used to receive according to the first DRX configuration or the specific DRX configuration for the Redcap terminal.

101. A terminal device comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the terminal device executes the method as claimed in any one of claims 1 to 50.

102. A chip, comprising: A processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes a method as claimed in any one of claims 1 to 50.

103. A computer-readable storage medium, used for storing a computer program, which, when executed by a device, causes the device to perform the method according to any one of claims 1 to 50.

104. A computer program product comprising computer program instructions, the computer program instructions causing a computer to perform the method of any one of claims 1 to 50.

105. A computer program, the computer program causing a computer to execute the method according to any one of claims 1 to 50.

Images