CN116530160A - Method for switching search space set packet SSSG by terminal equipment, terminal equipment and network equipment - Google Patents

Abstract

A method for switching search space set packets SSSG by a terminal device, the terminal device and a network device are beneficial to balancing scheduling requirements and power saving requirements of the terminal device, and the method comprises the following steps: in a time period when a terminal device monitors a 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; the terminal equipment is switched to a second SSSG under a specific condition, and PDCCH is monitored based on the second SSSG; and the density of the PDCCH monitoring time corresponding to the second SSSG on the time domain distribution is greater than that of the PDCCH monitoring time corresponding to the first SSSG on the time domain distribution.

Description

Method for switching search space set packet SSSG by terminal equipment, terminal equipment and network equipment Technical Field

The embodiment of the application relates to the field of communication, in particular to a method for switching a search space set packet (SSSG) by terminal equipment, the terminal equipment and network equipment.

Background

In a discontinuous reception (Discontinuous Reception, DRX) scenario, to reduce terminal device blind detection of physical downlink control channels (Physical Downlink Control Channel, PDCCH), it is considered to control the PDCCH listening behavior of the terminal through a search space set packet (Search Space Set Group, SSSG) switching mechanism. That is, the network device configures 2 SSSGs for the terminal device, where one SSSG corresponds to a denser PDCCH monitoring opportunity, and another SSSG corresponds to a thinner PDCCH monitoring opportunity. The dense SSSG is used for monitoring the PDCCH, so that more timely scheduling can be realized, and service time delay is reduced; the purpose of terminal power saving can be achieved by using sparse SSSG to monitor PDCCH.

The network device may instruct the terminal device based on which SSSG listens to the PDCCH, but in some scenarios the terminal device may trigger the uplink transmission itself to expect the network device to have a further response, such as: the terminal device has uplink data arrival without uplink resources for buffer status report (Buffer Status Report, BSR) reporting, thereby triggering a scheduling request (Scheduling Request, SR), in which case the terminal device has a more urgent need for PDCCH monitoring because it expects a response from the network device. From the network device's point of view, the network device can only learn the scheduling needs of the terminal device after receiving the uplink transmissions of the terminal device, whereas the network device does not know the scheduling needs of the terminal device before the network device receives the uplink transmissions of the terminal device. Therefore, how the terminal device performs PDCCH listening to balance the scheduling requirement and the power saving requirement of the terminal device is an urgent problem to be solved.

Disclosure of Invention

The application provides a method for switching search space set packets SSSG by terminal equipment, the terminal equipment and network equipment, which are beneficial to balancing the scheduling requirement and the power saving requirement of the terminal equipment.

In a first aspect, a method for switching a search space set packet SSSG by a terminal device is provided, including: in a time period when a terminal device monitors a 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;

the terminal equipment is switched to a second SSSG under a specific condition, and PDCCH is monitored based on the second SSSG;

and the density of the PDCCH monitoring time corresponding to the second SSSG on the time domain distribution is greater than that of the PDCCH monitoring time corresponding to the first SSSG on the time domain distribution.

In a second aspect, a method for switching search space set packets SSSG by a terminal device is provided, including: the network device sends configuration information to the terminal device, where 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, where a density of PDCCH monitoring opportunities corresponding to the second SSSG is greater on a time domain distribution than a density of PDCCH monitoring opportunities corresponding to the first SSSG on a time domain distribution.

In a third aspect, a terminal device is provided for performing the method in the first aspect or each implementation manner thereof.

Specifically, the terminal device comprises functional modules for performing the method of the first aspect or its implementation manner.

In a fourth aspect, a network device is provided for performing the method of the second aspect or implementations thereof.

In particular, the network device comprises functional modules for performing the method of the second aspect or implementations thereof described above.

In a fifth aspect, a terminal device is provided comprising a processor and a memory. The memory is used for storing a computer program, and the processor is used for calling and running the computer program stored in the memory and executing the method in the first aspect or various implementation manners thereof.

In a sixth aspect, a network device is provided that includes a processor and a memory. The memory is for storing a computer program and the processor is for calling and running the computer program stored in the memory for performing the method of the second aspect or implementations thereof described above.

A seventh aspect provides a chip for implementing the method of any one of the first to second aspects or each implementation thereof.

Specifically, the chip includes: a processor for calling and running a computer program from a memory, causing a device in which the apparatus is installed to perform the method as in any one of the first to second aspects or implementations thereof described above.

In an eighth aspect, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the method of any one of the above-described first to second aspects or implementations thereof.

A ninth aspect provides a computer program product comprising computer program instructions for causing a computer to perform the method of any one of the first to second aspects or implementations thereof.

In a tenth aspect, there is provided a computer program which, when run on a computer, causes the computer to perform the method of any one of the first to second aspects or implementations thereof.

Through the technical scheme, if the terminal equipment sends the SR in the period of monitoring the PDCCH by using the sparse SSSG and the SR is in the pending state, the terminal equipment can switch to the dense SSSG to monitor the PDCCH under a specific condition, so that the scheduling requirement and the power saving requirement of the terminal equipment are balanced.

Drawings

Fig. 1 is a schematic diagram of a communication system architecture provided in an embodiment of the present application.

Fig. 2 is a schematic diagram of a DRX cycle of a terminal device according to an embodiment of the present application.

Fig. 3 is a schematic interaction diagram of a method for a terminal device to switch a search space set packet SSSG according to an embodiment of the present application.

Fig. 4 is an example diagram of a terminal device switching SSSG according to an embodiment of the present application.

Fig. 5 is an example diagram of a terminal device switching SSSG according to another embodiment of the present application.

Fig. 6 is a schematic block diagram of a terminal device according to an embodiment of the present application.

Fig. 7 is a schematic block diagram of a network device provided according to an embodiment of the present application.

Fig. 8 is a schematic block diagram of a communication device provided according to an embodiment of the present application.

Fig. 9 is a schematic block diagram of a chip provided according to an embodiment of the present application.

Fig. 10 is a schematic block diagram of a communication system provided according to an embodiment of the present application.

Detailed Description

The following description of the technical solutions in the embodiments of the present application will be made with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden for the embodiments herein, are intended to be within the scope of the present application.

The technical solution of the embodiment of the application can be applied to various communication systems, for example: global system for mobile communications (Global System of Mobile communication, GSM), code division multiple access (Code Division Multiple Access, CDMA) system, wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA) system, general packet Radio service (General Packet Radio Service, GPRS), long term evolution (Long Term Evolution, LTE) system, advanced long term evolution (Advanced long term evolution, LTE-a) system, new Radio (NR) system, evolved system of NR system, LTE-based access to unlicensed spectrum, LTE-U) system on unlicensed spectrum, NR (NR-based access to unlicensed spectrum, NR-U) system on unlicensed spectrum, non-terrestrial communication network (Non-Terrestrial Networks, NTN) system, universal mobile communication system (Universal Mobile Telecommunication System, UMTS), wireless local area network (Wireless Local Area Networks, WLAN), wireless fidelity (Wireless Fidelity, wiFi), fifth Generation communication (5 th-Generation, 5G) system, or other communication system, etc.

Generally, the number of connections supported by the conventional communication system is limited and easy to implement, however, with the development of communication technology, the mobile communication system will support not only conventional communication but also, for example, device-to-Device (D2D) communication, machine-to-machine (Machine to Machine, M2M) communication, machine type communication (Machine Type Communication, MTC), inter-vehicle (Vehicle to Vehicle, V2V) communication, or internet of vehicles (Vehicle to everything, V2X) communication, etc., and the embodiments of the present application may also be applied to these communication systems.

Optionally, the communication system in the embodiment of the present application may be applied to a carrier aggregation (Carrier Aggregation, CA) scenario, a dual connectivity (Dual Connectivity, DC) scenario, and a Stand Alone (SA) fabric scenario.

Optionally, the communication system in the embodiments of the present application may be applied to unlicensed spectrum, where unlicensed spectrum may also be considered as shared spectrum; alternatively, the communication system in the embodiments of the present application may also be applied to licensed spectrum, where licensed spectrum may also be considered as non-shared spectrum.

Embodiments of the present application describe various embodiments in connection with network devices and terminal devices, where a terminal device may also be referred to as a User Equipment (UE), access terminal, subscriber unit, subscriber station, mobile station, remote terminal, mobile device, user terminal, wireless communication device, user agent, user Equipment, or the like.

The terminal device may be a STATION (ST) in a WLAN, may be a cellular telephone, a cordless telephone, a session initiation protocol (Session Initiation Protocol, SIP) phone, a wireless local loop (Wireless Local Loop, WLL) STATION, a personal digital assistant (Personal Digital Assistant, PDA) device, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, a vehicle mounted device, a wearable device, a terminal device in a next generation communication system such as an NR network, or a terminal device in a future evolved public land mobile network (Public Land Mobile Network, PLMN) network, etc.

