Method and apparatus for power saving physical downlink control channel monitoring after random access transmission

Abstract

A method and apparatus are provided in which a configuration including a number of symbols for delaying monitoring of a physical downlink control channel (PDCCH) in a search space set associated with each of at least one type of physical random access channel (PRACH) occasion is determined (202). A PRACH preamble is transmitted (204) in a PRACH occasion for the identified type of PRACH occasion. In response to transmitting the PRACH preamble in the PRACH, a PDCCH is monitored (206) for a random access response in a search space set associated with a control resource set (CORESET) during a window, where the window starts at least the configured number of symbols after a last symbol of the PRACH occasion for the identified type of PRACH occasion at which a user equipment is configured to receive a first symbol of an earliest CORESET of the PDCCH.

Description

Technical Field

[0001] This disclosure relates to methods and apparatus for managing and monitoring physical downlink control channels, and more specifically, to avoiding monitoring of a particular user equipment in response to a random access transmission when the channel is unlikely to convey information more directly relevant to a particular user equipment—such as a random access response related to the user equipment. Background Technology

[0002] Currently, user equipment, such as wireless communication devices, uses wireless signals to communicate with other communication devices, such as within a network environment that can include one or more cells, supporting various communication connections with the network and other devices operating within that network. A network environment typically involves one or more sets of standards, each defining aspects of any communication connection made when the corresponding standard is used within the network environment. Examples of standards under development and / or existing standards include New Radio Access Technology (NR), Long Term Evolution (LTE), Universal Mobile Telecommunications Service (UMTS), Global System for Mobile Communications (GSM), and / or Enhanced Data GSM Environment (EDGE).

[0003] As part of network communication, user equipment (UE) does not always know when it will receive incoming communication from the network. Furthermore, proactively monitoring incoming communication for UE can involve keeping certain parts of electronic circuitry active, where the corresponding circuitry may require a significant amount of power to maintain its activity.

[0004] As a way to help save power, various forms of discontinuous reception modes have been implemented, which seek to limit the duration in which the user equipment needs to actively monitor incoming communications by defining inactivity periods relative to monitoring at least some forms of incoming communications. These periods are generally known to the network, so attempts by the network to contact the user equipment can be limited to one window of these previously determined activity monitoring and / or availability windows.

[0005] One of the challenges in managing the time periods during which user equipment (UE) is monitoring the availability of incoming communications is that, in some cases, it may be necessary to delay any incoming communications until the monitoring activity window for a particular UE becomes available. In some cases, incoming communications may be associated with a requested scheduling clearance, which is related to the expected transmission of data from the UE to the network to be sent. The scheduling clearance may have varying degrees of tolerance for any such delays.

[0006] For some types of devices, there may be increased incentives to manage the available time periods during which the device can receive incoming communications, and correspondingly, when the device is unavailable, it may be possible to place one or more portions of its electronic circuitry into an inactive state, during which the overall power consumption of the device can be reduced. Such a device can include at least some form of reduced-capability user equipment, which can sometimes be used for unattended long-term operation on a single charge. To the extent that the overall power consumption can be further reduced, the device can be better positioned to operate for longer periods on a single charge.

[0007] The inventors have recognized that it would be beneficial to better manage the monitoring of control channels, including random access responses, to better align with instances such as those where communication is expected after one or more types of random access channel events have occurred, instances including general requests for access to shared communication channels, and / or more specific types of instances—such as beam failure recovery requests. In some instances, timers or predetermined offsets can be used to further manage the delay associated with the start of control channel monitoring to help identify the time between when a user equipment requests random access to a channel for communication with the network and the expected delay associated with responding to such a request and communicating with the network. Summary of the Invention

[0008] This application provides a method for communication within a user equipment (UE) in a network. The method includes determining a configuration including a number of symbols for delaying the monitoring of a physical downlink control channel in a search space set associated with each of at least one type of physical random access channel (PRAM) timing. A physical random access channel (PRAM) preamble is transmitted to the network during a PRAM timing for the identified type of PRAM timing. In response to the transmission of the PRAM preamble, a PRAM for random access response is monitored in a search space set associated with a control resource set during a time window, wherein the window begins at the first symbol of the earliest control resource set, which is at least the number of symbols configured for the identified type of PRAM timing, after the last symbol of the PRAM timing corresponding to the transmission of the PRAM preamble during the PRAM timing.

[0009] According to another possible embodiment, a user equipment (UE) for communicating within a network is provided. The UE includes a controller that determines a configuration including a number of symbols for delaying the monitoring of physical downlink control channels in a search space set associated with each of at least one type of physical random access channel (PRAM) timing. The UE also includes a transceiver that transmits a physical random access channel (PRAM) preamble to the network in a PRAM timing for an identified type of PRAM timing. In response to transmitting the PRAM preamble in a PRAM, the controller also monitors the PRAM for random access channel responses in a search space set associated with a control resource set during a time window, wherein the window begins at the first symbol of the earliest control resource set for receiving the PRAM for the search space set, at least the number of symbols configured for the identified type of PRAM timing, after the last symbol of the PRAM timing corresponding to the transmission of the PRAM preamble in the PRAM timing.

[0010] According to another possible embodiment, a method is provided in a network entity for communicating with a user equipment. The method includes determining a configuration including the number of symbols for monitoring a physical downlink control channel in each search space set associated with at least one type of physical random access channel (PRAM) timing, including delays for the user equipment, and communicating this configuration to the user equipment. A physical random access channel (PRAM) preamble is received from the user equipment in a PRAM timing for an identified type of PRAM timing, wherein the user equipment is configured to monitor a physical downlink control channel for a random access channel response in a search space set associated with a set of control resources during a time window in which the network entity responds to the PRAM timing of that type. This window begins at the first symbol of the earliest set of control resources where the user equipment is configured to receive the physical downlink control channel for the search space set, at least the number of symbols configured for the identified type of PRAM timing, following the last symbol of the PRAM timing corresponding to the PRAM preamble transmitted by the user equipment in the PRAM timing.

[0011] According to another possible embodiment, a network entity for communicating with a user equipment is provided. The network entity includes: a controller that determines a configuration including the number of symbols for monitoring physical downlink control channels in a search space set associated with each of at least one type of physical random access channel (PRAM) timing; and a transceiver that transmits the configuration to the user equipment. The transceiver also receives a physical random access channel (PRAM) preamble from the user equipment in a PRAM timing for the identified type of PRAM timing. The user equipment is configured to monitor the PRAM for random access channel response in a search space set associated with a control resource set during a time window in which the network entity responds to the PRAM timing of that type. This window begins at the first symbol of the earliest control resource set for which the user equipment is configured to receive the PRAM for the search space set, at least the number of symbols configured for the identified type of PRAM timing, following the last symbol of the PRAM timing corresponding to the PRAM preamble transmitted by the user equipment in the PRAM timing.

[0012] These and other features and advantages of this application will become apparent from the following description of one or more preferred embodiments, with reference to the accompanying drawings. Attached Figure Description

[0013] Figure 1 This is a block diagram of an example network environment in which the present invention is suitable for operation;

[0014] Figure 2 This is a flowchart in a user equipment associated with an instance where monitoring of the physical downlink control channel in the user equipment is configured to occur, according to at least one embodiment;

[0015] Figure 3 This is a flowchart in a network entity associated with an instance where monitoring of the physical downlink control channel in a user equipment is set to occur; and

[0016] Figure 4 This is an example block diagram of an apparatus according to a possible embodiment. Detailed Implementation

[0017] While this disclosure may take various forms of embodiments, as illustrated in the accompanying drawings and described below as preferred embodiments, it should be understood that this disclosure is considered to be exemplary of the invention and is not intended to limit the invention to the specific embodiments shown.

[0018] The implementation provides more power-efficient physical downlink control channel (PDCCH) monitoring.

[0019] Figure 1 This is an example block diagram of system 100 according to a possible embodiment. System 100 may include wireless communication device 110 such as user equipment (UE), base station 120 such as enhanced NodeB (eNB) or next-generation NodeB (gNB), and network 130. Wireless communication device 110 may be a wireless terminal, portable wireless communication device, smartphone, cellular phone, flip phone, personal digital assistant, personal computer, selective call receiver, tablet computer, laptop computer, or any other device capable of transmitting and receiving communication signals on a wireless network.

[0020] Network 130 can include any type of network capable of transmitting and receiving wireless communication signals. For example, network 130 can include wireless communication networks, cellular telephone networks, time division multiple access (TDMA) based networks, code division multiple access (CDMA) based networks, orthogonal frequency division multiple access (OFDMA) based networks, long-term evolution (LTE) networks, fifth-generation (5G) networks, 3rd generation partnership (3GPP) based networks, satellite communication networks, high-altitude platform networks, the Internet and / or other communication networks.

[0021] The fifth generation (5G) has been introduced with the aim of connecting everything to everything. A prominent use case is the need to connect Internet of Things (IoT) devices to monitoring stations for the purpose of generating actions based on data analytics. There is also a desire to monitor events in key areas in real time to provide necessary security or other related monitoring functionality. Wireless sensors are an example of such devices. Long battery life is advantageous for these devices to help ensure relatively low operating and maintenance costs. In particular, long battery life is beneficial to avoid replacements and the costs of connecting to wired power. Power saving has long been a prominent goal for wireless devices, including smartphones. In the case of wireless sensors and similar IoT devices, this expectation is likely to be even more pronounced due to the large number of such devices envisioned in a connected world.

