Transmitting / receiving device and scheduling device

Abstract

The present disclosure provides a transceiver, a scheduling device, and a communication method between the transceiver and the scheduling device. The transceiver includes a transceiver that, during operation, transmits a schedule request for scheduling data via a PUCCH, and a circuit that starts a monitoring sleep timer after transmitting the schedule request. The transceiver does not monitor a PDCCH during operation of the monitoring sleep timer, and starts monitoring the PDCCH for resource allocation for the scheduling data when the monitoring sleep timer expires.

Description

[Technical Field]

[0001] The present disclosure relates to transmitting and receiving signals in communication systems. In particular, the present disclosure relates to methods and apparatus for such transmission and reception. [Background technology]

[0002] Currently, the 3rd Generation Partnership Project (3GPP) is working on technical specifications for next-generation cellular technology, also known as the fifth generation (5G). 5G includes New Radio (NR) and Radio Access Technology (RAT), which operate in frequency bands ranging from near 1 GHz to millimeter wave bands. NR will follow technologies represented by Long Term Evolution (LTE) and LTE Advanced (LTE-A).

[0003] For systems such as LTE, LTE-A, and NR, further modifications and options may facilitate efficient operation of the communication system and certain devices associated with the system.

[0004] One non-limiting exemplary embodiment facilitates providing flexibility and power consumption that reduces scheduling requirements. Summary of the Invention

[0005] In one embodiment, a transceiver device that is a technology disclosed in this specification comprises: a transceiver that, during operation, transmits a scheduling request for scheduling data via a PUCCH that is a physical uplink control channel; and a circuit that, during operation, starts a monitoring sleep timer after the transceiver transmits the scheduling request, wherein the transceiver, during operation, does not monitor a PDCCH that is a physical downlink control channel while the monitoring sleep timer is operating, and starts monitoring the PDCCH for resource allocation for the scheduling data when the monitoring sleep timer expires.

[0006] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof.

[0007] Further benefits and advantages of the disclosed embodiments may become apparent from the specification and drawings. Benefits and / or advantages may be obtained individually through various embodiments and features of the specification and drawings, which need not all be provided to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0008] In the following, exemplary embodiments are explained in more detail with reference to the accompanying drawings. [Figure 1] FIG. 1 illustrates an example architecture of a 3GPP NR system. [Figure 2] FIG. 1 is a block diagram illustrating an example user and control plane architecture for an LTE eNB, gNB, and UE. [Figure 3] 1 is a schematic diagram showing the division of functions between NG-RAN and 5GC. [Figure 4] FIG. 1 is a sequence diagram of an RRC connection setup / reconfiguration procedure. [Figure 5] FIG. 1 is a schematic diagram illustrating usage scenarios for Enhanced Mobile Broadband, Massive Machine Type Communications (mMTC), and Ultra Reliable and Low Latency Communications (URLLC). [Figure 6] FIG. 1 is a block diagram illustrating an example 5G system architecture. [Figure 7] 10 is a diagram illustrating a transmission scheduling request and an active period when the DRX cycle, which is discontinuous reception, is set in accordance with 3GPP TR 38.321. FIG. [Figure 8A] 10 shows a schematic time sequence of sending a scheduling request and receiving an uplink grant aligned with an active period in a DRX configuration for an associated high priority logical channel; [Figure 8B] 10 shows a schematic time sequence of sending a scheduling request and receiving an uplink grant aligned with an active period in a DRX configuration for an associated low priority logical channel; [Figure 9] FIG. 2 is a block diagram illustrating functional components of a transceiver and a scheduling device according to an embodiment. [Figure 10] FIG. 10 illustrates a delay of an active period from the transmission time of a scheduling request, according to one embodiment. [Figure 11] 10 is a flowchart illustrating the transmission of a scheduling request and the initiation of monitoring the physical downlink control channel after a monitoring sleep timer expires. [Figure 12] FIG. 10 is a diagram illustrating a mapping of one scheduling request setting per logical channel when a first runtime of the monitoring sleep timer is set to a first logical channel and a second runtime of the monitoring sleep timer is set to a second logical channel. [Figure 13] FIG. 10 shows a schematic diagram of a mapping of one scheduling request setting for each of two logical channels. [Figure 14] FIG. 1 illustrates a schematic diagram of a MAC Control Element, CE, showing the runtime of a monitoring sleep timer, according to one embodiment. [Figure 15] 2 illustrates a schematic time sequence of sending a scheduling request, receiving a monitoring sleep indicator, and receiving an uplink grant aligned with an active period according to one embodiment; [Figure 16] 10 is a flowchart illustrating the transmission of a scheduling request, the reception of a monitoring sleep indicator, and the initiation of monitoring the physical downlink control channel after the monitoring sleep timer expires. [Figure 17] FIG. 2 illustrates a schematic time sequence of sending a scheduling request, starting a monitoring sleep timer, receiving a monitoring sleep indicator, and restarting a monitoring sleep timer according to one embodiment; [Figure 18A] FIG. 10 is a diagram showing the short format of a buffer status report (BSR). [Figure 18B] FIG. 10 is a diagram showing the long format of a BSR, which is a buffer status report. [Figure 19] 10A and 10B are diagrams illustrating transmission of a buffer status report and an active period when a DRX cycle is set as discontinuous reception. [Figure 20A] 10 shows a schematic time sequence of sending a buffer status report and receiving an uplink grant aligned with the active period of the DRX configuration of the associated high priority logical channel group; [Figure 20B] 10 shows a schematic time sequence of sending a buffer status report and receiving an uplink grant aligned with the active period of the DRX configuration of the associated low priority logical channel group; [Figure 21] FIG. 10 illustrates the delay of an active period from the transmission time of a buffer status report, according to one embodiment. [Figure 22] 10 is a flowchart illustrating the transmission of a buffer status report and the initiation of monitoring of the physical downlink control channel after the monitoring sleep timer expires. [Figure 23] FIG. 1 illustrates the steps of a scheduling request procedure in which a scheduling request and a buffer status report are sent and respective monitoring sleep timers are started. DETAILED DESCRIPTION OF THE INVENTION

[0009] 5G NR system architecture and protocol stack 3GPP is working on the next release for fifth-generation cellular technology, simply called 5G, which includes the development of New Radio Access Technology (NR), which will operate in frequencies up to the 100 GHz range. The first version of the 5G standard was completed at the end of 2017, allowing for the advancement of trials and commercial deployment of smartphones compliant with the 5G NR standard.

[0010] In particular, the overall system architecture assumes a Next Generation-Radio Access Network (NG-RAN) that includes gNBs and provides NG radio access user plane (SDAP / PDCP / RLC / MAC / PHY) and control plane (RRC) protocol termination for UEs. The gNBs are interconnected with each other by an Xn interface. The gNBs are also connected to a Next Generation Core (NGC) by an NG (Next Generation) interface, and more specifically to an Access and Mobility Management Function (AMF) (e.g., a specific core entity that runs the AMF) by an NG-C interface and to a User Plane Function (UPF) (e.g., a specific core entity that runs the UPF) by an NG-U interface. The NG-RAN architecture is shown in Figure 1.

[0011] Various different deployment scenarios can be supported. For example, a decentralized deployment scenario is presented therein, in which base stations supporting 5G NR can be deployed. FIG. 2 illustrates an example decentralized deployment scenario and further illustrates an LTE eNB with user equipment (UE) connected to both the gNB and the LTE eNB. The new eNB for NR 5G can illustratively be referred to as a gNB. The eLTE eNB is an evolved version of the eNB that supports connectivity with the Evolved Packet Core (EPC) and Next Generation Core (NGC).

[0012] The NR user plane protocol stack includes a Packet Data Convergence Protocol (PDCP) sublayer, a Radio Link Control (RLC) sublayer, and a Medium Access Control (MAC) sublayer, which are terminated at the gNB on the network side. Additionally, a new Access Stratum (AS) sublayer (Service Data Adaptation Protocol, SDAP) is introduced on top of PDCP. A control plane protocol stack is also specified for NR.

[0013] 5G NR function split between NG-RAN and 5GC Figure 3 shows the functional division between NG-RAN and 5GC. The NG-RAN logical node is the gNB or ng-eNB. The 5GC has the above-mentioned logical nodes AMF, UPF, and SMF.

[0014] In particular, the gNB and ng-eNB host the following main functions: Functions for radio resource management, such as radio bearer control, radio admission control, connection mobility control, and dynamic allocation (scheduling) of resources to UEs in both uplink and downlink IP header compression, encryption, and data integrity protection AMF selection at UE attachment when routing to the AMF cannot be determined from information provided by the UE Routing user plane data to the UPF Routing of control plane information to AMF Setting up and disconnecting connections Scheduling and sending paging messages Scheduling and transmission of system broadcast information (originating from AMF or OAM) Measurement and measurement reporting configuration for mobility and scheduling Transport-level packet marking in the uplink Session management Network slicing support QoS flow management and mapping to data radio bearers Support for UEs in RRC_INACTIVE state NAS message distribution function Radio access network sharing Dual Connectivity · Close interaction between NR and E-UTRA

[0015] The Access and Mobility Management Function (AMF) hosts the following main functions: Non-Access Stratum (NAS), signaling termination NAS signaling security Access Layer (AS), security control Core Network (CN) inter-node signaling for mobility between 3GPP access networks Idle mode UE reachability (including control and execution of paging retransmissions) Registration area management Support for intra- and inter-system mobility Access authentication Access permissions, including roaming rights checks Mobility management controls (subscriptions and policies) Network slicing support Session Management Function (SMF), selection

