Method for terminal device to switch search space set group (SSSG), terminal device and network device

Abstract

A method for switching search space set group (SSSG) by a terminal device, a terminal device and a network device, which are beneficial to balance the scheduling requirement and power saving requirement of the terminal device, the method comprising: during a time period in which the terminal device listens to a physical downlink control channel (PDCCH) based on a first SSSG, the terminal device sends a scheduling request (SR) to the network device, and the SR is in a waiting state; the terminal device switches to a second SSSG under certain conditions and listens to the PDCCH based on the second SSSG; wherein the density of the PDCCH listening occasions corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening occasions corresponding to the first SSSG in the time domain distribution.

Description

Technical Field

[0001] This application relates to the field of communications, specifically to a method for switching search space set groups (SSSG) on a terminal device, a terminal device, and a network device. Background Technology

[0002] In discontinuous reception (DRX) scenarios, to reduce blind detection of the Physical Downlink Control Channel (PDCCH) by terminal devices, a Search Space Set Group (SSSG) handover mechanism is considered to control the terminal's PDCCH listening behavior. Specifically, the network device configures two SSSGs for the terminal device: one SSSG for more frequent PDCCH listening and the other for less frequent PDCCH listening. Using a more frequent SSSG for PDCCH listening enables more timely scheduling and reduces service latency; using a less frequent SSSG for PDCCH listening saves terminal power.

[0003] Network devices can instruct terminal devices which SSSG to listen to on the PDCCH. However, in some scenarios, terminal devices may trigger uplink transmissions themselves, expecting further responses from the network device. For example, a terminal device may receive uplink data but lack uplink resources for reporting a Buffer Status Report (BSR), thus triggering a Scheduling Request (SR). In this case, the terminal device's expectation of a response from the network device creates an urgent need for PDCCH listening. From the network device's perspective, it can only learn about the terminal device's scheduling needs after receiving these uplink transmissions. Before receiving these transmissions, the network device is unaware of the terminal device's scheduling needs. Therefore, how terminal devices perform PDCCH listening to balance scheduling and power-saving requirements is a pressing issue that needs to be addressed. Summary of the Invention

[0004] This application provides a method for switching search space set groups (SSSG) for terminal devices, as well as terminal devices and network devices, which helps to balance the scheduling needs and power saving needs of terminal devices.

[0005] In a first aspect, a method for a terminal device to switch Search Space Set Group (SSSG) is provided, comprising: during a time period in which the terminal device listens to the Physical Downlink Control Channel (PDCCH) based on a first SSSG, the terminal device sends a scheduling request (SR) to a network device, and the SR is in a waiting state;

[0006] Under certain conditions, the terminal device switches to the second SSSG and listens to the PDCCH based on the second SSSG;

[0007] The density of PDCCH listening opportunities corresponding to the second SSSG in the time domain is greater than that of PDCCH listening opportunities corresponding to the first SSSG in the time domain.

[0008] Secondly, a method for a terminal device to switch Search Space Set Group (SSSG) is provided, comprising: a network device sending configuration information to the terminal device, the configuration information being used to configure whether the terminal device performs a switch from the first SSSG to the second SSSG and / or a switch condition from the first SSSG to the second SSSG when the terminal device sends a scheduling request (SR) and the SR is in a waiting state, wherein the density of the PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution.

[0009] Thirdly, a terminal device is provided for executing the methods described in the first aspect or its various implementations.

[0010] Specifically, the terminal device includes a functional module for performing the methods described in the first aspect or its various implementations.

[0011] Fourthly, a network device is provided for performing the methods described in the second aspect or its various implementations.

[0012] Specifically, the network device includes a functional module for performing the methods described in the second aspect or its various implementations.

[0013] Fifthly, a terminal device is provided, including a processor and a memory. 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 to perform the methods described in the first aspect or its various implementations.

[0014] In a sixth aspect, a network device is provided, including a processor and a memory. 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 to perform the methods in the second aspect or its implementations described above.

[0015] In a seventh aspect, a chip is provided for implementing the methods of any one of the first to second aspects or their respective implementations.

[0016] Specifically, the chip includes a processor for calling and running a computer program from memory, causing a device equipped with the device to perform the methods described in any of the first to second aspects above or their respective implementations.

[0017] Eighthly, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the methods of any one of the first to second aspects or their respective implementations.

[0018] Ninthly, a computer program product is provided, including computer program instructions that cause a computer to perform the methods of any one of the first to second aspects or their respective implementations.

[0019] In a tenth aspect, a computer program is provided that, when run on a computer, causes the computer to perform the methods of any one of the first to second aspects or their respective implementations.

[0020] With the above technical solution, if the terminal device sends an SR and the SR is in a pending state during the time period of using sparse SSSG to listen to PDCCH, the terminal device can switch to intensive SSSG to listen to PDCCH under certain conditions, which is beneficial to balancing the scheduling needs and power saving needs of the terminal device. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of a communication system architecture provided in an embodiment of this application.

[0022] Figure 2 This is a schematic diagram of the DRX cycle of a terminal device according to an embodiment of this application.

[0023] Figure 3 This is a schematic interactive diagram illustrating a method for switching search space set groups (SSSG) on a terminal device according to an embodiment of this application.

[0024] Figure 4 This is an example diagram of a terminal device switching SSSG according to an embodiment of this application.

[0025] Figure 5 This is an example diagram of a terminal device switching SSSG according to another embodiment of this application.

[0026] Figure 6 This is a schematic block diagram of a terminal device provided according to an embodiment of this application.

[0027] Figure 7 This is a schematic block diagram of a network device provided according to an embodiment of this application.

[0028] Figure 8 This is a schematic block diagram of a communication device provided according to an embodiment of this application.

[0029] Figure 9 This is a schematic block diagram of a chip provided according to an embodiment of this application.

[0030] Figure 10 This is a schematic block diagram of a communication system provided according to an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art without creative effort regarding the embodiments of this application are within the scope of protection of this application.

[0032] The technical solutions of this application embodiment can be applied to various communication systems, such as: Global System for 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, evolution of NR system, LTE-based access to unlicensed spectrum (LTE-U) system, NR-based access to unlicensed spectrum (NR-U) system, Non-Terrestrial Networks (NTN) system, Universal Mobile Telecommunication System (UMTS), Wireless Local Area Networks (WLAN), and Wireless Fidelity (WF). Fidelity (WiFi), 5th-Generation (5G) communication systems, or other communication systems.

[0033] Traditional communication systems typically 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 communication but also, 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. The embodiments of this application can also be applied to these communication systems.

[0034] Optionally, the communication system in this application embodiment can be applied to a carrier aggregation (CA) scenario, a dual connectivity (DC) scenario, or a standalone (SA) network deployment scenario.

[0035] Optionally, the communication system in this application embodiment can be applied to unlicensed spectrum, wherein unlicensed spectrum can also be considered as shared spectrum; or, the communication system in this application embodiment can also be applied to licensed spectrum, wherein licensed spectrum can also be considered as non-shared spectrum.

[0036] This application describes various embodiments in conjunction with network devices and terminal devices. 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.

[0037] Terminal devices can be stations (STs) in WLANs, cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, Personal Digital Assistant (PDA) devices, handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in next-generation communication systems such as NR networks, or terminal devices in future evolved Public Land Mobile Network (PLMN) networks, etc.

[0038] In the embodiments of this application, the terminal device can be deployed on land, including indoor or outdoor, handheld, wearable or vehicle-mounted; it can also be deployed on water (such as ships); and it can also be deployed in the air (such as airplanes, balloons and satellites).

[0039] In the embodiments of this application, the terminal device may be a mobile phone, a tablet computer, a computer with wireless transceiver capabilities, 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 care, 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.