[0022] This motivation is reflected in at least some existing publications, such as 3GPP RP-193238, entitled "Newstudy Item (SID) on Support of Reduced Capability NR Devices," which aims to investigate the various mechanisms that may be needed to support this type of device, similar to other connected industries such as 5G connectivity, and could serve as a catalyst for the next wave of innovation in smart cities. As an example, 3GPP Technical Report (TR) 22.804 describes smart city use cases and several possible anticipated requirements for such use cases. The exemplary smart city verticals discussed cover data collection and processing aimed at more effectively monitoring and controlling urban resources and providing services to city residents. This includes the deployment of surveillance cameras as a potentially important aspect of smart cities, as well as future factories and industries.

[0023] Furthermore, use cases for wearable devices can include smartwatches, rings, eHealth-related devices, and medical monitoring devices. At least one characteristic of such use cases can include small device size.

[0024] As a baseline, exemplary requirements for these three use cases can include: General requirements:

[0025] ● Equipment Complexity: Compared to Rel-15 / Rel-16 high-end enhanced mobile broadband (eMBB) and ultra-reliable low latency communication (URLLC) equipment, at least one motivation for the new equipment type could be to reduce equipment cost and complexity. Equipment cost is generally a factor for all equipment, but equipment cost sensitivity can sometimes be a factor and / or a greater concern for at least some types of equipment, such as industrial sensors.

[0026] ● Device size: For most use cases, the standard allows for device designs with a more compact form factor.

[0027] ● Deployment requirements: The system should support all frequency range 1 (FR1) / frequency range 2 (FR2) bands for frequency division duplex (FDD) and time division duplex (TDD).

[0028] Use case specific requirements:

[0029] ● Industrial Wireless Sensors: Reference use cases and requirements are described in 3GPP Technical Reports (TR) 22.832, entitled "Study on Enhancements for Cyber-Physical Control Applications in Vertical Domains, Technical Specification Group: Services and Systems" and TS 22.104, entitled "Service Requirements for Cyber-Physical Control Applications in Vertical Domains, Technical Specification Group: Services and Systems": Communication service availability is 99.99% and end-to-end latency is less than 100ms. For all use cases, the reference bit rate is less than 2Mbps (potentially asymmetric, e.g., uplink (UL) heavy traffic), and the device is stationary. The battery should last for at least several years. For safety-related sensors, latency requirements are lower, 5-10ms (TR 22.804).

[0030] ● Video Surveillance: As described in TS 22.804, the reference economic video bitrate will be 2-4 Mbps with a latency of <500 ms and 99%-99.9% reliability. High-end video for agriculture, for example, will require 7.5-25 Mbps. Note that the service mode is dominated by UL transmission.

[0031] Wearable devices: The reference bit rate for smart wearable applications can be 10-50 Mbps for downlink (DL) and a minimum of 5 Mbps for UL, and the peak bit rate of the device can be higher, such as 150 Mbps for downlink and 50 Mbps for uplink. The device's battery should last for several days (up to 1-2 weeks).

[0032] Therefore, it is interesting to study and specify a list of UE features and parameters with lower-end capabilities relative to version 16eMBB and Ultra Reliable Low Latency Communication (URLLC) NR to serve the three use cases mentioned above, and to identify methods for achieving power savings and lower complexity operation.

[0033] Some existing standards can provide support for this type of communication. Specific examples may include:

[0034] PDCCH monitoring in 3GPP NR Rel-15 / 16

[0035] The 3GPP TS 38.213, titled "Technical Specification Group Radio Access Network, NR, Physical layer procedure for control", specifies the procedure in a 5G UE to monitor and decode the PDCCH license addressed to it.

[0036] On each active serving cell configured with PDCCH monitoring according to the corresponding search space set, the UE monitors a set of PDCCH candidates in one or more core resource sets (CORESET) on the active DL bandwidth portion (BWP), wherein the monitoring implies decoding each PDCCH candidate according to the monitored downlink control information (DCI) format.

[0037] If the UE is provided with a PDCCHMonitoringCapabilityConfig for the serving cell, the UE receives an indication of the maximum number of PDCCH candidates and non-overlapping control channel elements (CCEs) for monitoring PDCCH on the serving cell.

[0038] - For each time slot, as shown in Tables 10.1-2 and 10.1-3, if PDCCHMonitoringCapabilityConfig = R15, the PDCCH monitoring capability, or

[0039] - For each time span, as shown in Tables 10.1-2A and 10.1-3A, if PDCCHMonitoringCapabilityConfig = R16, PDCCH monitoring capability...

[0040] If PDCCHMonitoringCapabilityConfig is not provided for the UE, the UE monitors the PDCCH on the serving cell for each time slot.

[0041] The UE's ability to monitor PDCCH per time slot or per time span on the active DL BWP of the serving cell is defined by the maximum number of PDCCH candidates and non-overlapping CCEs. The UE can monitor per time slot or per time span on the active DL BWP of the serving cell.

[0042] The PDCCH candidate set for UE monitoring is defined based on the PDCCH search space set. The search space set can be a common search space (CSS) set or a UE-specific search space (USS) set. The UE monitors PDCCH candidates from one or more of the following search space sets:

[0043] - Type 0 - PDCCH CSS set, configured for a DCI format by pdcch-ConfigSIB1 in the MIB, or searchSpaceSIB1 in PDCCH-ConfigCommon, or searchSpaceZero in PDCCH-ConfigCommon, that the DCI format has Cyclic Redundancy Check (CRC) scrambled on the primary cell of the Primary Cell Group (MCG) by the System Information Radio Network Temporary Identifier (SI-RNTI).

[0044] - Type 0A-PDCCH CSS set, configured for the DCI format by searchSpaceOtherSystemInformation in PDCCH-ConfigCommon, which has CRC scrambled on the main cell of the MCG by SI-RNTI.

[0045] - Type l-PDCCH CSS set, configured for the DCI format in PDCCH-ConfigCommon by ra-Searchspace, which has CRC scrambled on the primary cell by the Random Access Radio Network Temporary Identifier (RA-RNTI) or the Temporary Cell Radio Network Temporary Identifier (TC-RNTI).

[0046] -Type 2-PDCCH CSS set, configured by pagingSearchSpace in PDCCH-ConfigCommon for a DCI format with CRC scrambled on the main cell of the MCG by the Paging Radio Network Temporary Identifier (P-RNTI).

[0047] -Type 3-PDCCH CSS set, configured for DCI format by SearchSpace in PDCCH-Config with searchSpaceType=common, which has CRC scrambled by Interrupted Radio Network Temporary Identifier (INT-RNTI), Slot Format Indicator Radio Network Temporary Identifier (SFI-RNTI), Transmit Power Control Physical Uplink Shared Channel Radio Network Temporary Identifier (TPC-PUSCH-RNTI), Transmit Power Control Physical Uplink Control Channel Radio Network Temporary Identifier (TPC-PUCCH-RNTI), Transmit Power Control Detection Reference Symbol Radio Network Temporary Identifier (TPC-SRS-RNTI), CI-RNTI or PS-RNTI, and Cell Radio Network Temporary Identifier for Primary Cell Only (C-RNTI), Modulation and Coding Scheme Cell Radio Network Temporary Identifier (MCS-C-RNTI), or the configured Scheduling Radio Network Temporary Identifier (CS-RNTI), and

[0048] -USS set, which is configured for DCI format by Searchspace in PDCCH-Config with searchSpaceType=ue-Specific, which has CRC scrambled by C-RNTI, MCS-C-RNTI, SP-CSI-RNTI, (one or more) CS-RNTI, SL-RNTI, SL-CS-RNTI or SL-L-CS-RNTI.

[0049] PDCCH transmission includes downlink control information for one or more cells via an RNTI.

[0050] The following encoding steps can be identified:

[0051] - Information element reuse

[0052] -CRC Attachment

[0053] - Channel coding

[0054] - Rate matching

[0055] Support the DCI format defined in Table 7.3.1-1 of TS 38.212, which is titled “technical specification group radio access network, NR, multiplexing and channel coding”.

[0056] Table 7.3.1-1: DCI Format

[0057]

[0058] Fields defined in the following DCI format are mapped to the following information bits a0 to a0. A-1 .

[0059] Each field is mapped in the order it appears in the description, including one or more zero-padding bits (if any), with the first field mapped to the lowest-order information bit a0, and each consecutive field mapped to a higher-order information bit. The most significant bit of each field is mapped to the lowest-order information bit of that field; for example, the most significant bit of the first field is mapped to a0.

[0060] If the number of information bits in the DCI format is less than 12 bits, zeros should be appended to the DCI format until the payload size is equal to 12.

[0061] The size of each DCI format is determined by the configuration of the corresponding active bandwidth portion of the scheduled cell, and should be adjusted as described in Clause 7.3.1.0 if necessary.

[0062] [TR 38.840, titled "Technical Specification Group Radio Access Network, NR, Study on User Equipment Power Saving in NR"] It is known that reducing the number of UE PDCCH monitoring opportunities and / or the number of blind PDCCH decodings can reduce UE power consumption.

[0063] The following power-saving schemes for further research are proposed to reduce PDCCH monitoring and blind decoding.

[0064] - Triggering PDCCH monitoring - Dynamic triggering via Layer 1 (L1) signals / signaling

[0065] - Power-saving signal that triggers PDCCH monitoring

[0066] -Sleep signaling that skips PDCCH monitoring

[0067] -PDCCH skip-

[0068] - DCI-based indications for PDCCH skipping (e.g., indications in DCI content, New Slot Format Indication (SFI) status).

[0069] - Triggering based on LI signals / signaling (excluding DCI) -

[0070] -Multiple Core Sets / Search Space Configuration

[0071] - Configuration of different PDCCH periods with dynamic signaling

[0072] - Adapts to CORESET / Search Space Configuration - DCI / Timer / Hybrid Automatic Repeat Request (HARQ) - Acknowledgment (ACK) Based Indication