[0016] Furthermore, the User Plane Function (UPF) hosts the following main functions: Anchor points for intra / inter-RAT mobility (if applicable) External PDU session points for interconnection to data networks Packet routing and forwarding Packet inspection and user plane portion of policy rule enforcement Traffic usage reporting Uplink classifier that supports routing of traffic flows to the data network Branching point supporting multi-homed PDU sessions QoS processing for the user plane, including packet filtering, gating, and UL / DL rate enforcement Uplink traffic validation (SDF to QoS flow mapping) Downlink packet buffering and downlink data notification trigger

[0017] Finally, the Session Management Function (SMF) hosts the following main functions: Session management UE IP address allocation and management ·UP function selection and control Configuring traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination Policy enforcement and QoS control parts Downlink data notification

[0018] RRC connection setup and reconfiguration procedures Figure 4 illustrates some interactions between the UE, gNB, and AMF (5GC entity) regarding RRC, which is an upper layer signaling (protocol) used for UE and gNB configuration. In particular, the AMF prepares UE context data (e.g., including PDU session context, security keys, UE radio capabilities, and UE security capabilities) and sends it to the gNB with an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security in the UE. This is performed by the gNB sending a SecurityModeCommand message to the UE, and the UE responding with a SecurityModeComplete message to the gNB. The gNB then performs reconfiguration to set up signaling radio bearer 2, SRB2, and data radio bearer, DRB, with RRCReconfiguration and RRCReconfigurationComplete. If only a connection is signaled, step 8 is skipped because SRB2 and DRB are not set up. Finally, the gNB notifies the AMF that the setup procedure is complete with an INITIAL CONTEXT SETUP RESPONCE.

[0019] Therefore, the present disclosure provides a fifth-generation core (5GC) entity (e.g., AMF, SMF, etc.) that includes: a control circuit that, during operation, establishes a next-generation (NG) connection with a gNodeB; and a transmitter that, during operation, sends an initial context setup message to the gNodeB over the NG connection to trigger a signaling radio bearer setup between the gNodeB and a user equipment (UE). Specifically, the gNodeB sends radio resource control (RRC) signaling, which includes a resource allocation configuration information element, to the UE over the signaling radio bearer. The UE then performs uplink transmission or downlink reception based on the resource allocation configuration.

[0020] IMT usage scenarios from 2020 onwards Figure 5 illustrates several use cases for 5G NR. 3GPP NR (3rd Generation Partnership Project new radio) considers three use cases that are envisioned to support a wide variety of services and applications via IMT-2020. Phase 1 specifications for enhanced mobile broadband (eMBB) have been completed. In addition to further extending eMBB support, current and future work will involve standardization for Ultra-reliable and Low Latency Communications (URLLC) and Massive Machine Type Communications. Figure 5 illustrates some examples of envisioned usage scenarios for IMT beyond 2020.

[0021] URLLC use cases have stringent requirements for capabilities such as throughput, latency, and availability, and are envisioned as one of the enablers for future vertical applications such as wireless control of industrial manufacturing or production processes, remote medical surgery, distribution automation in smart grids, and transportation safety. URLLC's high reliability is supported by identifying technologies that meet the requirements set by TR 38.913. For NR URLLC in Release 15, key requirements include a target user plane latency of 0.5 ms for the uplink (UL) and 0.5 ms for the downlink (DL). Typical URLLC requirements for a single transmission of a packet are a BLER (block error rate) of 1E-5 for a 32-byte packet size with a user plane latency of 1 ms.

[0022] From the RAN1 perspective, reliability can be improved in many possible ways. Current scope for improving reliability includes defining separate CQI tables for URLLC, more compact DCI formats, PDCCH repetition, etc. However, as NR becomes more stable and developed (for NR URLLC key requests), the scope for achieving high reliability may increase. Thus, the NR URLCC in Rel. 15 is capable of transmitting 32-byte data packets within 1 ms user-plane latency with a success probability corresponding to a BLER of 1E-5. Specific use cases for the NR URLCC in Rel. 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and mission-critical applications.

[0023] Additionally, technology enhancements targeted by NR URLCC aim to improve latency and reliability. Technology enhancements for latency improvement include configurable numerology, non-slot-based scheduling with flexible mapping, gratuitous (configured grant) uplink grants, slot-level repetition of data channels, and downlink preemption. Preemption means that a transmission with already allocated resources is stopped and the already allocated resources are used for another transmission requested later, but with lower latency and higher priority requirements. Therefore, an already granted transmission is preempted by a later transmission. Preemption is applicable regardless of the specific service type. For example, a transmission for service type A (URLCC) can be preempted by a transmission for service type B (eMBB, etc.). Technology enhancements for reliability improvement include dedicated CQI / MCS tables for a target BLER of 1E-5.

[0024] The mMTC use case is characterized by a very large number of connected devices, typically transmitting relatively small amounts of non-latency-sensitive data. The devices are required to be low cost and have very long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one possible solution that has power savings from the UE perspective and allows for long battery life.

[0025] Thus, it is expected that the reliability range for NR will expand. One key requirement for all cases, especially for URLLC and mMTC, is high or ultra-reliability. Several mechanisms can be considered to improve reliability from a radio perspective and a network perspective. In general, there are several key potential areas that can help improve reliability. Among these areas are compact control channel information, repetition of data / control channels, and diversity in terms of frequency, time, and / or space domains. These areas are generally applicable to reliability, regardless of the specific communication scenario.

[0026] For NR URLLC, further use cases with more stringent requirements have been identified, such as factory automation, transportation, and power supply, including power distribution. The more stringent requirements include higher reliability (up to the 10-6 level), higher availability, packet sizes up to 256 bytes, time synchronization up to a few microseconds, which can be 1 microsecond or a few microseconds depending on the frequency range, and low latency, on the order of 0.5-1 ms, depending on the use case, with a target user plane latency of 0.5 ms.

[0027] Additionally, for NR URLLC, several technology enhancements from a RAN1 perspective have been identified. Among these are PDCCH (Physical Downlink Control Channel) enhancements related to compact DCI, PDCCH repetition, and increased PDCCH monitoring. Furthermore, UCI (Uplink Control Information) enhancements are related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback enhancements. Also identified are PUSCH enhancements related to minislot-level hopping and retransmission / repetition enhancements. The term "minislot" refers to a transmission time interval (TTI) containing fewer symbols than a slot (a slot containing 14 symbols).

[0028] QoS Control The 5G QoS model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). Therefore, at the NAS level, QoS flows are the finest granularity of QoS differentiation in a PDU session. QoS flows are identified within a PDU session by a QoS Flow ID (QFI) carried in the encapsulation header on the NG-U interface.

[0029] For each UE, the 5GC establishes one or more PDU sessions. For each UE, the NG-RAN establishes at least one data radio bearer (DRB) with the PDU session; additional DRBs for that PDU session's QoS flow(s) may be configured subsequently (it is up to the NG-RAN when to do so), e.g., as shown above with reference to FIG. 4. The NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS-level packet filters in the UE and the 5GC associate UL and DL packets with QoS flows, while AS-level mapping rules in the UE and the NG-RAN associate UL and DL QoS flows with DRBs.

[0030] Figure 6 shows the 5G NR non-roaming reference architecture. Application Functions (AFs) interact with the 3GPP core network to provide services, such as supporting application influence on traffic routing, access to the Network Exposure Function (NEF), or interaction with the policy framework for policy control (see Policy Control Function, PCF). Based on the operator's deployment, application functions that are deemed trusted by the operator can interact directly with the relevant network functions. Application functions that the operator does not allow direct access to network functions interact with the relevant network functions using the external exposure framework via the NEF.

[0031] Figure 6 shows further functional units of the 5G architecture, namely, Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN), i.e., operator services, Internet access or third-party services.

[0032] In LTE and NR, the terminal is called a user equipment (UE). This may be a mobile device such as a wireless phone, a smartphone, a tablet computer, or a universal serial bus (USB) stick with user equipment functionality. However, the term mobile device is not limited thereto, and in general, a relay can also have the functionality of such a mobile device and can also act as a relay.

[0033] A base station is a network node that forms part of a network for providing services to terminals, for example. A base station is a network node that provides radio access to terminals. Communication between terminals and base stations is typically standardized. In LTE and NR, the radio interface protocol stack includes a physical layer, a medium access layer (MAC), and higher layers. In the control plane, the higher layer protocol Radio Resource Control Protocol is provided. Through RRC, the base station can control the configuration of terminals, and the terminals can communicate with the base station to perform control tasks such as connection and bearer establishment, modification, measurements, and other functions.

[0034] The services provided by a layer for transferring data to higher layers are usually called channels. For example, LTE and NR distinguish between logical channels, which are provided by the MAC layer to higher layers, transport channels, which are provided by the physical layer to the MAC layer, and physical channels, which define the mapping on physical resources.

[0035] Logical channels are the different types of data transfer services offered by the MAC. Each logical channel type is defined by the type of information it transfers. Logical channels are divided into two groups: control channels and traffic channels. Control channels are used only for the transfer of control plane information. Traffic channels are used only for the transfer of user plane information.

[0036] Logical channels are then mapped to transport channels by the MAC layer, for example, logical traffic channels and some logical control channels may be mapped onto a transport channel called the Downlink Shared Channel (DL-SCH) in the downlink and onto a transport channel called the Uplink Shared Channel (UL-SCH) in the uplink.

[0037] Scheduling 3GPP describes scheduling for NR-based operation (see, for example, 3GPP TR 38.321, NR; Medium Access Control (MAC) Protocol Specification, Version 15.4.0).

[0038] Scheduling is a central part of communication systems such as NR and / or LTE. The scheduler decides, for each instance, to which UEs a shared time-frequency resource is assigned. Uplink, downlink, and / or sidelink transmissions can be scheduled.