[0040] By way of example and not limitation, in this embodiment, the terminal device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

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

[0042] By way of example and not limitation, in this embodiment, the network device may have mobility characteristics; for example, the network device may be a mobile device. Optionally, 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 located on land, water, or other similar locations.

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

[0044] For example, the communication system 100 used in the embodiments of this application is as follows: Figure 1 As shown. The communication system 100 may include a network device 110, which may be a device that communicates with a terminal device 120 (or a communication terminal, terminal). The network device 110 can provide communication coverage for a specific geographical area and can communicate with terminal devices located within that coverage area.

[0045] Figure 1 An exemplary embodiment shows a network device and two terminal devices. Optionally, the communication system 100 may include multiple network devices and each network device may include other numbers of terminal devices within its coverage area. This application embodiment does not limit this.

[0046] Optionally, the communication system 100 may also include other network entities such as a network controller and a mobility management entity, which is not limited in this embodiment.

[0047] It should be understood that devices with communication functions in the network / system of this application embodiment can be referred to as communication devices. Figure 1Taking the communication system 100 shown as an example, the communication equipment may include a network device 110 and a terminal device 120 with communication functions. The network device 110 and the terminal device 120 may be the specific devices described above, which will not be repeated here. The communication equipment may also include other devices in the communication system 100, such as network controllers, mobility management entities and other network entities. This application embodiment does not limit this.

[0048] It should be understood that the terms "system" and "network" are often used interchangeably in this document. The term "and / or" in this document merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0049] It should be understood that the term "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0050] In the description of the embodiments of this application, the term "correspondence" may indicate that there is a direct or indirect correspondence between two things, or that there is an association between two things, or that there is a relationship of instruction and being instructed, configuration and being configured, etc.

[0051] In this application embodiment, "predefined" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0052] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0053] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The following related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0054] In some scenarios, network devices can configure DRX functionality for terminal devices, enabling them to intermittently listen to the PDCCH, thus saving power. Specifically, the network device can configure the terminal device to wake up (DRX ON) at a time predicted by the network and listen to the PDCCH. Conversely, the network can also configure the terminal device to sleep (DRX OFF) at a time predicted by the network, meaning the terminal device does not need to listen to the PDCCH. Therefore, if network device 120 has data to transmit to terminal device 110, network device 120 can schedule terminal device 110 during the DRX ON period, while reducing terminal power consumption during the DRX OFF period due to radio frequency shutdown.

[0055] like Figure 2 The DRX cycle configured by the network device for the terminal device consists of an active period (On Duration) and a sleep period (Opportunity for DRX). In RRC Connected mode, if the terminal device is configured with DRX function, the terminal device listens to and receives PDCCH during the DRX active period; the terminal device does not listen to PDCCH during the sleep period to reduce power consumption.

[0056] It should be understood that the terminal device in the dormant state in this application embodiment does not receive PDCCH, but can receive data from other physical channels. This embodiment of the invention is not specifically limited. For example, the terminal device can receive Physical Downlink Shared Channel (PDSCH), acknowledgment / non-acknowledgment (ACK / NACK), etc. As another example, in semi-permanent scheduling (SPS), the terminal device can receive periodically configured PDSCH data.

[0057] In some embodiments, DRX functionality can be configured for Media Access Control (MAC) entities via Radio Resource Control (RRC) to control the behavior of terminal devices listening to the PDCCH. That is, each MAC entity can correspond to one DRX configuration. Optionally, the DRX configuration may include at least one of the following:

[0058] DRX-onDurationTimer: The duration during which a terminal device wakes up at the start of a DRX Cycle.

[0059] DRX Slot Offset: The delay at which the terminal device starts the drx-onDurationTimer.

[0060] DRX Inactivity Timer: The duration for which the terminal device continues to listen to the PDCCH after receiving a PDCCH indicating an uplink or downlink initial transmission.

[0061] DRX Downlink Retransmission Timer (drx-RetransmissionTimerDL): The longest duration for which the terminal device listens for the PDCCH indicating downlink retransmission scheduling. One drx-RetransmissionTimerDL corresponds to each downlink HARQ process, excluding broadcast HARQ processes.

[0062] DRX Uplink Retransmission Timer (drx-RetransmissionTimerUL): The longest duration for which the terminal device listens for the PDCCH indicating uplink retransmission scheduling. Each uplink HARQ process corresponds to one drx-RetransmissionTimerUL.

[0063] Long DRX Cycle Start Offset: Used to configure the long DRX cycle, as well as the subframe offset at the start of the long and short DRX cycles.

[0064] Short DRX Cycle: Short DRX cycle, optional configuration.

[0065] Short Cycle Timer (drx-ShortCycleTimer): The duration during which the terminal device is in a short DRX cycle (and has not received any PDCCH), which is an optional configuration.

[0066] Downlink Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) Timer: The minimum waiting time that the terminal device expects to receive the PDCCH indicating downlink scheduling. Each downlink HARQ process, excluding the broadcast HARQ process, corresponds to one HARQRTT Timer.

[0067] Short TTI DRX Retransmission Timer (drx-RetransmissionTimerShortTTI): The duration of the downlink retransmission timer when short TTI is configured.

[0068] Short TTI DRX uplink retransmission timer (drx-ULRetransmissionTimerShortTTI): The duration of the uplink retransmission timer when short TTI is configured.

[0069] Uplink Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) Timer (UL HARQ RTT Timer): The minimum waiting time required for the terminal device to receive the PDCCH indicating the uplink scheduling. Each uplink HARQ process corresponds to one UL HARQ RTT Timer.

[0070] If the terminal device is configured with DRX, then the terminal device needs to listen to the PDCCH during the DRX Active Time. DRX Active Time includes the following scenarios:

[0071] Any of the following timers are running: drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, and ra-ContentionResolutionTimer.

[0072] The terminal device sent a scheduling request (SR) on the PUCCH and is in a pending state;

[0073] In a contention-based random access process, the terminal device has not yet received an initial transmission of the PDCCH scrambled with the Cell Radio Network Temporary Identifier (C-RNTI) after successfully receiving the random access response.

[0074] In some embodiments, the terminal device may determine when to start the drx-onDurationTimer based on whether it is currently in a long DRX cycle or a short DRX cycle.

[0075] For example, if a short DRX cycle is used, and the current subframe satisfies [(SFN×10)+subframe number]modulo(drx-ShortCycle)=(drx-StartOffset)modulo(drx-ShortCycle).

[0076] For example, if a long DRX cycle is used, and the current subframe satisfies [(SFN×10)+subframe number]modulo(drx-LongCycle)=drx-StartOffset.

[0077] Here, modulo represents the modulo operation.

[0078] In some embodiments, the terminal device may start drx-onDurationTimer at a time after drx-SlotOffset slots from the start of the current subframe.

[0079] In some embodiments, the conditions for starting or restarting drx-InactivityTimer include, but are not limited to:

[0080] If the terminal device receives a PDCCH indicating the initial downlink or uplink transmission, the terminal device starts or restarts the drx-InactivityTimer.

[0081] In some embodiments, the conditions for starting and stopping drx-RetransmissionTimerDL include, but are not limited to:

[0082] When the terminal device receives a PDCCH indicating downlink transmission, or when the terminal device receives a MAC PDU on the configured downlink licensed resources, the terminal device stops the drx-RetransmissionTimerDL corresponding to the HARQ process. After completing the transmission of the HARQ process feedback for this downlink transmission, the terminal device starts the drx-HARQ-RTT-TimerDL corresponding to the HARQ process.

[0083] If the timer drx-HARQ-RTT-TimerDL corresponding to a certain HARQ on the terminal device times out, and the downlink data transmitted using this HARQ process fails to be decoded, then the terminal device starts the drx-RetransmissionTimerDL corresponding to this HARQ process.

