Transmitting / receiving apparatus, scheduling apparatus, method, and integrated circuit

Abstract

To provide a method and an apparatus for achieving flexibility and power consumption that reduce scheduling requirements.SOLUTION: In a communication system, a transmitting / receiving apparatus includes: a transceiver that, during operation, transmits a scheduling request SR on a physical uplink control channel (PUCCH), in which the scheduling request is held in abeyance until a valid uplink grant is received; and a circuit that, during operation, initiates an active period, after the transmission of the scheduling request and a monitoring sleep period, and monitors a physical downlink control channel (PDCCH) during the active period.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present disclosure relates to the transmission and reception of signals in a communication system. In particular, the present disclosure relates to methods and apparatuses for such transmission and reception.

Background Art

[0002] Currently, the 3GPP (3rd Generation Partnership Project) is working on the technical specifications of the next-generation cellular technology, also known as the 5th generation (5G). 5G includes NR (New Radio), a RAT (Radio Access Technology) that operates in frequency bands from near 1 GHz to the millimeter-wave band. NR follows the technologies represented by LTE (LоNG Term Evоlutiоn) and LTT-A (LTE Advanced).

[0003] In the case of systems such as LTE, LTE-A, and NR, further modifications and options can facilitate the efficient operation of the communication system as well as specific apparatuses related to the system.

[0004] One non-limiting and exemplary embodiment facilitates providing flexibility to reduce scheduling requests and power consumption.

Summary of the Invention

[0005] In one embodiment, a transceiver device, which is the technology disclosed herein, includes a transceiver that transmits a scheduling request for scheduling data via a Physical Uplink Control Channel (PUCCH) during operation, and a circuit that starts a monitoring sleep timer after the transceiver transmits the scheduling request during operation. The transceiver does not monitor a Physical Downlink Control Channel (PDCCH) during the operation of the monitoring sleep timer during operation, and starts monitoring the PDCCH for resource allocation of the scheduling data when the monitoring sleep timer expires.

[0006] Note that general or specific embodiments may be implemented as a system, method, integrated circuit, computer program, storage medium, or any optional combination thereof.

[0007] Further benefits and advantages of the disclosed embodiments may become apparent from the specification and drawings. The benefits and / or advantages can be obtained individually by the various embodiments and features of the specification and drawings, and not all of these are provided in order to obtain one or more of such benefits and / or advantages.

Brief Description of Drawings

[0008] In the following, exemplary embodiments will be described in more detail with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18A

Figure 18B

Figure 19

Figure 20A

Figure 20B

Figure 21

Figure 22

Figure 23

Embodiments for Carrying out the Invention

[0009] 5G NR System Architecture and Protocol Stack 3GPP is working on the next release for the 5th generation cellular technology simply called 5G, which includes the development of NR (New Radio Access Technology) operating in the frequency range up to 100 GHz. The first version of the 5G standard was completed by the end of 2017, enabling trials and commercial deployments of smartphones compliant with the 5G NR standard.

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

[0011] Various different deployment scenarios are supportable. For example, a non - centralized deployment scenario is presented where base stations supporting 5G NR can be deployed. Figure 2 shows an example of a non - centralized deployment scenario, further showing a user equipment (UE) connected to both a gNB and an LTE eNB, along with the LTE eNB. The new eNB for NR 5G can be exemplarily called a gNB. The eLTE eNB is an evolved type of eNB that supports the connectivity between the EPC (Evolved Packet Core) and the NGC (Next Generation Core).

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

[0013] 5G NR functional split between NG-RAN and 5GC Figure 3 is a diagram showing the functional split between NG-RAN and 5GC. The NG-RAN logical node is a gNB or an ng-eNB. In 5GC, there are the logical nodes AMF, UPF, and SMF described above.

[0014] In particular, 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 the UE in both the uplink and downlink · Compression of IP headers, encryption, and protection of data integrity · Selection of the AMF in UE attachment when the routing to the AMF cannot be determined from the information provided by the UE · Routing of user plane data to the UPF · Routing of control plane information to the AMF · Establishment and release of connections · Scheduling and transmission of paging messages · Scheduling and transmission of system broadcast information (originated from the AMF or OAM) · Measurement and measurement report configuration for mobility and scheduling · Transport-level packet marking in the uplink · Session management · Support for network slicing · QoS flow management and mapping to data radio bearers · Support for UE in RRC_INACTIVE state · NAS message distribution function · Radio access network sharing · Dual connectivity · Tight 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 Stratum (AS) security control · Core Network (CN) node-to-node signaling for mobility between 3GPP access networks · Idle mode UE reachability (including control and execution of paging retransmission) · Registration area management · Support for intra-system and inter-system mobility · Access authentication · Access rights including roaming right check · Mobility management control (subscription and policy) · Support for network slicing · Selection of Session Management Function (SMF)

[0016] Furthermore, the User Plane Function (UPF) hosts the following main functions. · Anchor point for mobility within / across RATs (if applicable) · External PDU session point of interconnection to data networks · Packet routing and forwarding · Packet inspection for policy rule enforcement and user plane part · Traffic usage reporting · Uplink classifier that supports routing of traffic flows to the data network · Branch point that supports multi - home PDU sessions · QoS processing for the user plane, such as packet filtering, gating, UL / DL rate enforcement · Uplink traffic verification (flow mapping from SDF to QoS) · Downlink packet buffering and downlink data notification trigger

[0017] Finally, the Session Management Function (SMF) hosts the following main functions. · Session management · Allocation and management of UE IP addresses · Selection and control of the UP function · Configuration of traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination · Policy enforcement and the QoS control part · Downlink of data notification