[0039] In particular, the uplink scheduler can be responsible for dynamically controlling which terminals should transmit on the uplink shared channel (UL-SCH). Each scheduled terminal is given a scheduling grant that includes a set of resources on which the terminal should transmit its UL-SCH.

[0040] In other words, the function of uplink scheduling is to dynamically determine the transmitting device and uplink resource. Dynamic scheduling is typically performed by the physical downlink control channel (PDCCH). The physical downlink control channel carries scheduling grants and other control information, which may also be called downlink control information (DCI). Each terminal (UE) monitors the PDCCH. This means that the UE (blindly) decodes specific resources, called search spaces. The PDCCH search space is an area in the downlink resource grid where the PDCCH can be carried. The UE performs blind decoding in these search spaces to try to find the PDCCH data (DCI). To decode the PDCCH, the UE applies its own Radio Network Temporary Identity (RNTI) and attempts to decode the PDCCH in resources called control channel elements (CCEs). If the decoding is successful (which can be checked by an error detection code such as a cyclic redundancy check), the DCI is received. The UE can also blindly try various parameter values ​​for some selected transmission parameters. Each terminal may monitor more than one PDCCH, which may be common to a group of UEs (in which case the UEs use a common group RNTI) or may be dedicated to a particular UE.

[0041] The standard (LTE or NR) defines several different formats for DCI. These formats differ from each other depending on their purpose. For example, a format carrying an uplink grant (such as format 0 or 4) differs from a format carrying a downlink grant or no grant at all. Also, these are different formats defined depending on the use of beamforming, broadcast / multicast, etc.

[0042] Correspondingly, in the uplink, physical layer control information is transmitted by the Physical Uplink Control Channel. The PUCCH carries a set of parameters called UCI (Uplink Control Information), which is similar to the PDCCH that carries DCI mentioned above. Depending on the type of information carried by the UCI in the PUCCH, the PUCCH is also available in different formats. For example: Format 1 to carry the scheduling request SR Format 4 carries SR along with channel state information (CSI) Format 3 carries SR along with HARQ response (positive or negative) and CSI These are further formats defined by LTE and / or NR.

[0043] The basis for uplink scheduling is a scheduling grant, which involves providing device information about resources and associated transport formats to use for transmitting the UL-SCH. In other words, a DCI having a certain format (e.g., defined in a standard) may carry a resource allocation (RA) corresponding to the resource grant, as well as some further transmission parameters such as modulation and coding scheme (MCS), settings for multiple input multiple output (MIMO) transmission, etc.

[0044] If a terminal has a valid grant, the terminal is allowed to transmit its corresponding UL-SCH mapped onto the physical uplink shared channel (PUSCH) specified by the resource allocation.

[0045] That is, the scheduler needs knowledge of terminals that have data to transmit and therefore needs to schedule uplink resources. There is no need to provide uplink resources to devices that have no data to transmit. This allows devices to perform padding and fill the granted resources. Therefore, the scheduler needs to know whether a device has data to transmit or not and needs to grant permission.

[0046] Scheduling Request Scheduling requests may be used for terminals that do not have a valid scheduling grant. Scheduling requests may be transmitted on the physical uplink control channel, PUCCH. Each terminal may be assigned a dedicated scheduling request resource that occurs every nth subframe. A scheduling request may be a simple flag generated (set) by the terminal to request uplink resources from the uplink scheduler. With a dedicated scheduling request mechanism, the identity of the requesting terminal does not need to be provided with the scheduling request, as it is implicit from the resource on which the request is sent. These are configured by a scheduling node, such as a gNB, for example, by a higher layer control protocol.

[0047] Upon receiving the scheduling request, the scheduling device can allocate a scheduling grant to the terminal. Once the terminal receives the scheduling grant, it transmits its data on the scheduled resources. The data transmitted on the PUSCH may first include a buffer status that informs the scheduling node of the amount of data the UE has to transmit. Based on the buffer status, the scheduling node can then schedule the actual data resources on the PUSCH. However, this is only optional, and in general, data resources may also be scheduled directly. In some systems, it is also possible to associate a scheduling request with a specific amount of data that is requested to be scheduled.

[0048] If the terminal does not receive a scheduling grant until the next available time instant, the scheduling request may be repeated.

[0049] Thus, a contention-free scheduling request mechanism on the PUCCH is provided, where each terminal in the cell is given reserved resources on which it can transmit requests for uplink resources.

[0050] A UE MAC entity can be configured with zero, one, or multiple SR configurations. An SR configuration consists of a set of PUCCH resources for scheduling requests across different Bandwidth Parts (BWPs). For logical channels (LCHs), at most one SR PUCCH resource is configured per BWP. Each SR configuration corresponds to one or more logical channels. The mapping between logical channels and SR configurations can be configured by Radio Resource Control (RRC) messaging.

[0051] As mentioned above, if a normal buffer status report (BSR) is triggered but uplink radio resources for transmitting the BSR are unavailable to the UE, an SR procedure may be initiated. During the SR procedure, the UE can either transmit the SR via PUCCH or initiate a random access (RA) procedure, depending on whether the UE is configured with PUCCH resources for SR. The RA procedure is initiated only if PUCCH resources for SR are not configured.

[0052] If the UE MAC entity has an SR transmission position on a valid PUCCH resource for the configured SR, the physical layer (PHY) is instructed to signal the SR on one valid PUCCH resource for the SR. The SR prohibit timer then starts (SR_prohibitTimer). At the time of the consecutive SR transmission opportunity, the MAC does not instruct the PHY to signal the SR if the SR prohibit timer is running.

[0053] In NR, SR resources are configured with a specific periodicity. When an SR is transmitted by the UE, an SR inhibit timer is started, and no SRs are transmitted on already configured resources as long as the SR inhibit timer is running.

[0054] The scheduling request configuration information element used to configure the scheduling request is defined in 3GPP TS 38.331 (“NR; Radio Resource Control (RRC); Protocol Specification”, Version 15.4.0, Section 6.3.2) and is shown below.

[0055] [Table 1]

[0056] In particular, the scheduling request prohibit timer is set by SR-ProhibitTimer and indicates the duration during which no scheduling requests are sent after sending an SR, even if no scheduling grant has been received. The maximum number of scheduling requests is defined by SR-TransMax. SR-ProhibitTimer and SR-TransMax are provided to the UE by the scheduling node, e.g., via RRC signaling.

[0057] When the prohibit timer (SR-ProhibitTimer) is active, no further SRs will be initiated. The SR-ProhibitTimer is per SR setting and can be set to a value ranging from 1ms to 128ms.

[0058] For example, if the gNB sets the SR-ProhibitTimer to 32 ms, the gNB can allocate uplink resources within 32 ms after receiving an SR, and the UE must monitor the PDCCH for a maximum of 32 ms after transmitting an SR.

[0059] Discontinuous Reception - DRX Packet data is often very bursty, with occasional periods of silence. From a latency perspective, it is beneficial to permanently monitor downlink control signaling in order to receive uplink grants or downlink data transmissions and react immediately to changes in traffic behavior. At the same time, this is costly in terms of power consumption in devices. To reduce device power consumption, LTE includes a mechanism for discontinuous reception (DRX).

[0060] The basic mechanism of DRX is a configurable DRX period within the device. When the DRX period is set, the device monitors downlink control signaling only for the active period per DRX cycle and sleeps with the receiver circuitry turned off during the remaining inactive periods. This allows for a significant reduction in power consumption. Naturally, this imposes limitations on the scheduler, as the device can only respond during the active periods.

[0061] The DRX period may be configured in the LTE downlink such that the UE does not need to decode physical downlink control channel (PDCCH) or receive physical downlink shared channel (PDSCH) transmissions for a certain period of time, e.g., by periodically switching off the receiver as defined for connected mode in 3GPP TS 36.321 (“Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Protocol Specification”, version 15.5.0, section 5.7), and as defined for idle mode in 3GPP TS 36.304 (“Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Procedures in Idle Mode”, version 15.3.0, section 7.1).

[0062] According to the 3GPP TS 38.321 v15.5.0 specification, when a DRX period is configured, the active time includes the time during which the drx-onDurationTimer, drx-InactivitTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, or ra-ContentionResolutionTimer is running, as described in section 5.1.5 of 3GPP TS 38.321.

[0063] The drx-onDurationTimer defines the duration at the start of a DRX period, and the drx-InactivitTimer specifies the duration after a PDCCH opportunity where the PDCCH indicates a new uplink (UL) or downlink (DL) transmission for the MAC entity. The drx-RetransmissionTimerDL and UL define the maximum duration before receiving a DL retransmission and a grant for a UL retransmission, respectively.

[0064] Additionally, the active time includes the time during which no PDCCH indicating a new transmission addressed to the MAC entity's cell radio network temporary identifier (C-RNTI) has been received after successful reception of a random access response to a contention-based random access preamble that has not been selected by the MAC entity, as described in section 5.1.4 of 3GPP TS 38.321 v15.5.0.

[0065] As mentioned above, the scheduling request procedure is used by the UE to request radio resources for a new uplink transmission. In particular, as described in section 5.4.4 of 3GPP TS 38.321 v15.5.0, while a scheduling request is transmitted and pending, the PDCCH is monitored for scheduling assignments.

[0066] That is, the PDCCH is monitored when an SR is transmitted on the PUCCH and is pending. Figure 7 is a diagram that schematically illustrates active and inactive times (on and off periods) according to a configured DRX period (solid line) and active time according to a pending scheduling request (dashed line). In Figure 7, time is shown on the horizontal axis. As soon as an SR is transmitted on the PUCCH, the UE starts monitoring the PDCCH for uplink grants for scheduling data to be transmitted, as indicated by the arrow labeled "SR" in Figure 7.