[0084] In some embodiments, the conditions for the terminal to start and stop drx-RetransmissionTimerUL are as follows:

[0085] When the terminal device receives a PDCCH indicating uplink transmission, or when the terminal device sends a MAC PDU on the configured uplink grant resource, the terminal device stops the drx-RetransmissionTimerUL corresponding to the HARQ process. After completing the first repetition of this PUSCH, the terminal device starts the drx-HARQ-RTT-TimerUL corresponding to the HARQ process.

[0086] If the timer drx-HARQ-RTT-TimerUL corresponding to a certain HARQ on the terminal times out, the terminal device will start the drx-RetransmissionTimerUL corresponding to this HARQ process.

[0087] In some embodiments, the terminal device requests uplink resources from the network device via SR. The network device does not know when the terminal needs to send uplink data, i.e., it does not know when the terminal device will send SR. Therefore, the network device can allocate physical uplink control channel (PUCCH) resources periodically for transmitting SR to the terminal device, and then the network device checks whether there are SR reports on the allocated SR resources.

[0088] In NR systems, SR (Simultaneous Request for Access) is based on logical channels. For each uplink logical channel, the network device can choose whether to configure PUCCH resources for transmitting SR on that uplink logical channel. If an SR is triggered on an uplink logical channel, and the network device has configured PUCCH resources for transmitting SR on that uplink logical channel, the terminal device will transmit the SR on the PUCCH resources corresponding to that logical channel; otherwise, the terminal device will initiate a random access request for uplink resources.

[0089] In addition, if the terminal device triggers BFR on at least one secondary cell (SCell), and the terminal device currently has no uplink resources available for the initial transmission, or the terminal device currently has uplink resources available for the initial transmission but the resources are insufficient to carry the BFR Media Access Control Element (MAC CE) or the truncated BSR MAC CE, the terminal device will trigger SR.

[0090] Additionally, if the terminal device triggers a persistent Listen Before Talk (LBT) failure on at least one SCell, and the terminal device currently has no uplink resources available for the initial transmission, or the terminal device currently has uplink resources available for the initial transmission but these resources are insufficient to support the LBT failure MAC CE, the terminal device triggers an SR.

[0091] In some embodiments, the network device can configure multiple PUCCH resources for transmitting SR for the terminal device. For an uplink logical channel, if the network device configures PUCCH resources for transmitting SR for the uplink logical channel, then on each uplink bandwidth part (BWP), the network device can configure at most one PUCCH resource for transmitting SR for the logical channel.

[0092] Each PUCCH resource used for transmitting SR corresponds to the following configuration parameters:

[0093] 1. PUCCH resource cycle and slot / time symbol offset;

[0094] 2. PUCCH Resource Index.

[0095] To reduce the number of times connected terminal devices blindly detect the Physical Downlink Control Channel (PDCCH) when DRX is configured, a SSSG handover mechanism is considered to control the PDCCH listening behavior of the terminal devices. Specifically, the network device configures two SSSGs for each terminal device: one SSSG for more frequent PDCCH listening and the other for less frequent PDCCH listening. Using a more frequent SSSG for PDCCH listening enables more timely scheduling and reduces service latency; using a less frequent SSSG for PDCCH listening saves power for the terminal.

[0096] Network devices can instruct terminal devices which SSSG to listen to on the PDCCH. However, in some scenarios, terminal devices may trigger uplink transmissions themselves, expecting further responses from the network device. For example, a terminal device may receive uplink data but lack uplink resources for reporting a Buffer Status Report (BSR), thus triggering a Scheduling Request (SR). In this case, the terminal device's expectation of a response from the network device creates an urgent need for PDCCH listening. From the network device's perspective, it can only learn about the terminal device's scheduling needs after receiving these uplink transmissions. Before receiving these transmissions, the network device is unaware of the terminal device's scheduling needs. Therefore, how terminal devices can directly listen to the PDCCH to obtain a response from the network device is a problem that urgently needs to be solved.

[0097] Figure 3 This is a schematic interactive diagram of a method 200 for switching search space set groups (SSSG) on a terminal device according to an embodiment of this application. The method 200 can be performed by... Figure 1 The terminal device in the communication system shown performs, such as Figure 3 As shown, method 200 includes the following:

[0098] S201, During the time period when the terminal device is listening to the physical downlink control channel PDCCH based on the first SSSG, the terminal device sends a scheduling request SR to the network device, and the SR is in a waiting state.

[0099] S202, under specific conditions, the terminal device switches to the second SSSG and listens to the PDCCH based on the second SSSG, wherein the density of the PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution.

[0100] In this embodiment of the application, the terminal device is in a connected state and the terminal device is configured with DRX function, that is, the terminal device non-continuously listens to PDCCH.

[0101] In some embodiments of this application, the terminal device can receive configuration information from the network device. The configuration information is used to configure a first SSSG and a second SSSG, wherein the density of PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution.

[0102] That is, the first SSSG is a sparse SSSG and the second SSSG is a dense SSSG. Performing PDCCH listening based on the first SSSG is more conducive to saving power of terminal devices, while performing PDCCH listening based on the second SSSG is conducive to realizing timely scheduling of terminal devices and reducing service latency.

[0103] During the period when using sparse SSSG to listen to PDCCH, if the terminal device sends an SR and the SR is in a pending state, that is, it has not yet received a response from the network device, in this case, the SSSG handover mechanism needs to be designed to balance the scheduling performance and power saving requirements of the terminal device.

[0104] In other words, the technical solution of this application embodiment can be the design of a handover mechanism for the SSSG of a terminal device in a specific scenario. For example, the specific scenario may include a time period during which the terminal device uses a sparse SSSG to listen to the PDCCH, the terminal device sends an SR, and the SR is in a pending state.

[0105] In some embodiments of this application, if the terminal device sends an SR during the time period when it uses the first SSSG to listen to the PDCCH and the SR is in a pending state, the terminal device switches to the second SSSG to listen to the PDCCH.

[0106] In a specific scenario, the terminal device can switch to the second SSSG to listen to the PDCCH regardless of the triggering reason of the SR.

[0107] In some embodiments, when the terminal device sends an SR and the SR is in a pending state, switching to a more intensive SSSG to listen to the PDCCH can be decided by the terminal device itself or configured by the network device.

[0108] For example, a network device can send first configuration information to a terminal device, the first configuration information being used to configure whether the terminal device performs a switch from sparse SSSG to dense SSSG when the terminal device sends an SR and the SR is in a pending state.

[0109] In other words, network devices can be configured to allow terminal devices to switch from sparse SSSG to dense SSSG in specific scenarios.

[0110] In some embodiments, if the first configuration information configures the terminal device to switch from sparse SSSG to dense SSSG when it sends an SR and the SR is in a pending state, then the terminal device can switch to dense SSSG to listen to PDCCH when it sends an SR, the SR is in a pending state, and it is currently listening to PDCCH using sparse SSSG.

[0111] In other embodiments, if the first configuration information configures the terminal device not to perform a switch from sparse SSSG to dense SSSG when it sends an SR and the SR is in a pending state, then the terminal device will not perform a switch from sparse SSSG to dense SSSG when it sends an SR, the SR is in a pending state, and it is currently using sparse SSSG to listen to PDCCH, that is, it will continue to use sparse SSSG to listen to PDCCH.

[0112] In some embodiments of this application, the method 200 further includes:

[0113] The terminal device determines whether to perform a handover from the first SSSG to the second SSSG based on the triggering reason of the SR and / or the configuration information of the network device.