[0018] Procedures for RRC connection setup and re - configuration Figure 4 is a diagram showing some interactions between a UE, a gNB, and an AMF (5GC entity) regarding the upper layer signals (protocols) used by RRC for UE and gNB configuration. In particular, the AMF prepares UE context data (including, for example, PDU session context, security keys, UE radio capabilities, and UE security capabilities) and sends it to the gNB together with an INITIAL CONTEXT SETUP REQUEST. Next, the gNB activates AS security at the UE. This is performed by the gNB that sends a SecurityModeCommand message to the UE and the UE that responds to the gNB with a SecurityModeComplete message. Thereafter, the gNB performs reconfigurations to set up signaling radio bearer 2, SRB2, and data radio bearer, DRB, by means of RRCReconfigration and RRCReconfigrationComplete. If only signaling of the connection is performed, since SRB2 and DRB are not set up, step 8 is skipped. Finally, the gNB notifies the AMF with an INITIAL CONTEXT SETUP RESPONCE that the setup procedure is complete.

[0019] Therefore, in the present disclosure, during operation, an entity (such as AMF, SMF, etc.) of the fifth generation core (5GC) is provided that includes a control circuit for establishing a next generation (NG) connection with a gNodeB and a transmitter for transmitting an initial context setup message to the gNodeB via the NG connection to trigger signaling radio bearer configuration between the gNodeB and a user equipment (UE). Specifically, the gNodeB transmits radio resource control (RRC), which is signaling including a resource allocation configuration information element, to the UE via a signaling radio bearer. Next, the UE performs uplink transmission or downlink reception based on the resource allocation configuration.

[0020] IMT Usage Scenarios After 2020 Figure 5 is a diagram showing several use cases for 5G NR. In 3GPP NR (3rd Generation Partnership Project new radio), three use cases are considered that are expected to support a wide variety of services and applications by IMT-2020. The Phase 1 specifications for eMBB (enhanced mobile broadband) are complete. In addition to further expanding eMBB support, current and future work will involve standardization for Ultra-reliable and Low Latency Communications (URLLC) and Massive Machine Type Communications. Figure 5 is a diagram showing some examples of usage scenarios assumed for IMT after 2020.

[0021] The use case for URLLC has strict requirements for capabilities such as throughput, latency, and availability, and is assumed to be 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. The high reliability of URLLC is supported by identifying technologies that meet the requirements set by TR 38.913. For NR URLLC in Release 15, the key requirements include a target user plane latency of 0.5 ms for UL (uplink) and a target user plane latency of 0.5 ms for DL (downlink). The general URLLC requirement for a single transmission of a packet is a user plane latency of 1 ms with a BLER (block error rate) of 1E-5 for a packet size of 32 bytes.

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

[0023] Furthermore, the technical enhancements targeted by NR URLCC aim to improve latency and reliability. Technical extensions for latency improvement include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition of data channels, and downlink preemption. Preemption means stopping a transmission for which resources have already been allocated and using the already allocated resources for another transmission that is requested later, with low latency and high-priority requirements. Therefore, an already permitted transmission can be 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 (such as eMBB). Technical enhancements related to reliability improvement include dedicated CQI / MCS tables for a target BLER of 1E-5.

[0024] mMTC use cases are characterized by a very large number of connected devices that typically transmit relatively small amounts of non-delay-sensitive data. The devices are required to be low-cost and have a very long battery life. From the perspective of NR, utilizing very narrow bandwidth portions is one possible solution that is power-saving from the UE's perspective and enables a long battery life.

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

[0026] For NR URLLC, additional use cases with more stringent requirements have been identified, such as factory automation, the transportation industry, and power supply including factory automation, the transportation industry, and power supply. The more stringent requirements are higher reliability (up to the 10~6 level), higher availability, packet sizes up to 256 bytes, time synchronization up to about several μs, and the value can be 1 μs or several μs depending on the frequency range. The short latency can be about 0.5~1 ms depending on the use case, and especially the target user plane latency can be 0.5 ms.

[0027] Furthermore, for NR URLLC, several technical enhancements from the perspective of RAN1 have been identified. Among these are PDCCH (Physical Downlink Control Channel) enhancements related to compact DCI, repetition of PDCCH, and increased PDCCH monitoring. In addition, UCI (Uplink Control Information) extensions are related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback extensions. Also, PUSCH enhancements related to mini-slot level hopping and retransmission / repetition enhancements have been identified. The term "mini-slot" refers to a transmission time interval (TTI) that contains 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). Thus, at the NAS level, a QoS flow is the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS flow ID (QFI) carried in a capsule 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 a PDU session and, together with at least one data radio bearer (DRB), and additional DRBs (if any) for the QoS flow(s) of that PDU session can then be configured as shown above, for example, with reference to Figure 4 (it is up to the NG-RAN to do so). The NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS level packet filters within the UE and the 5GC associate UL and DL packets with QoS flows, while AS level mapping rules within the UE and the NG-RAN associate UL and DL QoS flows with DRBs.

[0030] Figure 6 shows a 5G NR non-roaming reference architecture. The Application Function (AF) interacts with the 3GPP core network to provide services that support, for example, the application's impact on traffic routing, or access to the Network Exposure Function (NEF), or interaction with the policy framework for policy control (refer to the Policy Control Function, PCF). Based on the operator's deployment, application functions considered to be trusted by the operator can interact directly with the relevant network functions. Application functions that are not permitted to directly access network functions by the operator use the external exposure framework via the NEF to interact with the relevant network functions.

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

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

[0033] A base station is, for example, a network node that forms part of a network for providing services to terminals. A base station is a network node that provides wireless access to terminals. The communication between a terminal and a base station is typically standardized. In LTE and NR, the radio interface protocol stack includes a physical layer, a MAC (medium access layer), and upper layers. In the control plane, an upper layer protocol radio resource control protocol is provided. Through RRC, the base station can control the settings of the terminal, and the terminal can communicate with the base station to perform control tasks such as connection and bearer establishment and modification, measurements, and other functions.

[0034] The service for transferring data provided by a layer to an upper layer is usually called a channel. For example, LTE and NR distinguish between logical channels provided by the MAC layer to upper layers, transport channels provided by the physical layer to the MAC layer, and physical channels that define mappings on physical resources.

[0035] Logical channels are various types of data transfer services provided by the MAC. Each logical channel type is defined by the type of information being transferred. Logical channels are classified 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] Next, the logical channels are mapped by the MAC layer to transport channels. For example, logical traffic channels, and some logical control channels, can 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 in 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 determines, for each instance, which UEs to allocate the shared time-frequency resources to. It can schedule uplink transmissions, downlink transmissions, and / or sidelink transmissions.

