METHOD AND NETWORK NODE FOR MONITORING SHORT DOWNLINK CONTROL

INFORMATION

RELATED APPLICATIONS

[0001] The present application claims the benefits of priority of U.S. Provisional Patent Application No. 62/529771, entitled "Method for enhanced discontinuous reception (RDX) for STTI", and filed at the United States Patent and Trademark Office on July 7, 2017, the content of which is incorporated herein by reference.

TECHNICAL FIELD

[0002] The present description generally relates to wireless communication systems and more specifically to monitoring of short downlink control information (sDCI).

BACKGROUND

[0003] LTE Frame Structure and Physical Channels for lms TTI

[0004] In 3 GPP Long Term Evolution (LTE) systems, data transmissions in both downlink (i.e. from a radio network node or eNB to a user equipment or UE) and uplink (from a user equipment or UE to a radio network node or eNB) are organized into radio frames of 10 ms, each radio frame consisting of ten equally-sized subframes of length Tsubframe = 1 ms. An example of an LTE radio frame is shown in Figure 1.

[0005] LTE uses Orthogonal Frequency Division Multiple Access (OFDMA) in the downlink and Single Carrier FDMA (SC-FDMA) in the uplink. The basic LTE downlink physical resource can thus be seen as a time-frequency grid 200 as illustrated in Figure 2, where each resource element 210 corresponds to one OFDM subcarrier during one OFDM symbol interval 220.

[0006] Furthermore, the resource allocation in LTE is typically described in terms of resource blocks (RBs), where a resource block corresponds to one slot (0.5 ms) in the time domain and 12 contiguous subcarriers in the frequency domain. Resource blocks are numbered in the frequency domain, starting with 0 from one end of the system bandwidth.

[0007] Similarly, the LTE uplink resource grid 300 is illustrated in Figure 3, where NR is the number of resource blocks (RBs) contained in the uplink system bandwidth, A = the number subcarriers in each RB, typically N^ _C ^B = 12, N^y _mb is the number of Single Carrier-Frequency Division Multiple Access (SC-FDMA) symbols in each slot. N^y _mb = 7 for normal cyclic prefix (CP) and N^y _mb = 6 for extended CP. A subcarrier and a SC-FDMA symbol forms an uplink resource element (RE). In the system bandwidth, there are B= N^xN^ _c ^B subcarriers.

[0008] Downlink data transmissions from a radio network node (generally referred to as an eNB in LTE) to a UE are dynamically scheduled, i.e., in each subframe the eNB transmits control information about to which UEs data is transmitted and upon which resource blocks the data is transmitted in the current downlink subframe. This control signaling is typically transmitted in the first 1, 2, 3 or 4 Orthogonal Frequency Division Multiplex (OFDM) symbols in each subframe. A downlink transmission with 3 OFDM symbols for control signaling is illustrated in Figure 4.

[0009] Transmissions in the uplink (from a UE to an eNB) are, as in the downlink, also dynamically scheduled through the downlink control channel. When a UE receives an uplink grant in subframe n, it transmits data in the uplink at subframe n+k, where k = 4 for Frequency Division Duplex (FDD) system and where k varies for Time Divison Duplex (TDD) systems.

[0010] In LTE, a number of physical channels are supported for data transmissions. A downlink or an uplink physical channel corresponds to a set of resource elements carrying information originating from higher layers (e.g., Media Access Control (MAC), Radio Resource Control (RRC), etc.). while a downlink or an uplink physical signal is used by the physical layer but does not carry information originating from higher layers. Some of the downlink physical channels and signals supported in LTE are:

[0011] - Physical Downlink Shared Channel, PDSCH

[0012] - Physical Downlink Control Channel, PDCCH

[0013] - Enhanced Physical Downlink Control Channel, EPDCCH

[0014] - Cell Specific Reference Signals (CRS)

[0015] - DeModulation Reference Signal (DMRS) for PDSCH

[0016] - Channel State Information Reference Signals (CSI-RS)

[0017] PDSCH is used mainly for carrying user traffic data and higher layer messages in the downlink and is transmitted in a downlink subframe outside of the control region as shown in Figure 4. Both

PDCCH and EPDCCH are used to carry Downlink Control Information (DO) such as Physical

Resource Block (PRB) allocation, modulation level and coding scheme (MCS), precoder used at the transmitter, etc. PDCCH is transmitted in the first one to four OFDM symbols in a downlink subframe, i.e., in the control region, while EPDCCH is transmitted in the same region as PDSCH.