[0114] In this embodiment of the application, when the terminal device sends an SR, the SR is in a pending state, and the SSSG that the terminal device is currently listening to on the PDCCH is a sparse SSSG, it determines whether to switch to a dense SSSG based on the triggering reason of the SR. This is beneficial to balancing the scheduling performance of the terminal device and the power saving requirements of the terminal device.

[0115] For example, if the triggering reason of SR indicates that the terminal device has an urgent need for PDCCH monitoring, switching to intensive SSSG monitoring of PDCCH is beneficial to ensuring the scheduling performance of the terminal device. If the triggering reason of SR indicates that the terminal device does not have an urgent need for PDCCH monitoring, not performing SSSG switching is beneficial to ensuring the power saving needs of the terminal device.

[0116] In some embodiments, if the triggering cause of the SR is the failure to recover the secondary cell beam or the failure to recover the LBT, it can be assumed that the terminal device has an urgent need for PDCC monitoring, and the terminal device switches from the first SSSG to the second SSSG.

[0117] In some embodiments of this application, when the terminal device sends an SR and the SR is in a pending state, whether to switch to a more intensive SSSG to listen to the PDCCH based on certain judgment conditions can be decided by the terminal device itself, or it can be configured by the network device.

[0118] Optionally, the judgment conditions may include, but are not limited to, the triggering reason of SR, network device configuration information, etc.

[0119] In some embodiments, the configuration information of the network device may include second configuration information, which is used to configure whether to perform a handover from the first SSSG to the second SSSG when the terminal device sends an SR, the SR is in a pending state and the triggering reason of the SR is secondary cell beam failure recovery or LBT failure recovery.

[0120] As an example, the second configuration information may include a 1-bit indication information, which is used to indicate whether the terminal device should perform a handover from a sparse SSSG to a dense SSSG in a specific scenario, where the triggering reason of SR is secondary cell beam failure recovery or LBT failure recovery.

[0121] For example, a value of 1 for this bit indicates that a handover from a sparse SSSG to a dense SSSG will be performed when the triggering cause of the SR is a secondary cell beam failure recovery or an LBT failure recovery. A value of 0 for this bit indicates that a handover from a sparse SSSG to a dense SSSG will not be performed when the triggering cause of the SR is a secondary cell beam failure recovery or an LBT failure recovery.

[0122] In other words, the network equipment controls whether to perform SSSG handover based on whether the SR is triggered by secondary cell beam failure recovery or LBT failure recovery.

[0123] In other embodiments, the network device sets corresponding configuration information for different triggering reasons of the SR to control whether to perform a switch from sparse SSSG to dense SSSG when the SR is triggered by different reasons.

[0124] As an example, the configuration information of the network device includes third configuration information and / or fourth configuration information, wherein the third configuration information is used to indicate whether to perform a handover from the first SSSG to the second SSSG when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is secondary cell beam failure recovery, and the fourth configuration information is used to indicate whether to perform a handover from the first SSSG to the second SSSG when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery.

[0125] As an example, the third configuration information includes a 1-bit indication information, which is used to indicate whether to perform a handover from a sparse SSSG to a dense SSSG in a specific scenario and when the triggering reason of SR is secondary cell failure recovery.

[0126] For example, if the third configuration information is configured to perform a handover from a sparse SSSG to a dense SSSG when the triggering cause of SR is the secondary cell beam failure recovery, then the terminal device will perform a handover from a sparse SSSG to a dense SSSG in a specific scenario when the triggering cause of SR is the secondary cell beam failure recovery.

[0127] As an example, the fourth configuration information may include a 1-bit indication information, which is used to indicate whether to perform a switch from sparse SSSG to dense SSSG in a specific scenario and when the triggering reason of SR is LBT failure recovery.

[0128] For example, if the fourth configuration information is configured to perform a handover from a sparse SSSG to a dense SSSG when the triggering cause of SR is the secondary cell beam failure recovery, then the terminal device will perform a handover from a sparse SSSG to a dense SSSG in a specific scenario, and when the triggering cause of SR is the LBT failure recovery.

[0129] In some embodiments of this application, if the SR is triggered by the first logical channel, that is, the SR is triggered by the logical channel, in this case, the terminal device's urgency to listen to the PDCCH is less than the urgency to listen to the PDCCH due to secondary cell beam failure and LBT failure recovery. As an implementation method, the terminal device may not perform the handover from sparse SSSG to dense SSSG.

[0130] In other embodiments of this application, if the SR is triggered by the first logical channel, the terminal device can determine whether to switch from the first SSSG to the second SSSG based on the configuration information of the first logical channel or the service carried by the first logical channel.

[0131] In some embodiments, the configuration information of the first logical channel includes first indication information, which is used to indicate whether the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG when the SR is triggered by the first logical channel. In other words, the first indication information is used to indicate whether the SR is allowed to trigger the switch from a sparse SSSG to a dense SSSG when the SR is triggered by the first logical channel in the above-mentioned specific scenario.

[0132] Optionally, the first indication information can be configured together with other configuration information of the first logical channel, or it can be configured separately.

[0133] In some embodiments of this application, each logical channel corresponds to its own first indication information. For example, when configuring logical channels, a network device can configure the first indication information corresponding to each logical channel.

[0134] In some embodiments, if in the specific scenario, the SR is triggered by a first logical channel, and the first indication information corresponding to the first logical channel indicates that the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then the terminal device switches from the first SSSG to the second SSSG.

[0135] In other embodiments, if in the specific scenario, the SR is triggered by the first logical channel, and the first indication information corresponding to the first logical channel indicates that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then the terminal device will not switch from the first SSSG to the second SSSG.

[0136] Optionally, the content indicated by the first indication information can be determined based on the service corresponding to the first logical channel. For example, if the first logical channel is used to transmit a first type of service, the first indication information corresponding to the first logical channel indicates that the SR triggering terminal device triggered by the first logical channel is allowed to switch from a sparse SSSG to a dense SSSG; or, if the first logical channel is used to transmit a second type of service, the first indication information corresponding to the first logical channel indicates that the SR triggering terminal device triggered by the first logical channel is not allowed to switch from a sparse SSSG to a dense SSSG.

[0137] As an example and not a limitation, the first type of service includes latency-sensitive services, and the second type of service includes latency-insensitive services.

[0138] In other embodiments, in the specific scenario, and when the SR is triggered by the first logical channel, the terminal device may also determine whether to perform a handover from a sparse SSSG to a dense SSSG based on the service carried by the first logical channel.

[0139] As an example, if the service carried by the first logical channel is a first type of service, then it is determined to switch from the first SSSG to the second SSSG.

[0140] As another example, if the service carried by the first logical channel is a second type of service, it is determined not to switch from the first SSSG to the second SSSG.

[0141] Optionally, in this embodiment of the application, the terminal device switching from sparse SSSG to dense SSSG to listen to PDCCH may include: the terminal device stopping listening to PDCCH based on the first SSSG and starting listening to PDCCH based on the second SSSG.

[0142] Correspondingly, in the embodiments of this application, the network device may also switch from sending PDCCH based on the first SSSG to sending PDCCH based on the second SSSG according to the aforementioned SSSG switching conditions.

[0143] For example, when the network device receives an SR from the terminal device, and the SR is sent during the period of listening to the PDCCH based on the first SSSG, the network device switches from sending the PDCCH based on the first SSSG to sending the PDCCH based on the second SSSG.

[0144] For example, upon receiving an SR from a terminal device, and the SR is transmitted during PDCCH listening based on a first SSSG, and the SR is recovered from a secondary cell beam failure or LBT failure, the network device switches from transmitting PDCCH based on a first SSSG to transmitting PDCCH based on a second SSSG.

[0145] For example, when receiving an SR from a terminal device, where the SR is sent during the period of listening to the PDCCH based on the first SSSG, the SR is triggered by a logical channel, and the first indication information corresponding to the logical channel indicates that the SR is allowed to trigger the terminal device to perform an SSSG handover, the network device switches from sending the PDCCH based on the first SSSG to sending the PDCCH based on the second SSSG.