[0039] In particular, the uplink scheduler can play a role in 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 resources. Dynamic scheduling is typically performed by the Physical Downlink Control Channel (PDCCH). The Physical Downlink Control Channel also carries scheduling grants and other control information that can also be referred to as Downlink Control Information (DCI). Each terminal (UE) monitors the PDCCH. This means that the UE blindly decodes a specific resource called the search space. The search space of the PDCCH is the area within 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 RNTI (Radio Network Temporary Identity) and tries to decode the PDCCH within a resource called a Control Channel Element (CCE). 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 randomly try various parameter values for some selected transmission parameters. Each terminal can monitor two or more PDCCHs. The PDCCH can be common to a group of UEs (in which case the UEs are using a common group RNTI), or it can be specific to a particular UE.

[0041] The standard (LTE or NR) defines several different formats of DCI. These formats differ from each other according to the purpose. For example, the format carrying an uplink grant (such as format 0 or 4) is different from the format carrying a downlink grant or a format with no grant at all. Also, these are different formats defined according to the utilization such as 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). This is similar to the PDCCH that carries the above-mentioned DCI. Depending on the type of information carried by the UCI in the PUCCH, the PUCCH can be available in different formats. The following are examples. · Format 1 that carries the SR which is a scheduling request · Format 4 that carries the SR together with channel state information (CSI) · Format 3 that carries the SR together with HARQ response (positive or negative) and CSI These are additional formats defined by LTE and / or NR.

[0043] The basis of uplink scheduling is the scheduling grant, which includes providing device information about the resources and related transport formats to be used for the transmission of the UL-SCH. In other words, DCI with a certain format (e.g., defined by the standard) can carry a resource allocation (RA) corresponding to the resource grant, as well as some additional transmission parameters such as modulation and coding scheme (MCS), settings for multiple input multiple output (MIMO) transmission.

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

[0045] That is, the scheduler needs knowledge about the terminals having data to transmit and thus needs to schedule uplink resources. There is no need to provide uplink resources to devices without data to transmit. This causes padding to be performed at the device and fills the permitted resources. Thus, the scheduler needs to know whether the device has data to transmit and needs to grant permission.

[0046] Scheduling Request A scheduling request may be used by a terminal that does not have a valid scheduling grant. The scheduling request may be transmitted on the PUCCH, which is a physical uplink control channel. A dedicated scheduling request resource that occurs for each nth subframe can be allocated to each terminal. The 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 is implicitly known from the resource on which the request is transmitted and thus does not need to be provided with the scheduling request. These are set by a scheduling node such as a gNB, for example, by a higher layer control protocol.

[0047] Upon receiving a scheduling request, the scheduling device can allocate a scheduling grant to the terminal. When 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 notifies the scheduling node of the amount of data that the UE has to transmit. Then, based on the buffer status, the scheduling node can schedule the actual data resources on the PUSCH. However, this is just an option and generally, the data resources may also be scheduled directly. In some systems, it is also possible to associate the scheduling request with a specific amount of data for which the scheduling is requested.

[0048] If the terminal does not receive scheduling permission until the next possible moment, the scheduling request may be repeated.

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

[0050] The 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), a maximum of 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 set by radio resource control (RRC) messaging.

[0051] As described above, a normal buffer status report (BSR) is triggered. If uplink radio resources for transmitting the BSR are not available to the UE, the SR procedure may be initiated. During the SR procedure, the UE can perform either transmitting the SR via PUCCH or starting a random access (RA) procedure depending on whether the UE is configured with a PUCCH resource for SR. The RA procedure is started only when the SR PUCCH resource is 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 SR. Then, the SR prohibit timer starts this timer (SR_prohibitTimer). At the time of consecutive SR transmission opportunities, 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 a UE, an SR prohibition timer is started, and as long as the SR prohibition timer is running, no SR is transmitted on the already configured resources.

[0054] The scheduling request configuration information element used for scheduling request configuration 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, even if no scheduling grant is received, the scheduling request prohibition timer is set by SR-ProhibitTimer and indicates the duration during which no scheduling request is transmitted after the transmission of an SR. The maximum number of scheduling requests is defined by SR-TransMax. SR-ProhibitTimer and SR-TransMax are provided to the UE from the scheduling node via, for example, RRC signaling.

[0057] When the prohibition timer (SR-ProhibitTimer) is active, no further SRs are started. SR-ProhibitTimer is per SR configuration and can be set to a value in the range of 1 ms to 128 ms.

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

[0059] Discontinuous Reception - DRX Packet data is often highly bursty and sometimes has periods of silence. From the perspective of latency, it is beneficial to continuously 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 the device. To reduce the power consumption of the device, LTE includes a mechanism for discontinuous reception (DRX).

[0060] The basic mechanism of DRX is a configurable DRX cycle within the device. When the DRX cycle is set, the device monitors downlink control signaling only during the active period per DRX cycle and sleeps with the receiving circuit turned off during the remaining inactive periods. This can significantly reduce power consumption. Naturally, this means a limitation to the scheduler since the device can only respond during the active period.

[0061] The DRX cycle can be set for the LTE downlink, for example, by periodically turning off the receiver switch so that the UE does not need to decode the physical downlink control channel (PDCCH) or receive physical downlink shared channel (PDSCH) transmissions for a specific period, as defined for the 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 for the 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 cycle is configured, the active time includes the time during which drx-onDurationTimer, drx-InactivitTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, or ra-ContentionResolutionTimer is operating, as described in Section 5.1.5 of 3GPP TS 38.321.

[0063] drx-onDurationTimer defines the duration at the start of a DRX cycle, and drx-InactivitTimer specifies the duration after a PDCCH opportunity indicating a new uplink (UL) or downlink (DL) transmission for the MAC entity. drx-RetransmissionTimerDL and UL define the maximum duration until a DL retransmission is received and the maximum duration until permission for a UL retransmission is received, respectively.

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

[0065] As described 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 a scheduling assignment.

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