[0018] Some of the uplink physical channels and signals supported in LTE are: [0019] - Physical Uplink Shared Channel, PUSCH

[0020] - Physical Uplink Control Channel, PUCCH

[0021] - DeModulation Reference Signal (DMRS) for PUSCH

[0022] - DeModulation Reference Signal (DMRS) for PUCCH

[0023] The PUSCH is used to carry uplink data and/or uplink control information from the UE to the eNB. The PUCCH is used to carry uplink control information from the UE to the eNB.

[0024] DCI Formats for lms Transmission Time Interval (TTI) Scheduling

[0025] The current control channels carry control information, referred to as Downlink Control Information (DCI). There are several DCI formats which have different options depending on e.g., configured transmission mode. The DCI format has a Cyclic Redundancy Check (CRC) which is scrambled by a UE identifier, such as a Cell-Radio Network Temporary Identifier (C-RNTI), and when the CRC matches, after descrambling, a PDCCH with a certain DCI format has been detected. There are also identifiers that are shared by multiple UEs, such as the System Information-RNTI (SI- RNTI) which is used for transmission of system information.

[0026] DCI Formats for DL Scheduling Assignments

[0027] As described in 3 GPP TS 36.212, there are currently a number of different DCI formats for downlink resource assignments including format 1, 1A, IB, 1C, ID, 2, 2A, 2B, 2C and 2D. The downlink control information (DCI) for a downlink scheduling assignment contains information on downlink data resource allocation in the frequency domain (the resource allocation), modulation and coding scheme (MCS) and Hybrid Automatic Repeat Request (HARQ) process information. In case of carrier aggregation, information related to which carrier the PDSCH is transmitted on may be included as well.

[0028] DCI Formats for UI Scheduling Grants

[0029] There are two main families of DCI formats for UL grants, DCI format 0 and DCI format 4. The latter was added in Release 10 for supporting uplink spatial multiplexing. Several DCI format variants exist for both DCI format 0 and format 4 for various purposes, e.g., scheduling in unlicensed spectrum.

[0030] Latency Reduction with Short TTI (sTTI)

[0031] Packet data latency is one of the performance metrics that vendors, operators, and end-users (via speed test applications) regularly measure. Latency measurements are done in all phases of a radio access network system lifetime, when verifying a new software release or system component, when deploying a system and when the system is in commercial operation.

[0032] Shorter latency than previous generations of 3 GPP Radio Access Technologies (RATs) was one performance metric that guided the design of LTE. The end-users also now recognize LTE to be a system that provides faster access to Internet and lower data latencies than previous generations of mobile radio technologies.