[0146] Optionally, the network device can determine the triggering reason of the SR based on the uplink resources used by the terminal device to send the SR.

[0147] Terminal devices switch to a denser SSSG listening PDCCH to obtain network device responses more quickly. Therefore, deciding which serving cells to switch from sparse SSSG listening PDCCH to dense SSSG listening PDCCH is also a problem that needs to be solved. That is, on which serving cells should the SSSG handover mechanism of this application embodiment be executed?

[0148] In some embodiments of this application, the method 200 further includes:

[0149] The terminal device determines the target serving cell set for handover from the first SSSG to the second SSSG based on the logical channel priority (LCP) limit parameter of the first logical channel that triggers the SR and / or the cross-carrier scheduling configuration.

[0150] In some embodiments, the terminal device determines the target serving cell set for performing a handover from the first SSSG to the second SSSG based on the logical channel priority (LCP) limit parameter of the first logical channel that triggers the SR and / or the cross-carrier scheduling configuration, including:

[0151] The first serving cell set is determined based on the LCP limiting parameters of the first logical channel;

[0152] Based on the cross-carrier scheduling configuration of each serving cell in the first set of serving cells, a scheduling cell corresponding to each serving cell is determined, and the scheduling cell corresponding to the serving cell can instruct the uplink scheduling of the serving cell;

[0153] The scheduling cells corresponding to all serving cells in the first serving cell set are determined as the target serving cell set.

[0154] It should be understood that in order to obtain uplink scheduling information of the serving cell, the terminal device needs to listen to the PDCCH of the scheduling cell corresponding to the serving cell. The scheduling cell corresponding to the serving cell can refer to a cell that can send a PDCCH indicating the uplink scheduling of the serving cell.

[0155] In some embodiments, if the first logical channel is not configured with LCP restriction parameters, the first serving cell set is determined to include all active serving cells of the terminal device.

[0156] In other embodiments, if the first logical channel is configured with an LCP restriction parameter, the first serving cell set is determined to include serving cells that are allowed to transmit the first logical channel.

[0157] Taking the first serving cell in the first set of serving cells as an example, the method for determining the scheduling cell corresponding to the serving cell is explained.

[0158] For example, if the first serving cell is not configured with cross-carrier scheduling, the first serving cell is determined as the scheduling cell of the first serving cell, that is, the scheduling cell of the first serving cell is the first serving cell itself.

[0159] For example, if the first serving cell is configured with cross-carrier scheduling, the cell configured by the cross-carrier scheduling of the first serving cell that can instruct the uplink scheduling of the first serving cell is determined as the scheduling cell of the first serving cell.

[0160] Furthermore, the terminal device performs a handover from the first SSSG to the second SSSG on the target serving cell in the target serving cell set.

[0161] Specifically, the terminal device can first determine the SSSG currently used on each target serving cell. If the SSSG currently used on the target serving cell is a sparse SSSG, then a handover from the first SSSG to the second SSSG is performed; otherwise, a handover from the first SSSG to the second SSSG is not performed.

[0162] The following describes the SSSG handover mechanism in a specific scenario according to the embodiments of this application, and the specific execution process for determining the target serving cell of the SSSG handover mechanism, in conjunction with Embodiment 1 and Embodiment 2.

[0163] Example 1: SSSG switching mechanism in a specific scenario.

[0164] Step 1:

[0165] The terminal device receives configuration information from the network device. This configuration information is used to configure the first SSSG and the second SSSG. The PDCCH listening time corresponding to the second SSSG is more densely distributed in the time domain than the PDCCH listening time corresponding to the first SSSG. That is, the first SSSG is a sparse SSSG, and the second SSSG is a more dense SSSG.

[0166] Step 2:

[0167] The terminal device sent an SR via PUCCH, and the SR is in a pending state.

[0168] If, for each serving cell of the terminal device, the terminal device is currently listening to the PDCCH based on the first SSSG, then the terminal device can execute the aforementioned SSSG handover mechanism.

[0169] As an example 1, if the triggering reason of the SR is SCell beam failure recovery, the terminal device stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG.

[0170] Optionally, the terminal device may perform the SSSG handover as shown in Example 1, which is determined autonomously by the terminal device.

[0171] Optionally, the terminal device performs the SSSG handover in Example 1 based on the network device configuration. For example, the network device can be configured to perform the above-mentioned SSSG handover when the SR is triggered by the secondary cell beam failure recovery in a specific scenario.

[0172] As an example 2, if the triggering reason of the SR is LBT failure recovery, the terminal device stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG.

[0173] Optionally, the terminal device may perform the SSSG handover as shown in Example 2, which is determined autonomously by the terminal device.

[0174] Optionally, the terminal device performs the SSSG handover in Example 2 based on the network device configuration. For example, the network device can be configured to perform the above-mentioned SSSG handover when the SR is triggered by LBT failure recovery in a specific scenario.

[0175] As an example 3, if the SR is triggered by the first logical channel, for example, the first logical channel triggers a BSR or a pre-emptive BSR, but there are no uplink resources for BSR reporting, or the uplink resources for BSR reporting are insufficient, the terminal device decides whether to perform SSSG handover based on the configuration information of the first logical channel.

[0176] Optionally, the network device may configure an indication message for each uplink logical channel to indicate whether the SR-triggered terminal device triggered by that uplink logical channel is allowed to perform SSSG handover, i.e., the first indication message mentioned above.

[0177] For example, network devices can be configured to allow SR-triggered terminal devices triggered by the uplink logical channel to switch to the more dense SSSG to listen to the PDCCH for logical channels of transmission latency-sensitive services.

[0178] For example, network devices may be configured to prevent SR-triggered terminal devices triggered by the uplink logical channel from switching to the more dense SSSG to listen to the PDCCH for logical channels of services that are not sensitive to transmission latency.

[0179] Optionally, the terminal device may determine whether to perform an SSSG handover based on the configuration information of the first logical channel, which may include:

[0180] If the first logical channel is configured to allow an SR-triggered terminal device triggered by the first logical channel to switch to listening to the PDCCH on a denser SSSG, then the terminal device stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG.

[0181] If the first logical channel is configured to disallow SR-triggered terminal devices triggered by the first logical channel to switch to a more dense SSSG to listen to the PDCCH, then the terminal device continues to listen to the PDCCH based on the first SSSG.

[0182] Combination Figure 4 For example, suppose a terminal device has two uplink logical channels, denoted as LC1 and LC2. LC1 is configured to allow SR-triggered terminal devices triggered by LC1 to switch to a more densely populated SSSG to listen to the PDCCH. LC2 is not configured to allow SR-triggered terminal devices triggered by LC2 to switch to a more densely populated SSSG to listen to the PDCCH. Alternatively, LC2 is configured to disallow SR-triggered terminal devices triggered by logical channels to switch to a more densely populated SSSG to listen to the PDCCH. That is, if a logical channel is not configured with the first indication information, it can be considered disallowed. Alternatively, if a logical channel is not configured with the first indication information, it can also be considered allowed.

[0183] like Figure 4 As shown, if LC1 triggers SR during the time period when the terminal device is listening to PDCCH based on the first SSSG, and SR is in a pending state, the terminal device switches to listening to PDCCH using the second SSSG.

[0184] If LC2 triggers SR during the time period when the terminal device is listening to PDCCH based on the first SSSG, and the SR is in a pending state, then the terminal device continues to use the first SSSG to listen to PDCCH.

[0185] Example 2: Method for determining the target serving cell for executing the SSSG handover mechanism

[0186] Step 1:

[0187] The terminal device receives configuration information from the network device, which is used to configure at least one of the following:

[0188] a) Configure the first SSSG and the second SSSG. The PDCCH listening time corresponding to the second SSSG is more densely distributed in the time domain than the PDCCH listening time corresponding to the first SSSG.

[0189] b) For each uplink logical channel of the terminal device, the network device may choose whether to configure PUCCH resources for transmitting SR for that uplink logical channel.

[0190] If the network device chooses to configure PUCCH resources for transmitting SR on the uplink logical channel, the network device can configure 0 or 1 PUCCH resources for transmitting SR on each uplink BWP of each serving cell of the terminal device for the uplink logical channel.

[0191] c) For each uplink logical channel of the terminal device, the network device may configure LCP restriction parameters for the uplink logical channel, or may not configure LCP restriction parameters for the uplink logical channel. The LCP restriction parameters are used to limit the serving cell that is allowed to transmit on the uplink logical channel.

[0192] Optionally, the LCP limiting parameters include, but are not limited to, the following parameters:

[0193] Allowed Serving Cells: This is the list of serving cells that are allowed to transmit this uplink logical channel.

[0194] The allowed subcarrier spacing (SCS) list is the list of subcarrier spacings that are allowed to be transmitted on this uplink logical channel.

[0195] Step 2:

[0196] If the terminal device's first logical channel triggers the terminal device to send an SR on the PUCCH of the serving cell and the SR is in a pending state, the terminal device determines the target serving cell set for executing the aforementioned SSSG handover mechanism based on the LCP limiting parameter of the uplink logical channel that triggered the SR.

[0197] Specifically, the terminal device first determines the first set of serving cells that are allowed to transmit through the first logical channel based on the LCP limitation parameters of the first logical channel.

[0198] For example, if the network device does not configure LCP restriction parameters for the first logical channel that triggers the SR, the terminal device determines that the first serving cell set includes all the serving cells activated by the terminal device, that is, the first logical channel is allowed to be transmitted on all the activated serving cells.

[0199] For example, if the network device configures an LCP restriction parameter for the first logical channel that triggers the SR, the terminal device can determine the cell that allows the first logical channel to transmit based on the LCP restriction parameter of the first logical channel.

[0200] Furthermore, based on the cross-carrier scheduling configuration of the first serving cell set, the target serving cell set for performing SSSG handover is determined.

[0201] Specifically, based on the cross-carrier scheduling configuration of each serving cell in the first serving cell set, the scheduling cell corresponding to each serving cell is determined, and further, the scheduling cells corresponding to all serving cells in the first serving cell set constitute the target serving cell set.

[0202] For example, if the first serving cell in the first serving cell set is not configured with cross-carrier scheduling, then the scheduling cell corresponding to the first serving cell is determined to be the first serving cell itself. Alternatively, if the first serving cell is configured with cross-carrier scheduling, then the scheduling cell corresponding to the first serving cell can be determined based on the cross-carrier scheduling configuration of the first serving cell.

[0203] Furthermore, for each serving cell in the target serving cell set, the terminal device determines whether it is currently listening to the PDCCH based on the first SSSG on that serving cell. If so, the terminal device performs an SSSG handover, that is, it stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG. Otherwise, no SSSG handover is performed.

[0204] Combination Figure 5 For example, suppose a terminal device is configured with two uplink logical channels, denoted as LC1 and LC2. All active serving cells of the network device include the primary cell (PCell) and secondary cell 1 (Scell ​​1). The network device does not configure LCP restriction parameters for LC1, but it does configure LCP restriction parameters for LC2, and determines that LC2 transmission is only permitted on PCell based on these LCP restriction parameters. For the terminal device's serving cells, the network device does not configure cross-carrier scheduling; that is, for each serving cell, the scheduling cell is the serving cell itself.

[0205] like Figure 5 As shown, if LC1 triggers SR and SR is in a pending state, since LC1 is not configured with LCP restriction parameters, it can be determined that the target serving cell set includes PCell and Scell ​​1. If the terminal device is currently listening to PDCCH on PCell and Scell ​​1 based on the first SSSG, the terminal device will switch to listening to PDCCH on PCell and Scell ​​1 using the second SSSG.

[0206] If LC2 triggers SR and SR is in a pending state, LC2 is configured with LCP restriction parameters. The target serving cell set can be determined based on the LCP restriction parameters, including Pcell. If the terminal device is currently listening to PDCCH on Pcell based on the first SSSG, then the terminal device will switch to listening to PDCCH using the second SSSG on Pcell. No SSSG handover will be performed on Scell ​​1.

[0207] In summary, if a terminal device sends an SR during a period of sparse SSSG listening to PDCCH and the SR is in a pending state, the terminal device can switch to dense SSSG listening to PDCCH if the SR is triggered by secondary cell beam failure recovery or LBT failure recovery, which is beneficial to ensuring the scheduling needs of the terminal device.

[0208] In addition, if a terminal device sends an SR during the period when it is using sparse SSSG to listen to PDCCH and the SR is in a pending state, the terminal device can determine whether to switch to dense SSSG to listen to PDCCH based on the LC configuration if the SR is triggered by LC. This is beneficial to ensuring the scheduling needs and power saving needs of the terminal device.

[0209] Furthermore, when SR is triggered by a logical channel, the target serving cell set for SSSG handover is determined based on the LCP parameters of the logical channel and the cross-carrier scheduling configuration of the serving cell. This helps ensure that the terminal device listens to the PDCCH on the correct cell so as to obtain the response from the network device in a timely manner.

[0210] The above text combined Figures 3 to 5 The method embodiments of this application are described in detail below, in conjunction with... Figures 6 to 10 The present application describes the device embodiments in detail. It should be understood that the device embodiments correspond to the method embodiments, and similar descriptions can be referred to the method embodiments.

[0211] Figure 6 A schematic block diagram of a terminal device 400 according to an embodiment of this application is shown. Figure 6 As shown, the terminal device 400 includes:

[0212] Communication unit 410 is used to send a scheduling request SR to the network device during the time period of listening to the physical downlink control channel PDCCH based on the first SSSG, and the SR is in a waiting state;

[0213] Processing unit 420 is used to switch to the second SSSG under specific conditions;

[0214] The communication unit 410 is also used to listen to the PDCCH based on the second SSSG;

[0215] The density of PDCCH listening opportunities corresponding to the second SSSG in the time domain is greater than that of PDCCH listening opportunities corresponding to the first SSSG in the time domain.

[0216] In some embodiments of this application, the processing unit 420 is further configured to:

[0217] Based on the triggering reason of the SR and / or the configuration information of the network device, determine whether to switch from the first SSSG to the second SSSG.

[0218] In some embodiments of this application, the processing unit 420 is further configured to:

[0219] If the triggering cause of the SR is a secondary cell beam failure recovery, determine to switch from the first SSSG to the second SSSG; or

[0220] If the triggering cause of the SR is the failure of the Listen-After-Speak LBT recovery, then switch from the first SSSG to the second SSSG.

[0221] In some embodiments of this application, the processing unit 420 is further configured to:

[0222] If the SR is triggered by the first logical channel, determine whether to switch from the first SSSG to the second SSSG based on the configuration information of the first logical channel or the service carried by the first logical channel;

[0223] The configuration information of the first logical channel includes first indication information, which is used to indicate whether the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG when the SR is triggered by the first logical channel.

[0224] In some embodiments of this application, the processing unit 420 is further configured to:

[0225] If the first indication information is used to indicate that the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then determine to switch from the first SSSG to the second SSSG; or

[0226] If the fifth first indication information is used to indicate that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then it is determined that the device will not switch from the first SSSG to the second SSSG.

[0227] In some embodiments of this application, the processing unit 420 is further configured to:

[0228] If the service carried by the first logical channel is a first type of service, determine to switch from the first SSSG to the second SSSG; or

[0229] If the service carried by the first logical channel is a second type of service, it is determined not to switch from the first SSSG to the second SSSG.

[0230] In some embodiments of this application, the first type of service includes latency-sensitive services, and the second type of service includes latency-insensitive services.

[0231] In some embodiments of this application, the terminal device determines whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR.

[0232] In some embodiments of this application, the configuration information of the network device includes first configuration information, wherein the first configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG when it sends an SR and the SR is in a waiting state.

[0233] In some embodiments of this application, the configuration information of the network device includes second configuration information, wherein the second configuration information is used to configure a handover from the first SSSG to the second SSSG when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is secondary cell beam failure recovery or LBT failure recovery; or

[0234] The configuration information of the network device includes third configuration information and / or fourth configuration information, wherein the third configuration information is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is secondary cell beam failure recovery, a handover from the first SSSG to the second SSSG is performed; and the fourth configuration information is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

[0235] In some embodiments of this application, the communication unit 410 is further configured to:

[0236] Upon determining that the device is switching from the first SSSG to the second SSSG, the terminal device stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG.

[0237] In some embodiments of this application, the processing unit 420 is further configured to:

[0238] Based on the logical channel priority (LCP) limit parameter of the first logical channel that triggers the SR and / or the cross-carrier scheduling configuration, determine the target serving cell set for performing a handover from the first SSSG to the second SSSG.

[0239] In some embodiments of this application, the processing unit 420 is further configured to:

[0240] The first serving cell set is determined based on the LCP limiting parameters of the first logical channel;

[0241] Based on the cross-carrier scheduling configuration of each serving cell in the first set of serving cells, a scheduling cell corresponding to each serving cell is determined, and the scheduling cell corresponding to the serving cell can instruct the uplink scheduling of the serving cell;

[0242] The scheduling cells corresponding to all serving cells in the first serving cell set are determined as the target serving cell set.

[0243] In some embodiments of this application, the processing unit 420 is further configured to:

[0244] If the first logical channel is not configured with LCP restriction parameters, the first serving cell set is determined to include all active serving cells of the terminal device; or...

[0245] If the first logical channel is configured with LCP restriction parameters, the first serving cell set is determined to include serving cells that are allowed to transmit the first logical channel.

[0246] In some embodiments of this application, the processing unit 420 is further configured to:

[0247] If the first serving cell in the first serving cell set is not configured with cross-carrier scheduling, the first serving cell will be determined as the scheduling cell for the first serving cell; or

[0248] If the first serving cell in the first serving cell set is configured with cross-carrier scheduling, the cell configured by the cross-carrier scheduling of the first serving cell that can instruct the uplink scheduling of the first serving cell is determined as the scheduling cell of the first serving cell.

[0249] Optionally, in some embodiments, the communication unit may be a communication interface or transceiver, or an input / output interface of a communication chip or system-on-a-chip. The processing unit may be one or more processors.

[0250] It should be understood that the terminal device 400 according to the embodiments of this application may correspond to the terminal device in the method embodiments of this application, and the above and other operations and / or functions of each unit in the terminal device 400 are respectively for implementing Figure 3 The corresponding process of the terminal device in method 200 shown will not be described in detail here for the sake of brevity.

[0251] Figure 7 This is a schematic block diagram of a network device according to an embodiment of this application. Figure 7 The network equipment 500 includes:

[0252] The communication unit 510 is used to send configuration information to the terminal device. The configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG and / or a handover condition from the first SSSG to the second SSSG when the terminal device sends a scheduling request SR and the SR is in a waiting state. The density of the PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution.

[0253] In some embodiments of this application, the configuration information includes second configuration information, wherein the second configuration information is used to configure a handover from the first SSSG to the second SSSG when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is secondary cell beam failure recovery or LBT failure recovery.

[0254] In some embodiments of this application, the configuration information includes third configuration information and / or fourth configuration information, wherein the third configuration information is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is secondary cell beam failure recovery, a handover from the first SSSG to the second SSSG is performed; and the fourth configuration information is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

[0255] In some embodiments of this application, the configuration information includes configuration information of the logical channel that triggers the SR. The configuration information of the logical channel that triggers the SR includes first indication information, which is used to indicate whether the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG when the SR is triggered by the logical channel.

[0256] In some embodiments of this application, when the type of service carried by the logical channel is a first type, the first indication information is used to indicate that the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG;

[0257] When the type of service carried by the logical channel is type two, the first indication information is used to indicate that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG.

[0258] In some embodiments of this application, the first type of service includes latency-sensitive services, and the second type of service includes latency-insensitive services.

[0259] In some embodiments of this application, the communication unit 510 is further configured to:

[0260] Receive the SR sent by the terminal device, wherein the SR is sent during the time period when the terminal device uses the first SSSG to listen to the PDCCH;

[0261] Switch to using the second SSSG to send the PDCCH.

[0262] Optionally, in some embodiments, the communication unit may be a communication interface or transceiver, or an input / output interface of a communication chip or system-on-a-chip. The processing unit may be one or more processors.

[0263] It should be understood that the network device 500 according to the embodiments of this application may correspond to the network device in the method embodiments of this application, and the above and other operations and / or functions of each unit in the network device 500 are respectively for implementing Figure 3 The corresponding procedures for network devices in method 200 are not described in detail here for the sake of brevity.

[0264] Figure 8 This is a schematic structural diagram of a communication device 600 provided in an embodiment of this application. Figure 8 The communication device 600 shown includes a processor 610, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0265] Optionally, such as Figure 8 As shown, the communication device 600 may further include a memory 620. The processor 610 can retrieve and run computer programs from the memory 620 to implement the methods described in this embodiment.

[0266] The memory 620 can be a separate device independent of the processor 610, or it can be integrated into the processor 610.

[0267] Optionally, such as Figure 8 As shown, the communication device 600 may also include a transceiver 630, and the processor 610 may control the transceiver 630 to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices.

[0268] The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0269] Optionally, the communication device 600 may specifically be a network device in the embodiments of this application, and the communication device 600 may implement the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0270] Optionally, the communication device 600 may specifically be a mobile terminal / terminal device in the embodiments of this application, and the communication device 600 may implement the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0271] Figure 9 This is a schematic structural diagram of the chip according to an embodiment of this application. Figure 9 The chip 700 shown includes a processor 710, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0272] Optionally, such as Figure 9 As shown, chip 700 may further include memory 720. Processor 710 can retrieve and run computer programs from memory 720 to implement the methods described in this embodiment.

[0273] The memory 720 can be a separate device independent of the processor 710, or it can be integrated into the processor 710.

[0274] Optionally, the chip 700 may also include an input interface 730. The processor 710 can control the input interface 730 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0275] Optionally, the chip 700 may also include an output interface 740. The processor 710 can control the output interface 740 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0276] Optionally, the chip can be applied to the network device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0277] Optionally, the chip can be applied to the mobile terminal / terminal device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

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

[0279] Figure 10 This is a schematic block diagram of a communication system 900 provided in an embodiment of this application. Figure 10 As shown, the communication system 900 includes a terminal device 910 and a network device 920.

[0280] The terminal device 910 can be used to implement the corresponding functions implemented by the terminal device in the above method, and the network device 920 can be used to implement the corresponding functions implemented by the network device in the above method. For the sake of brevity, these will not be elaborated here.

[0281] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0282] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0283] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this 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 memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0284] This application also provides a computer-readable storage medium for storing computer programs.

[0285] Optionally, the computer-readable storage medium can be applied to the network device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0286] Optionally, the computer-readable storage medium can be applied to the mobile terminal / terminal device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0287] This application also provides a computer program product, including computer program instructions.