[0067] However, the UE may not be scheduled immediately after transmitting the scheduling request. FIGS. 8A and 8B are diagrams schematically showing the active time and the inactive time according to the set DRX cycle, and the active time according to the pending scheduling request. In the figure, the time point at which the uplink grant (UL grant) is received is indicated by the arrow labeled "UL grant". As long as the SR is pending, the PDCCH is monitored for the UL grant.

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

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

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

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

[0072] The transmitting and receiving device 100 includes a transceiver 110 (a transmitter and / or receiver including hardware components such as one or more antennas and a control circuit for controlling the operation of the hardware components), and during operation, this transceiver transmits a scheduling request for scheduling data via a Physical Uplink Control Channel (PUCCH). Further, the transmitting and receiving device 100 includes a circuit 120 (or a processing circuit), and during operation, this circuit 120 starts a monitoring sleep timer after the transceiver 110 transmits a scheduling request. Further, during operation, the transceiver 110 does not monitor a Physical Downlink Control Channel (PDCCH) while the monitoring sleep timer is running, and when the monitoring sleep timer expires, starts monitoring the PDCCH for resource allocation of scheduling data.

[0073] For example, the transmitting and receiving device 100 is a UE in an NR network. Therefore, the transceiver 110 and the circuit 120 are also referred to as a "UE transceiver" and a "UE circuit", but these terms are only used to distinguish the transceiver 110 and the circuit 120 from circuits and transceivers configured by other devices such as a scheduling device or a base station. The transmitting and receiving device 100 may be a terminal service, a relay device, or a communication device of a similar communication system, and the UE circuit may be regarded as "monitoring a sleeping control circuit" or may be regarded as including a "sleeping control circuit".

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

[0075] During operation, the scheduling device 200 includes a circuit 220 that allocates resources according to a scheduling request for scheduling data and starts a transmission timer. During operation, the scheduling device 200 receives a scheduling request via a physical uplink control channel (PUCCH), and after the transmission timer expires, further includes a transceiver 210 that transmits a resource allocation indicator indicating the allocated resources via a physical downlink control channel (PDCCH).

[0076] For example, the scheduling device 200 is a network node (base station) within an 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] Furthermore, a method is provided that includes transmitting a scheduling request for scheduling data via a physical uplink control channel (PUCCH) and starting a monitoring sleep timer after transmitting the scheduling request. Further, this method includes stopping 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 scheduling data when the monitoring sleep timer expires.

[0078] Furthermore, a method is provided that includes receiving a scheduling request for scheduling data via a physical uplink control channel (PUCCH) and starting a transmission timer. This method further includes allocating resources according to the scheduling request and, after the transmission timer expires, transmitting a resource allocation indicator indicating the allocated resources via a physical downlink control channel (PDCCH).

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

[0080] The transceiver device 100 transmits using the transceiver 110, which is a scheduling request for transmitting scheduling data via PUCCH, and uses the UE circuit 120 to start a monitoring sleep timer after the SR is transmitted. While the monitoring sleep timer is operating, the transceiver 110 does not monitor the PDCCH for receiving a UL grant corresponding to the transmitted SR. After the expiration of the monitoring sleep timer, the transceiver 110 starts monitoring the PDCCH for receiving a UL grant according to the transmitted SR. The UL grant indicates the resources allocated for transmitting scheduling data.

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

[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 a UL grant from the scheduling device 200. That is, according to this embodiment, the monitoring sleep timer is started when the scheduling request is transmitted by the transceiver 110.

[0083] In this procedure, during a period when the SR is pending but the scheduling device does not intend to transmit a UL grant, the active time of the UE that monitors the PDCCH by the running monitoring sleep timer is reduced, so the power consumption of the UE is reduced.

[0084] FIG. 11 is a flowchart showing the transmission of a scheduling request and the start of monitoring of a physical downlink control channel after the monitoring sleep timer expires according to an embodiment.

[0085] After the start of the procedure, in step S100, it is determined whether the DRX mode is set, that is, whether the UE is in the DRX mode. If it is determined that the UE is not in the DRX mode (step S100, NO), this 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 scheduling data to be transmitted to the scheduling device 200 via the PUCCH. If the scheduling request has not been transmitted (step S110, NO), step S110 is repeated. If it is determined that the SR has been transmitted (step S110, YES), the process proceeds to step S120.

[0087] In step S120, the monitoring sleep timer is started. For example, as illustrated 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 specific symbol or slot of the PDCCH. This will be described below. Also, the runtime of the monitoring sleep timer may be set according to the setting of the scheduling request as described below. While the monitoring sleep timer is running, that is, while it 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, and 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, in order to receive resource allocation (UL grant) of scheduling data corresponding to the scheduling request transmitted in step S110, monitoring of the PDCCH is started.

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

[0091] For example, the runtime of the monitoring sleep timer can be set to a value smaller than the value for SR setting with the first-level priority, for the SR setting with the second-level priority. The second-level priority is a value lower than the first-level priority.

[0092] In other words, an SR with high priority and low latency can set the runtime of the monitoring sleep timer to be relatively small, and an SR with low priority and high latency can set the runtime of the monitoring sleep timer to be relatively large. In this case, power saving is less for services with higher priority and lower latency than for services with lower priority and higher latency.

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

[0094] As shown in FIG. 12, the first runtime of the monitoring sleep timer may be set for the first logical channel, and the second runtime of the monitoring sleep timer may be set for the second logical channel. Therefore, the runtime of the monitoring sleep timer may vary depending on the logical channel. In particular, a larger runtime of the monitoring sleep timer may be set for a logical channel with a lower priority than for a logical channel with a higher priority, and vice versa. As shown in FIG. 12, since LCH1 and LCH2 have different levels of priority, they are mapped to different SR settings.

[0095] FIG. 12 shows the mapping of the runtime of the monitoring sleep timer for two logical channels, but the present embodiment is not limited thereto, and different runtimes of the monitoring sleep timer may be set for a plurality of 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] FIGS. 12 and 13 show either a one-to-one mapping of runtime, SR setting, and logical channel, or a mapping of a plurality of logical channels to one SR setting, but the present embodiment is not limited thereto, and a combination of a mapping of a plurality of logical channels to one SR setting and a mapping of one logical channel to one SR setting 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 such that which logical channel corresponds to which runtime of the monitoring sleep timer is defined. In this approach, no additional signaling is required.