[0073] -Dynamic / Semi-Persistent CORESET / Searchspace Enable / Disable

[0074] - Adaptation between Discontinuous Receive (DRX) duration timer and inactive timer

[0075] -DL and UL separate PDCCH monitoring

[0076] -L1 signaling triggering helps the UE reduce the number of blind PDCCH decodings.

[0077] - Reduced PDCCH monitoring on SCell (including cross-carrier scheduling)

[0078] - To dynamically transmit network-aided reference signals (RS) to assist the UE in performing synchronization, channel tracking, measurement, and channel estimation before PDCCH decoding.

[0079] Although each of the different detailed schemes offers a different power saving gain, for evaluation purposes, the power saving schemes for reducing PDCCH monitoring show a power saving gain of 5%–85% across the different detailed schemes compared to the assumed baseline scheme for Rel-15 PDCCH monitoring. For continuous traffic, a lower power saving gain of 5%–15% is observed. For intermittent traffic arrivals, a high power saving gain of 50%–85% is observed. This comes at the cost of a 5%–43% reduction in UPT throughput and an increase in latency of 0%–115% (this does not necessarily result in exceeding the corresponding latency budget). In terms of DL resource usage, this also comes at the cost of additional overhead ranging from 0%–26.53%.

[0080] For Discontinuous Reception (DRX) in TS 38.321, the title is "technical specification group radio access network, NR, medium access control protocol specification":

[0081] The MAC entity can be configured by a Radio Resource Control (RRC) with DRX functionality, which controls the PDCCH monitoring activities of the UE for C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI of the Media Access Control (MAC) entity. When using DRX operation, the MAC entity shall also monitor the PDCCH according to the requirements found in other clauses of this specification. When RRC_CONNECTED, if DRX is configured, the MAC entity may use the DRX operation specified in this clause to monitor the PDCCH discontinuously for all active serving cells; otherwise, the MAC entity will monitor the PDCCH as specified in TS 38.213.

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

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

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

[0085] -drx-InactivityTimer: The duration following the PDCCH timing of a new UL or DL ​​transmission by the MAC entity, where PDCCH indicates the duration after the PDCCH timing.

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

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

[0088] -drx-LongCycleStartOffset: Defines the long DRX cycle and drx-StartOffset of the subframe where the long and short DRX cycles begin;

[0089] -drx-ShortCycle (optional): Short DRX cycle;

[0090] -drx-ShortCycleTimer (optional): The UE should follow the duration of the short DRX cycle;

[0091] -drx-HARQ-RTT-TimerDL (per DL HARQ process except for broadcast processes): The minimum duration expected by the MAC entity before the DL assignment used for HARQ retransmission.

[0092] -drx-HARQ-RTT-TimerUL (per UL HARQ process): The minimum duration before the MAC entity expects a UL HARQ retransmission permission;

[0093] -ps-Wakeup (optional): Configures the associated drx-onDurationTimer to start if a DCI with a CRC scrambled by PS-RNTI (DCP) is detected but not detected;

[0094] -ps-Periodic_CS1_Transmit (optional): Configures the reporting periodic CSI during the duration indicated by drx-onDurationTimer if DCP is configured but the associated drx-onDurationTimer is not started;

[0095] -ps-TransmitPeriodicLl-RSRP (optional): Configures the transmission of one or more periodic L1-RSRP reports during the duration indicated by drx-onDurationTimer, provided that DCP is configured but the associated drx-onDurationTimer is not started.

[0096] When configuring DRX cycles, the activity period includes time, and also:

[0097] -drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in Clause 5.1.5) is running; or

[0098] - The scheduling request is sent on the Physical Uplink Control Channel (PUCCH) and is pending (as described in Clause 5.4.4); or

[0099] - No PDCCH (as described in Clause 5.1.4) indicating a new transmission addressing to the MAC entity is received after a random access response has been successfully received from the MAC entity for which no random access preamble has been selected in the contention-based random access preamble.

[0100] When configuring DRX, the MAC entity should:

[0101] 1> If a MAC PDU is received in the configured downlink assignment:

[0102] 2> After the corresponding transmission carrying DL HARQ feedback is completed, start the drx-HARQ-RTT-TimerDL of the corresponding HARQ process in the first symbol;

[0103] 2> Stop the corresponding HARQ process's drx-RetransmissionTimerDL.

[0104] If a MAC PDU is transmitted within a configured uplink license:

[0105] 2> After the first repetition of the corresponding Physical Uplink Shared Channel (PUSCH) transmission ends, start the drx-HARQ-RTT-TimerDL of the corresponding HARQ process in the first symbol;

[0106] 2> Stop the corresponding HARQ process's drx-RetransmissionTimerUL.

[0107] 1> If the drx-HARQ-RTT-TimerDL expires:

[0108] 2> If the data for the corresponding HARQ procedure was not successfully decoded:

[0109] 3> After the drx-HARQ-RTT-TimerDL expires, start the drx-RetransmissionTimerDL of the corresponding HARQ procedure in the first symbol.

[0110] 1> If drx-HARQ-RTT-TimerUL expires:

[0111] 2> After the drx-HARQ-RTT-TimerUL expires, start the drx-RetransmissionTimerUL of the corresponding HARQ procedure in the first symbol.

[0112] 1> If you receive a DRX command MAC CE or a long DRX command MAC CE:

[0113] 2> Stop drx-onDurationTimer;

[0114] 2> Stop drx-InactivityTimer.

[0115] 1> If the drx-InactivityTimer expires or a DRX command MAC CE is received:

[0116] 2> If a short DRX cycle is configured:

[0117] 3> Start or restart the drx-ShortCycleTimer in the first symbol after the drx-InactivityTimer expires, or start or restart the drx-ShortCycleTimer in the first symbol after the DRX command MAC CE is received.

[0118] 3> Use short DRX cycles.

[0119] 2> Otherwise:

[0120] 3> Use a long DRX cycle.

[0121] 1> If the drx-ShortCycleTimer expires:

[0122] 2> Use a long DRX cycle.

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

[0124] 2> Stop drx-ShortCycleTimer;

[0125] 2> Use a long DRX cycle.

[0126] 1> If using a short DRX cycle, and [(SFN x 10) + subframe number]modulo(drx-ShortCycle)=(drx-StartOffset)modulo(drx-ShortCycle):

[0127] 2> After drx-SlotOffset starts from the subframe, drx-onDurationTimer starts.

[0128] 1> If using a long DRX cycle, and [(SFN x 10) + subframe number]modulo(drx-LongCycle) = drx-StartOffset:

[0129] 2> If DCP is configured for the activity DL BWP:

[0130] 3> As specified in TS 38.213, if the DCP indication is associated with the current DRX period received from the lower layer and indicated as the start of drx-onDurationTimer; or

[0131] 3> If all DCP opportunities (as specified in TS38.213) in the time domain associated with the current DRX cycle occur during the active time, taking into account received grant / assignment / DRX command MAC CE / long DRX command MAC CE and sent scheduling requests, until 4ms before the start of the last DCP opportunity, or within the BWP handover interrupt length, or during the measurement gap; or

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

[0133] 4> Start drx-onDurationTimer after drx-SlotOffset starting from the subframe.

[0134] 2> Otherwise:

[0135] 3> After drx-SlotOffset starts from the subframe, drx-onDurationTimer starts.

[0136] Note 1: In the case of an unaligned SFN on a carrier in a cell group, the SFN of the SP cell is used to calculate the DRX duration.

[0137] 1> If the MAC entity is active:

[0138] 2> Monitor the PDCCH as specified in TS 38.213;

[0139] 2> If the PDCCH indicates a DL transfer:

[0140] 3> After the corresponding transmission carrying the DL HARQ feedback is completed, start the drx-HARQ-RTT-TimerDL of the corresponding HARQ process in the first symbol, regardless of the LBT failure indication from the lower layer.

[0141] Note 2: When the physical downlink shared channel (PDSCH) timing for HARQ feedback is delayed to the HARQ feedback, as indicated by the non-numeric k1 value specified in TS 38.213, the corresponding transmission opportunity for sending DLHARQ feedback is indicated in the PDCCH following the request for HARQ-ACK feedback.

[0142] 3> Stop the drx-RetransmissionTimerDL used for the corresponding HARQ procedure.

[0143] 3> If the PDSCH to HARQ feedback timing indication is a non-numeric k1 value as specified in TS 38.213:

[0144] 4> After the PDSCH transmission for the corresponding HARQ procedure, start the drx-RetransmissionTimerDL in the first symbol.

[0145] 2> If the PDCCH indicates UL transmission:

[0146] 3> After the first repetition of the corresponding PUSCH transmission ends, start the drx-HARQ-RTT-TimerUL for the corresponding HARQ procedure in the first symbol, regardless of the LBT failure indication from the lower layer.

[0147] 3> Stop using drx-RetransmissionTimerUL for the corresponding HARQ procedure.

[0148] 2> If the PDCCH indicates a new transmission (DL or UL):

[0149] 3> After the PDCCH reception ends, start or restart the drx-InactivityTimer in the first symbol.

[0150] 1> If DCP is configured for the active DL BWP; and

[0151] 1> If the current symbol n appears within the duration of drx-onDurationTimer; and

[0152] 1> If the drx-onDurationTimer associated with the current DRX period does not start as specified in this clause; and

[0153] 1> If the MAC entity is not active during the time period, consider received permission / assignment / DRX command MAC CE / long DRX command MAC CE and sent scheduling requests up to 4ms before symbol n is evaluated when all DRX active time conditions as specified in this clause are evaluated:

[0154] 2> Do not transmit periodic SRS and semi-persistent SRS as defined in TS 38.214, entitled “Technical Specification Group Radio Access Network, NR, Physical Layer procedure for data”;

[0155] 2> Do not report semi-persistent CSI configured on PUSCH;

[0156] 2> If ps-Periodic CSI_Transmit is not configured with a value of true:

[0157] 3> If ps-TransmitPeriodicLl-RSRP is not configured with the value true:

[0158] 4> Do not report periodic CSI on PUCCH.

[0159] 3> Otherwise:

[0160] 4> Do not report periodic CSIs on PUCCH except for (one or more) L1-RSRP reports.

[0161] 1> Otherwise:

[0162] 2> In the current symbol n, if the MAC entity is not in active time, considering received permission / assignment / DRX command MAC CE / long DRX command MAC CE and sent scheduling requests, up to 4ms before symbol n when evaluating all DRX active time conditions as specified in this clause:

[0163] 3> Do not transmit periodic SRS and semi-persistent SRS as defined in TS 38.214;

[0164] 3> Do not report CSI on PUCCH and semi-persistent CSI configured on PUSCH.

[0165] 2> If the CSI mask (CSI-mask) is set by the upper layer:

[0166] 3> In the current symbol n, if drx-onDurationTimer is not running, consider received license / assignment / DRX command MAC CE / long DRX command MAC CE until 4ms before symbol n is evaluated for all DRX activity time conditions as specified in this clause:

[0167] 4> Do not report CSI on PUCCH.

[0168] Note 3: If the UE multiplexes the CSI configured on the PUCCH with other overlapping UCIs according to the procedure specified in Clause 9.2.5 of TS 38.213, and reports the CSI multiplexed with (one or more) other UCIs on PUCCH resources outside of DRX activity time, whether or not to report the CSI multiplexed with (one or more) other UCIs depends on the UE implementation.

[0169] Wake-up signal

[0170] Rel-15 devices are expected to monitor all on-duration periods in their cDRX mode. In Rel-16, if the network intends to schedule a device during an on-duration period, a wake-up signal can be transmitted to the device before the on-duration period. Therefore, if a device does not detect WUS during the monitoring opportunity (MO), it can skip upcoming PDCCH monitoring (in cases where the UE is not configured (e.g., ps-Wakeup) to start the associated drx-onDurationTimer if DCP is monitored but not detected). Depending on the cDRX settings, this can provide up to 10% additional connectivity mode energy savings for devices that are not frequently scheduled.

[0171] The wake-up signal is transmitted using DCI format 26 with PS-RNTI. The detailed mechanism is as follows [TS38.213].

[0172] PDCCH monitoring indications and sleep / non-sleep behavior for SCell

[0173] The UE is configured to operate in DRX mode on PCell or SPcell [12, TS 38.331, titled "technical specification group radio access network, NR, radio resource control (RRC) protocol specification"] [11, TS 38.321].

[0174] - PS-RNTI for DCI format 2_6 by ps-RNTI

[0175] - The PDCCH is monitored by dci-Format2-6 to detect multiple search space sets of DCI-Format2_6 on the active DL BWP of PCell or SPcell according to the public search space as described in Clause 10.1.

[0176] - Payload size for DCI format 2_6 by SizeDCI_2-6

[0177] - The position of the wake-up indicator bit in PSPositionDCI2-6 within DCI format 2_6, where

[0178] - When the wake-up indicator bit is "0", the UE may not start drx-onDurationTimer in the next long DRX cycle.

[0179] - When the wake-up indicator bit is "1", the UE starts the drx-onDurationTimer during the next long DRX cycle.

[0180] - A bitmap, when providing the UE with multiple SCell groups configured by Scell-groups-for-dormancy-outside-active-time, where,

[0181] - The bitmap position immediately follows the wake-up indicator position.

[0182] - The bitmap size is equal to the number of configured SCell groups, where each bit of the bitmap corresponds to a configured SCell group from among multiple configured SCell groups.

[0183] - A "0" value in one bit of the bitmap indicates the active DL BWP provided by the dormant-BWP for each active SCell in the corresponding configured SCell group [11, TS38.321].

[0184] - The "1" value of a bit in the bitmap indicates

[0185] - If the currently active DL BWP is a dormant DL BWP, then the active DL BWP is provided by first-non-dormant-BWP-ID-for-DCI-outside-active-time for the UE for each active SCell in the corresponding configured SCell group.

[0186] - If the currently active DL BWP is not a dormant DL BWP, then the currently active DL BWP is used for the UE of each activated SCell in the corresponding configured SCell group.

[0187] - The time offset indicated by ps-Offset, where the UE starts monitoring the PDCCH for detecting DCI format 2_6 before the time slot that the drx-onDurationTimer will start on PCell or SPcell [11,TS 38.321], depending on the number of search space sets.

[0188] - For each search space set, the PDCCH monitoring timing is in the first T days indicated by the duration. s One time slot or if duration is not provided, then T s =The timing in slot 1, from the previous T s It begins in the first time slot of the time slots and ends before the start of drx-onDurationTimer.

[0189] The UE does not monitor the PDCCH used for detecting DCI format 2_6 during the active time [11, TS 38.321].

[0190] If the UE needs to report the active DL BWP in X time slots before the start of the time slot in which the UE will start drx-onDurationTimer, then the UE does not need to monitor the PDCCH for detecting DCI format 2_6 during the X time slots, where X corresponds to the SCS requirement of the active DL BWP.

[0191] If the UE is provided with a search space set to monitor the PDCCH for detecting DCI format 2_6 in the active DL BWP of the PCell or SPcell, and the UE does not detect DCI format 2_6...

[0192] - If ps-WakeupOrNot is provided to the UE, then ps-WakeupOrNot indicates to the UE whether the UE might not start or whether the UE will start drx-onDurationTimer in the next DRX cycle.

[0193] - If ps-WakeupOrNot is not provided to the UE, the UE may not start the activity time indicated by drx-onDurationTimer in the next DRX cycle.

[0194] If the UE is provided with a search space set to monitor the PDCCH for detecting DCI format 2_6 in the active DL BWP of PCell or SPcell, and the UE

[0195] - It is not required to monitor the PDCCH for detecting DCI format 2_6 during all corresponding PDCCH monitoring opportunities outside the activity time prior to the next DRX cycle, as described in Clauses 10, 11.1, 12 and Clause 5.7 of [14, TS 38.321], or

[0196] - There are no PDCCH monitoring opportunities for detecting DCI format 2_6 outside of the activity time of the next DRX cycle.

[0197] The UE should start drx-onDurationTimer in the next DRX cycle.

[0198] If a search space set is provided to the UE to monitor the PDCCH used for detecting DCI format 0_1 ​​and DCI format 1_1, and if one or both of DCI format 0_1 ​​and DCI format 1_1 include the SCell sleep indication field,

[0199] The -SCell dormancy indication field is a bitmap provided by Scell-groups-for-dormancy-within-active-time, in which the size is equal to the number of configured SCell groups.

[0200] - Each bit of the bitmap corresponds to a configured Scell ​​group from multiple configured Scell ​​groups.

[0201] - If the UE detects a DCI format 0_1 ​​or DCI format 1_1 that does not include a carrier indicator field, or detects a DCI format 0_1 ​​or DCI format 1_1 that includes a carrier indicator field with a value equal to 0.

[0202] - The "0" value of a bit in the bitmap indicates the active DL BWP provided by the dormant-BWP for the UE for each activated SCell in the corresponding configured SCell group.

[0203] - The "1" value of a bit in the bitmap indicates

[0204] - If the currently active DL BWP is a dormant DL BWP, then the active DL BWP is provided by first-non-dormant-BWP-ID-for-DCI-inside-active-time for the UE of each active SCell in the corresponding configured SCell group.

[0205] - If the currently active DL BWP is not a dormant DL BWP, then the currently active DL BWP for the UE in each activated SCell of the corresponding configured SCell group.

[0206] - The UE sets the active DL BWP to the indicated active DL BWP.

[0207] If the UE is provided with a search space set to monitor the PDCCH used for detecting DCI format 1_1, and if

[0208] - The CRC of DCI format 1_1 is scrambled by C-RNTI or MCS-C-RNTI, and if

[0209] -resourceAllocation = resourceAllocationType0 and all bits of the frequency domain resource allocation field in DCI format 1_1 are equal to 0, or

[0210] -resourceAllocation = resourceAllocationType1 and all bits of the frequency domain resource allocation field in DCI format 1_1 are equal to 1.

[0211] -resourceAllocation = dynamicSwitch and all bits of the frequency domain resource allocation field in DCI format 1_1 are equal to 0 or 1.

[0212] The UE interprets DCI format 1_1 as an indication for SCell to sleep, without scheduling PDSCH reception or indicating semi-persistent scheduling (SPS) PDSCH release, and for transport block 1, interprets the following sequence of fields:

[0213] - Modulation and coding schemes

[0214] -New data indicator

[0215] - Redundant version

[0216] as well as

[0217] -HARQ process number

[0218] -(one or more) antenna ports

[0219] -DMRS sequence initialization

[0220] For example, providing a bitmap to each configured SCell in ascending order of the SCell index, where

[0221] - The "0" value of a bit in the bitmap indicates the activity DL BWP provided by the dormant-BWP for the UE used for the corresponding activated SCell.

[0222] - The "1" value of a bit in the bitmap indicates

[0223] - If the currently active DL BWP is a dormant DL BWP, then the active DL BWP is provided by first-non-dormant-BWP-ID-for-DCI-inside-active-time for the UE used for the corresponding active SCell.

[0224] - If the currently active DL BWP is not a dormant DL BWP, then the currently active DL BWP for the UE of the corresponding activated SCell.