In embodiments of the present application, the terminal device may be deployed on land, including indoor or outdoor, hand-held, wearable or vehicle-mounted; can also be deployed on the water surface (such as ships, etc.); but may also be deployed in the air (e.g., on aircraft, balloon, satellite, etc.).

In the embodiment of the present application, the terminal device may be a Mobile Phone (Mobile Phone), a tablet computer (Pad), a computer with a wireless transceiving function, a Virtual Reality (VR) terminal device, an augmented Reality (Augmented Reality, AR) terminal device, a wireless terminal device in industrial control (industrial control), a wireless terminal device in unmanned driving (self driving), a wireless terminal device in remote medical (remote medical), a wireless terminal device in smart grid (smart grid), a wireless terminal device in transportation security (transportation safety), a wireless terminal device in smart city (smart city), or a wireless terminal device in smart home (smart home), and the like.

By way of example, and not limitation, in embodiments of the present application, the terminal device may also be a wearable device. The wearable device can also be called as a wearable intelligent device, and is a generic name for intelligently designing daily wear by applying wearable technology and developing wearable devices, such as glasses, gloves, watches, clothes, shoes and the like. The wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also can realize a powerful function through software support, data interaction and cloud interaction. The generalized wearable intelligent device includes full functionality, large size, and may not rely on the smart phone to implement complete or partial functionality, such as: smart watches or smart glasses, etc., and focus on only certain types of application functions, and need to be used in combination with other devices, such as smart phones, for example, various smart bracelets, smart jewelry, etc. for physical sign monitoring.

In this embodiment of the present application, the network device may be a device for communicating with a mobile device, where the network device may be an Access Point (AP) in WLAN, a base station (Base Transceiver Station, BTS) in GSM or CDMA, a base station (NodeB, NB) in WCDMA, an evolved base station (Evolutional Node B, eNB or eNodeB) in LTE, a relay station or an Access Point, a vehicle device, a wearable device, and a network device (gNB) in an NR network, or a network device in a PLMN network for future evolution, or a network device in an NTN network, etc.

By way of example and not limitation, in embodiments of the present application, a network device may have a mobile nature, e.g., the network device may be a mobile device. Alternatively, the network device may be a satellite, a balloon station. For example, the satellite may be a Low Earth Orbit (LEO) satellite, a medium earth orbit (medium earth orbit, MEO) satellite, a geosynchronous orbit (geostationary earth orbit, GEO) satellite, a high elliptical orbit (High Elliptical Orbit, HEO) satellite, or the like. Alternatively, the network device may be a base station disposed on land, in a water area, or the like.

In this embodiment of the present application, a network device may provide a service for a cell, where a terminal device communicates with the network device through a transmission resource (e.g., a frequency domain resource, or a spectrum resource) used by the cell, where the cell may be a cell corresponding to a network device (e.g., a base station), and the cell may belong to a macro base station, or may belong to a base station corresponding to a Small cell (Small cell), where the Small cell may include: urban cells (Metro cells), micro cells (Micro cells), pico cells (Pico cells), femto cells (Femto cells) and the like, and the small cells have the characteristics of small coverage area and low transmitting power and are suitable for providing high-rate data transmission services.

Exemplary, a communication system 100 to which embodiments of the present application apply is shown in fig. 1. The communication system 100 may include a network device 110, and the network device 110 may be a device that communicates with a terminal device 120 (or referred to as a communication terminal, terminal). Network device 110 may provide communication coverage for a particular geographic area and may communicate with terminal devices located within the coverage area.

Fig. 1 illustrates one network device and two terminal devices by way of example, and alternatively, the communication system 100 may include a plurality of network devices and may include other numbers of terminal devices within the coverage area of each network device, which is not limited in this embodiment of the present application.

Optionally, the communication system 100 may further include a network controller, a mobility management entity, and other network entities, which are not limited in this embodiment of the present application.

It should be understood that a device having a communication function in a network/system in an embodiment of the present application may be referred to as a communication device. Taking the communication system 100 shown in fig. 1 as an example, the communication device may include a network device 110 and a terminal device 120 with communication functions, where the network device 110 and the terminal device 120 may be specific devices described above, and are not described herein again; the communication device may also include other devices in the communication system 100, such as a network controller, a mobility management entity, and other network entities, which are not limited in this embodiment of the present application.

It should be understood that the terms "system" and "network" are used interchangeably herein. The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

It should be understood that, in the embodiments of the present application, the "indication" may be a direct indication, an indirect indication, or an indication having an association relationship. For example, a indicates B, which may mean that a indicates B directly, e.g., B may be obtained by a; it may also indicate that a indicates B indirectly, e.g. a indicates C, B may be obtained by C; it may also be indicated that there is an association between a and B.

In the description of the embodiments of the present application, the term "corresponding" may indicate that there is a direct correspondence or an indirect correspondence between the two, or may indicate that there is an association between the two, or may indicate a relationship between the two and the indicated, configured, or the like.

In the embodiment of the present application, the "predefining" may be implemented by pre-storing corresponding codes, tables or other manners that may be used to indicate relevant information in devices (including, for example, terminal devices and network devices), and the specific implementation of the present application is not limited. Such as predefined may refer to what is defined in the protocol.

In this embodiment of the present application, the "protocol" may refer to a standard protocol in the communication field, for example, may include an LTE protocol, an NR protocol, and related protocols applied in a future communication system, which is not limited in this application.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The following related technologies may be optionally combined with the technical solutions of the embodiments of the present application, which all belong to the protection scope of the embodiments of the present application. Embodiments of the present application include at least some of the following.

In some scenarios, the network device may configure the DRX function for the terminal device, so that the terminal device discontinuously listens to the PDCCH, thereby achieving the purpose of power saving of the terminal device. Specifically, the network device may configure the terminal device to wake up (DRX ON) at a network-predicted time, monitor PDSCH, and at the same time the network may also configure the terminal device to sleep (DRX OFF) at a network-predicted time, i.e., the terminal device does not need to monitor PDCCH. Thus, if the network device 120 has data to transmit to the terminal device 110, the network device 120 can schedule the terminal device 110 during the time when the terminal device 110 is in DRX ON, and reduce terminal power consumption due to radio frequency shutdown during the DRC OFF time.

As shown in fig. 2, the DRX cycle configured by the network device for the terminal device is composed of an active period (On Duration) and a sleep period (Opportunity for DRX), and in the RRC CONNECTED mode (RRC CONNECTED), if the terminal device is configured with a DRX function, the terminal device listens and receives the PDCCH during the DRX active period; the terminal device does not monitor the PDCCH during the sleep period to reduce power consumption.

It should be understood that the terminal device in sleep period in the embodiment of the present application does not receive PDCCH, but may receive data from other physical channels. The embodiment of the present invention is not particularly limited. For example, the terminal device may receive a physical downlink shared channel (Physical Downlink Shared Channel, PDSCH), acknowledgement/non-acknowledgement (ACK/NACK), or the like. For another example, in Semi-permanent scheduling (Semi-Persistent Scheduling, SPS), the terminal device may receive periodically configured PDSCH data.

In some embodiments, DRX functionality may be configured for a media intervention control (Media Access Control, MAC) entity (entity) by a radio resource control (Radio Resource Control, RRC) for controlling the behavior of the terminal device to listen to the PDCCH. That is, each MAC entity may correspond to one DRX configuration, which may optionally include at least one of:

DRX duration timer (DRX-onduration timer): the duration of the terminal device waking up at the beginning of one DRX Cycle.

DRX slot offset (DRX-SlotOffset): and starting the time delay of the drx-onDurationTimer by the terminal equipment.

DRX inactivity timer (DRX-inactivity timer): and after the terminal equipment receives the PDCCH indicating the uplink initial transmission or the downlink initial transmission, the terminal equipment continues to monitor the duration of the PDCCH.

DRX downlink retransmission timer (DRX-retransmission timer dl): the terminal device listens for the longest duration of the PDCCH indicating the downlink retransmission schedule. Each downlink HARQ process except for the broadcast HARQ process corresponds to one drx-retransmission timer dl.

DRX uplink retransmission timer (DRX-retransmission timer ul): the terminal device listens for the longest duration of the PDCCH indicating the uplink retransmission schedule. Each uplink HARQ process corresponds to one drx-retransmission timer ul.

Long DRX-cycle start offset (longDRX-cycle offset): for configuring the long DRX cycle, and the subframe offset at which the long DRX cycle and the short DRX cycle start.