[0099] For example, Table 1 shows the fixed values in the specification. For scheduling request identifiers 0 to 7, as shown in Table 1, the runtime of the monitoring sleep timer is indicated by a symbol (sym) or slot (sl) offset. 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 set from the perspective of a duration, for example, a duration from 0 to 256 ms.

[0100] [Table 2]

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

[0102] The scheduling request setting may be received by the transceiver device 100 by a scheduling request setting indicator indicating at least one scheduling request setting at at least one associated priority level.

[0103] For example, the transceiver 110 can receive a scheduling request setting indicator via an RRC message that is radio resource control.

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

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

[0106] [Table 3]

[0107] In particular, the monitoring sleep timer is set by a timer / offset and indicates the runtime of the monitoring sleep timer with respect to the symbols of the slots of the PDCCH.

[0108] According to one embodiment, if the network / gNB 200 does not intend to schedule UL resources after a scheduling request for scheduling data is received, the network / gNB 200 may determine the runtime of the monitoring sleep timer and transmit the determined runtime to the UE 100.

[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 a so-called MAC control element (MAC CE) into the transport block transmitted via the transport channel. The MAC CE is used for in-band control signaling, for example, for a timing advance command or a random access response.

[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 in the range from 0 to 256. The time unit of the length can be the duration (ms) or the number of symbols or slots.

[0112] FIG. 14 is a diagram schematically showing a CE which is a MAC control element indicating the runtime of the monitoring sleep timer according to an embodiment. For example, when the UE 100 receives a MAC CE command indicating "0 0 0 0 1 0 0 0", the UE does not monitor the scheduling resources of the PDCCH for 8 ms or 8 slots.

[0113] FIG. 15 is a diagram schematically showing a time sequence of transmission of a scheduling request, reception of a monitoring sleep indicator, and reception of an uplink grant in accordance with an active period according to an embodiment. Specifically, the transceiver 110 transmits a scheduling request for scheduling data and monitors the PDCCH for 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 operating, the transceiver 110 does not monitor the PDCCH for the 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 UL grant.

[0114] That is, the transceiver 110 receives a monitoring sleep indicator (e.g., MAC CE) indicating 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 during a period having the duration indicated by the received MAC CE. Therefore, power saving of the UE can be achieved in a more dynamic manner by considering both the traffic load and the priority of the SR.

[0116] FIG. 16 is a flowchart showing the transmission of a scheduling request, the reception of a monitoring sleep indicator, and the start of monitoring of a physical downlink control channel after the monitoring sleep timer expires.

[0117] After the start of the process, in step S200, it is determined whether the DRX mode is set, that is, whether the UE is in the DRX mode. If it is determined that the UE is not in the DRX mode (step S200, NO), this process is repeated from the beginning. If it is determined that the UE is in the DRX mode (step S200, YES), the process proceeds 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 scheduling data to be transmitted to the scheduling device 200 via the PUCCH. If the scheduling request has not been transmitted (step S210, NO), step S210 is repeated. If it is determined that the SR has been transmitted (step S210, YES), the process proceeds to step S220.

[0119] In step S220, monitoring of the PDCCH is started. In step S230, it is determined whether 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), the monitoring of the PDCCH is repeated. If a MAC CE indicating the runtime of the monitoring sleep timer has been received (step S240, YES), the process continues to step S240.

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

[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), in step S250, it is repeatedly determined whether the monitoring sleep timer has expired. If the monitoring sleep timer has expired (step S250, YES), the process continues to step S260.

[0122] In step S260, the monitoring of the PDCCH is started in order to receive a resource allocation (UL grant) for 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 device 200 using MAC control elements. However, the present disclosure is not limited to transmission using MAC CE, and the runtime of the monitoring sleep timer may be another transmission means. In particular, the scheduling device 200 can transmit a monitoring sleep indicator indicating the runtime of the monitoring sleep timer, and the UE circuit 120 can start the monitoring sleep timer when the monitoring sleep indicator is received.

[0124] Of course, a UL grant may be received via the PDCCH without receiving a monitoring sleep indicator. In such a case, monitoring of the PDCCH due to the pending scheduling request becomes unnecessary.

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

[0126] In the first example, instead of starting to monitor the PDCCH immediately after transmitting the scheduling request, the monitoring sleep timer is started, and monitoring is started after expiration.

[0127] In the second example, when the scheduling request is transmitted, monitoring of the PDCCH is started, and when the monitoring sleep indicator is received, the monitoring of the PDCCH is interrupted 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, PDCCH monitoring cannot be performed between the transmission of SR and the expiration of the monitoring sleep timer, and between the reception of the monitoring sleep indicator and the expiration of each monitoring sleep timer. In other words, the methods of the above-described examples may be combined.

[0129] This is shown in FIG. 17, and the hatched area indicates the period during which the PDCCH is not monitored due to the monitoring sleep timer started when the SR is transmitted. Also, when receiving a MAC CE indicating the runtime of the monitoring sleep timer, the monitoring sleep timer may be restarted at 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] Note that in this case, the monitoring sleep timer according to one or more embodiments may be restarted or restarted by the circuit 120. In other words, when the 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, an additional monitoring sleep timer can be started.

[0131] A scheduling device 200 according to an embodiment can 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 the DRX cycle is set for the transceiver 100. However, the present disclosure is not limited to determining whether the 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 in a set DRX cycle to reduce the power consumption of the UE.

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

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

[0136] During operation, the scheduling device 200 includes a circuit 220 that allocates resources according to a buffer status report indicating the amount of scheduling data and starts a transmission timer. During operation, the scheduling device 200 further includes a transceiver 210 that receives a buffer status report and transmits a resource allocation indicator indicating the resources allocated via a Physical Downlink Control Channel (PDCCH) after the transmission timer expires.