[0033] Packet data latency is important not only for the perceived responsiveness of the system; it is also a parameter that indirectly influences the throughput of the system. Hypertext Transfer Protocol/Transport Control Protocol (TTP/TCP) is the dominating application and transport layer protocol suite used on the internet today. According to HTTP Archive (http://httparchive.org/trends.php) the typical size of HTTP based transactions over the internet are in the range of a few tens of Kbytes up to one Mbyte. In this size range, the TCP slow start period is a significant part of the total transport period of the packet stream. During TCP slow start, the performance is latency limited. Hence, improved latency can rather easily be showed to improve the average throughput, for this type of TCP based data transactions.

[0034] Latency reductions could positively impact radio resource efficiency. Lower packet data latency could increase the number of transmissions possible within a certain delay bound; hence higher Block Error Rate (BLER) targets could be used for the data transmissions freeing up radio resources potentially improving the capacity of the system.

[0035] One approach to latency reduction is the reduction of transport time of data and control signaling, by addressing the length of a transmission time interval (TTI). By reducing the length of a TTI and maintaining the bandwidth, the processing time at the transmitter and the receiver nodes is also expected to be reduced, due to less data to process within the TTI. As described above, in LTE Release 8, a TTI corresponds to one subframe of length 1 millisecond. One such 1 ms TTI is constructed by using 14 OFDM or SC-FDMA symbols in the case of normal cyclic prefix and 12 OFDM or SC-FDMA symbols in the case of extended cyclic prefix. In LTE Release 14 in 3 GPP, a study item on latency reduction has been conducted, with the goal of specifying transmissions with shorter TTIs, such as a slot or a few symbols. A work item with the goal of specifying short TTI (sTTI) has started in August 2016.

[0036] An sTTI can be decided to have any duration in time and comprises resources on any number of OFDM or SC-FDMA symbols, and starts at symbol position within the overall frame. For the work in LTE, the focus of the work is currently to only allow the sTTIs to start at fixed positions with durations of either 2, 3, 4 or 7 symbols. Furthermore, the sTTI is not allowed to cross neither slot nor subframe boundaries.

[0037] Figure 5 shows some examples of a TTI and sTTI for the case where PDCCH spans one OFDM symbol. At the top of Figure 5, the legacy TTI 500 is depicted consisting of 14 OFDM symbols 510. The middle diagram of Figure 5 depicts the case where the duration of the uplink short TTI (520) is 0.5 ms, i.e. seven SC-FDMA symbols 530 for the case with normal cyclic prefix. Also, a combined length of 2 or 3 symbols are shown for the sTTI 540 and 550 (respectively) in the bottom diagram of Figure 5. Other configurations are not excluded, and Figure 5 is only an attempt to illustrate differences in sTTI lengths.

[0038] Although a shorter TTI has merits when it comes to latency, it can also have some negative impact to the uplink coverage since less energy is transmitted by the UE, specifically considering the UL control channel performance, which includes both HARQ bits, Channel Quality Information (CQI) and Scheduling Request.

[0039] Due to the limited UL coverage when transmitting a shortened TTI, it is possible to configure a longer TTI length on the UL than in the DL to combat these problems, with the standard supporting sTTI length combination in the {DL,UL} of {2,7} . There is also the possibility of the network to schedule the UE with 1 ms TTI duration dynamically on a subframe-by-subframe basis.

[0040] DL and UL sTTI scheduling

[0041] To schedule an uplink or a downlink sTTI transmission, it is possible for the eNB to transmit the corresponding control information by using a new DCI format, referred to as short DCI (sDCI), in each DL sTTI. This sDCI contains all control information required to decode the scheducled data transmission, e.g. modulation and coding scheme, resource allocation, precoding matrix, etc.

[0042] The control channel carrying this sDCI can be either PDCCH or short PDCCH (sPDCCH). In the example of Figure 5, there can be up to 6 sTTIs per LTE subframe, a UE should monitor sDCI in up to 6 instances per subframe. When sDCI is sent over PDCCH, it may be transmitted using a DCI format and radio resources that do not match the ones used for the DCI of 1ms TTI. This means that to find sDCI on PDCCH, the UE may be required to carry out additional processing on top of processing required for 1ms ΤΉ DCI detection.

[0043] Discontinuous Reception (DRX) [0044] It is currently possible to configure the UE with Discontinuous Reception (DRX). A DRX cycle is a periodic repetition of an on-duration period when the UE monitors PDCCH for data reception followed by an inactivity period when the UE can sleep in order to save UE battery. The UE is always configured with a long DRX cycle, but can also optionally be configured with a short DRX cycle. In case a short DRX cycle is configured, the UE will first enter short DRX for a period of time and then enter long DRX cycle.

[0045] The Active time is the time when the UE monitors PDCCH. It can be when any of the timers onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer or drx-ULRetransmissionTimer are running. During the Active time, the UE monitors the PDCCH. If the UE finds a grant for it in PDCCH it stays active during the rest of the subframe. Otherwise, it skips monitoring the remaining subframe. When the onDurationTimer expires, the UE can sleep based on short or long DRX cycle length, if any of the other timers above are not running.

[0046] The drx-InactivityTimer restarts every time data is scheduled in PDCCH (starts running in the next subframe) in order to keep the UE active for a longer time when data is transmitted. The drx- RetransmissionTimer and drx-ULRetransmissionTimer are for the UE to wake up again and monitor a possible retransmission in case the first transmission failed.

[0047] An example of a DRX configuration is shown in Figure 6. Figure 6 illustrates for example a short DRX cycle 600 compared to a long DRX cycle 610. The short DRX cycle 600 comprises an OnDuration 620 (when the wireless device is awake) and a sleep duration 630. Furthermore, Figure 6 shows that the DRX cycle is aligned with the timing of different subframes.

[0048] MAC Control Element (MAC CE)

[0049] In 3 GPP TS 36.321, MAC Control Elements (MAC CE) are defined. The MAC CEs are a number of bits included in the MAC Packet Data Unit (PDU) for transferring of pre-defined information. There are e.g. MAC CEs defined for Buffer Status Reports, DRX Command for start or restart of DRX cycle and Power Headroom Reports. Figure 7 illustrates an example of a MAC packet data unit 700 carrying different MAC CEs. For example, a MAC PDU 700 consists of a MAC header 710, MAC control elements 720, MAC SDUs 730 and padding 740.

SUMMARY

[0050] The current DRX controls monitoring of PDCCH for a legacy DCI, later called 1ms DCI, does not state any behavior for the monitoring of sDCI which can be transmitted on either sPDCCH or PDCCH. When configured with sTTI, the UE is required to monitor both PDCCH and sPDCCH the whole time which may consume a lot of UE battery. Even if the UE is only scheduled on PDCCH for a long period of time, it is still required to monitor sDCI which can be sent on both PDCCH and sPDCCH. There is no RRC reconfiguration between scheduling on 1ms ΤΉ on PDCCH and short TTI which means that the DRX cannot be reconfigured in-between.

[0051] In accordance with some embodiments, a mechanism for controlling the monitoring of sDCI, is introduced, which gives the UE opportunities for some sleep, i.e. the UE is not required to monitor sDCI the whole time.

[0052] According to one aspect, some embodiments include a method in a User Equipment, UE. The method comprises receiving a signal from a radio network node, the signal comprising an indication of short downlink control information (sDCI) to be monitored, and monitoring the sDCI based on the indication.

[0053] In some embodiments, the signal may be a RRC signal or a MAC level signal.

[0054] In some embodiments, the indication may be a bitmap.

[0055] Some embodiments provide the UE with opportunities to have periods of active time and periods of inactive time related to monitoring of sDCI/sPDCCH. As such, the UE can save some battery when monitoring sPDCCH, by having some active time and sleep time.

[0056] Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

[0057] According to one aspect, some embodiments include a method performed by a user equipment for monitoring short DCIs. The method generally comprises: receiving a signal from a radio network node, the signal comprising an indication of short downlink control information (sDCI) to be monitored; and monitoring the indicated sDCI.

[0058] In some embodiments, the indication comprises a bitmap indicating which sDCI to be monitored.

[0059] In some embodiments, monitoring the indicated sDCI comprises monitoring a downlink channel for the indicated sDCI, during an awake time of a Discontinuous Reception (DRX) cycle.

[0060] According to another aspect, some embodiments include a user equipment (UE) configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein. [0061] In some embodiments, the UE may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities of the UE as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities of the UE as described herein.

[0062] In some embodiments, the UE may comprise one or more functional modules configured to perform one or more functionalities of the UE as described herein.

[0063] According to another aspect, some embodiments include a non-transitory computer-readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the UE, configure the processing circuitry to perform one or more functionalities of the UE as described herein.

[0064] According to another aspect, some embodiments include a method performed by a radio network node for indicating short DCIs to be monitored. The method generally comprises: determining which short downlink control information (sDCI) is to be monitored; and sending a signal to a wireless device, the signal comprising an indication of the sDCI to be monitored.

[0065] In some embodiments, the method comprises determining a pattern of sDCI for monitoring and the indication comprises a bitmap indicating the sDCI to be monitored.

[0066] According to another aspect, some embodiments include a network node configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein.

[0067] In some embodiments, the network node may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities of the network node as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities of the network node as described herein.

[0068] In some embodiments, the network node may comprise one or more functional modules configured to perform one or more functionalities of the network node as described herein. [0069] According to another aspect, some embodiments include a non-transitory computer-readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the network node, configure the processing circuitry to perform one or more functionalities of the network node as described herein.

[0070] This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Exemplary embodiments will be described in more detail with reference to the following figures, in which:

[0072] Figure 1 illustrates a schematic diagram of an LTE time-domain structure.

[0073] Figure 2 illustrates a schematic diagram of the LTE downlink resource grid.

[0074] Figure 3 illustrates a schematic diagram of the LTE uplink resource grid.

[0075] Figure 4 illustrates a schematic diagram of an exemplary LTE downlink subframe.

[0076] Figure 5 illustrates schematic diagrams of exemplary 2/3 -symbol sTTI configurations within a downlink subframe.

[0077] Figure 6 illustrates a schematic diagram of an exemplary Discontinuous Reception (DRX).

[0078] Figure 7 illustrates a schematic diagram of an exemplary MAC PDU comprising a MAC header, MAC control elements, MAC SDUs and padding.

[0079] Figure 8 illustrates a schematic diagram of an example communication network in accordance with some embodiments.

[0080] Figure 9 illustrates a first signaling diagram for indicating sDCI to be monitored, according to some embodiments.

[0081] Figure 10 illustrates a second signaling diagram for indicating sDCI to be monitored, in accordance with some embodiments.

[0082] Figure 11 illustrates a third signaling diagram for indicating sDCI to be monitored, in accordance with some embodiments. [0083] Figure 12 illustrates a flow chart for controlling monitoring of sDCI in a wireless device, according to some embodiments.

[0084] Figure 13 illustrates a flow chart for controlling monitoring of sDCI by a radio network node, according to some embodiments.

[0085] Figure 14 illustrates a block diagram of a UE (or wireless device) in accordance with some embodiments.

[0086] Figure 15 illustrates a block diagram of a radio network node in accordance with some embodiments.

[0087] Figure 16 illustrates another block diagram of a UE (or wireless device) in accordance with some embodiments.

[0088] Figure 17 illustrates another block diagram of a radio network node in accordance with some embodiments.

DETAILED DESCRIPTION

[0089] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

[0090] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0091] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0092] As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0093] Several embodiments will be described in the context of 3GPP LTE standards. However, references to 3 GPP LTE standards and to their terminology should not be construed as limiting the scope of the present description to such standards. In that regard, various embodiments may also be applicable in the context of other standards, for instance, 3GPP UMTS and 3GPP NR (or 5G). For example, the embodiments of the present disclosure apply to any technology (e.g. NR, 5G) relying on reference signal transmission where there is a predictable part of the signal that might be distorted, the part of the signal being distorted being known, while the actual distortion is possibly unknown.