Short DRX cycle (DRX-short): short DRX cycle, an optional configuration.

Short period timer (drx-ShortCycleTimer): the duration that the terminal device is in a short DRX cycle (and does not receive any PDCCH) is an optional configuration.

A downlink hybrid automatic repeat request (Hybrid Automatic Repeat Request, HARQ) Round Trip Time (RTT) Timer (HARQ RTT Timer): the terminal device expects to receive the minimum waiting time required for the PDCCH indicating the downlink scheduling. Each downlink HARQ process except the broadcast HARQ process corresponds to one HARQ RTT Timer.

Short TTI DRX retransmission timer (DRX-retransmission timer short TTI): when a short TTI is configured, the duration of the downlink retransmission timer.

Short TTI DRX uplink retransmission timer (DRX-ul retransmission timer short TTI): when a short TTI is configured, the duration of the uplink retransmission timer.

Uplink hybrid automatic repeat request (Hybrid Automatic Repeat Request, HARQ) Round Trip Time (RTT) timer (UL HARQ RTT Timer): the terminal device expects to receive the minimum latency required for the PDCCH indicating the uplink schedule, one UL HARQ RTT Timer for each uplink HARQ process.

If the terminal device configures DRX, the terminal device needs to monitor PDCCH at the DRX activation Time (Active Time). The DRX Active Time includes the following cases:

any one of drx-onduration timer, drx-incaactyitytimer, drx-retransmission timer dl, drx-retransmission timer ul, and random access contention resolution timer (ra-contentdetemer) is running;

the terminal device sends a scheduling request (Scheduling Request, SR) on PUCCH and is in a waiting (pending) state;

in the contention-based random access procedure, the terminal device has not received one initial transmission of a Cell radio network temporary identity (Cell RNTI, C-RNTI) scrambled PDCCH indication after successful reception of the random access response.

In some embodiments, the terminal device may decide to start the DRX-onduration timer based on whether it is currently in a long DRX cycle or a short DRX cycle.

For example, if a short DRX cycle is used, and the current subframe satisfies [ (sfn×10) +subframe number ] module (DRX-short cycle) = (DRX-StartOffset) module (DRX-short cycle).

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

Wherein modulo represents the modulo operation.

In some embodiments, the terminal device may start the drx-onduration timer at a time after the drx-SlotOffset slots at the beginning of the current subframe.

In some embodiments, conditions for starting or restarting a drx-InactivityTimer include, but are not limited to:

if the terminal equipment receives a PDCCH indicating the initial downlink or uplink transmission, the terminal equipment starts or restarts the drx-InactivityTimer.

In some embodiments, conditions for starting and stopping drx-retransmission timerdl include, but are not limited to:

and when the terminal equipment receives a PDCCH indicating downlink transmission or receives a MAC PDU on the configured downlink grant resource, stopping the drx-retransmission timer DL corresponding to the HARQ process by the terminal equipment. After completing the transmission fed back by the HARQ process for the current downlink transmission, the terminal equipment starts the drx-HARQ-RTT-TimerDL corresponding to the HARQ process.

If a timer drx-HARQ-RTT-TimerDL corresponding to a certain HARQ of the terminal device is timed out and the downlink data transmitted by using the HARQ process is not successfully decoded, the terminal device starts drx-retransmission TimerDL corresponding to the HARQ process.

In some embodiments, the conditions for the terminal to start and stop drx-retransmission timer ul are:

when the terminal equipment receives a PDCCH indicating uplink transmission or when the terminal equipment transmits a MAC PDU on the configured uplink authorized resource, the terminal equipment stops the drx-retransmission timer UL corresponding to the HARQ process. After finishing the first repetition transmission (repetition) of the PUSCH, the terminal equipment starts the drx-HARQ-RTT-timerl corresponding to the HARQ process.

If the corresponding timer drx-HARQ-RTT-TimerUL of a certain HARQ of the terminal is overtime, the terminal equipment starts the corresponding drx-retransmission TimerUL of the HARQ process.

In some embodiments, the terminal device applies for uplink resources to the network device through the SR. The network device does not know when the terminal needs to transmit uplink data, i.e. when the terminal device will transmit SRs. Thus, the network device may allocate a periodic physical uplink control channel (Physical Uplink Control channel, PUCCH) resource for transmitting SR to the terminal device, and then the network device detects whether there is SR reporting on the already allocated SR resource.

In NR systems, SRs are based on logical channels. For each uplink logical channel, the network device may select whether PUCCH resources for transmitting SRs are configured for the uplink logical channel. If the network equipment configures PUCCH resources for transmitting the SR for the uplink logic channel under the condition that the uplink logic channel triggers the SR, the terminal equipment transmits the SR on the PUCCH resources for transmitting the SR corresponding to the logic channel; otherwise, the terminal equipment initiates a random access application for uplink resources.

Furthermore, if the terminal device triggers a BFR on at least one secondary cell (SCell), and the terminal device currently has no uplink resources available for initial transmission or the terminal device currently has uplink resources available for initial transmission but the resources are insufficient to carry a BFR media access control element (Media Access Control Control Element, MAC CE) or a shortened (counted) BSR MAC CE, the terminal device triggers an SR.

In addition, the terminal device triggers the SR if the terminal device triggers a persistent listen-before-transmit (Listen Before Talk, LBT) failure on at least one SCell and the terminal device currently has no uplink resources available for initial transmission or the terminal device currently has uplink resources available for initial transmission but the resources are insufficient to carry the LBT failed MAC CE.

In some embodiments, the network device may configure the terminal device with a plurality of PUCCH resources for transmitting SRs. For an uplink logical channel, if the network device configures PUCCH resources for transmitting SRs for the uplink logical channel, the network device may configure at most one PUCCH resource for transmitting SRs for the logical channel on each uplink bandwidth Part (BWP).

Each PUCCH resource for transmitting an SR corresponds to the following configuration parameters:

pucch resource period and slot/time symbol offset;

pucch resource index.

In order to reduce the number of times of blind detection of physical downlink control channels (Physical Downlink Control Channel, PDCCHs) in the case of configuring DRX by a terminal device in a connected state, the PDCCH monitoring behavior of the terminal device is considered to be controlled through an SSSG switching mechanism. That is, the network device configures 2 SSSGs for the terminal device, where one SSSG corresponds to a denser PDCCH monitoring opportunity, and another SSSG corresponds to a thinner PDCCH monitoring opportunity. The dense SSSG is used for monitoring the PDCCH, so that more timely scheduling can be realized, and service time delay is reduced; the purpose of terminal power saving can be achieved by using sparse SSSG to monitor PDCCH.

The network device may instruct the terminal device based on which SSSG listens to the PDCCH, but in some scenarios the terminal device may trigger the uplink transmission itself to expect the network device to have a further response, such as: the terminal device has uplink data arrival without uplink resources for buffer status report (Buffer Status Report, BSR) reporting, thereby triggering a scheduling request (Scheduling Request, SR), in which case the terminal device has a more urgent need for PDCCH monitoring because it expects a response from the network device. From the network device's point of view, the network device can only learn the scheduling needs of the terminal device after receiving the uplink transmissions of the terminal device, whereas the network device does not know the scheduling needs of the terminal device before the network device receives the uplink transmissions of the terminal device. Therefore, how the terminal device listens on the PDCCH to obtain the response of the network device is an urgent problem to be solved

Fig. 3 is a schematic interaction diagram of a method 200 for a terminal device to switch search space set packets SSSG according to an embodiment of the application, the method 200 being executable by a terminal device in the communication system shown in fig. 1, as shown in fig. 3, the method 200 comprising:

S201, in a time period that a terminal device monitors a 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;

s202, the terminal equipment is switched to a second SSSG under a specific condition, and PDCCH is monitored based on the second SSSG, wherein the density of PDCCH monitoring opportunities corresponding to the second SSSG on time domain distribution is greater than that of PDCCH monitoring opportunities corresponding to the first SSSG on time domain distribution.

In the embodiment of the application, the terminal equipment is in a connection state, and the terminal equipment is configured with a DRX function, namely the terminal equipment discontinuously monitors PDCCH.

In some embodiments of the present application, the terminal device may receive configuration information of a network device, where the configuration information is used to configure a first SSSG and a second SSSG, where a density of PDCCH monitoring opportunities corresponding to the second SSSG on a time domain distribution is greater than a density of PDCCH monitoring opportunities corresponding to the first SSSG on the time domain distribution.

Namely, the first SSSG is a sparse SSSG, the second SSSG is a dense SSSG, the PDCCH monitoring is performed based on the first SSSG, so that the power saving of the terminal equipment is more facilitated, the PDCCH monitoring is performed based on the second SSSG, the timely scheduling of the terminal equipment is facilitated, and the service delay is reduced.