[0288] Optionally, the computer program product can be applied to the network device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0289] Optionally, the computer program product can be applied to the mobile terminal / terminal device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0290] This application also provides a computer program.

[0291] Optionally, the computer program can be applied to the network device in the embodiments of this application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0292] Optionally, the computer program can be applied to the mobile terminal / terminal device in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0293] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0294] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0295] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0296] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0297] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0298] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0299] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for switching search space set groups (SSSG) in a terminal device, characterized in that, include: During the time period when the terminal device is listening to the physical downlink control channel (PDCCH) based on the first SSSG, the terminal device sends a scheduling request (SR) to the network device, and the SR is in a waiting state. Under certain conditions, the terminal device switches to the second SSSG and listens to the PDCCH based on the second SSSG; Among them, the density of PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution; The method further includes: The terminal device determines whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR and / or the configuration information of the network device; The configuration information of the network device includes fourth configuration information, which is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

2. The method according to claim 1, characterized in that, The terminal device determines whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR and / or the configuration information of the network device, including: If the triggering cause of the SR is a secondary cell beam failure recovery, determine to switch from the first SSSG to the second SSSG; or If the triggering cause of the SR is the failure of the Listen-After-Speak LBT recovery, then switch from the first SSSG to the second SSSG.

3. The method according to claim 1, characterized in that, The terminal device determines whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR and / or the configuration information of the network device, including: If the SR is triggered by the first logical channel, determine whether to switch from the first SSSG to the second SSSG based on the configuration information of the first logical channel or the service carried by the first logical channel; The configuration information of the first logical channel includes first indication information, which is used to indicate whether the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG when the SR is triggered by the first logical channel.

4. The method according to claim 3, characterized in that, The step of determining whether to switch from the first SSSG to the second SSSG based on the configuration information of the first logical channel or the service carried by the first logical channel includes: If the first indication information is used to indicate that the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then determine to switch from the first SSSG to the second SSSG; or If the first indication information is used to indicate that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG, then it is determined that the device will not switch from the first SSSG to the second SSSG.

5. The method according to claim 3, characterized in that, The step of determining whether to switch from the first SSSG to the second SSSG based on the configuration information of the first logical channel or the service carried by the first logical channel includes: If the service carried by the first logical channel is a first type of service, determine to switch from the first SSSG to the second SSSG; or If the service carried by the first logical channel is a second type of service, it is determined not to switch from the first SSSG to the second SSSG.

6. The method according to claim 5, characterized in that, The first type of service includes latency-sensitive services, and the second type of service includes latency-insensitive services.

7. The method according to any one of claims 1-6, characterized in that, The terminal device determines whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR.

8. The method according to any one of claims 1-6, characterized in that, The configuration information of the network device includes first configuration information, wherein the first configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG when the terminal device sends an SR and the SR is in a waiting state.

9. The method according to any one of claims 1-6, characterized in that, Under specific conditions, the terminal device switches to the second SSSG and listens to the PDCCH based on the second SSSG, including: Upon determining that the device is switching from the first SSSG to the second SSSG, the terminal device stops listening to the PDCCH based on the first SSSG and starts listening to the PDCCH based on the second SSSG.

10. The method according to any one of claims 1-6, characterized in that, The method further includes: The terminal device determines the target serving cell set for handover from the first SSSG to the second SSSG based on the logical channel priority (LCP) limit parameter of the first logical channel that triggers the SR and / or the cross-carrier scheduling configuration.

11. The method according to claim 10, characterized in that, The terminal device determines the target serving cell set for handover from the first SSSG to the second SSSG based on the logical channel priority (LCP) limit parameter of the first logical channel that triggers the SR and / or the cross-carrier scheduling configuration, including: The first serving cell set is determined based on the LCP limiting parameters of the first logical channel; Based on the cross-carrier scheduling configuration of each serving cell in the first set of serving cells, a scheduling cell corresponding to each serving cell is determined, and the scheduling cell corresponding to the serving cell can instruct the uplink scheduling of the serving cell; The scheduling cell corresponding to all serving cells in the first serving cell set is determined as the target serving cell set.

12. The method according to claim 11, characterized in that, The step of determining the first serving cell set based on the LCP limiting parameters of the first logical channel includes: If the first logical channel is not configured with LCP restriction parameters, the first serving cell set is determined to include all active serving cells of the terminal device; or... If the first logical channel is configured with LCP restriction parameters, the first serving cell set is determined to include serving cells that are allowed to transmit the first logical channel.

13. The method according to claim 11, characterized in that, The step of determining the scheduling cell corresponding to each serving cell based on the cross-carrier scheduling configuration of each serving cell in the first serving cell set includes: If the first serving cell in the first serving cell set is not configured with cross-carrier scheduling, the first serving cell will be determined as the scheduling cell for the first serving cell; or If the first serving cell in the first serving cell set is configured with cross-carrier scheduling, the cell configured by the cross-carrier scheduling of the first serving cell that can instruct the uplink scheduling of the first serving cell is determined as the scheduling cell of the first serving cell.

14. A method for switching search space set groups (SSSG) in a terminal device, characterized in that, include: The network device sends configuration information to the terminal device. The configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG and / or a handover condition from the first SSSG to the second SSSG when the terminal device sends a scheduling request SR and the SR is in a waiting state. The density of the PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution. The configuration information includes fourth configuration information, which is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a switch from the first SSSG to the second SSSG is performed.

15. The method according to claim 14, characterized in that, The configuration information includes configuration information for the logical channel that triggers the SR. The configuration information for the logical channel that triggers the SR includes first indication information. The first indication information is used to indicate whether the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG when the SR is triggered by the logical channel.

16. The method according to claim 15, characterized in that, When the type of service carried by the logical channel is a first type, the first indication information is used to indicate that the SR is allowed to trigger the terminal device to switch from the first SSSG to the second SSSG; When the type of service carried by the logical channel is the second type, the first indication information is used to indicate that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG.

17. The method according to claim 16, characterized in that, The first type of service includes latency-sensitive services, and the second type of service includes latency-insensitive services.

18. The method according to any one of claims 14 to 17, characterized in that, The method further includes: The network device receives the SR sent by the terminal device, wherein the SR is sent during the time period when the terminal device is listening to the PDCCH using the first SSSG; The network device switches to using the second SSSG to send the PDCCH.

19. A terminal device, characterized in that, include: A communication unit is used to send a scheduling request (SR) to a network device, and the SR is in a waiting state; The processing unit, if the SR is transmitted during the time period of listening to the physical downlink control channel PDCCH based on the first SSSG, switches to the second SSSG under certain conditions; The communication unit is also used to listen to the PDCCH based on the second SSSG; Among them, the density of PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution; The processing unit is further configured to determine whether to switch from the first SSSG to the second SSSG based on the triggering reason of the SR and / or the configuration information of the network device; The configuration information of the network device includes fourth configuration information, which is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

20. A network device, characterized in that, include: A communication unit is used to send configuration information to a terminal device. The configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG and / or a handover condition from the first SSSG to the second SSSG when the terminal device sends a scheduling request SR and the SR is in a waiting state. The density of the PDCCH listening opportunities corresponding to the second SSSG in the time domain distribution is greater than the density of the PDCCH listening opportunities corresponding to the first SSSG in the time domain distribution. The configuration information includes fourth configuration information, which is used to indicate that when the terminal device sends an SR, the SR is in a waiting state and the triggering reason of the SR is LBT failure recovery, a switch from the first SSSG to the second SSSG is performed.

21. A terminal device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 13.

22. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 13.

23. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 13.

24. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 13.

25. A network device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 14 to 18.

26. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 14 to 18.

27. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 14 to 18.

28. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 14 to 18.

Images