[0225] - The UE sets the active DL BWP to the indicated active DL BWP.

[0226] If the active DL BWP provided by dormant-BWP for a UE on an active SCell is not the default DL BWP for the UE on the active SCell, as described in Clause 12, then the BWP inactivity timer is not used to transition from the active DL BWP provided by dormant-BWP to the default DL BWP on the active SCell.

[0227] In response to the detection of a DCI format 1_1 indicating SCell sleep after N symbols from the last symbol of the PDCCH providing DCI format 1_1, the UE is expected to provide HARQ-ACK information. If the processingType1Enabled of PDSCH-ServingCellConfig is set to enable the serving cell to have a PDCCH providing DCI format 1_1, then for μ=0, N=5, for μ=1, N=5.5, for μ=2, N=11; otherwise, for μ=0, N=10, for μ=1, N=12, for μ=2, N=22, and for μ=3, N=25, where μ is the minimum SCS configuration between the SCS configuration of the PDCCH providing DCI format 1_1 and the SCS configuration of the PUCCH with HARQ-ACK information in response to the detection of DCI format 1_1.

[0228] Reduced-capability UEs, such as industrial wireless sensors, video surveillance, and wearables, may need to operate with batteries that should last from several days (e.g., wearables) to at least several years (e.g., industrial sensors). This application includes methods for enabling more power-efficient PDDCH monitoring.

[0229] Based on the currently specified behavior, the UE begins monitoring the PDCCH for Random Access Response (RAR) at the first symbol of the earliest CORESET, where the UE is configured to receive the PDCCH for Type 1-PDCCH CSS. Furthermore, when a Beam Failure Recovery Request (BFRR) PDCCH (UL / DL) is transmitted in the search space configured for Beam Failure Recovery (BFR) (SS-BFR), the UE monitors during the BFR process and additionally continues monitoring the PDCCH candidates in the configured search space monitored prior to the Physical Random Access Channel (PRACH).

[0230] According to at least two embodiments of this application:

[0231] Example 1: Time offset is introduced for PDCCH monitoring of random access response message / MsgB.

[0232] The UE should monitor only the PDCCH for RAR / MsgB after a pre-configured time offset following the transmission of the PRACH preamble—that is, taking into account the processing time required on the gNB side and the waiting time requirements for data such as requests for uplink shared channel (UL-SCH) resources.

[0233] Example 2: The UE decodes a specific DCI format only within a specific search space during the random access procedure.

[0234] The UE may only need to monitor the downlink (DL) downlink control information (DCI) format, while simultaneously monitoring PDCCH transmissions identified by the C-RNTI in the search space indicated by the recoverySearchSpaceId. During the BFR procedure, while the BFRR has been sent to the gNB, the UE may not need to monitor PDCCH in other previously monitored, configured search spaces.

[0235] In at least the first embodiment, in response to a PRACH transmission, the UE attempts to detect a DCI format 1_0 with a CRC scrambled by the corresponding RA-RNTI during the window period, wherein the window begins at the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, which is at least the number of configured symbols, after the last symbol of the PRACH timing corresponding to the PRACH transmission.

[0236] In at least one further embodiment, the UE monitors the PDCCH (DL DCI only) transmission addressed to C-RNTI in the search space indicated by the higher-layer parameter recoverySearchSpaceId (i.e., SS-BFR) after a pre-configured time offset following the transmission of PRACH.

[0237] According to the currently specified behavior, the UE begins monitoring for random access response messages (as specified in TS38.213) at the first symbol of the earliest CORSET of the PDCCH for the Type 1-PDCCH CSS set, at least one symbol after the last symbol of the PRACH timing corresponding to the PRACH transmission. This essentially means that the UE can (e.g., the configuration of the received PRACH timing and the CORESET for receiving the PDCCH for the possible Type 1-PDCCH CSS set) begin PDCCH monitoring for RACH responses (RAR) immediately after the PRACH transmission, which may be inefficient from a power-saving perspective.

[0238]

[0239] According to the current specification, the UE starts the raContentionResolutionTimer at each HARQ retransmission in the first symbol after the Msg3 transmission ends. Similarly, in this case, PDCCH monitoring activity therefore starts immediately after the Msg3 transmission, which may be inefficient from a power-saving perspective.

[0240]

[0241] Furthermore, even in cases where monitoring (one or more) DL DCIs is not required from a process perspective to determine the success of competing solutions, the UE monitors the PDCCH for UL and DL DCIs, i.e., the UE is active while the ra-ContentionResolutionTimer is running.

[0242]

[0243] First Embodiment

[0244] As a solution to the first problem and according to the first embodiment, the UE may not immediately monitor the PDCCH for the Random Access Response (RAR) in response to the transmission of the PRACH preamble. Instead, it may monitor the PDCCH only after a pre-configured time offset following the transmission of the PRACH, i.e., taking into account the processing time required at the gNB side for PRACH detection and RAR message generation / scheduling. According to one implementation of this embodiment, the RAR window begins at the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, at least a pre-configured symbol_offset after the last symbol of the PRACH timing corresponding to the PRACH transmission. The same principle can also be applied to a two-step random access procedure, for example, after at least some pre-configured offset (e.g., symbol_offset) following the last symbol of the MsgA transmission—e.g., the Physical Uplink Shared Channel (PUSCH) transmission—the UE begins monitoring the PDCCH for MsgB (during the msgB-ResponseWindow symbol offset). In one example, symbol_offset can be a value based on the number of symbols (or, in another instance, the number of slots) for the SCS (subcarrier spacing) of the Type 1-PDCCH CSS set, the SCS of the BWP where the PRACH preamble has been transmitted (and possibly the UL carrier UL / SUL), the PRACH preamble subcarrier spacing for PRACH transmission, the SIB1 subcarrier spacing, or a combination thereof (e.g., the minimum SCS configuration in one or more SCS configurations). In one example, for a UE configured with a connected DRX (cDRX), symbol_offset can be based on the minimum drx-HARQ-RTT-TimerUL across all ULHARQ procedures for the BWP (such as the active BWP where the PRACH preamble has been transmitted). Random access procedures can be triggered by several different types of events:

[0245] - Initial access from RRC_IDLE;

[0246] -RRC connection reconstruction procedure;

[0247] - When the UL synchronization status is "asynchronous", DL or UL data arrives during RRC_CONNECTED;

[0248] - UL data arrives during RRC_CONNECTED when no PUCCH resource for SR is available;

[0249] -SR failed;

[0250] - Requests from RRC during synchronous reconfiguration (e.g., switching);

[0251] - Conversion from RRC_INACTIVE;

[0252] - Establish time alignment for the second timing advance group (TAG);

[0253] - Request other SIs (see Clause 7.3);

[0254] - Beam fault recovery.

[0255] According to one aspect of this embodiment, the offset (e.g., symbol_offset) used to initiate PDDCH monitoring for RAR / MsgB messages can be pre-configured to different values ​​for different types of RACH events. According to one implementation of this embodiment, the predetermined offset used to monitor PDDCH when PRACH / MsgA has already been sent is applied only to contention-based random access procedures for scheduling requests, i.e., when UL data arrives during RRC_CONNECTED when no PUCCH resources for SR are available. For other RACH events, conventional UE behavior relative to PDDCH monitoring is applied. This difference in behavior between the two different scenarios when RACH is triggered can be demonstrated by the possibility that, in the latter case, the UE can expect to receive other messages from the network in DL, while in the case where RACH is triggered by a scheduling request, the UE may only request resource allocation due to uplink data arrival and not expect other message exchanges during the transition period. According to another implementation of this embodiment, the UE can use different RACH timings (RO) for different RACH events. For example, a specific RACH timing (RO) can be configured / reserved for situations where the UE performs a random access procedure to request UL-SCH resources (e.g., UL data arrives during RRC_CONNECTED when no PUCCH resources for SR are available). Similarly, different RACH timings can be linked to different offsets configured for the start of the corresponding RACH response window / msgB window. When a RACH preamble is detected on the gNB of a specific RACH timing / resource, it is known which offset the UE will apply to receive the corresponding RACH response message and MsgB message, respectively.

[0256] According to another embodiment of this example, the UE can monitor only the PDCCH on the Type1-PDCCH common search space used for Msg2 and Msg4 decoding during the RACH response window. Therefore, the UE can, for example, not monitor the PDCCH on other configured search spaces monitored before the RACH during the RACH window, before receiving the RACH response message. According to a specific embodiment of this example, when the UE performs a random access procedure, the Type1-PDCCH common search space for RACH-related DL transmissions is prioritized over other search spaces configured for the UE.

[0257] According to another aspect of this embodiment, the UE can use different RACH timings depending on which logical channel (LCH) triggers the random access procedure for requesting UL-SCH resources. Essentially, a link is introduced between (one or more) LCHs and (one or more) RACH timings. For a two-step RACH procedure, according to one implementation of this embodiment, a link can be used between the PUSCH timing and the LCH that has already triggered the random access procedure for requesting UL-SCH resources.

[0258] In one implementation, in response to a PRACH transmission, the UE attempts to detect DCI format 1_0 with a CRC scrambled by the corresponding RA-RNTI during the window period, wherein the window begins at the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, which is at least the number of symbols configured after the last symbol of the PRACH timing corresponding to the PRACH transmission, wherein the number of configured symbols is determined based on the LCH priority implicitly indicated from the PRACH transmission.