In the period of using sparse SSSG to monitor PDCCH, if the terminal device sends SR and the SR is in pending state, i.e. no response from the network device has been received, the SSSG switching mechanism needs to be designed to balance the scheduling performance and power saving requirement of the terminal device.

That is, the technical solution of the embodiment of the present application may be a design of a switching mechanism for an SSSG of a terminal device in a specific scenario. For example, the specific scenario may include that the terminal device transmits an SR in a period in which the terminal device listens to the PDCCH using a sparse SSSG, and the SR is in a pending state.

In some embodiments of the present application, during a period when the terminal device uses the first SSSG to monitor the PDCCH, if the terminal device sends an SR and the SR is in the pending state, the terminal device switches to the second SSSG to monitor the PDCCH.

That is, in a specific scenario, the terminal device may switch to the second SSSG to monitor the PDCCH regardless of the trigger reason of the SR.

In some embodiments, when the terminal device sends the SR and the SR is in the pending state, switching to the denser SSSG to monitor the PDCCH may be decided by the terminal device or configured by the network device.

For example, the network device may send first configuration information to the terminal device, where the first configuration information is used to configure whether the terminal device performs a handover from a sparse SSSG to a dense SSSG when the terminal device has sent an SR and the SR is in a pending state.

That is, the network device may configure whether the terminal device performs a handover from a sparse SSSG to a dense SSSG in a specific scenario.

In some embodiments, if the first configuration information configures the terminal device to perform switching from a sparse SSSG to a dense SSSG when the SR is transmitted and the SR is in a pending state, the terminal device may switch to the dense SSSG to listen to the PDCCH when the SR is transmitted and the SR is pending and the sparse SSSG is currently used to listen to the PDCCH.

In other embodiments, if the first configuration information configures the terminal device to send an SR and the SR is in a pending state, and does not perform a handover from a sparse SSSG to a dense SSSG, the terminal device is sending an SR and the SR is pending, and if the sparse SSSG is currently used to monitor the PDCCH, does not perform a handover from the sparse SSSG to the dense SSSG, i.e. continues to monitor the PDCCH using the sparse SSSG.

In some embodiments of the present application, the method 200 further comprises:

and the terminal equipment determines whether to execute the switching from the first SSSG to the second SSSG according to the triggering reason of the SR and/or the configuration information of the network equipment.

In the embodiment of the application, when the terminal equipment sends the SR, the SR is in the pending state, and the SSSG of the terminal equipment currently monitoring the PDCCH is a sparse SSSG, whether to switch to the dense SSSG is determined based on the triggering reason of the SR, which is beneficial to balancing the scheduling performance of the terminal equipment and the power saving requirement of the terminal equipment.

For example, when the trigger reason of the SR determines that the terminal device has urgent PDCCH monitoring requirements, the terminal device switches to the dense SSSG to monitor the PDCCH, which is beneficial to ensuring the scheduling performance of the terminal device.

In some embodiments, if the triggering reason of the SR is secondary cell beam failure recovery or LBT failure recovery, in this case, the terminal device may be considered to have urgent PDCC monitoring requirements, and the terminal device switches from the first SSSG to the second SSSG.

In some embodiments of the present application, if the terminal device sends an SR and the SR is in the pending state, whether to switch to a denser SSSG monitoring PDCCH based on a certain judgment condition may be determined by the terminal device or may also be configured by the network device.

Alternatively, the judging condition may include, for example, but not limited to, a trigger reason of SR, configuration information of the network device, and the like.

In some embodiments, the configuration information of the network device may include second configuration information, where the second configuration information is used to configure whether to perform handover from the first SSSG to the second SSSG in a case where the terminal device transmits an SR, the SR is in a pending state and a trigger of the SR is secondary cell beam failure recovery or LBT failure recovery.

As an example, the second configuration information may include 1-bit indication information, where the 1-bit indication information is used to indicate whether the terminal device performs handover from a sparse SSSG to a dense SSSG in a specific scenario in a case where the trigger of the SR is secondary cell beam failure recovery or LBT failure recovery.

For example, the 1-bit value of 1 indicates that a handover from a sparse SSSG to a dense SSSG is performed in the case where the trigger source of the SR is secondary cell beam failure recovery or LBT failure recovery, and the 1-bit value of 0 indicates that a handover from a sparse SSSG to a dense SSSG is not performed in the case where the trigger source of the SR is secondary cell beam failure recovery or LBT failure recovery.

That is, the triggering cause of the network device for SR is secondary cell beam failure recovery and LBT failure recovery, which uniformly controls whether to perform SSSG handover.

In other embodiments, the network device sets corresponding configuration information for different trigger reasons of the SR respectively to control whether to perform a handover from a sparse SSSG to a dense SSSG when the SR is triggered by different reasons.

As an example, the configuration information of the network device includes third configuration information for indicating whether to perform a handover from the first SSSG to the second SSSG in a case where the terminal device transmits an SR, the SR is in a waiting state and a trigger cause of the SR is secondary cell beam loss failure recovery, and/or fourth configuration information for indicating whether to perform a handover from the first SSSG to the second SSSG in a case where the terminal device transmits an SR, the SR is in a waiting state and a trigger cause of the SR is LBT failure recovery.

As an example, the third configuration information includes 1-bit indication information for indicating whether or not to perform a handover from a sparse SSSG to a dense SSSG when the trigger of the SR is that the secondary cell fails to recover in a specific scenario.

For example, if the third configuration information is configured to perform a handover from a sparse SSSG to a dense SSSG when the trigger cause of the SR is secondary cell beam failure recovery, the terminal device performs a handover from a sparse SSSG to a dense SSSG when the trigger cause of the SR is secondary cell beam failure recovery.

As an example, the fourth configuration information may include 1-bit indication information for indicating whether or not to perform a handover from a sparse SSSG to a dense SSSG in a specific scenario and the triggering of SR is due to LBT failure recovery.

For example, if the fourth configuration information is configured to perform handover from a sparse SSSG to a dense SSSG in a case where the trigger cause of the SR is secondary cell beam failure recovery, the terminal device performs handover from the sparse SSSG to the dense SSSG in a specific scenario and the trigger cause of the SR is LBT failure recovery.

In some embodiments of the present application, if the SR is triggered by the first logical channel, i.e. the SR is triggered by the logical channel, in this case, the urgency of the terminal device for monitoring the PDCCH is less than the urgency of the terminal device for monitoring the PDCCH due to the secondary cell beam failure and LBT failure recovery, as an implementation manner, the terminal device may not perform the handover from the sparse SSSG to the dense SSSG.

In other embodiments of the present application, if the SR is triggered by the first logical channel, the terminal device may determine whether to switch from the first SSSG to the second SSSG according to configuration information of the first logical channel or a service carried by the first logical channel.

In some embodiments, the configuration information of the first logical channel includes first indication information, where the first indication information is used to indicate whether to allow the SR to trigger the terminal device to switch from the first SSSG to the second SSSG if the SR is triggered by the first logical channel, or in other words, whether to allow the SR to trigger the switch from the sparse SSSG to the dense SSSG if the SR is triggered by the first logical channel in the specific scenario.

Alternatively, the first indication information may be configured together with other configuration information of the first logical channel, or may be configured separately.

In some embodiments of the present application, each logical channel corresponds to respective first indication information. For example, when the network device performs logical channel configuration, the first indication information corresponding to each logical channel may be configured.

In some embodiments, if in the specific scenario, an SR is triggered by a first logical channel, and a 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, the terminal device switches from the first SSSG to the second SSSG.

In other embodiments, if in the specific scenario, an SR is triggered by a 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, the terminal device is not switched from the first SSSG to the second SSSG.

Optionally, the content indicated by the first indication information may be determined according to 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-triggered terminal equipment 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-triggered terminal equipment triggered by the first logical channel is not allowed to switch from a sparse SSSG to a dense SSSG.

By way of example and not limitation, the first type of traffic includes delay sensitive traffic and the second type of traffic includes delay insensitive traffic.

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 according to the traffic carried by the first logical channel.

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

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

Optionally, in an embodiment of the present application, switching the terminal device from the sparse SSSG to the dense SSSG listening PDCCH may include: and the terminal equipment stops monitoring the PDCCH based on the first SSSG and starts monitoring the PDCCH based on the second SSSG.

Correspondingly, in the embodiment of the present application, the network device may also switch from based on the first SSSG to based on the second SSSG to send the PDCCH according to the foregoing switching condition of the SSSG.