[0094] Figure 8 illustrates an example of a wireless network 800 that may be used for wireless communications. Wireless network 800 includes UEs 11 OA- 110B (collectively referred to as UE or UEs 110) and a plurality of radio network nodes 820A-820B (e.g., Node Bs (NBs), Radio Network Controllers (RNCs), evolved NBs (eNBs), next generation NB (gNBs), etc.) (collectively referred to as radio network node or radio network nodes 820) directly or indirectly connected to a core network 130 which may comprise various core network nodes. The network 800 may use any suitable radio access network (RAN) deployment scenarios, including Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UMTS Terrestrial Radio Access Network (EUTRAN). UEs 810 within coverage areas 815 may each be capable of communicating directly with radio network nodes 820 over a wireless interface. In certain embodiments, UEs may also be capable of communicating with each other via device-to-device (D2D) communication.

[0095] As an example, UE 81 OA may communicate with radio network node 820 A over a wireless interface. That is, UE 81 OA may transmit wireless signals to and/or receive wireless signals from radio network node 820 A. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a radio network node 820 may be referred to as a cell.

[0096] It should be noted that a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.

[0097] As indicated above, the existing DRX controls the PDCCH monitoring for a legacy DCI, later called 1ms DCI, but it doesn't state any behavior for monitoring of sDCI which can be transmitted on either sPDCCH or PDCCH.

