USER EQUIPMENT FOR TRANSMITTING UE ASSISTANCE INFORMATION - Patent application
Patent Information
- Application Number
- JP2023184577
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-01-10
- Filing Date
- 2023-10-27
- Publication Date
- 2025-03-03
- Estimated Expiration
- 2039-09-25
Smart Images

Figure 0007638350000002 
Figure 0007638350000003 
Figure 0007638350000004
Abstract
Description
[Technical field]
[0001] The present disclosure relates to methods, apparatus and articles in communication systems, such as 3GPP communication systems. [Background technology]
[0002] Currently, the 3rd Generation Partnership Project (3GPP) is working on technical specifications for the next generation of cellular technology, also known as the fifth generation (5G).
[0003] One challenge is to provide a single technical framework that addresses all usage scenarios, requirements and deployment scenarios (see, for example, section 6 of TR 38.913 version 15.0.0, incorporated herein by reference), including at least enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC). For example, eMBB deployment scenarios may include indoor hotspots, dense urban, rural, urban large and high speed, URLLC deployment scenarios may include industrial control systems, mobile healthcare (remote monitoring, diagnosis and treatment), real-time control of vehicles, wide area monitoring and control systems for smart grids, and mMTC deployment scenarios may include scenarios with a large number of devices with non-time-critical data transfer, such as smart wearables and sensor networks. The services eMBB and URLLC are similar in that they both require very high bandwidth, but differ in that URLLC services may preferably require ultra-low latency.
[0004] The second challenge is to achieve forward compatibility: backward compatibility to Long Term Evolution (LTE, LTE-A) cellular systems is not required, which facilitates the introduction of entirely new system designs and / or novel features. Summary of the Invention
[0005] One non-limiting illustrative embodiment facilitates providing an improved procedure for transmitting UE assistance information from a UE to its serving base station.
[0006] In an embodiment, the techniques disclosed herein feature a user equipment having processing circuitry for determining assistance information to be transmitted to a serving base station of the UE. A transmitter of the UE transmits an assistance report to the serving base station of the UE, the assistance information including the determined assistance information. The number of information bits transmitted by the UE to the serving base station; the transport block size of the transport block used by the UE to transmit information bits to the serving base station; A power level indicating the minimum power used by the UE to transmit information bits to the serving base station; one or more discontinuous reception (DRX) configuration parameters used by the UE to operate a DRX mechanism; Indicates one or more of the following support information types:
[0007] It should be noted that the general or specific embodiments may be realized as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.
[0008] Additional advantages and benefits of the disclosed embodiments will become apparent from the specification and drawings, and advantages and / or benefits may be obtained individually from various embodiments and features of the specification and drawings, and not all of them need be provided to obtain one or more of such advantages and / or benefits. [Brief description of the drawings]
[0009] In the following, exemplary embodiments are explained in more detail with reference to the attached drawings. [Figure 1]1 illustrates an example architecture for a 3GPP NR system. [Diagram 2] 1 illustrates an example user and control plane architecture for LTE eNB, gNB and UE. [Diagram 3] 1 illustrates an uplink data transmission scenario and corresponding optimal scheduling. [Figure 4] 1 illustrates an uplink data transmission scenario and corresponding optimal scheduling. [Diagram 5] An exemplary simplified configuration of a UE and a gNB is shown. [Figure 6] 1 illustrates a configuration of a UE according to an example implementation of the first embodiment. [Figure 7] FIG. 11 is a flow diagram for UE operation according to an exemplary implementation of the first embodiment. [Figure 8] FIG. 11 is a flow diagram for UE operation according to an exemplary implementation of the first embodiment. [Figure 9] 1 illustrates a problem scenario for the DRX mechanism and active time handling. [Figure 10] 1 illustrates a problem scenario for the DRX mechanism and active time handling. [Figure 11] 1 illustrates a configuration of a UE according to an example implementation of the second embodiment. [Figure 12] FIG. 11 is a flow diagram for UE operation according to an exemplary implementation of the second embodiment. [Figure 13] 13 illustrates an interaction of active time extension with UE transmission of data according to an example implementation of the second embodiment. [Figure 14] FIG. 11 is a flow diagram for UE operation according to an exemplary implementation of the second embodiment. [Figure 15] 13 illustrates an interaction of active time extension with UE transmission of data according to another example implementation of the second embodiment. [Figure 16] FIG. 11 is a flow diagram for a UE operation according to another example implementation of the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0010] 5G NR system architecture and protocol stack 3GPP is working on the next resources for the fifth generation of cellular technology, simply called 5G, which includes the development of a new radio access technology (NR) that will operate in frequencies up to 100 GHz range. 3GPP needs to identify and develop the technology components required for successful standardization of an NR system that will meet both immediate market needs and longer-term requirements in a timely manner. To achieve this, the evolution of the radio network architecture together with the air interface is considered in the study item “New Radio Access Technology”. The results and consensus are collected in Technical Report TR 38.804 v14.0.0, which is incorporated herein by reference in its entirety.
[0011] In particular, the overall system architecture assumes a Next Generation-Radio Access Network (NG-RAN) including gNBs providing NG radio access user plane (SDAP / PDCP / RLC / MAC / PHY) and control plane (RRC) protocol termination for UEs. The gNBs are interconnected with each other by an Xn interface. The gNBs are also connected by a Next Generation (NG) interface to a Next Generation Core (NGC), more specifically to an Access and Mobility Management Function (AMF) (e.g., a specific core entity that runs the AMF) by an NG-C interface and to a User Plane Function (UPF) (e.g., a specific core entity that runs the UPF) by an NG-U interface. The NG-RAN architecture is shown in FIG. 1 (see, e.g., 3GPP TS 38.300 v15.2.0, section 4, which is incorporated herein by reference).
[0012] Various different deployment scenarios can be supported (see, for example, 3GPP TR 38.801 v14.0.0, which is incorporated herein by reference). For example, a decentralized deployment scenario (see, for example, section 5.2 of TR 38.801, with a centralized deployment shown in section 5.4) is presented therein, in which base stations supporting 5G NR can be deployed. FIG. 2 illustrates an exemplary decentralized deployment scenario (see, for example, FIG. 5.2.-1 of TR 38.801), while further illustrating an LTE eNB with user equipment (UE) connected to both the LTE eNB and the gNB. The new eNB for NR 5G can be exemplarily referred to as a gNB. The eLTE eNB is an evolution of the eNB that supports connectivity with the Evolved Packet Core (EPC) and the Next Generation Core (NGC).
[0013] The user plane protocol stack for NR (see, e.g., section 4.4.1 of 3GPP TS 38.300 v15.2.0, which is incorporated herein by reference) includes the Packet Data Convergence Protocol (PDCP, see section 6.4 of TS 38.300), Radio Link Control (RLC, see section 6.3 of TS 38.300), and Medium Access Control (MAC, see section 6.2 of TS 38.300) sublayers, which are terminated at the gNB on the network side. Furthermore, a new Access Stratum (AS) sublayer (Service Data Adaptation Protocol, SDAP) is introduced on top of PDCP (see, e.g., sub-clause 6.5 of 3GPP TS 38.300 version 15.2.0, which is incorporated herein by reference). A control plane protocol stack is also defined for NR (see, for example, section 4.4.2 of TS 38.300). An overview of Layer 2 functionality is given in sub-clause 6 of TS 38.300. The functions of the PDCP, RLC and MAC sublayers are listed in sections 6.4, 6.3 and 6.2 of TS 38.300, respectively. The functions of the RRC layer are listed in sub-clause 7 of TS 38.300. The above sections of TS 38.300 are incorporated herein by reference.
[0014] For example, the medium access control layer handles logical channel multiplexing, scheduling and scheduling related functions, including handling different numerologies.
[0015] As for the physical layer, the MAC layer uses services in the form of transport channels. A transport channel can be defined by how and with what characteristics information is transmitted over the radio interface. A Random Access Channel (RACH) is also defined as a transport channel that does not carry transport blocks but is processed by the MAC. One of the procedures supported by the MAC layer is the Random Access Procedure.
[0016] The physical layer (PHY) is responsible for e.g. coding, PHY HARQ processing, modulation, multi-antenna processing and mapping of signals to appropriate physical time-frequency resources. It also handles the mapping of transport channels to physical channels. The physical layer provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for the transmission of a particular transport channel, and each transport channel is mapped to a corresponding physical channel. One physical channel is the Physical Random Access Channel (PRACH) used for random access.
[0017] Use cases / deployment scenarios for NR can include enhanced Mobile Broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC), which have different requirements in terms of data rates, latency, and coverage. For example, eMBB is expected to support peak data rates (20 Gbps in downlink and 10 Gbps in uplink) and user-experienced data rates in the order of three times those offered by IMT-Advanced. On the other hand, the URLLC case requires ultra-low latency (0.5 ms for user plane latency for UL and DL, respectively) and high reliability (1-10 ms latency within 1 ms).-5 Finally, mMTC is preferably designed for high connection density (1,000,000 devices / km in urban environments). 2 ), may require large coverage in harsh environments and extremely long battery life (15 years) for low-cost devices.
[0018] Thus, OFDM numerology (e.g., subcarrier spacing, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) suitable for one use case may not work well for another use case. For example, low latency services may preferably require a shorter symbol duration (and larger subcarrier spacing) and / or fewer symbols per scheduling interval (a.k.a. TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer CP duration than scenarios with small delay spreads. To maintain similar CP overhead, the subcarrier spacing should be optimized accordingly. NR may support multiple values of subcarrier spacing. Correspondingly, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, ... are currently being considered. Symbol duration T u and the subcarrier spacing Δf is expressed by the formula (Δf=1 / T u ) In a similar manner to LTE systems, the term "resource element" can be used to denote the smallest resource unit consisting of one subcarrier for the duration of one OFDM / SC-FDMA symbol.
[0019] In the new radio system 5G-NR, for each numerology and each carrier, a resource grid of subcarriers and OFDM symbols is defined for the uplink and downlink, respectively. Each element in the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain. (See 3GPP TS 38.211 v15.2.0, which is incorporated herein by reference).
[0020] UE Support Information One objective is to achieve lower UE power consumption. One option in this regard is to minimize the duration of uplink transmissions in order to increase the UE's sleep opportunities. This can be done, for example, by aggregating as many data transmissions as possible in each transmission, taking into account the delay requirements to be met for the data transmissions. The gNB should schedule the data transmissions accordingly.
[0021] Figures 3 and 4 show two uplink transmission scenarios. In Figure 3, a UE has traffic with packets of x bits arriving at 5 ms intervals with an exemplary delay supply of 10 ms. In this particular scenario, the most power-saving procedure is to schedule the UE at least every 10 ms with an estimated Transport Block Size (TBS) of 2X bits to allow the UE to sleep the remaining time.
[0022] In Fig. 4, it is exemplarily assumed that the UE has traffic with packets of x bits arriving at 10 ms intervals with an exemplary delay requirement of 25 ms. In this scenario, a different scheduling is optimal than in the scenario of Fig. 3. That is, the UE is scheduled at least every 25 ms with an estimated TBS of 5X bits.
[0023] In both cases, the continued sleep opportunity is maximized while still complying with the delay requirements for data traffic in the uplink.
[0024] For example, the gNB needs to schedule the UE with suitable timing and number of information bits / TBS, also taking into account the available UE power for better power saving, which may depend on the packet delay requirement and traffic type.
[0025] However, the inventors have recognized that the gNB (at least for the uplink) does not have sufficient information to determine an optimal scheduling strategy, and therefore the scheduling parameters and opportunities provided by the gNB to the UE may not be optimal.
[0026] For uplink traffic, the UE has better knowledge of expected UL-directed traffic characteristics such as packet size, arrival / delivery intervals, delays, etc. A corresponding higher layer (e.g., application layer) can, for example, pass information of (e.g., long-term) traffic characteristics to a lower layer (e.g., RRC and / or MAC).
[0027] To address this issue, the UE provides assistance information to the gNB so that the gNB knows when and how to schedule the UE's uplink traffic to optimize power savings.
[0028] As a result, the inventors have identified the possibility of realising the transmission of UE assistance information according to the following solution.
[0029] In the following, UEs, base stations, and procedures for meeting these needs are described for a 5G mobile communication system, but for a new radio access technology that may also be used in an LTE mobile communication system. Different implementations and variations are also described. The following disclosure may be facilitated by, and may be based, for example, at least in part on, the discussions and discoveries as set forth above.
[0030] In general, it should be noted that many assumptions are made herein so that the principles underlying the present disclosure can be explained in a clear and understandable manner. However, these assumptions should be understood as merely examples made here for illustrative purposes that should not limit the scope of the present disclosure. Those skilled in the art will recognize that the principles provided in the following disclosure and claims can be applied to various scenarios and methods not explicitly described herein.
[0031] Furthermore, some of the terms such as procedures, entities, layers, etc. used below are closely related to those used in the LTE / LTE-A system or current 3GPP 5G standardization, but the specific terms used in the context of new radio access technologies for the upcoming 3GPP 5G communication system have not yet been fully determined. Thus, the terms may be changed in the future without affecting the functionality of the embodiments. Therefore, those skilled in the art will recognize that the embodiments and their scope of protection should not be limited to the specific terms used illustratively herein due to the lack of newer or finally agreed upon terms, but should be more broadly understood with respect to the functions and concepts underlying the functions and principles of the present disclosure.
[0032] For example, a mobile station, mobile node, user terminal or user equipment (UE) is a physical entity (physical node) in a communication network. A node may have multiple functional entities. A functional entity represents a software or hardware module that realizes and / or provides a given set of functions to other functional entities of the same or other nodes or the network. A node may have one or more interfaces that attach the node to communication facilities or media over which the node can communicate. Similarly, a network entity may have logical interfaces that attach a functional entity to communication facilities or media over which it may communicate with other functional entities or corresponding nodes.
[0033] Here, a "base station" or "radio base station" refers to a physical entity in a communication network. Similar to a mobile station, a base station may have several functional entities. A functional entity refers to a software or hardware module that realizes and / or provides a given set of functions to other functional entities of the same or another node or network. A physical entity performs several control tasks for a communication device, including one or more of scheduling and configuration. It should be noted that base station functions and communication device functions may also be integrated in a single device. For example, a mobile terminal may also realize the functions of a base station for other terminals. The term used in LTE is eNB (or eNodeB), while the term currently used for 5G NR is gNB.
[0034] 5 shows a schematic simplified exemplary block diagram of a user equipment (also called communication device) and a scheduling device (here assumed to be exemplarily located in a base station, e.g. an eLTE eNB (alternatively called ng-eNB) or a gNB in 5G NR5). The UE and the eNB / gNB communicate with each other via (radio) physical channels using respective transceivers.
[0035] A communication device may include a transceiver and a processing circuit. The transceiver may then include and / or function as a receiver and a transmitter. The processing circuit may be one or more hardware such as one or more processors or any LSI. Between the transceiver and the processing circuit, there may be input / output points (or nodes) where the processing circuit can control the transceiver in operation, i.e. control the receiver and / or transmitter and exchange receive / transmit data. The transceiver may include an RF (radio frequency) front including one or more antennas, amplifiers, RF modulators / demodulators, etc. as a transmitter and receiver. The processing circuit may realize control tasks such as controlling the transceiver to transmit user data and control data provided by the processing circuit and / or to receive user data and control data that are further processed by the processing circuit. The processing circuit may also be for performing other processes such as decisions, judgments, calculations, measurements, etc. The transmitter may be for performing the transmitting process and other processes related thereto. The receiver may be for performing the receiving process and other processes related thereto, such as monitoring the channel, etc.
[0036] Example 1 A first embodiment is described below with respect to FIGS.
[0037] Figure 6 illustrates a simplified exemplary UE configuration according to the present solution, which can be realized based on the general UE structure described above in connection with Figure 5. The various structural elements of the illustrated UE can be interconnected with each other, e.g., using corresponding input / output nodes (not shown), e.g., for exchanging control and user data and other signals. Although not shown for illustrative purposes, the UE may include further structural elements.
[0038] As will be apparent therefrom, the UE may include an assistance information determining circuit and an assistance report transmitter to participate in an improved procedure for transmitting UE assistance information, as described below.
[0039] In the present case, as will become apparent from the disclosure below, the processing circuitry can therefore be exemplarily configured to at least partially perform one or more of the steps of determining assistance information (e.g. different types thereof) and determining different intermediate parameters for deriving the assistance information.
[0040] The transmitter may then be configured to at least partially perform one or more of the steps of transmitting the assistance information, for example in an assistance report, and transmitting the uplink data.
[0041] FIG. 7 is a sequence diagram for UE operation according to the improved assistance information transmission procedure.
[0042] Illustratively, it is assumed that the UE is exchanging data, e.g., uplink data traffic from a particular application, with its serving base station (e.g., a gNB), and the UE is configured to assist the gNB in determining optimal uplink scheduling for allocating radio resources to the UE for transmitting the uplink data traffic.
[0043] To this end, the UE may determine assistance information and transmit the assistance information to the serving base station, eg, as part of an assistance report.
[0044] There may be various types of assistance information that can help the serving base station to make optimal uplink scheduling decisions. That is, the assistance information may be indicative of one or more of the following: The number of information bits transmitted by the UE to the serving base station for each scheduling For each scheduling, the transport block size of the transport block used by the UE to transmit information bits to the serving base station A power level indicating the minimum power used by the UE to transmit information bits to the serving base station. One or more discontinuous reception,DRX,configuration parameters used by the UE to operate the DRX,mechanism.
[0045] More detailed exemplary implementations of these different types of information are presented further below.
[0046] In general, the assistance information relates to uplink traffic expected to occur by the UE in the near future and thus provides the gNB with suitable information to adapt / optimize the uplink scheduling performed by the gNB to these future data traffic. For example, providing the assistance information to the gNB may facilitate the gNB to optimize the uplink scheduling with respect to power saving for the UE.
[0047] In response, the UE receives an uplink assignment message (e.g., DCI) from the gNB and performs a corresponding uplink transmission of data.
[0048] However, although the main use of the assistance information is to assist uplink scheduling in the gNB, the use of the assistance information by the gNB is not limited thereto, and the assistance information may also or instead be used for other purposes such as downlink scheduling, load balancing, handover decision making, etc.
[0049] As mentioned above, there are several different types of information that can be transmitted to the gNB as assistance information. In the following, each type is described, including the advantages that can be derived therefrom when used by the gNB to make uplink scheduling decisions.
[0050] The assistance information may indicate the number of information bits to be transmitted by the UE to the gNB (i.e., suggested for each scheduling of the UE). More specifically, the UE may attempt to predict future data traffic in the uplink, for example from traffic characteristics available at higher layers. In one exemplary solution, the number of information bits may be determined by the UE from a typical packet size of the uplink traffic, a typical arrival time of the uplink traffic, and / or a delay requirement to be met for the uplink traffic.
[0051] More specifically, a typical packet size may be determined to be the size of packets from a particular layer driven by one or more traffic / services, e.g., generated by an application layer or segmented / concatenated by a higher layer.
[0052] In one exemplary solution, the number of information bits may be determined based on the following formula: I=U*ceiling(L / T) where I is the number of information bits, L is the delay requirement to be met, T is the typical arrival time of uplink traffic, and “ceiling()” is the ceiling function.
[0053] The information on the number of information bits to be transmitted in the uplink is available to the gNB to determine an appropriate transport block size (TBS) (see, for example, 3GPP TS 38.214 and 3GPP 36.213). Furthermore, the gNB can estimate and determine the appropriate bandwidth portion to be used by the UE and can perform the switching and configuration of the bandwidth required for this new bandwidth portion. This allows to minimize the transmission duration and meet the delay requirement by an optimal uplink scheduling, which can also realize the aggregation of traffic of different transmissions by the UE.
[0054] The assistance information may further indicate a transport block size. As with the number of information bits, the UE may attempt to predict future traffic in the uplink and based thereon predict an expected transport block size optimally required in this regard. For example, the transport block size may be determined from one or more of the number of information bits, the coding rate and the modulation order.
[0055] In one example solution, the transport block size may be determined based on the following formula: TBS=I*C / M where TBS is the transport block size to be determined, I is the number of information bits, C is the coding rate, and M is the modulation order.
[0056] The coding rate and modulation order may then be determined from the modulation scheme used by the UE to transmit uplink data to the gNB. In case information about the modulation scheme is not available to the UE, the UE may also use, for example, a reference modulation scheme that is primarily used to determine the assistance information, or may use a modulation scheme previously used by the UE to transmit uplink data (e.g., from a previous uplink radio position).
[0057] When the gNB receives such expected transport block size, it can directly use the same for uplink scheduling, i.e., schedule the UE with the proposed TBS. Furthermore, the base station can estimate and determine the appropriate bandwidth portion to be used by the UE in a similar manner as already described above for the number of information bits. Correspondingly, the gNB can also perform a switching and setting of the requested bandwidth portion for this new bandwidth portion. This allows the gNB to minimize the transmission duration and meet the delay requirement.
[0058] The assistance information may further indicate a (minimum) power level to be used by the UE to transmit data on the uplink, for example, the power level may be determined based on one or more of the number of information bits, the frequency bandwidth required to transmit the information bits on the uplink, and a path loss measurement (e.g., the last one) of a communication channel between the UE and the gNB.
[0059] In one example solution, the power level may be determined based on the following formula: P=10*lg(BW)+P O +alpha*PL where P is the power level, BW is the frequency bandwidth, and the parameter P O and alpha are set by higher layers in RRC messages. These two power control parameters are set, for example, by RRC (see, for example, 3GPP TS 38.123, TS 36.213, TS 38.331, and TS 36.331). For example, P O is the target power, alpha is a power compensation factor, and the frequency bandwidth BW can be determined by the UE from the estimated information bits and MCS level.
[0060] From this power level information, the gNB can determine whether the UE has enough power to allocate a particular bandwidth portion in the uplink, for example. Furthermore, the base station can also estimate whether the UE has enough power to schedule radio resources for aggregating different traffic. This can enable the gNB to determine the appropriate number of bits and bandwidth for a scheduling opportunity to reduce the UE's power consumption.
[0061] The assistance information may further signal one or more parameters related to the DRX mechanism used by the UE. In particular, it is exemplarily assumed that the UE and the gNB have configured a discontinuous reception (DRX) mechanism for the UE. In an exemplary implementation for 5G, the DRX mechanism as currently specified for 5G is available (see, for example, TS 38.321, together with 3GPP TS G38.331 sections 4.4 and 6.3.2). Correspondingly, the DRX mechanism operates according to some DRX parameters, such as drx-onDurationTimer, drx-InactivityTimer, drx-LongCycle, drx-ShortCycle, etc., as described in the above-mentioned 3GPP Technical Standard.
[0062] The UE may include a suggestion of values for one or more of the DRX parameters in the assistance information, where the suggested DRX parameter values are different from the values of the respective DRX parameters currently used by the UE to operate the DRX mechanism. Since the UE may select a preferred scheduling interval and active duration based on the traffic inter-arrival time estimate and delay requirement, the UE may decide to modify one or more DRX parameters. Thus, the proposed DRX cycle can be aligned or close to the scheduling interval suggested by the UE. Optionally, the desired active duration can be aligned or close to the drx-onDurationTimer suggested by the UE. Alternatively, the UE directly suggests one DRX configuration index from multiple DRX configurations configured by the gNB.
[0063] Upon receiving such DRX parameter suggestions, the gNB may decide whether or how to adapt the DRX mechanism, e.g., to improve power saving possibilities for the UE. For example, the gNB may schedule the UE with the proposed DRX configuration. Optionally, the gNB may change some of the parameters of the DRX configuration used by the UE as proposed.
[0064] In the above discussion, different types of assistance information have been discussed to compile the assistance information transmitted to the gNB. So far, it has been exemplarily assumed that the different types of assistance information represent the complete UE behavior. Additionally or alternatively, the different types of assistance information can also be determined for a part of the UE behavior, such as, for example, per type of traffic, per logical channel group, or per (higher layer) application. For example, the assistance information may be limited to only high priority traffic, low latency traffic, etc.
[0065] For example, the assistance report can be in a format associated with a particular type of traffic or logical channel group or application. The assistance report can include multiple parameter sets, each parameter set having an index and linked to a particular type of traffic or logical channel group or application.
[0066] For example, a UE may be exemplarily assumed to have two different traffic types, such as a first one for traffic with low delay requirements and a second one for relatively high delay tolerant traffic. Correspondingly, in one implementation, some or all of the assistance information may be generated separately for the two available traffic types and then transmitted jointly or separately to the gNB. More specifically, the number of information bits, transport block size, power level and DRX settings (or parameters thereof) may be specific to a particular traffic type.
[0067] In such an exemplary scenario, the assistance information may further indicate, for example, a particular traffic type to which the assistance information relates, which is advantageous since the gNB may determine an optimized scheduling strategy to save the UE's power consumption by determining suitable scheduling parameters based on the assistance information specific to this traffic type.
[0068] Similarly, it may be exemplarily assumed that the UE has data to be transmitted according to two different logical channel groups. Logical channel groups are typically and exemplarily used in the context of buffer status reporting (see, for example, 3GPP TS 38.321 v15.0.0 section 5.4.5), where logical channels with similar scheduling requirements can be grouped together in one logical channel group for buffer status reporting. This concept can be reused to improve the assistance information reporting procedure discussed so far, i.e., by compiling the assistance information per logical channel group.
[0069] More specifically, the number of information bits, transport block size, power level and DRX settings may be specific to a particular logical channel group.
[0070] In such an exemplary scenario, the system information may further indicate, for example, a particular logical channel group to which the assistance information relates, which is advantageous since the gNB may determine an optimized scheduling strategy to save the UE's power consumption by determining suitable scheduling parameters based on the assistance information specific to this logical channel group.
[0071] In the above solution, it is exemplarily assumed that different support information types directly notify absolute values representing the types of information. For example, the bit number information indicates, for example, 5000 bits, and indicates a value directly indicating the number of bits.
[0072] Alternatively, however, other exemplary solutions may use differential values rather than absolute values to indicate assistance information parameters. For example, instead of indicating an absolute value (such as 5000 bits), the assistance information may indicate a differential value such as +1000 bits, which together with a corresponding reference value (here, for example, 4000 bits) results in an absolute value that properly indicates the assistance information. For example, when the UE determines the assistance information, it first determines its absolute value, and then determines a differential value based on a specific reference value, which is encoded into the assistance information transmitted to the gNB. The corresponding determination is performed on the gNB side using the reported assistance information differential value together with the corresponding reference value (the same is used by the UE) to finally obtain the absolute value of a specific assistance information type parameter.
[0073] There are different options on how to define the reference value to obtain the difference value, for example the reference value can be obtained from a previous report of assistance information or from a previous radio resource allocation (e.g. TBS or power level).
[0074] The use of difference values rather than absolute values can reduce the number of bits of the aiding information since fewer different values are required for each aiding information type.
[0075] Furthermore, the absolute and / or difference values may also be coded as indices related to the values themselves, rather than as the values themselves. For example, for each assistance information type, there may be a table with multiple different indices (e.g., 8 in total, using 3 bits), each index associated with a different absolute or difference value of the assistance information type. When using TBS for illustrative purposes, 8 different TBS values may be coded with a 3-bit index. Compared to coding the assistance information values (e.g., TBS values) directly, more bits are required, which may further reduce the number of bits of the assistance information.
[0076] In the above-mentioned solution, it was assumed that the assistance information is reported by providing (at least) one separate value for each assistance information type. For example, assuming that the assistance information report includes assistance information for TBS, power level and DRX configuration, the assistance information report includes one value indicating the TBS, one value indicating the power level and at least one value indicating at least one DRX suggested configuration parameter. However, in addition or instead, a joint index can be used to indicate a combination of two or more assistance information types.
[0077] In the following, an exemplary implementation of a joint index is presented, where one index indicates a combination of two different assistance information types, in particular a combination of a power level and a TBS. It is further exemplary assumed that the TBS is not coded as a number of bits, but its size is classified as high, medium, low or 0. [Table 1]
[0078] Correspondingly, the assistance information report may signal a joint index of 1 (eg, 000 as a 3-bit value) to jointly indicate a power level of 23 dB and a high transport block size.
[0079] The above-mentioned association between different indexes and different assistance information parameters (or combinations of parameters) can be established between the UE and the gNB using an RRC message, such as an RRCConnectionReconfiguration message.
[0080] There are different ways how the assistance information, respectively the assistance report, can be transmitted by the UE to the gNB. In one exemplary solution, the assistance report can be transmitted as uplink control information in the physical layer (see 3GPP TS 38.212 or TS 38.21).
[0081] Additionally or alternatively, the assistance report can be transmitted as a Medium Access Control (MAC Protocol) Control Element (see 3GPP TS 38.321).
[0082] Additionally or alternatively, the assistance report can be sent as a message (e.g., information element) of the Radio Resource Control protocol (see 3GPP TS 38.331). New information elements of the RRC can be used for this, or existing ones such as the "UEAssistanceInformation" IE can be extended to carry this new UE assistance information, as described above (see 3GPP TS 36.331 v15.3.0 section 6.2.2 pages 371-374).
[0083] In an optional implementation, the report can be associated with one of the configured DRX configurations representing the suggested scheduling interval. If the report is not associated with a DRX configuration, the report can be interpreted by the gNB to schedule the UE with at least the corresponding assistance information (e.g. information bit size or TBS) reported therein when the UE's buffer becomes larger than a certain value.
[0084] In the above exemplary solutions, it was assumed that the assistance information is transmitted to assist uplink scheduling. However, the above solutions and implementations are not limited to only providing uplink assistance information. Additionally or alternatively, the UE can provide assistance information to the gNB to assist downlink scheduling. The various solutions, variants and implementations described above for the uplink are equally applicable for downlink assistance, and thus repetition of the above description is avoided. For example, different assistance information types can be useful to assist the gNB in downlink scheduling, such as the number of information bits transmitted from the serving base station to the UE, the transport block size of the transport block used by the serving base station to transmit the information bits to the UE, and / or one or more DRX configuration parameters used by the UE to operate the DRX mechanism. Some or all of this information can be obtained from a higher layer, e.g., an application layer, which knows how much data is to be downloaded.
[0085] The downlink assistance information may be transmitted to the gNB together with or separately from the uplink assistance information.
[0086] In the above exemplary solution, different assistance information types are described that can be transmitted to the gNB in the corresponding assistance information report. In one exemplary implementation, the UE can determine by itself which information should be transmitted to the gNB, e.g., which type of assistance information is worth transmitting to the gNB to assist the gNB in optimizing uplink scheduling for the UE. Meanwhile, the selection of the assistance information type reported to the gNB may be pre-configured by the gNB, e.g., by using an RRC message.
[0087] The following embodiment is illustrated by a practical scenario in which a UE is assumed to transmit information bits for two different logical channel groups LCG#1 and LCG#2. In particular, it is exemplarily assumed that the UE estimates a TBS of 5000 bits for LCG#1 associated with a DRX configuration having a period of 10 ms (e.g., the packet delivery delay is 10 ms, so that a DRX configuration with a period of 10 ms is suitable), while the UE estimates a TBS of 10000 bits for LCG#2 associated with a DRX configuration with a period of 20 ms.
[0088] Based on the modulation and coding scheme used in the previous (e.g., most recent) uplink grant (or at a different configured reference MCS value), the UE estimates the subsequently required frequency bandwidth (e.g., number of PRBs (Physical Resource Blocks)) and further estimates the required power level (e.g., 10 dBm for LCG#1 and 13 dBm for LCG#2). The UE then compiles assistance information regarding power levels and TBS into a corresponding assistance information report and sends it to the gNB. By utilizing the TBS and power level information to the gNB (e.g., rather than directly providing bandwidth portion information), the gNB may be provided with more accurate information to determine the most power-efficient uplink scheduling strategy for both LCGs with better traffic adaptation.
[0089] The gNB may then determine, based on the report and taking into account other UEs serving its radio cell, the appropriate uplink bandwidth portion and scheduling slot to be used to schedule the UE for which the report was received. Since the received UE assistance information report is for multiple LCGs, the gNB may also try to consider traffic aggregation across different LCGs, if possible. Taking everything into account, the gNB may perform uplink scheduling and, for example, allocate a suitable uplink bandwidth portion, where the UE is scheduled every 10 ms and kept in sleep for the remaining 9 ms. In slot #2n*10 (20, 40, 60, 80, ...), a larger bandwidth portion is utilized, with a transport block size of 15000 bits, since the power of 14.7 dBm (10 dBm + 13 dBm) available to the UE is sufficient for both traffics at the same time. Aggregating packets of two different logical channel groups allows minimizing the scheduling duration and thus allows the UE to save power.
[0090] On the other hand, in slot #(2n+1)*10 (10, 30, 50, 70, ...), the UE may be scheduled with a smaller bandwidth and with a transport size of only 5000 bits for LCG #1.
[0091] In a corresponding exemplary variant of implementation, if no relevant DRX configuration is reported in the assistance information, the gNB schedules the UE when the accumulated buffer exceeds the TBS suggested in the report.
[0092] FIG. 8 is a sequence diagram for UE operation according to a more detailed exemplary implementation of the above solution. In particular, compared with the more basic flow diagram of FIG. 7, the UE first determines whether it is configured to provide assistance information to the gNB and proceeds only in the affirmative. The UE may then use the arrival of new data traffic as a trigger to determine and report assistance information to the gNB. As described above, the gNB may determine optimal scheduling for the UE based on the received assistance information and provide a corresponding uplink grant to the UE. In response, the UE receives an uplink grant scheduled based on the previously reported assistance information. The UE may then perform uplink transmission (e.g., PUSCH) based on the received uplink grant.
[0093] Example 2 A second embodiment is described below with respect to figures 9-16. The second embodiment relates to an improvement of the utilization of active time in the UE. More specifically, the inventors have recognized the problem that UL data traffic can be somewhat dynamic and can arrive just at the end of the UE active period of the DRX mechanism. In this case, the UE may not be able to react properly to the new data arrival before entering the DRX off period of the DRX mechanism. Furthermore, this may cause unnecessary UE transitions to sleep periods, with ramping down and up of the power consuming RF unit and possibly other hardware parts.
[0094] These problematic scenarios are shown diagrammatically and exemplarily in Fig. 9 and Fig. 10. As is evident therefrom, new data arrivals are close to the end of the active period. In the exemplary scenario of Fig. 9, the UE does not even have time to transmit a BSR (Buffer Status Report indicating new data) or a Scheduling Request (SR) to the gNB (BS, the illustrated base station) if no BSR resources are available. Correspondingly, the UE enters a DRX off period of the DRX mechanism to save power, ramps down when it comes out of the DRX off period, and finally ramps up. During the next active period, the UE gets the opportunity to transmit a BSR to the gNB. It is exemplarily assumed that the gNB responds with an uplink grant (PDCCH) that the UE can receive during the active period (during the active period, the UE monitors the PDCCH). The UE can then transmit the previously arrived data to the gNB in the uplink. Such a situation gives rise to higher power consumption due to the associated ramping down and ramping up, together with delays in transmitting data to the gNB.
[0095] On the other hand, as shown in Figure 10, the UE may have enough time to transmit a BSR to the gNB, but there is no time for the gNB to process the BSR (e.g., received in the MAC CE) and transmit a PDCCH to the UE before the UE leaves the active time (and thus stops monitoring the PDCCH). Scheduling the terminal for uplink transmission is only possible in the next active period of the normal DRX mechanism.
[0096] The second embodiment provides a solution to this problem by implementing a mechanism for extending the active time, as described below.
[0097] The UE is exemplarily assumed to be configured with a typical DRX mechanism whereby periods of active time (where normal communication is possible including monitoring of the PDCCH) alternate with sleep periods for the UE (DRX off allowing power saving opportunities).
[0098] Figure 11 illustrates a simplified exemplary UE structure according to the present solution, which can be realized based on the general UE structure described above in connection with Figure 5 above. The various structural elements of the illustrated UE can be interconnected between each other, e.g., by corresponding input / output nodes (not shown), e.g., for communicating control and user data and other signals. Although not shown for illustrative purposes, the UE may include further structural elements.
[0099] As will be apparent therefrom, the UE may include an extension request transmitter, an active time extension determination circuit, and an extended active time processing circuit to participate in an improved procedure for performing an active time extension, as described below. Thus, in this example, the processing circuit can be exemplarily configured to at least partially perform the step of autonomously determining to extend the active time upon transmitting the extension request. Thus, the transmitter can be exemplarily configured to at least partially perform the step of transmitting the extension request.
[0100] FIG. 12 is a sequence diagram of a UE operation according to an improved active time handling procedure for extending the active time by the UE.
[0101] To extend an ongoing active time, the UE may send an extension request to its serving base station (gNB) and then autonomously decide to extend the active time. For example, the UE extends the active time by itself after sending the extension request without waiting for a response from the gNB. Thereby, the UE does not follow the normal DRX process to enter the DRX off time, but rather stays in the extended active time, so that the "normal" DRX process is temporarily suspended. The UE accordingly proceeds to operate according to the extended active time.
[0102] Thereby, unnecessary transitions of the UE to sleep, along with the associated ramping-down and ramping-up power overhead, may be avoided.
[0103] According to one example, the UE operations during the extended active time may be similar or identical to those during the normal active time of the DRX mechanism, for example, the UE operations may include PDCCH monitoring, PDSCH reception, and PUSCH transmission, etc.
[0104] Continuing to operate in accordance with the extended active time facilitates the UE completing the process that initially triggered the UE to extend the active time in the first place.
[0105] Extending the active time according to any one of the solutions and variants described herein may be triggered for various reasons, such as the arrival of new data (mentioned in connection with Figures 9 and 10), the need to send a Power Headroom Report (PHR), or the UE already knowing that new data is coming in the near future, even though the new data is not immediately available for transmission.
[0106] Assuming exemplarily that the arrival of new data triggers the extension of the active time, the UE is scheduled according to the uplink radio resources to transmit a Buffer Status Report (BSR) to the gNB during the extended active time and then perform uplink transmission of the new data. This is illustrated in Figure 13, which shows that during the extended active period, the BSR is transmitted by the UE to the gNB, the PDCCH is transmitted from the gNB to the UE, and the uplink transmission is performed by the UE.
[0107] There are several options as to how the extended active time can end. One exemplary option is to extend the active time for a determined time. This length of the extended active time can be pre-configured, for example, between the UE and the gNB, for example, by means of RRC. According to a different option, the length of the extended active time can be unilaterally determined by the UE, for example, based on a trigger event for extending the active time. Optionally, information regarding the determined length of the extended active time can be transmitted to the gNB, for example, together with the extension request. Yet another option is to extend the active time until the next active time of a normal DRX mechanism (not shown).
[0108] FIG. 14 is an example sequence diagram for UE operation according to one of the solutions, which extends the UE operation shown in FIG. 12 by providing a general determination as to whether the extended active time has elapsed. If the extended active time has not elapsed, the UE continues to operate according to the extended active time. Conversely, if the extended active time has ended (e.g., after a few ms), the UE comes out of the extended active time and continues to operate according to the normal DRX mechanism. For example, the scenario in FIG. 13 assumes that the normal DRX process upon ending the extended active time is still DRX off time.
[0109] According to yet another option, terminating the extended active time is requested by the UE from the gNB using a sleep request, as described below. Figures 15 and 16 illustrate this solution. Figure 16 is an example sequence diagram for a UE operation according to this solution, which extends the UE operation shown in Figure 12, when the UE determines that the extended active time is terminated, by providing a sleep request to the gNB (base station BS in the figure) for transmission to the gNB. The UE further checks whether a sleep indication is received from the gNB (sent by the gNB in response to the sleep request). When such a sleep indication is not received, the UE continues to operate according to the extended active time. Upon receiving such a sleep indication from the gNB, the UE may exit the extended active time and continue to operate according to the normal DRX mechanism.
[0110] One advantage that can be obtained by utilizing a sleep request is that the length of the extended active time can be flexibly adapted to the traffic conditions at the UE. For example, when requesting an extended active time, the UE may be scheduled with a higher TBS and power thereafter, so that the uplink transmission of data can be finished earlier and thus the sleep request can be sent earlier. On the other hand, if the UE is scheduled with a lower TBS and power, the UE will take longer to transmit data on the uplink and the sleep request will be sent later. However, in either case, the length of the extended active time corresponds to the time actually needed by the UE, thus providing optimal power saving while still allowing early data transmission.
[0111] The sleep request is sent by the UE to exit the extended active time, but the use of the sleep request can be extended to exit the normal active time of the DRX mechanism. In such a case, illustratively, the UE may send a sleep request during the normal active time, for example, when it determines that no traffic is expected and there is a further opportunity to sleep and save power. In the same or similar manner as described above, the UE sends a sleep request to the gNB and, upon receiving a corresponding sleep indication, enters the DRX off period until the next opportunity in the active time of the DRX mechanism.
[0112] As mentioned above, the extension of the active time can be determined by the UE for a combination of different reasons. Furthermore, the extension request sent by the UE can be extended by a notification suitable for providing the gNB with information about why the active time request was sent by the UE. Correspondingly, the UE may send the extension request together with a notification about one or more of new data to be sent to the serving base station, a new buffer status report sent by the UE to the serving base station, or a new power headroom report sent by the UE to the serving base station.
[0113] According to one exemplary solution, the further information may indicate one or more of the following: Newly arrived BSR - No data to send immediately, but the drx-Inactivity Timer has not expired Suggested DRX_On extension period is 5ms Recent PHR Still have at least x information bits / TBS to transmit and extend DRX_ON Estimated required power levels for newly arrived data
[0114] Furthermore, there are several possibilities regarding how exactly the active time extension request can be transmitted to the gNB. In general, the UE may utilize PUCCH or PUSCH resources. For example, the UE may utilize PUCCH resources available until the end of DRX_ON (active time). In particular, the extension request can be transmitted on any of the configured resources within the period until the end of the active time, such as periodic resources every 5 ms. One possible exemplary configuration is that the extension request is transmitted at the last opportunity / time within the configured period. Illustratively, the UE can reuse the configured radio resources to transmit the scheduling request and / or extend the current scheduling request notification to carry the active time extension request.
[0115] In another solution, the UE can send the extension request as an uplink control information (UCI) or MAC control element on the PUSCH resource, assuming that a suitable PUSCH resource is available. Again, the UE may utilize the PUSCH resource that is the last available resource before the active time expires.
[0116] In one further example solution, whether the UE may utilize resources other than those at the very end of the active time may depend on the information transmitted together with the extension request and / or the reason for extending the active time. For example, the active time extension request may be transmitted only at the last opportunity in the active time when the reason is the transmission of a power headroom report or the arrival of new data (new BSR) or new data in the near future.
[0117] Furthermore, the second embodiment described herein may also be combined with the first embodiment described above. For example, a request for an active time extension can be sent to the gNB together with assistance information. In one example solution, the assistance information sent to the gNB in the case where the active time is extended is: The number of bits expected to be transmitted by the UE to the serving base station The power level required to transmit new data sent by the UE to the serving base station This allows the effects of the first and second embodiments to be combined.
[0118] Further Aspects According to a first aspect, a UE is provided having a processing circuit for determining, during operation, assistance information to be transmitted to a serving base station of the UE. A transmitter of the UE transmits an assistance report to the serving base station of the UE, the assistance information including the determined assistance information. The assistance information may be one of the following assistance information types: The number of information bits transmitted by the UE to the serving base station; the transport block size of the transport block used by the UE to transmit information bits to the serving base station; A power level indicating the minimum power used by the UE to transmit information bits to the serving base station; One or more discontinuous reception (DRX) configuration parameters used by the UE to operate the DRX mechanism.
[0119] According to a second aspect provided in addition to the first aspect, the UE further comprises a receiver configured to receive, during operation, a radio resource allocation from a serving base station usable by the UE for performing uplink transmissions.
[0120] According to a third aspect provided in addition to the first or second aspect, the assistance report is optionally transmitted in an information element of an RRC protocol message, such as Uplink Control Information (UCI) of the physical layer, a Medium Access Control (MAC) Control Element, or a Radio Resource Control (RRC) protocol message.
[0121] According to a fourth aspect provided in addition to any of the first to third aspects, the number of information bits is A typical packet size U of the uplink traffic transmitted by the UE to the serving base station; Typical arrival time of uplink traffic, T, The delay requirement L to be met for the uplink traffic, determined by the UE based on one or more traffic characteristics, such as at least one of: Optionally, the number of information bits I is: I=U*ceiling(L / T) It is determined based on the formula:
[0122] According to a fifth aspect provided in addition to any of the first to fourth aspects, the processing circuitry is adapted to, during operation: Number of information bits I, · Coding rate C, Modulation order M, determining a transport block size of the transport block based on at least one of Optionally, the transport block size (TBS) is TBS=I*C / M is determined based on the formula: Optionally, the processing circuitry determines the coding rate and modulation order from a modulation coding scheme (MCS) level assigned to the UE by a serving base station in a previous uplink radio resource allocation or at a reference MCS level during operation.
[0123] According to a sixth aspect provided in addition to any of the first to fifth aspects, the processing circuitry is adapted to, during operation: Number of information bits I, The frequency bandwidth BW required to transmit the number of information bits from the UE to the serving base station, A path loss measurement PL of the path between the UE and the serving base station; determining a power level based on one or more of: Optionally, the power level Pc is: PC=10*lg(BW)+P O +alpha*PL It is determined based on the formula, P O and alpha are set by higher layers in an RRC message.
[0124] According to a seventh aspect provided in addition to any of the first to sixth aspects, the assistance information is associated with a DRX configuration, optionally indicating one or more DRX configuration parameters different from respective DRX configuration parameters currently used by the user equipment for operating the DRX mechanism.
[0125] According to an eighth aspect provided in addition to any of the first to seventh aspects, the processing circuitry determines during operation the aiding information for each traffic type and / or each logical channel group.
[0126] According to a ninth aspect provided in addition to any of the first to eighth aspects, the assistance information includes an individual value for each assistance information type, optionally the individual value being determined by the processing circuitry based on an association between different individual values and the assistance information type. The assistance information includes a combined value for two or more combinations of the assistance information types, optionally the combined value being determined by the processing circuitry based on an association between different combinations of the assistance information types and different combined values. Optionally, the association is set by the UE based on an RRC message received from the serving base station.
[0127] According to a tenth aspect provided in addition to any of the first to ninth aspects, the assistance information types are coded using absolute values, or alternatively, the assistance information types are coded using differential values that are differential with respect to a reference value, and the absolute value of each assistance information type is determined based on the differential value and the reference value, optionally the reference value being determined by the mobile terminal based on a previous radio resource allocation received from the serving base station.
[0128] According to an eleventh aspect provided in addition to any one of the first to tenth aspects, the support information further comprises: The number of information bits transmitted from the serving base station to the UE; The transport block size of the transport block used by the serving base station to transmit information bits from the UE; one or more discontinuous reception (DRX) configuration parameters used by the UE to operate a DRX mechanism; Indicates one or more of the following support information types:
[0129] According to a twelfth aspect, a method for implementing the method, performed by a user equipment (UE), comprising: determining assistance information to be transmitted to a serving base station of the UE; sending an assistance report including the determined assistance information to a serving base station of the UE; having Support information is available at The number of information bits transmitted by the UE to the serving base station; the transport block size of the transport block used by the UE to transmit information bits to the serving base station; A power level indicating the minimum power used by the UE to transmit information bits to the serving base station; one or more discontinuous reception (DRX) configuration parameters used by the UE to operate a DRX mechanism; A method is provided for indicating one or more of the support information types.
[0130] According to a thirteenth aspect, a base station is provided having a processing circuit for receiving, during operation, an assistance report from a user equipment (UE) served by the base station. The assistance report includes assistance information. The processing circuit determines, based on the assistance information received during operation, radio resources to be assigned to the UE for performing an uplink transmission. A transmitter transmits a radio resource allocation to the UE indicating the radio resources determined during operation. The assistance information includes: The number of information bits transmitted by the UE to the serving base station; the transport block size of the transport block used by the UE to transmit information bits to the serving base station; A power level indicating the minimum power used by the UE to transmit information bits to the serving base station; one or more discontinuous reception (DRX) configuration parameters used by the UE to operate a DRX mechanism; Indicates one or more of the following support information types:
[0131] According to a fourteenth aspect, a user equipment is provided that includes a transmitter that transmits, during operation, an extension request to a serving base station of the UE to extend an active time of a discontinuous reception (DRX) mechanism. The extension request is transmitted during the active time. The UE has processing circuitry that, upon transmitting the extension request during operation, autonomously determines to extend the active time. The UE operates according to the extended active time.
[0132] According to a fifteenth aspect provided in addition to the fourteenth aspect, the transmitter, during operation, Information regarding a trigger for sending an extension request, such as a new buffer status report sent by the UE to the serving base station or a new power headroom report sent by the UE to the serving base station; The number of bits expected to be transmitted by the UE to the serving base station; The power level required to transmit new data transmitted by the UE to the serving base station; -The period during which active hours are extended, Submit an extension request along with one or more of the following:
[0133] According to a sixteenth aspect provided in addition to the fourteenth or fifteenth aspect, the transmitter, during operation, a radio resource of an uplink control channel, optionally the last radio resource of the uplink control channel before the active time expires; a radio resource of an uplink shared channel, optionally the last radio resource of the uplink shared channel before the active time expires; The extension request is transmitted using one of the uplink radio resources of the mobile station.
[0134] According to a 17th aspect provided in addition to the 14th to 16th aspects, a transmitter transmits a sleep request to a serving base station during operation to exit from an extended active time and enter a sleep period of a DRX mechanism. A receiver receives a sleep instruction from the serving base station during operation. A processing circuit determines, based on the sleep instruction during operation, to exit from the active time and enter a sleep period of a DRX mechanism.
[0135] According to an 18th aspect provided in addition to any one of the 14th to 16th aspects, during the extended active time, The transmitter transmits, during operation, one or more of a buffer status report, a power headroom report, and uplink data to a serving base station; During operation, the receiver monitors the downlink control channel to receive control information from the serving base station.
[0136] According to a nineteenth aspect, Executed by a user equipment (UE), sending an extension request to a serving base station of the UE to extend an active time of a discontinuous reception (DRX) mechanism, the extension request being sent during the active time; upon sending the extension request, autonomously deciding to extend the active time; operating the UE according to the extended active time; A method is provided having the steps:
[0137] According to a twentieth aspect, a base station is provided having a receiver for receiving, during operation, from a UE an extension request to extend an active time of a discontinuous reception (DRX) mechanism. The extension request is transmitted during the active time. The base station further has processing circuitry for determining, upon transmitting the extension request during operation, that the UE autonomously extends the active time and operates according to the extended active time. The base station operates according to the extended active time.
[0138] Hardware and Software Implementations of the Disclosure The present disclosure can be realized by software, hardware, or software in cooperation with hardware. Each functional block used in the description of each embodiment described above can be partially or entirely realized by an LSI such as an integrated circuit, and each process described in each embodiment can be partially or entirely controlled by the same LSI or a combination of LSIs. The LSI can be formed as a chip individually, or a single chip can be formed to include some or all of the functional blocks. The LSI can include data inputs and outputs coupled thereto. The LSI here can be referred to as an IC (Integrated Circuit), a system LSI, a super LSI, or an ultra LSI depending on the degree of integration. However, the technology for realizing the integrated circuit is not limited to an LSI, and can be realized by utilizing a dedicated circuit, a general-purpose processor, or an application-specific processor. Furthermore, a field programmable gate array (FPGA) that can be programmed after the LSI is manufactured, or a reconfigurable processor in which the connection and setting of the circuit cells arranged in the LSI can be reconfigured, can be used. The present disclosure can be realized as digital processing or analog processing. The functional blocks can be integrated using future integrated circuit technologies when they replace LSI as a result of advances in semiconductor technology or other derivative technologies. Biotechnology is also applicable.
[0139] The present disclosure may be implemented by any type of apparatus, device or system having communication capabilities, which may be referred to as a communications apparatus.
[0140] Some non-limiting examples of such communications devices include telephones (e.g., mobile (cell) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (remote health and medical) devices, and vehicles (e.g., cars, airplanes, ships) that provide communications capabilities, and various combinations thereof.
[0141] The communications apparatus is not limited to being portable or mobile, but may include any type of apparatus, device or system, non-portable or fixed, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other "thing" in an "Internet of Things (IoT)" network.
[0142] Communications may include, for example, exchanging data via cellular systems, wireless LAN systems, satellite systems, and the like, as well as various combinations thereof.
[0143] A communication device may have devices such as a controller or a sensor coupled to the communication device to perform the communication functions described in this disclosure. For example, a communication device may have a controller or a sensor that generates control or data signals that are used by the communication device to perform the communication functions of the communication device.
[0144] The communications equipment may also include infrastructure facilities such as base stations, access points, and any other equipment, devices, or systems that communicate with or control equipment such as those in the non-limiting examples above.
[0145] Furthermore, the various embodiments may be realized by means of software modules executed directly on a processor or in hardware. Also, a combination of software modules and hardware implementations may be possible. The software modules may be stored on any type of computer-readable storage medium, such as RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc. It is to be noted further that individual features of the different embodiments may also be the subject of other embodiments individually or in any combination.
[0146] It will be understood by those skilled in the art that numerous variations and / or modifications may be made to the present disclosure as set forth in the specific embodiments, and the present embodiments are therefore to be considered in all respects as illustrative and not restrictive.
Claims
1. A communication device, comprising: a processing circuit for determining, during operation, assistance information to be transmitted to a serving base station of the communication device, the assistance information relating to at least one of uplink scheduling or downlink scheduling; a transmitter for transmitting, during operation, a message relating to said assistance information to a serving base station of said communication device by a random access procedure; having the assistance information includes information regarding a transport block size used by the communication device to transmit information bits to the serving base station; Communications equipment.
2. and a receiver configured to receive from the serving base station a radio resource allocation available for use by the communications device to perform uplink transmissions during operation. The communication device according to claim 1 .
3. The support information is the number of information bits, a power level indicating the minimum power used by the communication device to transmit the information bits to the serving base station; one or more discontinuous reception (DRX) configuration parameters used by the communication device to operate a DRX mechanism; Include one or more of the following support information types: The communication device according to claim 1 .
4. The number of information bits is A typical packet size U of uplink traffic transmitted by the communication device to the serving base station; - the typical arrival time T of the uplink traffic, the delay requirement L to be met for the uplink traffic, determined by the communication device based on one or more traffic characteristics, such as at least one of: The communication device according to claim 1 .
5. The number of information bits I is I=U*ceiling(L / T) is determined based on the formula: The communication device according to claim 3.
6. The processing circuitry, during operation, The number of information bits I, Coding rate C, Modulation order M, determining the transport block size based on at least one of The transport block size (TBS) is TBS=I*C / M is determined based on the formula: the processing circuitry determines the coding rate and the modulation order from a modulation coding scheme (MCS) level assigned to the communication device by the serving base station in a previous uplink radio resource allocation or at a reference MCS level during operation. The communication device according to claim 1 .
7. The processing circuitry, during operation, The number of information bits I, the frequency bandwidth BW required to transmit the information bits from the communication device to the serving base station; a path loss measurement P L for a path between the communication device and the serving base station; determining the power level based on one or more of: The power level P is P=10*lg(BW)+PO+alpha*PL where PO and alpha are set by higher layers in an RRC message. The communication device according to claim 3.
8. the processing circuitry determines the aiding information for each traffic type and / or for each logical channel group during operation. The communication device according to claim 1 .
9. the aiding information includes a separate value for each aiding information type; the distinct values are determined by the processing circuitry based on associations between different distinct values and the aiding information types; the support information includes a combination value for two or more combinations of the support information types; the combination values are determined by the processing circuitry based on associations between different combinations of assistance information types and different combination values; the association is established by the communication device based on an RRC message received from the serving base station. The communication device according to claim 1 .
10. A method executed by a communication device, determining assistance information to be transmitted to a serving base station of the communication device, the assistance information relating to at least one of uplink scheduling or downlink scheduling; sending a message regarding the assistance information to the serving base station of the communication device by a random access procedure; having the assistance information includes a transport block size used by the communication device; method.
11. A base station, a processing circuit for receiving, during operation, from a communication device served by the base station, a message relating to assistance information by a random access procedure, and for determining radio resources to be assigned to the communication device for performing an uplink transmission based on the assistance information, the assistance information relating to at least one of uplink scheduling or downlink scheduling; a transmitter operable during operation to transmit a radio resource allocation to the communication device indicative of the determined radio resources; having the assistance information includes a transport block size used by the communication device to transmit information bits to the base station. Base station.
12. Executed by the base station, receiving a message related to assistance information from a communication device served by the base station via a random access procedure, the assistance information related to at least one of uplink scheduling or downlink scheduling; determining radio resources to be assigned to the communication device for performing uplink transmission based on the assistance information; transmitting a radio resource allocation to the communication device indicative of the determined radio resources; having the assistance information includes a transport block size used by the communication device to transmit information bits to the base station. method.
13. An integrated circuit for controlling processing of a communication device, the processing comprising: determining assistance information to be transmitted to a serving base station of the communication device, the assistance information relating to at least one of uplink scheduling or downlink scheduling; transmitting a message regarding the assistance information to the serving base station of the communication device by a random access procedure; having the assistance information includes a transport block size used by the communication device to transmit information bits to the serving base station. Integrated circuits.
14. An integrated circuit for controlling processing of a base station, the processing comprising: receiving a message related to assistance information from a communication device served by the base station via a random access procedure, the assistance information related to at least one of uplink scheduling or downlink scheduling; determining radio resources to be assigned to the communication device for performing uplink transmission based on the assistance information; transmitting a radio resource allocation to the communication device indicative of the determined radio resources; having the assistance information includes a transport block size used by the communication device to transmit information bits to the base station. Integrated circuits.
Citation Information
Patent Citations
Devices, methods and computer programs for enhanced user equipment assistance information in wireless communication systems
JP2016136767A