For example, in the case where an SR of the terminal device is received and the SR is transmitted during the period in which the PDCCH is monitored based on the first SSSG, the network device switches from transmitting the PDCCH based on the first SSSG to transmitting the PDCCH based on the second SSSG.

For another example, in the case where an SR of the terminal device is received and the SR is transmitted during the PDCCH is listened to based on the first SSSG and the SR is recovered by the secondary cell beam failure or LBT failure, the network device switches from transmitting the PDCCH based on the first SSSG to based on the second SSSG.

For another example, in a case where an SR of the terminal device is received, the SR is transmitted during the period of monitoring the PDCCH based on the first SSSG, the SR is triggered by the logical channel, and the first indication information corresponding to the logical channel indicates that the SR triggers the terminal device to perform the SSSG switching, the network device switches from the first SSSG to the second SSSG.

Optionally, the network device may determine the trigger reason of the SR according to the uplink resource used by the terminal device to send the SR.

The terminal device switches to a denser SSSG listening PDCCH in order to obtain the response of the network device faster, so switching from performing sparse SSSG listening PDDC to dense SSSG listening PDCCH for which serving cells is also a problem to be solved. I.e. on which serving cells the SSSG switching mechanism of the embodiments of the present application is performed.

In some embodiments of the present application, the method 200 further includes:

the terminal device determines to perform a handover from the first SSSG to the target set of serving cells of the second SSSG according to a logical channel priority (Logical Channel Priority, LCP) limiting parameter and/or a cross-carrier scheduling configuration of a first logical channel triggering the SR.

In some embodiments, the determining, by the terminal device, to perform the handover from the first SSSG to the target set of serving cells of the second SSSG according to a logical channel priority (Logical Channel Priority, LCP) limiting parameter and/or a cross-carrier scheduling configuration of a first logical channel triggering the SR comprises:

determining a first set of serving cells according to LCP limitation parameters of the first logical channel;

determining a scheduling cell corresponding to each service cell according to cross-carrier scheduling configuration of each service cell in the first service cell set, wherein the scheduling cell corresponding to the service cell can indicate uplink scheduling of the service cell;

and determining the scheduling cells corresponding to all the service cells in the first service cell set as the target service cell set.

It should be understood that, if the terminal device needs to obtain uplink scheduling information of the serving cell, it needs to monitor the PDCCH of the scheduling cell corresponding to the serving cell, where the scheduling cell corresponding to the serving cell may refer to a cell capable of sending the PDCCH indicating uplink scheduling of the serving cell.

In some embodiments, if the first logical channel is not configured with LCP limitation parameters, it is determined that the first set of serving cells includes all active serving cells of the terminal device.

In other embodiments, determining the first set of cells includes allowing transmission of the first logical channel of cells if the first logical channel is configured with LCP restriction parameters.

Taking the first service cell in the first service cell set as an example, a determination mode of a scheduling cell corresponding to the service cell is described.

For example, if the first serving cell is not configured with cross-carrier scheduling configuration, the first serving cell is determined to be a scheduling cell of the first serving cell, that is, the scheduling cell of the first serving cell is the first serving cell itself.

For another example, if the first serving cell is configured with a cross-carrier scheduling configuration, a cell configured by the cross-carrier scheduling configuration of the first serving cell and capable of indicating uplink scheduling of the first serving cell is determined as a scheduling cell of the first serving cell.

Further, the terminal device performs a handover from the first SSSG to a second SSSG on a target serving cell in the set of target serving cells.

Specifically, the terminal device may first determine the SSSG currently used on each target serving cell, perform handover from the first SSSG to the second SSSG if the SSSG currently used by the target serving cell is a sparse SSSG, and not perform handover from the first SSSG to the second SSSG otherwise.

In the following, a specific implementation procedure of the SSSG switching mechanism and determining the target serving cell of the SSSG switching mechanism in the specific scenario according to the embodiment of the present application will be described in conjunction with the first embodiment and the second embodiment.

Embodiment one: SSSG switching mechanism in specific scenarios.

Step 1:

the terminal device receives configuration information of the network device, wherein the configuration information is used for configuring a first SSSG and a second SSSG, and PDCCH monitoring opportunities corresponding to the second SSSG are more densely distributed in a time domain relative to PDCCH monitoring opportunities corresponding to the first SSSG. I.e. the first SSSG is a sparse SSSG and the second SSSG is a more dense SSSG.

Step 2:

the terminal device transmits an SR through the PUCCH, and the SR is in a pending state.

If the terminal device currently monitors the PDCCH based on the first SSSG for each serving cell of the terminal device, the terminal device may execute the SSSG switching mechanism described above.

As example 1, if the trigger 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.

Alternatively, the terminal device may perform the SSSG switching in example 1 that the terminal device autonomously decides.

Alternatively, the terminal device performs SSSG switching in example 1 based on the configuration of the network device, for example, the network device may configure whether the terminal device performs SSSG switching when the secondary cell beam fails to recover due to the trigger of SR in a specific scenario.

As example 2, if the trigger of the SR is LBT failure recovery, the terminal device stops listening to the PDCCH based on the first SSSG while starting listening to the PDCCH based on the second SSSG.

Alternatively, the terminal device may perform the SSSG switching in example 2 that the terminal device autonomously decides.

Alternatively, the terminal device performs SSSG switching in example 2 based on the configuration of the network device, for example, the network device may configure whether the terminal device performs SSSG switching when the LBT fails to recover due to the trigger of SR in a specific scenario.

As example 3, if the SR is triggered by a first logical channel, for example, the first logical channel triggers a BSR or a pre-occupied BSR, but there is no uplink resource for BSR reporting or there is insufficient uplink resource for BSR reporting, the terminal device decides whether to perform SSSG handover according to configuration information of the first logical channel.

Alternatively, the network device may configure, for each uplink logical channel, an indication information about whether to allow the SR triggering terminal device triggered by the uplink logical channel to perform SSSG switching, i.e., the first indication information described above.

For example, the network device configures a logical channel for transmission delay sensitive traffic, and allows the SR-triggered terminal device triggered by the uplink logical channel to switch to listening to PDCCH on a denser SSSG.

For another example, the network device configures a logical channel for a transmission delay insensitive service, and the SR triggering terminal device triggered by the uplink logical channel is not allowed to switch to a denser SSSG to monitor the PDCCH.

Optionally, the terminal device decides whether to perform SSSG switching according to the configuration information of the first logical channel, and may include:

if the first logical channel is configured to allow the SR-triggered terminal device triggered by the first logical channel to switch to listening for PDCCH on a denser SSSG, the terminal device stops listening for PDCCH based on the first SSSG while starting listening for PDCCH based on the second SSSG.

If the first logical channel is configured to not allow the SR triggered by the first logical channel to trigger the terminal device to switch to listening on a denser SSSG for PDCCH, the terminal device continues to listen for PDCCH based on the first SSSG.

For example, in connection with fig. 4, assuming that the terminal device is configured with 2 uplink logical channels, denoted LC1 and LC2, LC1 is configured to allow the LC 1-triggered SR-triggered terminal device to switch to listening on a denser SSSG for PDCCH, and LC2 is not configured to allow the LC 2-triggered SR-triggered terminal device to switch to listening on a denser SSSG for PDCCH, or LC2 is configured to not allow the logical channel-triggered SR-triggered terminal device to switch to listening on a denser SSSG for PDCCH. I.e. the logical channel is not configured with the first indication information, may be regarded as not allowed. Alternatively, the logical channel may be regarded as allowed when the first indication information is not configured.

As shown in fig. 4, if the terminal device triggers the SR in a period of time when the terminal device monitors the PDCCH based on the first SSSG, and the SR is in the pending state, the terminal device switches to using the second SSSG to monitor the PDCCH.

If the terminal equipment monitors the PDCCH based on the first SSSG, the LC2 triggers the SR, and when the SR is in the pending state, the terminal equipment continues to monitor the PDCCH by using the first SSSG.

Embodiment two: method for determining target service cell for executing SSSG switching mechanism

Step 1:

the terminal device receives configuration information of the network device, wherein the configuration information is used for configuring at least one of the following:

a) Configuring a first SSSG and a second SSSG, wherein PDCCH monitoring time corresponding to the second SSSG is more densely distributed in a time domain relative to PDCCH monitoring time corresponding to the first SSSG;

b) For each uplink logical channel of the terminal device, the network device may select whether PUCCH resources for transmitting SRs are configured for the uplink logical channel.

If the network device selects to configure PUCCH resources for transmitting SRs for the uplink logical channel, the network device may configure 0 or 1 PUCCH resources for transmitting SRs for the uplink logical channel on each uplink BWP of each serving cell of the terminal device.