[0259] In one implementation, the UE can include an indication of LCH priority as the payload of MsgAPUSCH during the two-step RACH process. In response to the transmission of PRACH and MsgA PUSCH, the UE attempts to detect DCI format 1_0 with a CRC scrambled by the corresponding MsgB-RNTI during the window period, wherein the window begins at the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, after the last symbol of the PUSCH timing corresponding to the PUSCH transmission, for a minimum number of configured symbols, whereby the UE is configured to receive the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, wherein the symbol duration corresponds to the SCS for the Type 1-PDCCH CSS set, and wherein the configured number of symbols is determined based on the LCH priority indicated in the MsgA PUSCH.

[0260] Second embodiment (ra-ContentionResolutionTimer)

[0261] According to the second embodiment, the UE starts the ra-ContentionResolution Timer at a pre-configured time offset after Msg3 has been transmitted. By not starting the ra-ContentionResolution Timer immediately after HARQ transmission of Msg3 has been sent, the UE can reduce power consumption. The UE can enter a sleep or micro-sleep mode because the network needs to transmit messages to the UE first to resolve contention, and during this period the UE may not receive any other messages from the network, nor expect to transmit any other messages in the UL, and therefore can start the ra-ContentionResolution Timer from the first instance where the UE expects to receive downlink messages from the contention-resolved network.

[0262] As a solution to the second problem, according to one embodiment, the UE can monitor UL grants (DCI formats associated with the PUSCH) only while the ra-ContentionResolutionTimer is running—for example, in response to the transmission of Msg3. By eliminating the need to monitor DL ​​grants, the UE can reduce power consumption and complexity. According to one implementation, for cases where the random access procedure is initiated by the MAC sublayer itself or by the RRC sublayer, such as for a contention-based random access procedure requesting UL-SCH resources, the UE can monitor only the PDCCH for UL grants while the ra-ContentionResolutionTimer is running. Since the contention resolution is based on the received UL grant that schedules the initial UL-SCH transmission, the UE can benefit from power savings when not monitoring one or more DL DCIs. In some examples, the UE can monitor one or more DL assigned DCIs of the same size as the one or more UL grant DCIs.

[0263]

[0264] Third Implementation Example (SR Retransmission Case)

[0265]

[0266] According to the currently specified behavior, when an SR has already been transmitted on the PUCCH and the SR is pending, the UE is in active time and monitors the PDCCH. Therefore, in the case where no UL clearance is received in response to a previous SR transmission and the sr-ProhibitTimer is not running, the UE is in active time if an SR has been (re)transmitted on the PUCCH (i.e., SR_COUNTER>=1).

[0267] According to another embodiment, in the case of an pending SR (SR_COUNTER>=1) in response to an SR triggered by the expiration of sr-ProhibitTimer already being transmitted on the PUCCH, but only after a pre-configured time offset following the (re)transmission of the SR on the PUCCH (i.e., considering the processing time required at the gNB side), the UE may not be in active time. Similar to the case of the first transmission of an SR triggered by a BSR, and also similar to the case of subsequent (re)transmissions of an SR triggered by the expiration of sr-ProhibitTimer, the UE enters DRX (sleep time) within a pre-configured time following the (re)transmission of the SR before switching to active time and monitoring the PDCCH for (one or more) UL DCIs. Since the UE can be configured with multiple SR configurations, for example, each SR configuration corresponding to one or more logical channel and / or SCell beam fault recovery and / or consistent Listen-After-Talk (LBT) failure, the time offset can be different for different SR configurations. For example, when retransmitting an SR on the PUCCH for an SR configuration corresponding to an LCH carrying non-critical delay data, the UE can remain in the DRX for a slightly longer period before starting PDCCH monitoring. However, for SR(s) corresponding to one or more delay-critical data, the time offset should be relatively small. The UE can be configured with one or more time offsets corresponding to one or more SR configurations via higher-layer signaling. In one example, the time offset could correspond to a set of SR configurations.

[0268] According to one embodiment, the network can configure the UE to enter a sleep or micro-sleep mode, thereby shutting down all or some of its receiver (or transceiver) components. In such an embodiment, the network can use a first timer to configure the UE, the duration of which is associated with the length of time the UE enters a micro-sleep or sleep mode after a (re)transmission of the SR. It should be noted that the SR transmission can be triggered by a BSR, i.e., the first transmission of the SR, and / or, in the case of an pending SR, by the expiration of the sr-ProhibitTimer, i.e., because a UL license was not detected during the previous transmission of the SR. The first timer begins after the (re)transmission of the SR. In one embodiment, the network can base the value of the first timer on the time required to process the SR. In this embodiment, the timer is a semi-static parameter configured by the network via RRC or via the MAC protocol. After the transmission of the SR, the UE skips decoding for the UL DCI for the duration of the first timer and then attempts to decode the UL PDCCH license sent to it in response to the SR. Once the timer expires, the UE begins blind decoding of the UL DCI.

[0269] Fourth embodiment (RACH for BFR)

[0270]

[0271]

[0272] According to the current specification shown above, when the UE has already transmitted the PRACH preamble for the beam failure recovery request, it monitors the PDCCH for C-RNTI during the ra-ResponseWindow configured in BeamFailureRecoveryConfig. PDCCH monitoring thus begins at the first PDCCH timing after the last symbol of the PRACH preamble transmission. The UE considers the contention-free BFR procedure to have successfully terminated only when a PDCCH addressing to C-RNTI is received in the search space indicated by the higher-layer parameter recoverySearchSpaceId (i.e., SS-BFR). In response to the transmission of the PRACH for the contention-free BFR, the UE continues to monitor PDCCH candidates in the configured search space previously monitored before the PRACH, in addition to the search space indicated by recoverySearchSpaceId.

[0273] According to another embodiment, the UE may not immediately monitor the PDCCH for the response message, such as the Random Access Response (RAR) addressed to C-RNTI, only after a pre-configured time offset following the transmission of the PRACH—that is, after considering the processing time required for PRACH detection and RAR message generation / scheduling at the gNB side. In one implementation of this embodiment, the RAR window begins at the PDCCH timing where the UE is configured to receive the PDCCH for SS-BFR, pre-configured as a symbol_offset following the last symbol of the PRACH timing corresponding to the PRACH transmission. By not immediately monitoring the PDCCH for the RACH addressed to C-RNTI, but only after a pre-configured offset, the UE can benefit from power savings.

[0274] According to another aspect of this embodiment, the UE may only need to monitor the DL DCI format while monitoring PDCCH transmissions identified by the C-RNTI in the search space indicated by the recoverySearchSpaceId. By eliminating the need to monitor UL clearance, the UE can reduce power consumption and complexity. In one example, the UE may not monitor or attempt to decode a UL DCI format of a different size than the DLDCI; the UE can continue to monitor UL DCIs of the same size as the DL DCI (e.g., backed-up DCI 1_0 and DCI 0_0). It is assumed that the gNB will send a downlink message in response to having received a PRACH for the BFR, for example by means of a MAC CE (TCI State Activated MAC CE) or DL ​​DCI (DCI-based TCI State Switching) to indicate a Transport Configuration Indicator (TCI) state switch and the corresponding beam switching.

[0275] According to a further implementation of this embodiment, the UE can monitor PDCCH transmissions identified by C-RNTI only in the search space indicated by recoverySearchSpaceId during the beam fault recovery process. Therefore, the UE will not monitor PDCCH in other configured search spaces that may have been previously monitored, after the BFR has been sent to the gNB during the BFR process.

[0276] Fifth Implementation Example (Delayed Trigger SR)

[0277] According to another embodiment, the UE delays the transmission of a triggered SR to the next on-duration period, such as the next drx-onDurationTimer duration, or to the next active time. This behavior can be linked to the LCH that triggered the SR. If the logical channel priority is below a threshold, the UE delays the transmission of the SR to the next active time or the next on-duration period. For cases where the SR is triggered outside the active time, such as when the UE is in DRX, the UE may not transmit the SR on the next available PUCCH resource, but instead transmit the SR on the PUCCH resource that occurs within the next drx-onDurationTimer duration. According to a specific implementation of this embodiment, the UE transmits the SR triggered outside the active time on the PUCCH resource that occurs within the next drx-onDurationTimer duration while the drx-onDurationTimer is running. As previously mentioned, if a DCI with a CRC scrambled by PS-RNTI (DCP) is configured, the wake-up signal (e.g., DCI format 2_6 with a CRC scrambled by PS-RNTI (Power Saving RNTI)) indicates whether the UE should start the drx-onDurationTimer within the next drx-onDurationTimer duration. According to one implementation of the embodiment, the transmission of the delayed SR may be limited to LCHs with a specific delay-tolerant configuration. By not transmitting the triggered SR immediately on the next available PUCCH resource, but rather on a PUCCH resource occurring during the UE's monitoring of PDCCH activity regardless of its availability, the UE can obtain additional power-saving benefits.

[0278] Sixth embodiment (for UL-licensed DRX)

[0279] According to another embodiment, the UE may monitor the ULDCI only at pre-configured times (e.g., slots / subframes / symbols). There is no good incentive to monitor the PDCCH for the ULDCI that allocates UL-SCH resources when there is no data available for transmission in the UE. According to one implementation, the UE may not monitor the PDCCH for one or more UL DCIs when there is no data available for transmission in the UE. This could be similar to skipping UL grants / transmissions when the UE receives UL-SCH resource allocation but has no data to transmit. However, since aperiodic SRS or CSI required for downlink scheduling (CSI) or beam management is also scheduled by UL DCI formats (e.g., format 0_1), the UE may still need to monitor these DCI formats. Therefore, according to one embodiment, when the UE has no data available for transmission, the UE may only monitor the PDCCH for a specific UL-related DCI format. In one embodiment of this embodiment, the UE may only monitor the UL DCI format at some predefined times (e.g., slots / subframes / symbols), such as some specific UL DCI formats. To synchronize between the UE and the gNB, i.e., the gNB should know when the UE monitors the PDCCH for the UL DCI format, certain rules can be defined regarding when low PDCCH monitoring activity in the UE should begin. According to one specific implementation, the UE starts a timer when it receives the UL DCI format for allocating UL-SCH resources. Upon the expiration of this timer, the UE begins PDCCH (UL DCI) monitoring activity according to a predefined pattern. The timer (re)starts upon receiving the ULDCI for allocating UL-SCH resources and upon transmitting the SR on the PUCCH.