[0098] When configured with sTTI, the UE is required to monitor both PDCCH and sPDCCH the whole time which consumes a lot of UE battery. Even if the UE is only scheduled on PDCCH for a long period of time it is still required to monitor sDCI which can be sent on both PDCCH and sPDCCH. There is no RRC reconfiguration between scheduling on 1ms ΤΉ on PDCCH and short TTI which means that the DRX cannot be reconfigured in-between.

[0099] Embodiments of the present disclosure introduce a mechanism for controlling the monitoring of sDCI. In most cases, sDCI is sent on sPDCCH. In the following, sPDCCH monitoring and sPDCCH occasions should be understood as sDCI monitoring and sDCI occasions as the present disclosure can also apply to the case where sDCI sent on PDCCH should not be monitored.

[0100] The present disclosure gives the UE opportunities for some sleep and does not require the UE to monitor sDCI the whole time.

[0101] The existing DRX controls the PDCCH monitoring for possible DCI. The current DRX can be extended to also include the monitoring of sPDCCH (and PDCCH) for possible sDCI, i.e during active time the UE monitors both PDCCH and sPDCCH for possible 1ms DCI and sDCI and during sleep time it monitors none of the channels. That leads to a lot of active time for the UE as there can be one PDCCH and six sPDCCH occasions in one subframe. Embodiments of the present disclosure allow to indicate to the UE some of the sPDCCH occasions that need to be monitored and some of the sPDCCH occasions which do not have to be monitored, in order to offer the UE some opportunities for sleep.