[0067] However, the UE may not be scheduled immediately after transmitting a scheduling request. Figures 8A and 8B are diagrams that schematically illustrate active and inactive times according to a configured DRX period and active times according to a pending scheduling request. In the diagrams, the time when an uplink grant (UL grant) is received is indicated by the arrow labeled "UL grant." As long as an SR is pending, the PDCCH is monitored for an UL grant.

[0068] In the situation shown in Figure 8B, the UL grant is received at a later time point after the SR transmission than in the situation shown in Figure 8A. This may be the case when the scheduling device prioritizes the scheduling of the UL grant based on the priority and traffic load of the associated logical channel.

[0069] As a result, the UE consumes power when monitoring the PDCCH during periods when the gNB does not intend to schedule an UL grant to the UE. This period is shown as the hatched area in Figures 8A and 8B. During periods when no UL grants are transmitted, the UE monitors the PDCCH and therefore consumes power.

[0070] The present disclosure provides techniques that can facilitate an adjusted monitoring duration within the framework of an SR procedure. In particular, the present disclosure provides an SR procedure within a set DRX period to reduce power consumption of a UE.

[0071] The present disclosure provides a transceiver and a scheduling device as shown in FIG.

[0072] The transceiver 100 includes a transceiver 110 (a transmitter and / or receiver including hardware components such as one or more antennas and control circuitry for controlling the operation of the hardware components), which, during operation, transmits a scheduling request for scheduling data via a physical uplink control channel PUCCH. The transceiver 100 also includes a circuit 120 (or processing circuitry) which, during operation, starts a monitoring sleep timer after the transceiver 110 transmits the scheduling request. Furthermore, during operation, the transceiver 110 does not monitor a physical downlink control channel PDCCH while the monitoring sleep timer is running, and starts monitoring the PDCCH for resource allocation for scheduling data when the monitoring sleep timer expires.

[0073] For example, the transceiver 100 is a UE in an NR network. Therefore, the transceiver 110 and the circuitry 120 are also referred to as a “UE transceiver” and “UE circuitry,” but these terms are merely used to distinguish the transceiver 110 and the circuitry 120 from circuits and transceivers configured by other devices, such as a scheduling device or a base station; the transceiver 100 may be a terminal service, relay device, or similar communication device of a communication system, and the UE circuitry may be considered to “monitor a sleeping control circuit” or to include a “sleeping control circuit.”

[0074] Further, a scheduling device 200 (or scheduling node) is provided as shown in FIG.

[0075] The scheduling apparatus 200 comprises a circuit 220 for, during operation, allocating resources according to a scheduling request for scheduling data and starting a transmission timer. The scheduling apparatus 200 further comprises a transceiver 210 for, during operation, receiving a scheduling request via a physical uplink control channel PUCCH and transmitting, after expiration of the transmission timer, a resource allocation indicator indicative of the allocated resources via a physical downlink control channel PDCCH.

[0076] For example, the scheduling device 200 is a network node (base station) in a NR network system (gNB) or a similar communication system. The circuit 220 is also referred to as a "scheduling request control circuit" or a "scheduling device circuit" to distinguish it from circuits such as the UE circuit 120.

[0077] Further provided is a method including the steps of transmitting a scheduling request for the scheduling data over a physical uplink control channel PUCCH and starting a monitoring sleep timer after transmitting the scheduling request, the method further including the steps of ceasing monitoring of a physical downlink control channel PDCCH while the monitoring sleep timer is running and starting monitoring of the PDCCH for resource allocation for the scheduling data if the monitoring sleep timer expires.

[0078] Further provided is a method comprising receiving a scheduling request for scheduling data via a physical uplink control channel PUCCH and starting a transmission timer, the method further comprising allocating resources according to the scheduling request and transmitting, after expiration of the transmission timer, a resource allocation indicator indicating the allocated resources via a physical downlink control channel PDCCH.

[0079] In the further description, details and embodiments apply to the transceiver device 100, the scheduling device 200 (or scheduling node), and the method, respectively, unless an explicit statement or context indicates otherwise.

[0080] The transceiver 100 transmits, using the transceiver 110, a scheduling request for transmission of scheduling data via the PUCCH, and uses the UE circuitry 120 to start a monitoring sleep timer after the SR is transmitted. While the monitoring sleep timer is running, the transceiver 110 does not monitor the PDCCH to receive an UL grant corresponding to the transmitted SR. After the monitoring sleep timer expires, the transceiver 110 starts monitoring the PDCCH to receive an UL grant according to the transmitted SR. The UL grant indicates the resources allocated for transmission of the scheduling data.

[0081] When the DRX cycle is configured, the UE (or particularly the transceiver) monitors the PDCCH during the active period and does not monitor the PDCCH during the inactive period, the time sequence being schematically shown in FIG.

[0082] According to one embodiment, when the SR is transmitted, a monitoring sleep timer is started and when the monitoring sleep timer expires the transceiver 110 starts monitoring the PDCCH for an UL grant from the scheduling device 200. That is, according to this embodiment the monitoring sleep timer is started when a scheduling request is transmitted by the transceiver 110.

[0083] This procedure reduces the UE's power consumption since the active time of the UE monitoring the PDCCH is reduced by a running monitoring sleeping timer during the period when an SR is pending but the scheduling device does not intend to send an UL grant.

[0084] FIG. 11 is a flow chart illustrating the transmission of a scheduling request and the initiation of monitoring the physical downlink control channel after the monitoring sleep timer expires, according to one embodiment.

[0085] After the procedure starts, in step S100, it is determined whether the DRX mode is set, i.e., whether the UE is in the DRX mode. If it is determined that the UE is not in the DRX mode (step S100, NO), the procedure is repeated from the beginning. If it is determined that the UE is in the DRX mode (step S100, YES), the procedure continues to step S110.

[0086] In step S110, it is determined whether an SR has been transmitted. For example, as shown in Fig. 9, it is determined whether the transceiver 110 has transmitted a scheduling request for the scheduling data to be transmitted to the scheduling device 200 via the PUCCH. If a scheduling request has not been transmitted (step S110, NO), step S110 is repeated. If it is determined that an SR has been transmitted (step S110, YES), the process proceeds to step S120.

[0087] In step S120, a monitoring sleep timer is started. For example, as shown in Fig. 9, the circuit 120 of the transceiver device 100 starts the monitoring sleep timer. For example, the runtime of the monitoring sleep timer may be defined by a duration or an offset with respect to a particular symbol or slot of the PDCCH, as will be described below. The runtime of the monitoring sleep timer may also be set according to the configuration of the scheduling request, as will be described below. While the monitoring sleep timer is running, i.e., has not expired, the PDCCH is not monitored for UL grants for scheduling data.

[0088] In step S130, it is determined whether the monitoring sleep timer has expired. If the monitoring sleep timer has not expired (step S130, NO), the process proceeds to step S130, where it is repeatedly determined whether the monitoring sleep timer has expired. If the monitoring sleep timer has expired (step S130, YES), the process proceeds to step S140.

[0089] In step S140, start monitoring the PDCCH to receive a resource allocation (UL grant) for the scheduling data corresponding to the scheduling request sent in step S110.

[0090] As described above, the runtime of the monitoring sleep timer can be set individually according to the priority of the service, i.e., the value of the monitoring sleep timer can be set individually in each SR configuration, i.e., the runtime of the monitoring sleep timer is set according to the priority level of the scheduling request configuration.

[0091] For example, the monitoring sleep timer runtime may set a value for the SR setting of the first level priority to a value that is less than the value for the SR setting of the second level priority, which is a value that is less than the first level priority.

[0092] In other words, a high priority, low latency SR can set a relatively small runtime for the monitoring sleep timer, and a low priority, high latency SR can set a relatively large runtime for the monitoring sleep timer, in which case power savings are less for higher priority, lower latency services than for lower priority, higher latency services.

[0093] As described above, after the SR is transmitted by the transceiver 110, the UE circuitry 120 applies the runtime of the monitoring sleep timer corresponding to the SR setting.

[0094] As shown in Figure 12, a first monitoring sleep timer runtime may be set for a first logical channel, and a second monitoring sleep timer runtime may be set for a second logical channel. Therefore, different logical channels may have different monitoring sleep timer runtimes. In particular, a larger monitoring sleep timer runtime may be set for a lower priority logical channel than a higher priority logical channel, or vice versa. As shown in Figure 12, LCH1 and LCH2 are mapped to different SR settings because LCH1 and LCH2 have different levels of priority.

[0095] In Figure 12, the mapping of the runtime of the monitoring sleep timer is shown for two logical channels, but this embodiment is not limited to this, and different runtimes of the monitoring sleep timer may be set for multiple logical channels / SR settings.

[0096] For example, as shown in FIG. 13, two logical channels (LCH1 and LCH2) with the same level of priority are mapped to one SR setting, and one runtime of the monitoring sleep timer is mapped to the SR setting.

[0097] Although Figures 12 and 13 show either a one-to-one mapping of runtime SR settings and logical channels, or a mapping of multiple logical channels to one SR setting, this embodiment is not limited to this, and a combination of mapping one SR setting to multiple logical channels and mapping one SR setting to one logical channel can be applied.

[0098] According to one embodiment, the runtime of the monitoring sleep timer is fixed, and the network / scheduling device 200 and the transceiver device 100 map each SR setting to a predefined runtime of the monitoring sleep timer. In particular, the mapping may depend on the logical channel (SR) priority, so that it is defined which logical channel corresponds to which runtime of the monitoring sleep timer. With this approach, no additional signaling is required.