c) For each uplink logical channel of the terminal device, the network device may or may not configure LCP restriction parameters for the uplink logical channel, where the LCP restriction parameters are used to define a serving cell that allows transmission of the uplink logical channel.

Optionally, the LCP limitation parameters include, but are not limited to, the following:

allowed cells (allowed cells), i.e., a list of cells that are allowed to transmit the uplink logical channel;

a List of allowed subcarrier spacings (Subcarrier spacing, SCS) i.e. a List of subcarrier spacings allowing transmission of the uplink logical channel.

Step 2:

if the first logic channel of the terminal equipment triggers the terminal equipment to send an SR on the PUCCH of the service cell and the SR is in a pending state, the terminal equipment judges a target service cell set for executing the SSSG switching mechanism according to LCP limiting parameters of the uplink logic channel triggering the SR.

Specifically, the terminal device first determines a first set of serving cells that allow transmission of the first logical channel according to LCP restriction parameters of the first logical channel.

For example, if the network device does not configure LCP limited parameters for the first logical channel that triggered the SR, the terminal device determines that the first set of serving cells includes all active serving cells of the terminal device, i.e. that transmission of the first logical channel is allowed on all active serving cells.

For another example, if the network device configures LCP limitation parameters for a first logical channel that triggers the SR, the terminal device may determine a cell that allows transmission of the first logical channel based on the LCP limitation parameters for the first logical channel.

Further, according to the cross-carrier scheduling configuration of the first service cell set, a target service cell set for executing SSSG switching is determined.

Specifically, according to the cross-carrier scheduling configuration of each service cell in the first service cell set, determining a scheduling cell corresponding to each service cell, and further determining that scheduling cells corresponding to all service cells in the first service cell set form the target service cell set.

For example, if the first serving cell in the first serving cell set is not configured with the cross-carrier scheduling configuration, determining that the scheduling cell corresponding to the first serving cell is the first serving cell itself, or if the first serving cell is configured with the cross-carrier scheduling configuration, determining the scheduling cell corresponding to the first serving cell according to the cross-carrier scheduling configuration of the first serving cell.

Further, for each serving cell in the target serving cell set, the terminal device determines whether to monitor the PDCCH on the serving cell based on the first SSSG currently, if so, the terminal device performs SSSG switching, i.e. stops monitoring the PDCCH based on the first SSSG, and starts monitoring the PDCCH based on the second SSSG. Otherwise, SSSG switching is not performed.

As illustrated in connection with fig. 5, it is assumed that the terminal device is configured with 2 uplink logical channels, denoted LC1 and LC2, all active serving cells of the network device including a primary cell (PCell) and a secondary cell 1 (Scell 1). The network device is not configured with LCP limitation parameters for LC1, is configured with LCP limitation parameters for LC2, and determines from said LCP limitation parameters of LC2 that only LC2 is allowed to be transmitted on the PCell. For the serving cell of the terminal device, the network device is not configured with cross-carrier scheduling configuration, i.e. for each serving cell, the scheduling cell is the serving cell itself.

As shown in fig. 5, if LC1 triggers SR and SR is in the pending state, since LC1 is not configured with LCP restriction parameters, it may be determined that the target serving cell set includes PCell and Scell 1, and if the terminal device listens to the PDCCH on PCell and Scell 1 based on the first SSSG, the terminal device switches to listening to the PDCCH on PCell and Scell 1 using the second SSSG.

If the LC2 triggers the SR and the SR is in the pending state, the LC2 is configured with an LCP restriction parameter, and it may be determined that the target serving cell set includes a Pcell according to the LCP restriction parameter, and the terminal device monitors the PDCCH on the Pcell based on the first SSSG, then the terminal device switches to monitor the PDCCH on the Pcell using the second SSSG, and does not execute switching of the SSSG on the Scell 1.

In summary, if the terminal device sends an SR and the SR is in the pending state in a period of time when the terminal device monitors the PDCCH using the sparse SSSG, the terminal device can switch to the dense SSSG to monitor the PDCCH when the SR is triggered by the secondary cell beam failure recovery or the LBT failure recovery, which is beneficial to ensuring the scheduling requirement of the terminal device.

In addition, if the terminal device sends the SR in the period of monitoring the PDCCH by using the sparse SSSG and the SR is in the pending state, the terminal device can determine whether to switch to the dense SSSG to monitor the PDCCH according to the configuration of the LC under the condition that the SR is triggered by the LC, which is beneficial to ensuring the scheduling requirement of the terminal device and the power saving requirement of the terminal device.

Further, under the condition that the SR is triggered by the logical channel, the target serving cell set for performing SSSG switching is determined according to the LCP parameter of the logical channel and the cross-carrier scheduling configuration of the serving cells, which is beneficial to ensuring that the terminal device monitors the PDCCH on the correct cell so as to acquire the response of the network device in time.

The method embodiments of the present application are described in detail above with reference to fig. 3 to 5, and the apparatus embodiments of the present application are described in detail below with reference to fig. 6 to 10, it being understood that the apparatus embodiments and the method embodiments correspond to each other, and similar descriptions may refer to the method embodiments.

Fig. 6 shows a schematic block diagram of a terminal device 400 according to an embodiment of the present application. As shown in fig. 6, the terminal device 400 includes:

a communication unit 410, configured to send a scheduling request SR to a network device in a period of listening to a physical downlink control channel PDCCH based on a first SSSG, where the SR is in a waiting state;

a processing unit 420 for switching to the second SSSG under a specific condition;

the communication unit 410 is further configured to monitor a PDCCH based on the second SSSG;

and the density of the PDCCH monitoring time corresponding to the second SSSG on the time domain distribution is greater than that of the PDCCH monitoring time corresponding to the first SSSG on the time domain distribution.

In some embodiments of the present application, the processing unit 420 is further configured to:

and determining whether to switch from the first SSSG to the second SSSG according to the triggering reason of the SR and/or configuration information of network equipment.

In some embodiments of the present application, the processing unit 420 is further configured to:

if the triggering reason of the SR is the failure recovery of the secondary cell wave beam, determining to switch from the first SSSG to the second SSSG; or alternatively

And if the triggering reason of the SR is Listen Before Talk (LBT) failure recovery, determining to switch from the first SSSG to the second SSSG.

In some embodiments of the present application, the processing unit 420 is further configured to:

if the SR is triggered by a first logic channel, determining whether to switch from the first SSSG to the second SSSG according to configuration information of the first logic channel or service carried by the first logic channel;

the configuration information of the first logic channel includes first indication information, where 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 first logic channel.

In some embodiments of the present application, the processing unit 420 is further configured to:

If the first indication information is used for indicating that the SR is allowed to trigger the terminal equipment to switch from the first SSSG to the second SSSG, determining to switch from the first SSSG to the second SSSG; or alternatively

And if the fifth first indication information is used for indicating that the SR is not allowed to trigger the terminal equipment to switch from the first SSSG to the second SSSG, determining that the terminal equipment is not switched from the first SSSG to the second SSSG.

In some embodiments of the present application, the processing unit 420 is further configured to:

if the service carried by the first logic channel is a first type of service, determining to switch from the first SSSG to the second SSSG; or alternatively

And if the service carried by the first logic channel is the service of the second type, determining not to switch from the first SSSG to the second SSSG.

In some embodiments of the present application, the first type of traffic comprises delay sensitive traffic and the second type of traffic comprises delay insensitive traffic.

In some embodiments of the present application, the determining, by the terminal device, whether to switch from the first SSSG to the second SSSG according to a trigger cause of SR is determined by the terminal device.

In some embodiments of the present application, the configuration information of the network device includes first configuration information, where the first configuration information is used to configure whether the terminal device performs a handover from the first SSSG to the second SSSG when an SR is sent and the SR is in a waiting state.

In some embodiments of the present application, the configuration information of the network device includes second configuration information, where the second configuration information is used to configure that, when the terminal device sends an SR, the SR is in a waiting state and a trigger of the SR is secondary cell beam failure recovery or LBT failure recovery, a handover is performed from the first SSSG to the second SSSG; or alternatively

The configuration information of the network device includes third configuration information and/or fourth configuration information, wherein the third configuration information is used for indicating that when the terminal device sends an SR, the SR is in a waiting state and the trigger factor 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 for indicating that when the terminal device sends an SR, the SR is in a waiting state and the trigger factor of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

In some embodiments of the present application, the communication unit 410 is further configured to:

in case of determining to switch from the first SSSG to the second SSSG, the terminal device stops monitoring PDCCH based on the first SSSG and starts monitoring PDCCH based on the second SSSG.

In some embodiments of the present application, the processing unit 420 is further configured to:

and determining to perform switching from the first SSSG to the target service cell set of the second SSSG according to the logic channel priority LCP limiting parameter of the first logic channel triggering the SR and/or the cross-carrier scheduling configuration.

In some embodiments of the present application, the processing unit 420 is further configured to:

determining a first set of serving cells according to LCP limitation parameters of the first logical channel;

determining a scheduling cell corresponding to each service cell according to cross-carrier scheduling configuration of each service cell in the first service cell set, wherein the scheduling cell corresponding to the service cell can indicate uplink scheduling of the service cell;

and determining the scheduling cells corresponding to all the service cells in the first service cell set as the target service cell set.

In some embodiments of the present application, the processing unit 420 is further configured to:

if the first logical channel is not configured with LCP limiting parameters, determining that the first service cell set comprises all activated service cells of the terminal equipment; or alternatively, the process may be performed,

if the first logical channel is configured with LCP restriction parameters, determining that the first set of serving cells includes serving cells that are allowed to transmit the first logical channel.

In some embodiments of the present application, the processing unit 420 is further configured to:

if the first service cell in the first service cell set is not configured with cross-carrier scheduling configuration, determining the first service cell as a scheduling cell of the first service cell; or alternatively

And if the first service cell in the first service cell set is configured with cross-carrier scheduling configuration, determining a cell which is configured by the cross-carrier scheduling configuration of the first service cell and can indicate uplink scheduling of the first service cell as a scheduling cell of the first service cell.

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

It should be understood that the terminal device 400 according to the embodiment of the present application may correspond to the terminal device in the embodiment of the method of the present application, and the foregoing and other operations and/or functions of each unit in the terminal device 400 are respectively for implementing the corresponding flow of the terminal device in the method 200 shown in fig. 3, and are not further described herein for brevity.

Fig. 7 is a schematic block diagram of a network device according to an embodiment of the present application. The network device 500 of fig. 7 includes:

A communication unit 510, configured to send configuration information to a terminal device, where the configuration information is configured to configure whether to perform 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, where a density of PDCCH listening occasions corresponding to the second SSSG is greater on a time domain distribution than a density of PDCCH listening occasions corresponding to the first SSSG.

In some embodiments of the present application, the configuration information includes second configuration information, where the second configuration information is used to configure that, in a case where a terminal device sends an SR, the SR is in a waiting state and a trigger of the SR is secondary cell beam failure recovery or LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.

In some embodiments of the present application, the configuration information includes third configuration information and/or fourth configuration information, where the third configuration information is used to instruct, in a case where a terminal device sends an SR, the SR is in a waiting state and a trigger cause of the SR is secondary cell beam failure recovery, to perform a handover from the first SSSG to the second SSSG, and the fourth configuration information is used to instruct, in a case where a terminal device sends an SR, the SR is in a waiting state and a trigger cause of the SR is LBT failure recovery, to perform a handover from the first SSSG to the second SSSG.

In some embodiments of the present application, the configuration information includes configuration information of a logical channel triggering an SR, and the configuration information of the logical channel triggering an SR includes first indication information, where 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 if the SR is triggered by the logical channel.

In some embodiments of the present application, in a case that a type of a 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;

in case that the type of the service carried by the logical channel is a second type, the first indication information is used for indicating that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG

In some embodiments of the present application, the first type of traffic comprises delay sensitive traffic and the second type of traffic comprises delay insensitive traffic.

In some embodiments of the present application, the communication unit 510 is further configured to:

receiving an SR sent by the terminal equipment, wherein the SR is sent in a time period when the terminal equipment monitors PDCCH by using a first SSSG;

And switching to transmitting the PDCCH by using the second SSSG.

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

It should be understood that the network device 500 according to the embodiment of the present application may correspond to the network device in the embodiment of the method of the present application, and the foregoing and other operations and/or functions of each unit in the network device 500 are respectively for implementing the corresponding flow of the network device in the method 200 shown in fig. 3, and are not further described herein for brevity.

Fig. 8 is a schematic structural diagram of a communication device 600 provided in an embodiment of the present application. The communication device 600 shown in fig. 8 comprises a processor 610, from which the processor 610 may call and run a computer program to implement the method in the embodiments of the present application.

Optionally, as shown in fig. 8, the communication device 600 may further comprise a memory 620. Wherein the processor 610 may call and run a computer program from the memory 620 to implement the methods in embodiments of the present application.

The memory 620 may be a separate device from the processor 610 or may be integrated into the processor 610.

Optionally, as shown in fig. 8, the communication device 600 may further include a transceiver 630, and the processor 610 may control the transceiver 630 to communicate with other devices, and in particular, may send information or data to other devices, or receive information or data sent by other devices.

The transceiver 630 may include a transmitter and a receiver, among others. Transceiver 630 may further include antennas, the number of which may be one or more.

Optionally, the communication device 600 may be specifically a network device in the embodiment of the present application, and the communication device 600 may implement a corresponding flow implemented by the network device in each method in the embodiment of the present application, which is not described herein for brevity.

Optionally, the communication device 600 may be specifically a mobile terminal/terminal device in the embodiment of the present application, and the communication device 600 may implement corresponding processes implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which are not described herein for brevity.

Fig. 9 is a schematic structural diagram of a chip of an embodiment of the present application. The chip 700 shown in fig. 9 includes a processor 710, and the processor 710 may call and run a computer program from a memory to implement the methods in the embodiments of the present application.

Optionally, as shown in fig. 9, chip 700 may also include memory 720. Wherein the processor 710 may call and run a computer program from the memory 720 to implement the methods in embodiments of the present application.

Wherein the memory 720 may be a separate device from the processor 710 or may be integrated into the processor 710.

Optionally, the chip 700 may also include an input interface 730. The processor 710 may control the input interface 730 to communicate with other devices or chips, and in particular, may obtain information or data sent by other devices or chips.

Optionally, the chip 700 may further include an output interface 740. The processor 710 may control the output interface 740 to communicate with other devices or chips, and in particular, may output information or data to other devices or chips.

Optionally, the chip may be applied to a network device in the embodiment of the present application, and the chip may implement a corresponding flow implemented by the network device in each method in the embodiment of the present application, which is not described herein for brevity.

Optionally, the chip may be applied to a mobile terminal/terminal device in the embodiment of the present application, and the chip may implement a corresponding flow implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein for brevity.

It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, or the like.

Fig. 10 is a schematic block diagram of a communication system 900 provided in an embodiment of the present application. As shown in fig. 10, the communication system 900 includes a terminal device 910 and a network device 920.

The terminal device 910 may be configured to implement the corresponding functions implemented by the terminal device in the above method, and the network device 920 may be configured to implement the corresponding functions implemented by the network device in the above method, which are not described herein for brevity.

It should be appreciated that the processor of an embodiment of the present application may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

It will be appreciated that the memory in embodiments of the present application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and Direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

It should be understood that the above memory is exemplary but not limiting, and for example, the memory in the embodiments of the present application may be Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), direct RAM (DR RAM), and the like. That is, the memory in embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

Embodiments of the present application also provide a computer-readable storage medium for storing a computer program.

Optionally, the computer readable storage medium may be applied to a network device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer readable storage medium may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding procedure implemented by the mobile terminal/terminal device in each method of the embodiments of the present application, which is not described herein for brevity.

Embodiments of the present application also provide a computer program product comprising computer program instructions.

Optionally, the computer program product may be applied to a network device in the embodiments of the present application, and the computer program instructions cause the computer to execute corresponding flows implemented by the network device in the methods in the embodiments of the present application, which are not described herein for brevity.

Optionally, the computer program product may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program instructions cause a computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, which are not described herein for brevity.

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to a network device in the embodiments of the present application, and when the computer program runs on a computer, the computer is caused to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer program may be applied to a mobile terminal/terminal device in the embodiments of the present application, where the computer program when run on a computer causes the computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, and for brevity, will not be described herein.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (34)

1. A method for a terminal device to switch a search space set packet SSSG, comprising:

   in a time period when a terminal device monitors a 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;

   the terminal equipment is switched to a second SSSG under a specific condition, and PDCCH is monitored based on the second SSSG;

   and the density of the PDCCH monitoring time corresponding to the second SSSG on the time domain distribution is greater than that of the PDCCH monitoring time corresponding to the first SSSG on the time domain distribution.
2. The method according to claim 1, wherein the method further comprises:

   and the terminal equipment determines whether to switch from the first SSSG to the second SSSG according to the triggering reason of the SR and/or the configuration information of the network equipment.