[0280] According to one implementation of the embodiments, the UE can be provided with a DRX mode / configuration for monitoring UL DCI and a separate DRX mode / configuration for monitoring DL DCI.

[0281] In one implementation, if the UE is in active time and if the UL inactivity timer is running, the UE monitors a PDCCH for a UL DCI with a different size than the DL DCI in a given search space set, wherein the UE starts or restarts the UL inactivity timer in the first symbol after the end of receiving the PDCCH including the UL DCI. For UE power saving, it may be beneficial to transmit buffered UL data as quickly as possible and to disable some Tx chain-related components when the transmission of buffered UL data is complete. Therefore, the UE can continue monitoring the UL DCI for a period of time after receiving it and can stop monitoring the UL DCI and disable the Tx components after the UL inactivity timer expires. In one example, if the UE starts a drx-onDurationTimer in the next DRX cycle, the UE can restart monitoring the UL DCI at the beginning of the next DRX cycle. In another example, the UE can restart monitoring the UL DCI after transmitting an SR and / or BSR on a configured licensed PUSCH.

[0282] In this application, the following aspects may be of interest with respect to at least some embodiments:

[0283] ● Introducing a time offset for PDCCH monitoring of random access response messages / MsgB

[0284] ○The UE attempts to detect DCI format 1_0 with a CRC scrambled by the corresponding RA-RNTI during the window period, wherein the window begins at the first symbol of the earliest CORESET of the PDCCH for the Type 1-PDCCH CSS set, at least the number of symbols configured after the last symbol of the PRACH timing corresponding to the PRACH transmission.

[0285] ○ The time offset (e.g., the number of symbols) can vary for different RACH events.

[0286] ○ The time offset is determined based on the LCH priority implied from the PRACH transmission.

[0287] Different Resource Orders (ROs) can be configured for different RACH events, such as requests for UL-SCH resources.

[0288] ●ra-ContentionResolutionTimer starts a pre-configured time offset once RACH MSg3 has been (re)transmitted.

[0289] ○ When the random access procedure is initiated by the MAC sublayer itself or by the RRC sublayer in connection mode (e.g., a contention-based random access procedure for requesting UL-SCH resources), the UE can monitor the PDCCH for UL permission only while the ra-ContentionResolutionTimer is running.

[0290] ●The UE may only need to monitor the DL DCI format, while monitoring the PDCCH transmission identified by C-RNTI in the search space indicated by recoverySearchSpaceId.

[0291] ○The UE may not monitor or attempt to decode a UL DCI format of a different size than the DL DCI; the UE may continue to monitor UL DCIs of the same size as the DL DCI (e.g., backdated DCI 1_0 and DCI 0_0).

[0292] During beam failure recovery, the UE can monitor PDCCH transmissions identified by C-RNTI only in the search space indicated by recoverySearchSpaceId.

[0293] ■When the BFR has already been sent to the gNB, the UE will not monitor the PDCCH in other configured search spaces that may have been previously monitored during the BFR process.

[0294] ● When the UE performs the BFR procedure, the SS-BFR used to successfully terminate the beam fault recovery procedure takes precedence over other search spaces configured for the UE, because only the PDCCH addressed to the C-RNTI received on the SS-BFR will successfully terminate the BFR procedure.

[0295] ● The UE delays the transmission of the triggered SR until the next on-duration period, such as the next drx-onDurationTimer duration, or until the next active time.

[0296] ○ If the logical channel priority is lower than the threshold, the UE delays the transmission of SR until the next active time or the next on-time duration.

[0297] ○The UE transmits an SR triggered outside of the active time on the PUCCH resource during the next drx-onDurationTimer duration that is currently running.

[0298] ● The UE can monitor UL DCI only at pre-configured times (e.g., slots / subframes / symbols).

[0299] ○The UE can monitor the UL DCI format only at certain pre-configured times (e.g., slots / subframes / symbols) (e.g., certain specific UL DCI formats).

[0300] ■The UE starts a timer when it receives the UL DCI format for allocating UL-SCH resources. When this timer expires, the UE starts PDCCH (UL DCI) monitoring activity according to a predefined pattern. The timer restarts (at) the UL DCI for allocating UL-SCH resources and when SR is transmitted on the PUCCH.

[0301] According to one embodiment of the example, the UE can be provided with a DRX mode / configuration for monitoring ULDCI and a separate DRX mode / configuration for monitoring DL DCI.

[0302] Figure 2 The illustration shows a flowchart 200 in a user equipment associated with an instance where monitoring of the physical downlink control channel in the user equipment is configured to occur. According to at least one embodiment, the method can include determining 202 a configuration for delaying the number of symbols used to monitor the physical downlink control channel in each associated search space set for at least one type of physical random access channel timing. A physical random access channel preamble can be transmitted 204 to the network in a physical random access channel timing for the identified type of physical random access channel timing. In response to the transmission of the physical random access channel preamble in the physical random access channel, the physical downlink control channel can be monitored 206 for random access response in the search space set associated with a control resource set during a time window, wherein the window begins at the first symbol of the earliest control resource set configured to receive the physical downlink control channel for the search space set, after the last symbol of the physical random access channel timing corresponding to the transmission of the physical random access channel preamble in the physical random access channel timing.

[0303] In some instances, the configuration for delaying the number of symbols used to monitor the physical downlink control channel in each search space set associated with at least one type of physical random access channel timing can be determined as part of a transmission received by the user equipment from the network. In some of these instances, the configuration for delaying the number of symbols used to monitor the physical downlink control channel in each search space set associated with at least one type of physical random access channel timing can be explicitly identified as part of a transmission received by the user equipment from the network. In other instances, the configuration for delaying the number of symbols used to monitor the physical downlink control channel in each search space set associated with at least one type of physical random access channel timing can be derived from information included as part of a transmission received by the user equipment from the network. In some of these instances, the information included as part of the transmission can include the number of time slots.

[0304] In some instances, the configuration for delaying the monitoring of the number of symbols of the physical downlink control channel in each search space set associated with at least one type of physical random access channel timing can be determined based on a logical channel priority indication from the transmission identifier of the physical random access channel timing.

[0305] In some instances, at least one type of physical random access channel timing can include multiple types of physical random access channel timing, including at least a first type of physical random access channel timing and a second type of physical random access channel timing. In some of these instances, the configured number of symbols can include a first configured number of symbols for the first type of physical random access channel timing and a second configured number of symbols for the second type of physical random access channel timing, wherein the second configured number of symbols differs from the first configured number of symbols.

[0306] In some instances, user equipment can attempt to detect downlink control information during a time window using a cyclic redundancy check scrambled with the corresponding random access radio network temporary identifier.

[0307] In some instances, the search space set can be the common search space set for Type 1 physical downlink control channels.

[0308] In some instances, the determined configuration, including the number of symbols for delaying the monitoring of the physical downlink control channel in the search space set, can be applied to a contention-based random access procedure. In some of these instances, the method can further include: receiving a physical downlink control channel with downlink control information within a time window, wherein a physical downlink shared channel associated with the physical downlink control channel includes a random access response message, which includes a random access response uplink grant for the user equipment; transmitting the random access channel Msg3 on the uplink resource indicated by the random access response uplink grant; and starting a random access contention resolution timer with a pre-configured time offset after the transmission of the random access channel Msg3. Further in these instances, the contention-based random access procedure can be a contention-based random access procedure initiated in response to a request for uplink resources, and the monitoring of the physical downlink control channel by the user equipment can be limited to monitoring uplink downlink control information while the random access contention resolution timer is running.

[0309] In some instances, the physical random access channel timing can be the type of transmission in response to a beam fault recovery process. In some of these instances, monitoring of the physical downlink control channel by the user equipment can be limited to monitoring downlink control information addressed to the cell radio network temporary identifier on a search space set, wherein the search space set is a beam fault recovery search space set configured by higher layers.

[0310] Figure 3The diagram illustrates a flowchart 300 in a network entity associated with an instance where monitoring of the physical downlink control channel in a user equipment (PMI) is configured to occur. According to at least one embodiment, the method can include: determining 302 a configuration including the number of symbols for the user equipment to delay monitoring the PMI in each associated search space set for at least one type of physical random access channel (PMI) timing; and communicating this configuration to the user equipment. A physical random access channel (PMI) preamble can be received from the user equipment 304 during a PMI timing for the identified type of PMI timing, wherein the user equipment can be configured 306 to monitor the PMI for random access channel response in the search space set associated with a set of control resources during a time window in which the network entity responds to the PMI of that type. This window begins at the first symbol of the earliest set of control resources where the user equipment is configured to receive the PMI for the search space set, at least the number of symbols configured for the identified type of PMI timing, following the last symbol of the PMI timing corresponding to the PMI preamble transmitted by the user equipment in the PMI timing.

[0311] It should be understood that although specific steps are shown in the figures, various additional or different steps can be performed depending on the embodiment, and one or more of specific steps can be rearranged, repeated, or completely eliminated depending on the embodiment. Furthermore, some steps can be repeated simultaneously on an ongoing or continuous basis while other steps are being performed. Additionally, different steps can be performed by different elements or individual elements of the disclosed embodiments.