[0099] For example, Table 1 shows fixed values ​​in the specification. Note that for scheduling request identifiers 0 to 7, the runtime of the monitoring sleep timer is indicated by a symbol (sym) or slot (sl) offset as shown in Table 1. For example, for scheduling request identifier 5, the transceiver 110 does not monitor the PDCCH for an 8-slot UL grant. Alternatively, the runtime of the monitoring sleep timer may be configured in terms of a duration, for example, a duration between 0 and 256 ms.

[0100] [Table 2]

[0101] For example, if logical channel LCH1 is mapped to SR setting 1 and a scheduling request is triggered by LCH1, MAC passes schedulingRequestID information to PHY to send the scheduling request. If the SR setting of LCH1 is associated with schedulingRequestID5, the UE applies a monitoring sleep timer runtime of 8 ms.

[0102] The scheduling request configuration may be received by the transceiver apparatus 100 via a scheduling request configuration indicator indicating at least one scheduling request configuration with at least one associated priority level.

[0103] For example, the transceiver 110 may receive the scheduling request configuration indicator via a radio resource control (RRC) message.

[0104] According to one embodiment, the network signals the monitoring sleep timer runtime for each SR configuration so that the monitoring sleep timer runtime can be dynamically configured. For example, the monitoring sleep timer runtime can be signaled via either an RRC message, a system information message, or a dedicated RRC message. In this approach, the network can take into account the current traffic load and change the runtime via an RRC message.

[0105] For example, the scheduling request configuration information element for RRC signaling that can be used to configure the scheduling request is shown below.

[0106] [Table 3]

[0107] In particular, the monitoring sleep timer is set by a timer / offset, which indicates the runtime of the monitoring sleep timer in terms of symbols of a slot of the PDCCH.

[0108] According to one embodiment, the network / gNB200 may determine the runtime of the monitoring sleep timer and transmit the determined runtime to the UE100 if it is not intended to schedule UL resources after a scheduling request for scheduling data is received.

[0109] For example, a MAC Control element indicating the runtime of the monitoring sleep timer may be transmitted to carry timing related information in a bitmap format.

[0110] In LTE, for example, the MAC layer can insert so-called MAC Control Elements (MAC CEs) into transport blocks transmitted over transport channels, which are used for in-band control signaling, such as timing advance commands or random access responses.

[0111] However, according to the present disclosure, the MAC CE can carry information regarding the runtime of the monitoring sleep timer, and the MAC CE can indicate, for example, a duration ranging from 0 to 256. The time unit of the length can be a duration (ms) or a number of symbols or slots.

[0112] 14 is a schematic diagram of a MAC Control Element, CE, indicating the runtime of a monitoring sleep timer according to one embodiment. For example, if the UE 100 receives a MAC CE command indicating "0 0 0 0 1 0 0 0", the UE will not monitor the 8 ms or 8 slots of scheduling resources of the PDCCH.

[0113] FIG. 15 is a diagram illustrating a time sequence of transmitting a scheduling request, receiving a monitoring sleep indicator, and receiving an uplink grant, aligned with an active period, according to one embodiment. Specifically, the transceiver 110 transmits a scheduling request for scheduling data and monitors the PDCCH for an UL grant. When a MAC CE indicating the runtime of the monitoring sleep timer is received (shown as an arrow indicating "MAC CE"), the circuit 120 starts a monitoring sleep timer having an associated runtime according to the runtime indicated by the received MAC CE. As long as the monitoring sleep timer is running, the transceiver 110 does not monitor the PDCCH for a scheduling assignment of the scheduling data corresponding to the transmitted scheduling request. When the monitoring sleep timer expires, the transceiver 110 starts monitoring the PDCCH for an UL grant.

[0114] That is, the transceiver 110 receives a monitoring sleep indicator (eg, MAC CE) that indicates the runtime of the monitoring sleep timer, and the circuit 120 starts the monitoring sleep timer when the monitoring sleep indicator is received by the transceiver.

[0115] In this approach, the transceiver 110 of the transceiver device 100 does not monitor the PDCCH for a period having a duration indicated by the received MAC CE. Thus, power savings for the UE can be achieved in a more dynamic manner by considering both the traffic load and the SR priority.

[0116] FIG. 16 is a flowchart illustrating the sending of a scheduling request, receiving a monitoring sleep indicator, and initiating monitoring of the physical downlink control channel after the monitoring sleep timer expires.

[0117] After the process starts, in step S200, it is determined whether the DRX mode is set, i.e., whether the UE is in the DRX mode. If it is determined that the UE is not in the DRX mode (step S200, NO), the process is repeated from the beginning. If it is determined that the UE is in the DRX mode (step S200, YES), the process continues to step S210.

[0118] In step S210, it is determined whether an SR has been transmitted. For example, it is determined whether the transceiver 110 has transmitted a scheduling request for the scheduling data to be transmitted to the scheduling device 200 via the PUCCH. If a scheduling request has not been transmitted (step S210, NO), step S210 is repeated. If it is determined that an SR has been transmitted (step S210, YES), the process continues to step S220.

[0119] In step S220, monitoring of the PDCCH is started. In step S230, it is determined whether or not a MAC CE indicating the runtime of the monitoring sleep timer has been received. If a MAC CE indicating the runtime has not been received (step S230, NO), monitoring of the PDCCH is repeated. If a MAC CE indicating the runtime of the monitoring sleep timer has been received (step S240, YES), processing continues to step S240.

[0120] In step S240, a monitoring sleep timer is started, having a runtime corresponding to the runtime indicated by the MAC CE. Furthermore, monitoring of the PDCCH is terminated. That is, the PDCCH is not monitored, for example, by the transceiver 110, while the monitoring sleep timer is running, i.e., has not expired.

[0121] In step S250, it is determined whether the monitoring sleep timer has expired. If the monitoring sleep timer has not expired (step S250, NO), it is repeatedly determined in step S250 whether the monitoring sleep timer has expired. If the monitoring sleep timer has expired (step S250, YES), processing continues to step S260.

[0122] In step S260, start monitoring the PDCCH to receive a resource allocation (UL grant) for the scheduling data corresponding to the transmitted scheduling request.

[0123] According to this embodiment, the runtime of the monitoring sleep timer is transmitted by the scheduling apparatus 200 using a MAC control element. However, the present disclosure is not limited to transmission using a MAC CE, and the runtime of the monitoring sleep timer may be transmitted by another means. In particular, the scheduling apparatus 200 may transmit a monitoring sleep indicator indicating the runtime of the monitoring sleep timer, and the UE circuit 120 may start the monitoring sleep timer when the monitoring sleep indicator is received.

[0124] Of course, it is also possible to receive an UL grant over the PDCCH without receiving a monitoring sleep indicator, in which case monitoring of the PDCCH with pending scheduling requests becomes unnecessary.

[0125] Furthermore, according to the above-described embodiments, the monitoring sleep timer may be started when a scheduling request is sent or when a monitoring sleep indicator is received, for example, by a MAC CE.

[0126] In a first example, instead of starting monitoring of the PDCCH immediately after transmitting a scheduling request, a monitoring sleep timer is started and monitoring starts after it expires.

[0127] In a second example, when a scheduling request is transmitted, monitoring of the PDCCH is initiated, and when a monitoring sleep indicator is received, monitoring of the PDCCH is suspended for a duration corresponding to the runtime indicated by the monitoring sleep indicator.

[0128] However, the present disclosure is not limited to any one of the above embodiments. In particular, monitoring of the PDCCH cannot be performed between the transmission of the SR and the expiration of the monitoring sleep timer, and between the reception of the monitoring sleep indicator and the expiration of the respective monitoring sleep timer. In other words, the methods of the above examples may be combined.

[0129] This is shown in Figure 17, where the hatched area indicates the period during which the PDCCH is not monitored due to the monitoring sleep timer that was started when the SR was transmitted. Also, if a MAC CE is received indicating the runtime of the monitoring sleep timer, the monitoring sleep timer may be started again with the received runtime, or a second monitoring sleep timer may be started so as not to monitor the PDCCH within the period indicated by the MAC CE.

[0130] In this case, it should be noted that a monitoring sleep timer according to one or more embodiments may be restarted or re-initiated by circuit 120. In other words, if a monitoring sleep timer is running, the monitoring sleep timer may be restarted or the remaining or total runtime of the monitoring sleep timer until expiration may be adjusted. Alternatively or additionally, additional monitoring sleep timers may be started.

[0131] The scheduling device 200 according to an embodiment may determine the runtime of the monitoring sleep timer and transmit a monitoring sleep indicator indicating the runtime of the monitoring sleep timer using the transceiver 210. In particular, the runtime of the transmission timer may correspond to the runtime of the monitoring sleep timer.

[0132] Furthermore, in the above embodiment, it is determined whether a DRX cycle is set for the transceiver device 100. However, the present disclosure is not limited to determining whether a DRX cycle is set. In particular, the set DRX cycle is not an essential requirement for starting the monitoring sleep timer and not monitoring the PDCCH as long as the monitoring sleep timer is running.

[0133] The present disclosure further provides an SR procedure at a set DRX period to reduce power consumption of a UE.

[0134] 9, the transceiver 100 includes a transceiver 110 (a transmitter and / or receiver including hardware components such as one or more antennas and control circuitry for controlling the operation of the hardware components), which transmits a buffer status report indicating an amount of scheduling data during operation. The transceiver 100 also includes a circuit 120 (or processing circuitry), which starts a monitoring sleep timer during operation after the transceiver 110 transmits the buffer status report. Furthermore, the transceiver 110 does not monitor a PDCCH, which is a physical downlink control channel, during the monitoring sleep timer is running, and starts monitoring the PDCCH for resource allocation for scheduling data when the monitoring sleep timer expires.