[0137] Furthermore, a method is provided that includes transmitting a buffer status report indicating the amount of scheduling data and starting a monitoring sleep timer after transmitting the buffer status report. Further, the method includes stopping 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 scheduling data when the monitoring sleep timer expires.

[0138] Furthermore, a method is provided that includes receiving a buffer status report indicating the amount of scheduling data and starting a transmission timer. The method further includes allocating resources according to the buffer status report and transmitting a resource allocation indicator indicating the allocated resources via a Physical Downlink Control Channel (PDCCH) after the transmission timer expires.

[0139] The BSR, which is a buffer status report, may be a MAC (Medium Access Control) layer message transmitted by the UE 100 to the serving gNB as the scheduling device 200 to provide the gNB with information regarding 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] Since the BSR reports for each logical channel group (LCG), it is reported in the uplink to inform the gNB 200 about the amount of buffered data in the UE 100, enabling the gNB 200 to distinguish data with different scheduling priorities. In this case, each LCG may be associated with its respective priority level.

[0141] The LCG is a group of uplink logical channels, or a single joint buffer fill level is reported by the UE 100 in the BSR. The mapping of the LCG can 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). The LCG may be defined as a group of logical channels with similar QoS (Quality of Service) requirements.

[0142] The buffer status report can be executed for each LCG by using either the long BSR format or the short BSR format, as shown in FIGS. 18A and 18B respectively. FIG. 18A is a diagram of the short BSR format, and the group of logical channels for which the buffer status is reported is indicated by a 3-bit long logical channel group ID field. Also, the buffer size field indicates the total amount of data. According to the long BSR format shown in FIG. 18B, the BSR includes a plurality of buffer size fields, and each field represents one LCG. In other words, the short BSR format is used to report the data amount of one indicated logical channel group, and the long BSR format is used to report the data amount of all logical channel groups. For example, the network can configure up to eight logical channel groups for each UE according to the QoS (Quality of Service) requirements.

[0143] When the BSR is transmitted during the DRX off period, the UE can switch to the DRX active time when the PDCCH is monitored to receive the uplink grant. This is shown in FIG. 19.

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

[0145] In this way, the transceiver 100 transmits a BSR indicating the amount of scheduling data using the transceiver 110, and starts a monitoring sleep timer after the BSR is transmitted using the UE circuit 120. While the monitoring sleep timer is operating, the transceiver 110 does not monitor the PDCCH for receiving a UL grant corresponding to the transmitted SR. After the expiration of the monitoring sleep timer, the transceiver 110 starts monitoring the PDCCH for receiving a UL grant according to the transmitted BSR, where the UL grant indicates the resources allocated for transmitting the scheduling data.

[0146] The time sequence is schematically shown in FIG. 21, and 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, the monitoring sleep timer is started, and when the timer expires, the UE 100 switches to the active time, and the PDCCH is monitored for the uplink grant. In other words, the switch from non-monitoring of the PDCCH to monitoring of the PDCCH is delayed by a time offset from the transmission of the BSR.

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

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

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

[0150] Table 2 shows, as an example, the fixed values of 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 the LCG having identifiers ID0 to ID7 respectively. For example, when the priority decreases from LGC 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. Defining the runtime / offset in advance eliminates the need for additional signaling.

[0151]

Table 4

[0152] Alternatively or additionally, the runtime of the monitoring sleep timer may be set dynamically by, for example, RRC. By dynamically setting the mapping between the LCG ID and the offset value / runtime of the timer, the network can consider the traffic load and traffic priority and change the runtime / offset value of the timer as needed via RRC (such as via system information messages or dedicated RRC messages).

[0153] For example, the logical channel configuration information element for available RRC signaling 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] When the BSR indicates scheduling data for a plurality of amounts associated with different LCGs, the runtime of the monitoring timer can be set to the runtime associated with the logical channel group with the highest priority, in which case the amount of scheduling data is indicated by 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 can be set to the shortest runtime associated with the LCG, in which case the amount of scheduling data is indicated by the BSR.

[0157] In summary, according to an embodiment of the present disclosure, a transceiver such as the UE100 transmits a scheduling request or a buffer status report, and then starts a dedicated timer, a monitoring sleep timer. As long as this timer has not expired, the UE100 does not monitor the PDCCH for receiving an uplink grant. When the timer expires, the UE starts monitoring the PDCCH. This can reduce energy consumption because the UE100 does not monitor the PDCCH while a scheduling grant is not expected.

[0158] The monitoring sleep timer can 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 the SR may be equal to the runtime of the timer started after transmitting the BSR. However, the present disclosure is not limited to this, and the runtime of the timer started after transmitting the SR may be different from the runtime of the timer started after transmitting the 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, a scheduling request is transmitted from UE100 to gNB200 via PUCCH. Further, in step 2, UE100 receives a scheduling grant from the gNB indicating a resource for transmitting scheduling data. In step 3, UE100 transmits a buffer status report to gNB200 using the indicated resource of PUSCH. In step 4, UE100 receives a scheduling grant for transmitting scheduling data from gNB200. In step 5, UE100 transmits scheduling data using the resource indicated by the received uplink grant.

[0160] As shown in FIG. 23B, according to the present disclosure, after transmitting an SR via PUCCH, UE100 starts a monitoring sleep timer and does not monitor the PDCCH for reception of an uplink grant while the timer has not expired, that is, in a period shown as an offset / sleeping period. After the monitoring sleep timer expires, UE100 monitors the PDCCH in a period shown as a UE wake-up period for reception of an uplink grant.

[0161] Furthermore, as shown in FIG. 23C, after transmitting a BSR, that is, after step 3, the UE starts a monitoring sleep timer and does not monitor the PDCCH while the monitoring sleep timer has not expired, that is, during a period shown as an offset / sleeping period. When the timer expires, UE1200 starts monitoring the PDCCH for reception of an uplink grant.

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