[0102] One possibility is to signal in RRC signaling which of the sDCI or sPDCCH occasions that need to be monitored (alternatively not monitored). The occasions can e.g. be signaled as a bitmap where each bit corresponds to one sDCI or one sPDCCH occasion. The bits can be set for the sDCI/sPDCCH occasions where the UE should monitor the sDCI/sPDCCH (alternative not monitor sDCI/sPDCCH). The signaling of which sDCI/sPDCCH occasions where the UE should monitor sDCI/sPDCCH can also be signaled in RRC in other ways, e.g. as numbers where the numbers correspond to a sDCI/sPDCCH occasion or some other kind of indication.

[0103] Figure 9 illustrates a signaling diagram 900 between the radio network node or eNB or gNB 820 and a UE 810, for indicating the sDCI or sPDCCHs to be monitored.

[0104] The eNB 820 sends a signal to the UE (step 910), the signal can be a RRCConnection Reconfiguration signal for example. The signal can comprise a bitmap for indicating which sDCI should be monitored. For example, the bitmap can indicate a sDCI pattern for monitoring.

[0105] The UE replies with a signal back to the eNB (step 920), the signal can be a RRCConnectionReconfigurationComplete signal for example.

[0106] The UE then monitors the PDCCH and the indicated sDCI (or sPDCCH) during the onDuration of the DRX cycle, (step 930) As a note, some sDCI occasions can happen on PDCCH.

[0107] As an example, the RRC signaling for switching off some sDCI/sPDCCH monitoring could look like this:

[0108] When the bit is set to one, it could mean that sDCI/sPDCCH for that sTTI should be monitored (or alternatively not monitored). The bitmap is applicable during the on duration time for DRX.

[0109] As an extension, monitoring of only part of the sDCI/sPDCCH occasions can be switched off. For instance, if there are 6 sDCI/sPDCCH occasions per subframe, the first sDCI/sPDCCH occasion is always monitored while the remaining 5 sDCI/sPDCCH occasions can be switched off with some signaling (e.g. RRC signaling). This can be of benefit to reduce the number of bits for signaling the sDCI/sDCCH occasions to monitor. In addition, this can also be used in case the first sDCI occasion occurs on PDCCH and the remaining sDCI occasions in a subframe are sent on sPDCCH

[0110] As an extension, if the UE detects a valid sPDSCH assignment or sPUSCH grant in one sPDCCH, it means there is traffic for the UE. It may thus be beneficial for the UE to not skip monitoring the next sPDCCH even if that sPDCCH has been indicated as not to be monitored. A separate inactivity timer could be introduced for the sPDCCH monitoring with sTTI granularity. If the UE has been scheduled in one sPDCCH, it monitors a few more sPDCCH according to the sPDCCH inactivity timer until it again follows the indicated pattern for sPDCCH monitoring.

[0111] The pattern limiting the sPDCCH monitoring could optionally be switched on and off with MAC CE. When switched on, the UE only monitors the indicated sPDCCH occasions, when switched off, the UE monitors all PDCCH occasions.

[0112] Figure 10 illustrates a signaling diagram 1000 between the radio network node or eNB or gNB 820 and the UE 810, for indicating the sDCI or sPDCCHs to be monitored and later on for switching off and on the monitoring.

[0113] The eNB sends a signal to the UE (step 1010), the signal can be a RRCConnectionReconfiguration signal. For example, the signal can comprise a bitmap for indicating the sDCI to be monitored.

[0114] The UE replies with a signal back to the eNB (step 1020), the signal can be a RRCConnectionReconfigurationComplete signal, for example.

[0115] Then, the UE starts monitoring the PDCCH and the indicated sPDCCH (or sDCI) during the on Duration of a DRX cycle (step 1030).

[0116] At some point, the eNB sends a first MAC CE to the UE, for indicating the switching off of the sPDCCH (or sDCI) monitoring (step 1040).

[0117] In this case, the UE may only monitor PDCCH (step 1050).

[0118] At some other point, the eNB sends a second MAC CE, for indicating the switching on of the sPDCCH (or sDCI) monitoring again (step 1060).

[0119] In some embodiments, the sPDCCH occasions which should be monitored can be indicated on MAC level instead, e.g. as a bitmap in a MAC CE. The number of bits in MAC CE are limited to five, which means that full flexibility will not be achieved if signaled in MAC layer.