[0135] Further, a scheduling device 200 (or scheduling node) is provided as shown in FIG.

[0136] The scheduling apparatus 200 comprises a circuit 220 for allocating resources according to a buffer status report indicating an amount of scheduling data and for starting a transmission timer during operation. The scheduling apparatus 200 further comprises a transceiver 210 for receiving the buffer status report during operation and transmitting a resource allocation indicator indicating the allocated resources via a physical downlink control channel, PDCCH, after the transmission timer has expired.

[0137] Further provided is a method including the steps of transmitting a buffer status report indicating the amount of scheduling data, and starting a monitoring sleep timer after transmitting the buffer status report. The method further includes the steps of ceasing monitoring of a PDCCH, which is a physical downlink control channel, while the monitoring sleep timer is running, and starting monitoring of the PDCCH for resource allocation for the scheduling data if the monitoring sleep timer expires.

[0138] Further provided is a method comprising the steps of receiving a buffer status report indicating an amount of scheduling data and starting a transmission timer, the method further comprising the steps of allocating resources in response to the buffer status report and transmitting, after expiry of the transmission timer, a resource allocation indicator indicating the allocated resources via a physical downlink control channel, PDCCH.

[0139] The buffer status report, BSR, may be a MAC (Medium Access Control) level message sent by the UE 100 to the serving gNB as the scheduling device 200 to provide the gNB with information about the amount of data in the uplink buffer of the UE 100 (see 3GPP TS 36.321 ("Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Protocol Specification", version 15.5.0, section 5.4.5)).

[0140] The BSR is reported in the uplink, with BSR reporting per logical channel group (LCG), to inform the gNB 200 about the amount of buffered data in the UE 100 and allow the gNB 200 to distinguish between data with different scheduling priorities, where each LCG may be associated with a respective priority level.

[0141] An LCG is a group of uplink logical channels, or for which a single joint buffer fill level is reported by the UE 100 in the BSR. The mapping of the LCG may be defined by the gNB 200 (3GPP TS 36.321 (“Evolved Universal Terrestrial Radio Access (E-UTRA)); Medium Access Control (MAC) Protocol Specification,” version 15.5.0, section 6.1.3.1, and 3GPP TS 36.331 (“Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification”), version 15.5.1, section 6.3.2). An LCG may be defined as a group of logical channels with similar Quality of Service (QoS) requirements.

[0142] Buffer status reporting can be performed per LCG by using either the long BSR format or the short BSR format, as shown in Figures 18A and 18B, respectively. Figure 18A illustrates the short BSR format, in which the group of logical channels for which the buffer status is being reported is indicated by a 3-bit logical channel group ID field. The buffer size field indicates the total amount of data. According to the long BSR format shown in Figure 18B, the BSR includes multiple buffer size fields, each representing one LCG. In other words, the short BSR format is used to report the data volume of one designated logical channel group, and the long BSR format is used to report the data volume of all logical channel groups. For example, a network can configure up to eight logical channel groups per UE depending on Quality of Service (QoS) requirements.

[0143] When the BSR is transmitted during the DRX off period, the UE may switch to the DRX active time where the PDCCH is monitored to receive an uplink grant, as shown in Figure 19.

[0144] However, monitoring the PDCCH by entering the DRX active time due to the transmission of a BSR may result in unnecessary power consumption because the UE 100 may not be scheduled immediately after transmitting the BSR. In other words, if the gNB 200 does not intend to schedule resources to the UE 100, for example, if the scheduling of UL grants is based on the priority level of the BSR and traffic load, the UE 100 may unnecessarily monitor the PUCCH for uplink grants. For example, as shown in Figures 20A and 20B, a higher priority of a BSR transmission may result in a shorter PDCCH monitoring period than a lower priority of a BSR transmission, resulting in a longer PDCCH monitoring period.

[0145] Thus, the transceiver 100 uses the transceiver 110 to transmit a BSR indicating the amount of scheduling data, and uses the UE circuitry 120 to start a monitoring sleep timer after the BSR is transmitted. While the monitoring sleep timer is running, the transceiver 110 does not monitor the PDCCH to receive an UL grant corresponding to the transmitted SR. After expiration of the monitoring sleep timer, the transceiver 110 starts monitoring the PDCCH to receive an UL grant according to the transmitted BSR, where the UL grant indicates resources allocated for transmission of the scheduling data.

[0146] The time sequence is shown schematically in Figure 21, where the UE (or specifically the transceiver) monitors the PDCCH during the active period and does not monitor the PDCCH during the inactive period. Specifically, after transmitting the BSR, a monitoring sleep timer is started, and when the timer expires, the UE 100 switches to the active time, where the PDCCH is monitored for uplink grants. In other words, the switch from not monitoring the PDCCH to monitoring the PDCCH is delayed by a time offset from the transmission of the BSR.

[0147] Figure 22 shows a method performed by the UE 100. Steps S300, S310, S330 and S340 correspond to the method shown in Figure 11, where a buffer status report is sent instead of a scheduling request SR. In step S320, a monitoring sleep timer is started at runtime according to the logical channel group LCG.

[0148] For example, a runtime can be configured for each LCG, e.g., a higher priority LCG can have a shorter runtime for the monitoring sleep timer compared to an LCG associated with a lower priority LCG.

[0149] The mapping of the LCG and the runtime of the monitoring sleep timer may be predefined, for example according to a definition given in a specification, or may be dynamically configured, for example via RRC.

[0150] Table 2 shows, as an example, fixed values ​​for the runtime of the monitoring sleep timer. As shown in the table, the runtime of the monitoring sleep timer is indicated by X1 to X10 associated with LCGs with identifiers ID0 to 7, respectively. For example, if the priority is lowered from LCG ID0 to LCG ID7, the runtime of the monitoring sleep timer may increase from X1 to X10. In other words, the runtime of the monitoring sleep timer may be larger the lower the level of the associated LCG. If the runtime / offset is predefined, no additional signaling is required.

[0151] [Table 4]

[0152] Alternatively or additionally, the runtime of the monitoring sleep timer may be dynamically configured, for example, by RRC. By dynamically configuring the mapping between LCG ID and offset value / timer runtime, the network can take into account traffic load and traffic priority and change the timer runtime / offset value as needed via RRC (e.g., via a system information message or a dedicated RRC message).

[0153] For example, the logical channel configuration information element for RRC signaling that can be used is shown below.

[0154] [Table 5]

[0155] In particular, the runtime of the monitoring sleep timer is indicated by the LogicalChannelGroupOffset in each logical channel group.

[0156] If the BSR indicates multiple amounts of scheduling data associated with different LCGs, the runtime of the monitoring timer may be set to the runtime associated with the highest priority logical channel group, in which case the amount of scheduling data is indicated to the BSR. Alternatively, the runtime of the monitoring sleep timer may be set to the runtime associated with the LCG with the smallest LCG ID. Alternatively, the runtime of the monitoring sleep timer may be set to the shortest runtime associated with the LCG, in which case the amount of scheduling data is indicated to the BSR.

[0157] In summary, according to an embodiment of the present disclosure, a transceiver device such as the UE 100 transmits a scheduling request or a buffer status report and then starts a dedicated timer, a monitoring sleep timer. Unless this timer has expired, the UE 100 does not monitor the PDCCH for the reception of an uplink grant. Once the timer has expired, the UE starts monitoring the PDCCH. This can allow for a reduction in energy consumption, as the UE 100 does not monitor the PDCCH while no scheduling grant is expected.

[0158] The monitoring sleep timer may be started after transmitting only a scheduling request, or after transmitting only a buffer status report, or after transmitting a scheduling request and a buffer status report. In the last case, the runtime of the timer started after transmitting an SR may be equal to the runtime of the timer started after transmitting a BSR. However, the present disclosure is not limited in this respect, and the runtime of the timer started after transmitting an SR may be different from the runtime of the timer started after transmitting a BSR.

[0159] FIG. 23A shows an example of a scheduling request procedure in which an SR and a BSR are transmitted from UE100 to gNB200. In step 1, UE100 transmits a scheduling request to gNB200 via PUCCH. Furthermore, in step 2, UE100 receives a scheduling grant from the gNB indicating resources for transmitting scheduling data. In step 3, UE100 transmits a buffer status report to gNB200 using the indicated resources of the PUSCH. In step 4, UE100 receives a scheduling grant for transmission of scheduling data from gNB200. In step 5, UE100 transmits the scheduling data using the resources indicated by the received uplink grant.

[0160] 23B, according to the present disclosure, after transmitting the SR via the PUCCH, the UE 100 starts a monitoring sleep timer and does not monitor the PDCCH for receiving an uplink grant while the timer has not expired, i.e., for a period indicated as the offset / sleeping period. After expiration of the monitoring sleep timer, the UE 100 monitors the PDCCH for receiving an uplink grant for a period indicated as the UE wake-up period.

[0161] 23C, the UE starts a monitoring sleep timer after transmitting the BSR, i.e., after step 3, and does not monitor the PDCCH while the monitoring sleep timer has not expired, i.e., for a period indicated as offset / sleeping period. Once the timer expires, the UE 1200 starts monitoring the PDCCH for receiving an uplink grant.

[0162] The UE 100 may start the monitoring sleep timer after transmitting the SR, after transmitting the BSR, or after each transmission. The runtime of the monitoring sleep timer started after transmitting the SR may be equal to or different from the runtime of the monitoring sleep timer started after transmitting the BSR.