3. The method according to claim 2, wherein the terminal device determining whether to switch from the first SSSG to the second SSSG according to the triggering reason of the SR and/or configuration information of a network device, comprises:

   if the triggering reason of the SR is the failure recovery of the secondary cell wave beam, determining to switch from the first SSSG to the second SSSG; or alternatively

   And if the triggering reason of the SR is Listen Before Talk (LBT) failure recovery, determining to switch from the first SSSG to the second SSSG.
4. The method according to claim 2, wherein the terminal device determining whether to switch from the first SSSG to the second SSSG according to the triggering reason of the SR and/or configuration information of a network device, comprises:

   if the SR is triggered by a first logic channel, determining whether to switch from the first SSSG to the second SSSG according to configuration information of the first logic channel or service carried by the first logic channel;

   the configuration information of the first logic channel includes first indication information, where 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 first logic channel.
5. The method of claim 4, wherein the determining whether to switch from the first SSSG to the second SSSG based on configuration information of the first logical channel or traffic carried by the first logical channel comprises:

   if the first indication information is used for indicating that the SR is allowed to trigger the terminal equipment to switch from the first SSSG to the second SSSG, determining to switch from the first SSSG to the second SSSG; or alternatively

   And if the first indication information is used for indicating that the SR is not allowed to trigger the terminal equipment to switch from the first SSSG to the second SSSG, determining that the terminal equipment is not switched from the first SSSG to the second SSSG.
6. The method of claim 4, wherein the determining whether to switch from the first SSSG to the second SSSG based on configuration information of the first logical channel or traffic carried by the first logical channel comprises:

   if the service carried by the first logic channel is a first type of service, determining to switch from the first SSSG to the second SSSG; or alternatively

   And if the service carried by the first logic channel is the service of the second type, determining not to switch from the first SSSG to the second SSSG.
7. The method of claim 6, wherein the first type of traffic comprises delay sensitive traffic and the second type of traffic comprises delay insensitive traffic.
8. The method according to any of claims 2-7, wherein the terminal device determining whether to switch from the first SSSG to the second SSSG according to a trigger cause of SR is determined by the terminal device.
9. The method according to any of claims 2-7, wherein the configuration information of the network device comprises 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 if an SR is sent and the SR is in a waiting state.
10. The method according to any of claims 2-7, wherein the configuration information of the network device comprises second configuration information, wherein the second configuration information is used for configuring performing a handover from the first SSSG to the second SSSG in case a terminal device sends an SR, the SR is in a waiting state and a trigger of the SR is secondary cell beam failure recovery or LBT failure recovery; or alternatively

    The configuration information of the network device includes third configuration information and/or fourth configuration information, wherein the third configuration information is used for indicating that when the terminal device sends an SR, the SR is in a waiting state and the trigger factor 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 for indicating that when the terminal device sends an SR, the SR is in a waiting state and the trigger factor of the SR is LBT failure recovery, a handover from the first SSSG to the second SSSG is performed.
11. The method according to any of claims 1-10, wherein the terminal device switches to a second SSSG under specific conditions, listens for PDCCH based on the second SSSG, comprising:

    in case of determining to switch from the first SSSG to the second SSSG, the terminal device stops monitoring PDCCH based on the first SSSG and starts monitoring PDCCH based on the second SSSG.
12. The method according to any one of claims 1-11, further comprising:

    and the terminal equipment determines to execute the switching from the first SSSG to the target service cell set of the second SSSG according to the logic channel priority LCP limiting parameter of the first logic channel triggering the SR and/or the cross-carrier scheduling configuration.
13. The method according to claim 12, wherein the terminal device determining to perform a handover from the first SSSG to the target set of serving cells of the second SSSG according to a logical channel priority LCP restriction parameter and/or a cross-carrier scheduling configuration of a first logical channel triggering the SR, comprises:

    determining a first set of serving cells according to LCP limitation parameters of the first logical channel;

    determining a scheduling cell corresponding to each service cell according to cross-carrier scheduling configuration of each service cell in the first service cell set, wherein the scheduling cell corresponding to the service cell can indicate uplink scheduling of the service cell;

    and determining the scheduling cells corresponding to all the service cells in the first service cell set as the target service cell set.
14. The method of claim 13, wherein the determining the first set of serving cells according to the LCP barring parameters of the first logical channel comprises:

    if the first logical channel is not configured with LCP limiting parameters, determining that the first service cell set comprises all activated service cells of the terminal equipment; or alternatively, the process may be performed,

    If the first logical channel is configured with LCP restriction parameters, determining that the first set of serving cells includes serving cells that are allowed to transmit the first logical channel.
15. The method according to claim 13 or 14, wherein the determining a scheduling cell corresponding to each serving cell in the first set of serving cells according to a cross-carrier scheduling configuration of the each serving cell comprises:

    if the first service cell in the first service cell set is not configured with cross-carrier scheduling configuration, determining the first service cell as a scheduling cell of the first service cell; or alternatively

    And if the first service cell in the first service cell set is configured with cross-carrier scheduling configuration, determining a cell which is configured by the cross-carrier scheduling configuration of the first service cell and can indicate uplink scheduling of the first service cell as a scheduling cell of the first service cell.
16. A method for a terminal device to switch a search space set packet SSSG, comprising:

    the network device sends configuration information to the terminal device, where 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, where a density of PDCCH monitoring opportunities corresponding to the second SSSG is greater on a time domain distribution than a density of PDCCH monitoring opportunities corresponding to the first SSSG on a time domain distribution.
17. The method of claim 16, wherein the configuration information comprises second configuration information, wherein the second configuration information is used to configure a handover from the first SSSG to the second SSSG to be performed if a terminal device sends an SR, the SR is in a waiting state and a trigger of the SR is secondary cell beam failure recovery or LBT failure recovery.
18. The method according to claim 16 or 17, wherein the configuration information comprises third configuration information and/or fourth configuration information, wherein the third configuration information is used for indicating that, in case a terminal device transmits an SR, the SR is in a waiting state and a trigger cause of the SR is secondary cell beam failure recovery, a handover is performed from the first SSSG to the second SSSG, and the fourth configuration information is used for indicating that, in case a terminal device transmits an SR, the SR is in a waiting state and a trigger cause of the SR is LBT failure recovery, a handover is performed from the first SSSG to the second SSSG.
19. The method according to any of claims 16-18, wherein the configuration information comprises configuration information of a logical channel triggering an SR, the configuration information of the logical channel triggering an SR comprising first indication information indicating whether the SR is allowed to trigger a handover of the terminal device from the first SSSG to the second SSSG if the SR is triggered by the logical channel.
20. The method according to claim 19, wherein in case the type of traffic 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;

    in case that the type of the service carried by the logical channel is a second type, the first indication information is used for indicating that the SR is not allowed to trigger the terminal device to switch from the first SSSG to the second SSSG
21. The method of claim 20, wherein the first type of traffic comprises delay sensitive traffic and the second type of traffic comprises delay insensitive traffic.
22. The method according to any one of claims 16 to 21, further comprising:

    the network equipment receives an SR sent by the terminal equipment, wherein the SR is sent in a time period when the terminal equipment monitors PDCCH by using a first SSSG;

    the network device switches to transmitting PDCCH using the second SSSG.
23. A terminal device, comprising:

    a communication unit, configured to send a scheduling request SR to a network device, where the SR is in a waiting state;

    The processing unit is used for switching to the second SSSG under a specific condition if the SR is sent in a time period based on the physical downlink control channel PDCCH monitored by the first SSSG;

    the communication unit is further configured to monitor a PDCCH based on the second SSSG;

    and the density of the PDCCH monitoring time corresponding to the second SSSG on the time domain distribution is greater than that of the PDCCH monitoring time corresponding to the first SSSG on the time domain distribution.
24. A network device, comprising:

    a communication unit, configured to send configuration information to a terminal device, where 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, where a density of PDCCH listening occasions corresponding to the second SSSG on a time domain distribution is greater than a density of PDCCH listening occasions corresponding to the first SSSG on the time domain distribution.
25. A terminal device, comprising: a processor and a memory for storing a computer program, the processor being adapted to invoke and run the computer program stored in the memory, to perform the method of any of claims 1 to 15.
26. A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method of any one of claims 1 to 15.
27. A computer readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 1 to 15.
28. A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 1 to 15.
29. A computer program, characterized in that the computer program causes a computer to perform the method according to any one of claims 1 to 15.
30. A network device, comprising: a processor and a memory for storing a computer program, the processor being for invoking and running the computer program stored in the memory, performing the method of any of claims 16 to 22.
31. A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method of any of claims 16 to 22.
32. A computer readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 16 to 22.
33. A computer program product comprising computer program instructions which cause a computer to perform the method of any of claims 16 to 22.
34. A computer program, characterized in that the computer program causes a computer to perform the method of any of claims 16 to 22.