[0312] Figure 4 This is an example block diagram of an apparatus 400, such as a wireless communication device 110, according to a possible embodiment. Apparatus 400 may include a housing 410, a controller 420 within the housing 410, audio input and output circuitry 430 coupled to the controller 420, a display 440 coupled to the controller 420, a transceiver 450 coupled to the controller 420, an antenna 455 coupled to the transceiver 450, a user interface 460 coupled to the controller 420, a memory 470 coupled to the controller 420, and a network interface 480 coupled to the controller 420. Apparatus 400 is capable of performing the methods described in all embodiments.

[0313] Display 440 can be a viewfinder, liquid crystal display (LCD), light-emitting diode (LED) display, organic light-emitting diode (OLED) display, plasma display, projection display, touchscreen, or any other device for displaying information. Transceiver 450 can include a transmitter and / or receiver. Audio input and output circuitry 430 can include a microphone, speaker, transducer, or any other audio input and output circuitry. User interface 460 can include a keypad, keyboard, buttons, touchpad, joystick, touchscreen display, another additional display, or any other device for providing an interface between the user and the electronic device. Network interface 480 can be a universal serial bus (USB) port, Ethernet port, infrared transmitter / receiver, IEEE 1394 port, WLAN transceiver, or any other interface capable of connecting the device to a network, device, and / or computer and capable of transmitting and receiving data communication signals. Memory 470 can include random access memory, read-only memory, optical memory, solid-state memory, flash memory, removable memory, hard disk drive, cache, or any other memory that can be coupled to the device.

[0314] Device 400 or controller 420 can implement any operating system, such as Microsoft. or, Android TM Or any other operating system. For example, device operating software can be written in any programming language (such as C, C++, Java, or Visual Basic). Device software can also be written in application frameworks (such as... frame,. The software and / or operating system may run on the memory 470 or any other application framework. The device 400 or controller 420 may also use hardware to implement the disclosed operations. For example, controller 420 may be any programmable processor. The disclosed embodiments may also be implemented with: a general-purpose or special-purpose computer, a programmable microprocessor or microcontroller, peripheral integrated circuit elements, application-specific integrated circuits or other integrated circuits, hardware / electronic logic circuits (such as discrete component circuits), programmable logic devices (such as programmable logic arrays, field-programmable gate arrays), etc. Generally, controller 420 may be any controller or processor device or multiple processor devices capable of operating the device and implementing the disclosed embodiments. Some or all of the additional elements of device 400 may also perform some or all of the operations of the disclosed embodiments.

[0315] The methods disclosed herein can be implemented on a programmable processor. However, the controller, flowchart, and modules can also be implemented on general-purpose or special-purpose computers, programmable microprocessors or microcontrollers and peripheral integrated circuit elements, integrated circuits, hardware electronics or logic circuits such as discrete component circuits, programmable logic devices, etc. Generally, any device on which resides a finite state machine capable of implementing the flowcharts shown in the figures can be used to implement the processor functions of this disclosure.

[0316] While this disclosure has been described using specific embodiments, it will be apparent to those skilled in the art that many alternatives, modifications, and variations will be readily apparent. For example, various components of the embodiments may be interchanged, added to, or substituted in other embodiments. Furthermore, not all elements in each figure are essential for the operation of the disclosed embodiments. For example, those skilled in the art will be able to make and use the teachings of this disclosure by simply employing the elements of the independent claims. Therefore, the embodiments of this disclosure as set forth herein are intended to be illustrative rather than restrictive. Various changes may be made without departing from the spirit and scope of this disclosure.

[0317] In this document, relational terms such as “first” and “second” may be used only to distinguish one entity or action from another, without necessarily requiring or implying any actual such relationship or order between these entities or actions. The phrases “at least one of…”, “at least one selected from the group of…”, or “at least one selected from…” in the following list are defined to refer to one, some, or all of the elements in the list, but not necessarily all of them. The terms “comprising,” “including,” “having,” or any other variation thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further constraints, an element preceded by “a,” “an,” etc., does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes that element. Furthermore, the term “another” is defined as at least a second or more. The terms “comprising,” “having,” etc., as used herein, are defined as “comprising.” In addition, the background section is written as the inventor's own understanding of the context of some embodiments at the time of submission, and includes the inventor's own awareness of any problems with the prior art and / or problems experienced in the inventor's own work.

Claims

1. A method performed by a user equipment (UE), the method comprising: The offset is determined based on the configuration, and the offset includes the number of time slots used to delay monitoring the physical downlink control channel in the search space set, wherein the offset varies based on the type of random access channel event; Transmit the physical random access channel preamble during the physical random access channel timing; as well as In response to transmitting the physical random access channel preamble in the physical random access channel timing, during a time window, the physical downlink control channel for random access response is monitored in a search space set associated with a control resource set, wherein the window begins at the first symbol of the earliest control resource set where the UE is configured to receive the physical downlink control channel for the search space set, at least after the last symbol of the physical random access channel timing corresponding to the physical random access channel preamble transmitted in the physical random access channel timing.

2. The method according to claim 1, wherein, The offset, which includes the number of time slots used to delay monitoring the physical downlink control channel in the search space set, is determined as part of the transmission received by the UE from the network.

3. The method according to claim 2, wherein, The number of time slots used to delay monitoring the physical downlink control channel in the search space set is explicitly identified as part of the transmission received by the UE from the network.

4. The method according to claim 2, wherein, The number of time slots used to delay monitoring the physical downlink control channel in the search space set is derived from information included as part of the transmission received by the UE from the network.

5. The method according to claim 4, wherein, The information included as part of the transmission includes the number of time slots.

6. The method according to claim 1, wherein, The configuration, including the number of time slots used to delay monitoring the physical downlink control channel in the search space set, is determined based on a logical channel priority indication from the timing identifier of the transmitted physical random access channel.

7. The method according to claim 1, wherein, The search space set is associated with each of at least one type of physical random access channel timing, wherein the at least one type of physical random access channel timing includes multiple types of physical random access channel timing, the multiple types of physical random access channel timing including at least a first type of physical random access channel timing and a second type of physical random access channel timing.

8. The method according to claim 7, wherein, The number of time slots includes a first configuration time slot number for the first type of physical random access channel timing and a second configuration time slot number for the second type of physical random access channel timing, wherein the second configuration time slot number is different from the first configuration time slot number.

9. The method according to claim 1, wherein, The UE attempts to detect downlink control information during the time window using a cyclic redundancy check scrambled by the corresponding random access radio network temporary identifier.

10. The method according to claim 1, wherein, The search space set is the common search space set for the Type 1 physical downlink control channel.

11. The method according to claim 1, wherein, An offset, including the number of time slots used to delay monitoring the physical downlink control channel in the search space set, is applied to the contention-based random access procedure.

12. The method of claim 11, further comprising: Within the time window, a physical downlink control channel with downlink control information is received, wherein the physical downlink shared channel associated with the physical downlink control channel includes a random access response message, the random access response message including a random access response uplink permission for the UE; Transmit random access channel Msg3 on the uplink resources indicated by the uplink grant in the random access response; and The random access contention solution timer is started with a pre-configured time offset following the transmission of random access channel Msg3.

13. The method according to claim 12, wherein, The contention-based random access procedure is initiated in response to a request for uplink resources, and the UE's monitoring of the physical downlink control channel is limited to monitoring downlink control information while the random access contention solution timer is running.

14. The method according to claim 1, wherein, The physical random access channel timing is the type of transmission that occurs in response to a beam fault recovery process.

15. The method according to claim 14, wherein, The UE's monitoring of the physical downlink control channel is limited to monitoring downlink control information addressed to the cell radio network temporary identifier on the search space set, wherein the search space set is a beam fault recovery search space set configured by higher layers.

16. A user equipment (UE) for wireless communication, comprising: One or more memory units; as well as One or more processors, said one or more processors coupled to said one or more memories, and operable individually or cooperatively to enable the UE to: The offset is determined based on the configuration, and the offset includes the number of time slots used to delay monitoring the physical downlink control channel in the search space set, wherein the offset varies based on the type of random access channel event; as well as Transmit the physical random access channel preamble during the physical random access channel timing; In response to a physical random access channel preamble transmitted in the physical random access channel timing, a physical downlink control channel for random access channel response is monitored in the search space set associated with the control resource set during a time window, wherein the window begins at the first symbol of the earliest control resource set for which the UE is configured to receive physical downlink control channels for the search space set, at least after the last symbol of the physical random access channel timing corresponding to the physical random access channel preamble transmitted in the physical random access channel timing.

17. The UE according to claim 16, wherein, The offset, which includes the number of time slots used to delay monitoring the physical downlink control channel in the search space set, is determined as part of the transmission received by the UE from the network.

18. The UE according to claim 16, wherein, An offset, including the number of time slots used to delay monitoring the physical downlink control channel in the search space set, is applied to the contention-based random access procedure.

19. The UE according to claim 16, wherein, The physical random access channel timing is the type of transmission that occurs in response to a beam fault recovery process.

20. A processor for wireless communication, comprising: One or more controllers, said one or more controllers coupled to one or more memories, and operable to cause the processor to: The offset is determined based on the configuration, and the offset includes the number of time slots used to delay monitoring the physical downlink control channel in the search space set, wherein the offset varies based on the type of random access channel event; as well as Transmit the physical random access channel preamble during the physical random access channel timing; In response to a physical random access channel preamble transmitted in the physical random access channel timing, a physical downlink control channel for random access channel response is monitored in the search space set associated with the control resource set during a time window, wherein the window begins at the first symbol of the earliest control resource set configured to receive physical downlink control channels for the search space set, at least after the last symbol of the physical random access channel timing corresponding to the physical random access channel preamble transmitted in the physical random access channel timing.

Images