[0163] The present disclosure may be realized by software, hardware, or software interlocked with hardware. Each functional block used in the description of each embodiment above may be partially or entirely realized by an LSI (Large Scale Integration) such as an integrated circuit (IC), and each process described in each embodiment may be partially or entirely controlled by the same LSI or a combination of LSIs. The LSI may be formed as an individual chip, or a single chip may be formed to include some or all of the functional blocks. The LSI may also include data input / output devices coupled thereto. Here, an LSI may be referred to as an IC, system LSI, super LSI, or ultra LSI depending on the level of integration. However, the technology for realizing an integrated circuit is not limited to LSI, and may be realized using a dedicated circuit, a general-purpose processor, or an application-specific processor. Furthermore, a field programmable gate array (FPGA), which allows reconfiguration of the connections and settings of circuit cells arranged within the LSI or a reconfigurable processor that can be programmed after fabrication, may also be used. The present disclosure may be realized as digital processing or analog processing. If future integrated circuit technologies replace LSI as a result of advances in semiconductor technology and other derivative technologies, functional blocks can be integrated using future integrated circuit technologies. Biotechnology is also applicable.

[0164] The present disclosure may be implemented by any type of apparatus, device or system having communication capabilities, referred to as a communications apparatus.

[0165] Some non-limiting examples of such communication devices include telephones (e.g., mobile (cell) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (remote health and remote medical) devices, and vehicles (e.g., automobiles, airplanes, ships) that provide communication capabilities, and various combinations thereof.

[0166] The communications apparatus is not limited to being portable or mobile, but may include any type of apparatus, device or system that is non-portable or fixed, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines and any other "thing" in an "Internet of Things (IoT)" network.

[0167] Communications may include, for example, exchanging data via cellular systems, wireless LAN systems, satellite systems, and the like, as well as various combinations thereof.

[0168] A communications apparatus may include devices such as a controller or a sensor coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications apparatus may include a controller or a sensor that generates control or data signals used by the communications device to perform the communications functions of the communications apparatus.

[0169] Communications equipment may also include infrastructure facilities such as base stations, access points, and any other equipment, device, or system that communicates with or controls equipment such as those in the above non-limiting examples.

[0170] As described above, an apparatus and method are provided that allow for adaptability and power consumption to reduce scheduling demands and resource allocation directives.

[0171] A transceiver device is provided, comprising: a transceiver that, during operation, transmits a scheduling request for scheduling data over a physical uplink control channel PUCCH; and circuitry that, during operation, starts a monitoring sleep timer after the transceiver transmits the scheduling request, wherein the transceiver, during operation, does not monitor a physical downlink control channel PDCCH while the monitoring sleep timer is running, and starts monitoring the PDCCH for resource allocation for the scheduling data when the monitoring sleep timer expires.

[0172] In some embodiments, the circuitry starts a monitoring sleep timer when, during operation, a scheduling request is transmitted by the transceiver.

[0173] In some embodiments, the transceiver receives, during operation, a monitoring sleep indicator indicating a runtime of the monitoring sleep timer, and the circuitry starts the monitoring sleep timer when, during operation, the monitoring sleep indicator is received by the transceiver.

[0174] For example, the monitoring sleep indicator indicates the runtime of the monitoring sleep timer in terms of duration or number of symbols and / or slots of the PDCCH.

[0175] In some embodiments, the runtime of the monitoring sleep timer is set according to the priority level of the scheduling request setting.

[0176] For example, a first runtime of the monitoring sleep timer is set for a first scheduling request setting having a first level priority, and a second runtime of the monitoring sleep timer different from the first runtime is set for a second scheduling request setting having a second level priority different from the first level priority.

[0177] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0178] In some embodiments, during operation, the transceiver receives a scheduling request setting indicator that indicates at least one scheduling request setting having at least one associated level of priority.

[0179] For example, during operation, the transceiver receives scheduling request configuration via radio resource control, RRC.

[0180] In some embodiments, the discontinuous reception DRX period is set to a period during which the transceiver, in operation, monitors the PDCCH during an active period and does not monitor the PDCCH during an inactive period.

[0181] The transceiver further comprises a transceiver that, during operation, transmits a buffer status report indicating at least an amount of scheduling data; and a circuit that, during operation, starts a monitoring sleep timer after the transceiver transmits the buffer status report, wherein, during operation, the transceiver does not monitor a PDCCH, which is a physical downlink control channel, while the monitoring sleep timer is running, and starts monitoring the PDCCH for resource allocation for the scheduling data when the monitoring sleep timer expires.

[0182] In some embodiments, the buffer status report is transmitted over the physical uplink shared channel, PUSCH.

[0183] In some embodiments, during operation, the circuitry starts a monitoring sleep timer when a buffer status report is transmitted by the transceiver.

[0184] In some embodiments, the transceiver, during operation, receives a monitoring sleep indicator that indicates a runtime of the monitoring sleep timer, and the circuit, during operation, starts the monitoring sleep timer when the monitoring sleep indicator is received by the transceiver.

[0185] In some embodiments, the monitoring sleep indicator indicates the runtime of the monitoring sleep timer in terms of duration or number of symbols and / or slots of the PDCCH.

[0186] In some embodiments, the runtime of the monitoring sleep timer is set according to the logical channel group.

[0187] For example, the buffer status report further indicates the logical channel group associated with the amount of scheduling data.

[0188] In some embodiments, the buffer status report indicates multiple logical channel groups, each associated with a respective amount of scheduling data.

[0189] For example, each logical channel group is associated with a corresponding monitoring sleep timer runtime.

[0190] For example, the runtime of the monitoring sleep timer may be set to the runtime associated with the LCG with the highest level of priority.

[0191] In some embodiments, a first runtime of the monitoring sleep timer is set for a first logical channel group having a first level priority, and a second runtime different from the first runtime of the monitoring sleep timer is set for a second logical channel group having a second level priority different from the first level priority.

[0192] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0193] In some embodiments, during operation, the transceiver receives a logical channel group runtime indicator indicative of at least one logical channel group along with a runtime of an associated monitoring time.

[0194] For example, during operation, the transceiver receives the logical channel group runtime indicator via a radio resource control (RRC) message.

[0195] In some embodiments, the discontinuous reception DRX period is set to a period during which the transceiver, in operation, monitors the PDCCH during an active period and does not monitor the PDCCH during an inactive period.

[0196] Further provided is a scheduling apparatus comprising: a circuit for allocating resources in response to a scheduling request for scheduling data indicating a transmission timer during operation; and a transceiver for receiving the scheduling request via a physical uplink control channel PUCCH and transmitting a resource allocation indicator indicating the allocated resources after expiry of the transmission timer via a physical downlink control channel PDCCH.

[0197] In some embodiments, the circuitry determines, during operation, a runtime of the monitoring sleep timer, and the transceiver, during operation, transmits a monitoring sleep indicator indicative of the runtime of the monitoring sleep timer.

[0198] For example, the runtime of the transmission timer is equal to the runtime of the monitoring sleep timer.

[0199] Further provided is a scheduling apparatus comprising: a circuit for, during operation, allocating resources in response to a buffer status report indicating an amount of scheduling data and starting a transmission timer; and a transceiver for, during operation, receiving the buffer status report and transmitting, after expiry of the transmission timer, a resource allocation indicator indicating the allocated resources via a physical downlink control channel, PDCCH.

[0200] For example, the transceiver receives buffer status reports via the physical uplink shared channel, PUSCH.

[0201] In some embodiments, the circuitry determines, during operation, a runtime of the monitoring sleep timer, and the transceiver, during operation, transmits a monitoring sleep indicator indicative of the runtime of the monitoring sleep timer.

[0202] For example, the runtime of the transmission timer is equal to the runtime of the monitoring sleep timer.

[0203] In some embodiments, during operation, the circuitry determines the runtime of the monitoring sleep timer as a function of the logical channel group.

[0204] For example, the buffer status report further indicates the logical channel group associated with the amount of scheduling data.

[0205] In some embodiments, the buffer status report indicates the amount of scheduling data for each of the multiple logical channel groups that are associated with each of the logical channel groups.

[0206] For example, each logical channel group is associated with a corresponding monitoring sleep timer runtime.

[0207] In some embodiments, a first runtime of the monitoring sleep timer is set for a first logical channel group having a first level priority, and a second runtime different from the first runtime of the monitoring sleep timer is set for a second logical channel group having a second level priority different from the first level priority.

[0208] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0209] In some embodiments, the transceiver, during operation, transmits a logical channel group runtime indicator indicative of at least one logical channel group along with an associated runtime of the monitoring sleep timer.

[0210] For example, during operation, the transceiver transmits the logical channel group runtime indicator via a radio resource control (RRC) message.

[0211] Further provided is a method comprising the steps of transmitting a scheduling request for the scheduling data over a physical uplink control channel PUCCH, starting a monitoring sleep timer after transmitting the scheduling request, ceasing monitoring of a physical downlink control channel PDCCH while the monitoring sleep timer is running, and starting monitoring of the PDCCH for resource allocation for the scheduling data if the monitoring sleep timer expires.

[0212] In some embodiments, a monitoring sleep timer is started when a scheduling request is sent.

[0213] In some embodiments, a monitoring sleep indicator is received that indicates a runtime of the monitoring sleep timer, and the monitoring sleep timer is started if the monitoring sleep indicator is received.

[0214] For example, the monitoring sleep indicator indicates the runtime of the monitoring sleep timer in terms of duration or number of symbols and / or slots of the PDCCH.

[0215] In some embodiments, the runtime of the monitoring sleep timer is set according to the priority level of the scheduling request setting.

[0216] For example, a first runtime of the monitoring sleep timer is set for a first scheduling request setting having a first level priority, and a second runtime of the monitoring sleep timer different from the first runtime is set for a second scheduling request setting having a second level priority different from the first level priority.

[0217] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0218] In some embodiments, a scheduling request setting indicator is received that indicates at least one scheduling request setting having at least one associated level of priority.