[0163] The present disclosure can be implemented by software, hardware, or software in conjunction with hardware. Each functional block used in the description of each of the above embodiments can be partially or wholly realized by LSI (Large Scale Integration) such as an integrated circuit (IC), and each process described in each embodiment may be partially or wholly controlled by the same LSI or a combination of LSIs. The LSI may be formed as an individual chip, or one chip may be formed to include part or all of the functional blocks. The LSI may include data input / outputs coupled thereto. Here, depending on the degree of integration, the LSI may be referred to as an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for realizing the integrated circuit is not limited to LSI and may be realized using an application-specific circuit, a general-purpose processor, or an application-specific processor. Further, an FPGA (Field Programmable Gate Array) that can be programmed after manufacturing an LSI or a reconfigurable processor in which the connection and setting of circuit cells arranged inside the LSI are reconfigurable may be used. The present disclosure can be realized as digital processing or analog processing. As a result of the progress of semiconductor technology and other derivative technologies, when future integrated circuit technology replaces LSI, the functional blocks can be integrated using future integrated circuit technology. Biotechnology can also be applied.

[0164] The present disclosure can be realized by any type of device, apparatus, or system having a communication function, referred to as a communication device.

[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, smartwatches, tracking devices), game consoles, digital book readers, remote health / telemedicine devices, and vehicles that provide communication capabilities (e.g., automobiles, airplanes, ships), as well as various combinations thereof.

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

[0167] Communication may include, for example, exchanging data via cellular systems, wireless LAN systems, satellite systems, etc., and various combinations thereof.

[0168] The communication device may also include devices such as a controller or sensor coupled to a communication device that performs the communication functions described in the present disclosure. For example, the communication device may include a controller or sensor that generates a control signal or data signal used by the communication device that performs the communication functions of the communication device.

[0169] The communication device may also include an infrastructure facility such as a base station, access point, and any other device, apparatus, or system that communicates or controls with a device such as those in the above non-limiting examples.

[0170] As described above, there are provided an apparatus and a method that enable adaptability and reduce power consumption that indicates scheduling requirements and resource allocation.

[0171] During operation, a transceiver that transmits a scheduling request for scheduling data via a Physical Uplink Control Channel (PUCCH), and a circuit that starts a monitoring sleep timer during operation after the transceiver transmits the scheduling request. The transceiver does not monitor a Physical Downlink Control Channel (PDCCH) during operation while the monitoring sleep timer is operating, and when the monitoring sleep timer expires, starts monitoring the PDCCH for resource allocation for scheduling data. A transceiver device is provided.

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

[0173] In some embodiments, the transceiver receives a monitoring sleep indicator indicating the runtime of the monitoring sleep timer during operation, and the circuit starts the monitoring sleep timer during operation when 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 the 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, the first runtime of the monitoring sleep timer is set for setting a first scheduling request having a first level of priority, and a second runtime different from the first runtime of the monitoring sleep timer is set for setting a second scheduling request having a second level of priority different from the first level of priority.

[0177] For example, when the first level of priority is lower than the second level of priority, the first runtime becomes larger than the second runtime, and when the first level of priority is higher than the second level of priority, the first runtime becomes smaller than the second runtime.

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

[0179] For example, the transceiver receives a scheduling request setting via Radio Resource Control (RRC) during operation.

[0180] In some embodiments, the Discontinuous Reception (DRX) cycle is set to a period during which the transceiver monitors the Physical Downlink Control Channel (PDCCH) during the active period and does not monitor the PDCCH during the inactive period during operation.

[0181] Furthermore, a transceiver that transmits, during operation, at least a buffer status report indicating the amount of scheduling data, and a circuit that starts a monitoring sleep timer after the transceiver transmits the buffer status report are provided. The transceiver does not monitor the Physical Downlink Control Channel (PDCCH) while the monitoring sleep timer is being executed during operation, and when the monitoring sleep timer expires, starts monitoring the PDCCH for resource allocation for scheduling data.

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

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

[0184] In some embodiments, the transceiver receives a monitoring sleep indicator indicating the runtime of the monitoring sleep timer during operation, and the circuit starts a monitoring sleep timer during operation 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 the number of symbols and / or slots of the PDCCH.

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

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

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

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

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

[0191] In some embodiments, the first runtime of the monitoring sleep timer is set for a first logical channel group having a first level of 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 of priority different from the first level of priority.

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

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

[0194] For example, during operation, the transceiver receives a logical channel group runtime indicator via a Radio Resource Control (RRC) message.

[0195] In some embodiments, the Discontinuous Reception (DRX) cycle is set to a period during which the transceiver monitors the Physical Downlink Control Channel (PDCCH) during the active period and does not monitor the PDCCH during the inactive period during operation.

[0196] Furthermore, provided is a scheduling apparatus including: a circuit that allocates resources in response to a scheduling request for scheduling data indicating a transmission timer during operation; and a transceiver that receives a scheduling request via a Physical Uplink Control Channel (PUCCH) during operation and transmits a resource allocation indicator indicating the allocated resources via a Physical Downlink Control Channel (PDCCH) after the transmission timer expires.

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

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

[0199] Furthermore, a scheduling apparatus is provided that includes a circuit that allocates resources and starts a transmission timer according to a buffer status report indicating the amount of scheduling data during operation, and a transceiver that receives the buffer status report during operation and transmits a resource allocation indicator indicating the allocated resources via a Physical Downlink Control Channel (PDCCH) after the transmission timer expires.

[0200] For example, the transceiver receives the buffer status report via a Physical Uplink Shared Channel (PUSCH).

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

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

[0203] In some embodiments, the circuit determines the runtime of a monitoring sleep timer during operation according to a logical channel group.

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

[0205] In some embodiments, the buffer status report indicates, for each amount of scheduling data, a plurality of logical channel groups each associated therewith.

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

[0207] In some embodiments, a first runtime of a monitoring sleep timer is set for a first logical channel group having a first level of 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 of priority different from the first level of priority.

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

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

[0210] For example, during operation, the transceiver transmits the logical channel group runtime indicator via an RRC message that is radio resource control.