[0120] A MAC CE for completely switching off sPDCCH monitoring can also be introduced. This is shown in Reference 1. The UE then only monitors PDCCH. If the monitoring of sPDCCH has been completely switched off, a fast way to activate sDRX again is to send an sDCI on PDCCH. The UE will know then that it is being scheduled with sTTI and can activate sDRX for monitoring of sPDCCH. Alternatively, another MAC CE could be defined to activate sPDCCH monitoring again. This is shown in Reference 1.

[0121] For example, Figure 11 illustrates a signal diagram 1100 where the sDCI or sPDCCH monitoring is completely switched off with a MAC CE. [0122] The eNB 820 sends a signal to the UE (step 1110), the signal can be a RRCConnectionReconfiguration signal. For example, the signal does not comprise any bitmap for indicating the sDCI to be monitored.

[0123] The UE replies with a signal back to the eNB (step 1120), the signal can be a RRCConnectionReconfigurationComplete signal.

[0124] Then, the eNB sends a MAC CE to the UE, for indicating the switching off of the sPDCCH (or sDCI) monitoring (step 1130).

[0125] At some point, the eNB can send a sDCI on PDCCH to the UE to activate sDRX again, i.e. to let the UE know that it is being scheduled with sTTI and it can activate sDRX for monitoring of sPDCCH (stepl l40).

[0126] Alternatively, the eNB can send another MAC CE to the UE for indicating the switching on of the sPDCCH (or sDCI) monitoring (step 1150).

[0127] Figure 12 is a flow chart that illustrates operations and method 1200 of the UE 810 in accordance with some embodiments. As illustrated, the UE 810 receives a signal from a radio network node, the signal comprising an indication of short downlink control information (sDCI) to be monitored (block sl210).

[0128] The UE monitors the sDCI based on the indication or monitors the indicated sDCI (block si 220). It should be noted that monitoring sDCI is equivalent to monitoring the sPDCCH, for the sDCI occasions/occurrences during an onduration (or awake time) of the DRX cycle, for example.

[0129] Also, the indication can be provided in a RRC signal or a MAC CE, using a bitmap for example. The bitmap can indicate which sDCI to be monitored and which sDCI not to be monitored. For example, the bitmap can comprise a pattern of sDCI for monitoring. As such, monitoring the sDCIs is done based on the indicated pattern.

[0130] In some embodiments, monitoring the sDCI comprises monitoring a downlink channel for the sDCI occasions, during an awake time of a DRX cycle.

[0131] In some embodiments, the eNB sends a signal to switch off the monitoring of some sDCIs so as to reduce a number of bits used for the indication of the sDCIs.

[0132] For example, when the UE detects a first sDCI and/or a sPUSCH grant, the UE may continue to monitor for the next sDCIs even though the next sDCIs are indicated as not to be monitored.

[0133] In some embodiments, an inactivity timer for sDCI monitoring with sTTI granularity may be used. [0134] When the sDCI monitoring is switched off, the wireless device (or UE) only monitors DCIs on PDCCHs.

[0135] In some embodiments, the sDCI monitoring is switched off with a MAC CE, in response to receiving a signal comprising the MAC CE, from the network node.

[0136] In some embodiments, the sDCI monitoring is switched on again when the UE receives another MAC CE from the network node.

[0137] Figure 13 is a flow chart that illustrates operations and method 1300 of the radio network node 820 in accordance with some embodiments. As illustrated, the radio network node 820 determines which sDCI is to be monitored (block si 310). For example, the sDCI to be monitored can be configured or determined based on certain configuration constraints or other factors.

[0138] The radio network node sends a signal to the wireless device, the signal comprising an indication of the sDCI to be monitored (block sl320).

[0139] In some embodiments, the radio network node may determine a pattern of sDCI for monitoring.

[0140] In some embodiments, the signal can be a RRC Connection Reconfiguration signal or a MAC level signal.

[0141] In some embodiments, the indication comprises a bitmap indicating the sDCI to be monitored. In some embodiments, the bitmap may indicate sDCI which does not need to be monitored. Alternatively, the signal can comprise an indication of sDCI which does not need to be monitored.

[0142] In some embodiments, the radio network node sends a signal to switch off the monitoring of some sDCIs so as to reduce a number of bits used for the indication of the sDCIs.

[0143] In some embodiments, the radio network node sends a first MAC CE to switch off the sDCI monitoring.

[0144] In some embodiments, the radio network node sends a second MAC CE to switch on the sDCI monitoring again.