[0219] For example, the scheduling request configuration indicator is received via a Radio Resource Control (RRC) message.

[0220] In some embodiments, the DRX cycle, which is discontinuous reception, is set to a period during which the PDCCH is monitored during the active period and the PDCCH is not monitored during the inactive period.

[0221] Further provided is a method comprising the steps of: transmitting a buffer status report indicating the amount of scheduling data; starting a monitoring sleep timer after transmitting the buffer status report; ceasing monitoring of a PDCCH, which is a physical downlink control channel, while the monitoring sleep timer is running; and starting monitoring of the PDCCH for resource allocation for the scheduling data if the monitoring sleep timer expires.

[0222] In some embodiments, the buffer status report is transmitted over the physical uplink shared channel, PUSCH.

[0223] In some embodiments, when a buffer status report is sent, a monitoring sleep timer is started.

[0224] In some embodiments, the method includes receiving a monitoring sleep indicator indicative of a runtime of a monitoring sleep timer, and starting the monitoring sleep timer if the monitoring sleep indicator is received.

[0225] In some embodiments, the monitoring sleep indicator indicates the runtime of the monitoring sleep timer in terms of duration or number of symbols and / or slots of the PDCCH.

[0226] In some embodiments, the runtime of the monitoring sleep timer is set according to the logical channel group.

[0227] For example, the buffer status report further indicates the logical channel group associated with the amount of scheduling data.

[0228] In some embodiments, the buffer status report indicates the amount of scheduling data for each of the multiple logical channel groups that are associated with each of the logical channel groups.

[0229] For example, each logical channel group is associated with a corresponding monitoring sleep timer runtime.

[0230] For example, the runtime of the monitoring sleep timer may be set to the runtime associated with the LCG with the highest level of priority.

[0231] In some embodiments, a first runtime of the monitoring sleep timer is set for a first logical channel group having a first level priority, and a second runtime different from the first runtime of the monitoring sleep timer is set for a second logical channel group having a second level priority different from the first level priority.

[0232] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0233] In some embodiments, the method includes receiving a logical channel group runtime indicator indicating at least one logical channel group having an associated runtime of a monitoring sleep timer.

[0234] For example, the logical channel group runtime indicator is received via a radio resource control (RRC) message.

[0235] In some embodiments, the DRX cycle, which is discontinuous reception, is set to a period during which the PDCCH is monitored during the active period and the PDCCH is not monitored during the inactive period.

[0236] Further provided is a method comprising the steps of receiving a scheduling request for scheduling data via a physical uplink control channel PUCCH, starting a transmission timer, allocating resources in response to the scheduling request, and, after expiry of the transmission timer, transmitting a resource allocation indicator indicating the allocated resources via a physical downlink control channel PDCCH.

[0237] In some embodiments, a runtime of the monitoring sleep timer is determined and a monitoring sleep indicator is transmitted that indicates the runtime of the monitoring sleep timer.

[0238] For example, the runtime of the transmission timer is equal to the runtime of the monitoring sleep timer.

[0239] Further provided is a method comprising the steps of receiving a buffer status report indicating an amount of scheduling data, starting a transmission timer, allocating resources in response to the buffer status report, and transmitting, after expiry of the transmission timer, a resource allocation indicator indicating the allocated resources via a physical downlink control channel, PDCCH.

[0240] For example, the transceiver receives buffer status reports via the physical uplink shared channel, PUSCH.

[0241] In some embodiments, the method includes determining a runtime of a monitoring sleep timer and transmitting a monitoring sleep indicator indicative of the runtime of the monitoring sleep timer.

[0242] For example, the runtime of the transmission timer is equal to the runtime of the monitoring sleep timer.

[0243] In some embodiments, the method includes determining a runtime of the monitoring sleep timer as a function of the logical channel group.

[0244] For example, the buffer status report further indicates the logical channel group associated with the amount of scheduling data.

[0245] In some embodiments, the buffer status report indicates the amount of scheduling data for each of the multiple logical channel groups that are associated with each of the logical channel groups.

[0246] For example, each logical channel group is associated with a corresponding monitoring sleep timer runtime.

[0247] In some embodiments, a first runtime of the monitoring sleep timer is set for a first logical channel group having a first level priority, and a second runtime different from the first runtime of the monitoring sleep timer is set for a second logical channel group having a second level priority different from the first level priority.

[0248] For example, if the first level priority is lower than the second level priority, the first runtime will be greater than the second runtime, and if the first level priority is higher than the second level priority, the first runtime will be less than the second runtime.

[0249] In some embodiments, the method includes transmitting a logical channel group runtime indicator indicating at least one logical channel group having an associated runtime of the monitoring sleep timer.

[0250] For example, the logical channel group runtime indicator is transmitted via an RRC message, which is a radio resource control message.

Claims

1. a transceiver configured, during operation, to transmit a scheduling request for scheduling data over a physical uplink control channel (PUCCH); circuitry that, during operation, starts a monitoring sleep timer after the transceiver transmits the scheduling request; Equipped with The transceiver, during operation, not monitoring a physical downlink control channel (PDCCH) during operation of the monitoring sleep timer; After the monitoring sleep timer expires, an active period of a discontinuous reception (DRX) cycle is started while the scheduling request is pending, and during the active period, the PDCCH is monitored for resource allocation for the scheduling data; the length of time of the monitoring sleep timer is dynamically configured by radio resource control (RRC); Transmitting and receiving device.

2. and wherein the circuitry, during operation, starts the monitoring sleep timer when the scheduling request is transmitted by the transceiver. The transmitting / receiving device according to claim 1 .

3. During operation, the transceiver receives a monitoring sleep indicator indicative of a runtime of the monitoring sleep timer; the circuit, during operation, starts the monitoring sleep timer when the monitoring sleep indicator is received by the transceiver. The transmitting / receiving device according to claim 1 .

4. the monitoring sleep indicator indicates the runtime of the monitoring sleep timer in terms of duration or number of symbols and / or slots of the PDCCH. The transmitting / receiving device according to claim 3.

5. The runtime of the monitoring sleep timer is set according to the priority level of the scheduling request setting. The transmitting / receiving device according to claim 1 .

6. and receiving, during operation, a scheduling request setting indicator indicative of at least one scheduling request setting having at least one associated level of priority. The transmitting / receiving device according to claim 5.

7. and wherein the transceiver, during operation, receives the scheduling request configuration via a radio resource control (RRC). The transmitting / receiving device according to claim 6.

8. The DRX cycle is set to a period during which the transceiver, in operation, monitors the PDCCH during the active period and does not monitor the PDCCH during an inactive period. The transmitting / receiving device according to claim 1 .

9. circuitry for allocating resources in response to a scheduling request for scheduling data indicative of a transmission timer during operation; a transceiver configured to, during operation, receive the scheduling request via a physical uplink control channel (PUCCH), and after the transmission timer expires, start an active period of a discontinuous reception (DRX) cycle while the scheduling request is pending, and transmit, during the active period, via a physical downlink control channel (PDCCH), a resource allocation indicator indicating the allocated resources; Equipped with the length of the transmission timer is dynamically configured based on a configuration by Radio Resource Control (RRC); Scheduling device.

10. The circuitry, during operation, determines a runtime of a monitoring sleep timer; and wherein the transceiver, during operation, transmits a monitoring sleep indicator indicating the runtime of the monitoring sleep timer. The scheduling device according to claim 9.

11. The runtime of the transmission timer is equal to the runtime of the monitoring sleep timer. The scheduling device according to claim 10.

12. 1. A method comprising: transmitting a scheduling request for scheduling data over a physical uplink control channel (PUCCH); after sending the scheduling request, starting a monitoring sleep timer; ceasing monitoring of a physical downlink control channel (PDCCH) while the monitoring sleep timer is running; after the monitoring sleep timer expires, starting an active period of a discontinuous reception (DRX) cycle while the scheduling request is pending, and monitoring the PDCCH for resource allocation for the scheduling data during the active period; and the length of time of the monitoring sleep timer is dynamically configured by radio resource control (RRC); method.

13. 1. A method comprising: receiving a scheduling request for scheduling data over a physical uplink control channel (PUCCH); starting a transmit timer; allocating resources in response to the scheduling request; after the transmission timer expires, starting an active period of a discontinuous reception (DRX) cycle while the scheduling request is pending, and transmitting a resource allocation indicator indicating the allocated resources via a physical downlink control channel (PDCCH) during the active period; and the length of the transmission timer is set based on a configuration by Radio Resource Control (RRC); method.

14. An integrated circuit that controls processing of a transceiver, the processing comprising: transmitting a scheduling request for scheduling data over a physical uplink control channel (PUCCH); after transmitting the scheduling request, starting a monitoring sleep timer; A process of stopping monitoring of a PDCCH that is a physical downlink control channel during operation of the monitoring sleep timer; after the monitoring sleep timer expires, starting an active period of a discontinuous reception (DRX) cycle while the scheduling request is pending, and monitoring the PDCCH for resource allocation for the scheduling data during the active period; and the length of time of the monitoring sleep timer is dynamically configured by radio resource control (RRC); Integrated circuit.

15. An integrated circuit for controlling a process of a scheduling node, the process comprising: receiving a scheduling request for scheduling data via a physical uplink control channel (PUCCH); starting a transmission timer; allocating resources in response to the scheduling request; After the transmission timer expires, an active period of a discontinuous reception (DRX) cycle is started while the scheduling request is pending, and a resource allocation indicator indicating the allocated resources is transmitted via a physical downlink control channel (PDCCH) during the active period. and the length of the transmission timer is set based on a configuration by Radio Resource Control (RRC); Integrated circuit.

Images