[0211] Furthermore, there is provided a method comprising: transmitting a scheduling request for scheduling data via a Physical Uplink Control Channel (PUCCH); starting a monitoring sleep timer after transmitting the scheduling request; stopping monitoring of a Physical Downlink Control Channel (PDCCH) during operation of the monitoring sleep timer; and starting monitoring of a PDCCH for resource allocation for scheduling data when the monitoring sleep timer expires.

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

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

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

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

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

[0217] For example, if the priority of the first level is lower than that of the second level, the first runtime will be larger than the second runtime, and if the priority of the first level is higher than that of the second level, the first runtime will be smaller 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 setting indicator is received via a Radio Resource Control (RRC) message.

[0220] In some embodiments, the Discontinuous Reception (DRX) cycle is set to a period during which the Physical Downlink Control Channel (PDCCH) is monitored during the active period and not monitored during the inactive period.

[0221] Furthermore, a method is provided that includes transmitting a buffer status report indicating the amount of scheduling data, starting a monitoring sleep timer after transmitting the buffer status report, stopping monitoring of the Physical Downlink Control Channel (PDCCH) during operation of the monitoring sleep timer, and starting monitoring of the PDCCH for resource allocation for scheduling data when the monitoring sleep timer expires.

[0222] In some embodiments, the buffer status report is transmitted via the Physical Uplink Shared Channel (PUSCH).

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

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

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

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

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

[0228] In some embodiments, the buffer status report indicates, for each amount of scheduling data, a plurality of logical channel groups respectively associated therewith.

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

[0230] For example, the runtime of the monitoring sleep timer can be set to a runtime associated with an LCG having 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 of 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 of priority different from the first level of priority.

[0232] For example, if the priority of the first level is lower than that of the second level, the first runtime will be larger than the second runtime, and if the priority of the first level is higher than that of the second level, the first runtime will be smaller 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 an RRC message that is radio resource control.

[0235] In some embodiments, a DRX period that 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] Furthermore, there is provided a method having steps of receiving a scheduling request for scheduling data via a PUCCH which is a physical uplink control channel, starting a transmission timer, allocating resources in response to the scheduling request, and transmitting a resource allocation indicator indicating the allocated resources via a PDCCH which is a physical downlink control channel after the transmission timer expires.

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

[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 including the steps of receiving a buffer status report indicating the amount of scheduling data, starting a transmission timer, allocating resources according to the buffer status report, and after the transmission timer expires, transmitting a resource allocation indicator indicating the allocated resources via a Physical Downlink Control Channel (PDCCH).

[0240] For example, the transceiver receives the buffer status report via a Physical Uplink Shared Channel (PUSCH).

[0241] In some embodiments, the method includes determining the runtime of a monitoring sleep timer and transmitting a monitoring sleep indicator indicating 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 the runtime of the monitoring sleep timer according to a logical channel group.

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

[0245] In some embodiments, the buffer status report indicates a plurality of logical channel groups respectively associated with the amount of each scheduling data.

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

[0247] In some embodiments, a first runtime of the monitoring sleep timer is set for a first logical channel group having a first level of 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 of priority different from the first level of priority.

[0248] For example, when the first level of priority is lower than the second level of priority, the first runtime is greater than the second runtime, and when the first level of priority is higher than the second level of priority, the first runtime is smaller 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 that is radio resource control.

Claims

1. During operation, a transceiver that transmits a scheduling request on a physical uplink control channel (PUCCH), and the scheduling request is held until a valid uplink grant is received; During operation, after the transmission of the scheduling request and the monitoring sleep period, a circuit that starts an active period and monitors a physical downlink control channel (PDCCH) during the active period; Comprising: A transceiver device.

2. The length of the monitoring sleep period is dynamically set by radio resource control (RRC). The transceiver device according to claim 1.

3. The length of the monitoring sleep period is indicated in milliseconds (ms), or in the number of symbols or slots. The transceiver device according to claim 1.

4. The active period includes a period during which the scheduling request is transmitted on the PUCCH and held. The transceiver device according to claim 1.

5. The discontinuous reception (DRX) cycle is set to a period during which the transceiver monitors the PDCCH during the active period and does not monitor the PDCCH during the inactive period during operation. The transceiver device according to claim 1.

6. During operation, a transceiver that receives a scheduling request on a physical uplink control channel (PUCCH) from a transceiver device, and the scheduling request is held until a valid uplink grant is transmitted on a physical downlink control channel (PDCCH), and the transceiver device starts an active period of monitoring a physical downlink control channel (PDCCH) after the transmission and monitoring sleep period of the scheduling request; During operation, a circuit that allocates resources in response to the scheduling request; Comprising: A scheduling device.

7. The length of the monitoring sleep period is dynamically set based on a setting by radio resource control (RRC). The scheduling device according to claim 6.

8. A method comprising: Transmitting a scheduling request on a physical uplink control channel (PUCCH), and the scheduling request is held until a valid uplink grant is received; After transmitting the scheduling request and during the monitoring sleep period, start an active period and monitor a physical downlink control channel (PDCCH) during the active period; having a method.

9. A method comprising: During operation, receive a scheduling request from a transceiver on a physical uplink control channel (PUCCH), the scheduling request being held until an active uplink grant is transmitted on a physical downlink control channel (PDCCH), the transceiver starting an active period of monitoring a physical downlink control channel (PDCCH) after transmitting the scheduling request and during a monitoring sleep period; allocating resources in response to the scheduling request; having a method.

10. An integrated circuit for controlling the processing of a transceiver, the processing comprising: transmitting a scheduling request on a physical uplink control channel (PUCCH), the scheduling request being held until a valid uplink grant is received; During operation, starting an active period after transmitting the scheduling request and during a monitoring sleep period, and monitoring a physical downlink control channel (PDCCH) during the active period; having an integrated circuit.

11. An integrated circuit for controlling the processing of a scheduling node, the processing comprising: Receiving a scheduling request from a transceiver on a physical uplink control channel (PUCCH), the scheduling request being held until a valid uplink grant is transmitted on a physical downlink control channel (PDCCH), the transceiver starting an active period of monitoring a physical downlink control channel (PDCCH) after transmitting the scheduling request and during a monitoring sleep period; allocating resources in response to the scheduling request; having an integrated circuit.

Images