[0145] In some embodiments, the radio network node further sends a sDCI and sPUSCH grant to indicate continuing monitoring for the next sDCIs even though the next sDCIs are indicated as not to be monitored.

[0146] Figure 15 is a block diagram of an exemplary UE (or wireless device) 810, in accordance with certain embodiments. UE 810 includes one or more of a transceiver 1400, processor 1410, and memory 1420. In some embodiments, the transceiver 1400 facilitates transmitting wireless signals to and receiving wireless signals from radio access node 820 (e.g., via transmitter(s) (Tx), receiver(s) (Rx) and antenna(s)). The processor 1410 executes instructions to provide some or all of the functionalities described above as being provided by UE 810, and the memory 1420 stores the instructions executed by the processor. In some embodiments, the processor and the memory form processing circuitry 1430.

[0147] The processor 1410 may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of UE 810, such as the functions of UE 810 described above. In some embodiments, the processor 1410 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic.

[0148] The memory is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 1420 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processor of UE 810.

[0149] Other embodiments of UE 810 may include additional components beyond those shown in Figure 14 that may be responsible for providing certain aspects of the UE's functionalities, including any of the functionalities described above (such as method 1200) and/or any additional functionalities (including any functionality necessary to support the solution described above). As just one example, UE 810 may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor. Input devices include mechanisms for entry of data into UE 810. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc.

[0150] Figure 15 is a block diagram of an exemplary radio network node 820, in accordance with certain embodiments. Radio access node 820 may include one or more of a transceiver 1500, processor 1510, memory 1520, and network interface 1530. In some embodiments, the transceiver facilitates transmitting wireless signals to and receiving wireless signals from UE 810 (e.g., via transmitter(s) (Tx), receiver(s) (Rx), and antenna(s)). The processor 1500 executes instructions to provide some or all of the functionalities described above (such as method 1300) as being provided by a radio access node 820, the memory 1520 stores the instructions executed by the processor 1510. In some embodiments, the processor 1510 and the memory 1520 form processing circuitry 1540. The network interface 1530 communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers, etc.

[0151] The processor 1510 may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of radio access node 820, such as those described above (e.g. method 1300). In some embodiments, the processor 1510 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic.

[0152] The memory 1520 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

[0153] In some embodiments, the network interface 1530 is communicatively coupled to the processor 1510 and may refer to any suitable device operable to receive input for radio access node 820, send output from radio access node 820, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface 1530 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

[0154] Other embodiments of radio access node 820 may include additional components beyond those shown in Figure 15 that may be responsible for providing certain aspects of the radio network node's functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

[0155] Processors, interfaces, and memory similar to those described with respect to Figure 15 may be included in other network nodes (such as core network nodes). Other network nodes may optionally include or not include a wireless interface (such as the transceiver described in Figure 15).

[0156] In some embodiments, a UE 1600 (such as the UE 810) may comprise a series of modules configured to implement the functionalities of the UE described above. Referring to Figure 16, in some embodiments, the UE 16000 may comprise at least a receiving module 1610 and a monitoring module 1620. The receiving module 1610 is configured to receive a signal comprising an indication of sDCI to be monitored. The monitoring module 1620 is configured to monitor the sDCI based on the received indication.

[0157] It will be appreciated that the various modules may be implemented as combination of hardware and/or software, for instance, the processor, memory and transceiver(s) of UE 1600/UE 810 shown in Figure 14. Some embodiments may also include additional modules to support additional and/or optional functionalities.

[0158] In some embodiments, a radio network node 1700 (such as network node 820) may comprise a series of modules configured to implement the functionalities of the radio network node described above. Referring to Figure 17, in some embodiments, the radio network node 1700 may comprise at least a determining module 1710 and a sending module 1720. The determining module 1710 is configured to determine sDCI to be monitored. The sending module 1720 is configured to send a signal to a wireless device, the signal comprising an indication of the sDCI to be monitored.

[0159] It will be appreciated that the various modules may be implemented as combination of hardware and/or software, for instance, the processor, memory and transceiver(s) of radio network node 1700/network node 820 shown in Figure 15. Some embodiments may also include additional modules to support additional and/or optional functionalities.

[0160] Some embodiments may be represented as a non-transitory software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to one or more of the described embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

[0161] The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description.

REFERENCES

[0162] Reference 1 : PCT/CN2017/083445 entitled "Discontinuous Reception DRX in wireless communication networks", filed on May 8, 2017, by Cecilia Eklof, Laetitia Falconetti and Zhan Zhang.