Patent Description:
For the 3rd Generation Partnership Project (3GPP) Release-<NUM>, discussions are ongoing regarding enhanced ultra-reliable low-latency communications (eURLLC), out-of-order (OoO) hybrid automatic repeat request (HARQ), collision handling between two unicast physical downlink shared channels (PDSCHs) or two different physical uplink shared channels (PUSCHs) are being discussed.

The 3GPP New Radio (NR) technical report (TR) <NUM> defines OoO operations including OoO HARQ and collision handling between two unicast PDSCHs or two different PUSCHs. Generally, in 3GPP Release <NUM>, intra-UE overlapping PDSCHs or PUSCHs in time or frequency are not allowed, although in Rel-<NUM> such scenarios may be possible. For example, such overlapping scenarios may be beneficial for ultra-reliable low-latency communication (uRLLC) applications.

Two scenarios can be defined for the overlapping: scenario <NUM>, in which two channels overlap only in time, and scenario <NUM>, in which two channels overlap in both time and frequency.

<FIG> illustrates a scenario in which two unicast PUSCHs overlap in time and frequency. Specifically, <FIG> illustrates an example of scenario <NUM>.

Referring to <FIG>, a collision occurs in the time domain between the last four slots (<NUM>-<NUM>) of an enhanced mobile broadband (eMBB) PUSCH of a first UL grant (UL grant1), and the first four slots (<NUM>-<NUM>) of a uRLLC PUSCH of a second UL grant (UL grant2).

A collision event is often due to arrival of a high priority scheduling request (SR) for uRLLC. In this case, different UE capabilities can be defined to process one or both of the overlapping channels. According to one of the possible capabilities, a UE drops the processing of one of the channels based on an indicated priority. For example, a UE drops the processing of the first PDSCH or PUSCH, which normally corresponds to a lower priority service type, e.g., eMBB.

Dropping can also be done always or under some scheduling condition or as a UE capability.

Another scenario in which an uplink transmission may be dropped by a UE is when different uplink transmissions of two different UEs collide with each other, i.e., an inter-UE collision. In this scenario, typically, one of the uplink transmissions corresponds to a higher priority service type, e.g., a uRLLC, and the other one corresponds to eMBB.

Additionally, two uplink transmissions of the same UE may collide with each other, i.e., intra-UE collision. In this scenario, a higher priority channel is scheduled by a base station (e.g., a gNB (Next Generation Node-B)) such that it overlaps with the previously scheduled uplink transmission.

In any of these scenarios, under specific scheduling conditions or as a UE capability, the UE can stop processing the lower priority channel. Similar to the downlink scheduling, a UE may drop a transmission, even if it does not overlap with any other transmission. For example, dropping can also be done if the two channels do not overlap in either time or in frequency, but still happen to be too close in the time domain, thereby making it too difficult for the UE to properly process both channels.

Dropping an uplink channel is already defined in Rel-<NUM>, and there are conditions under which a UE drops the uplink transmission or reception of a downlink channel. These conditions include when an uplink CG (configured grant) is to take place on symbols that a later slot format indicator (SFI) indicates as being downlink or flexible, or when a downlink CG (configured grant) is to take place on symbols that a later SFI indicates as being uplink or flexible.

A different scenario includes when on a capability <NUM> processing serving cell, a PDSCH is scheduled with more than <NUM> resource blocks (RBs). In this case, a UE defaults to capability <NUM> and may skip decoding the PDSCH if its last symbol is within <NUM> symbols before the start of a PDSCH scheduled with capability <NUM>.

More specifically, 3GPP Release <NUM> provides:.

A UE capability feature group (FG), such as FG <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> defines the number of PDSCH or PUSCH a UE is capable of processing per slot. However, how to count a processed channel has not been defined. For example, it is not determined if a cancelled uplink channel should be counted towards this capability or not.

Accordingly, a need exists for specific methods to count the number of PDSCH or PUSCH per slot in order to determine a UE capability.

"<NPL>, discloses a list of UE features for NR.

The disclosure is made to address the problems and/or disadvantages described above and to provide the advantages described below.

Specific embodiments are defined by the dependent claims.

Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be noted that the same elements will be designated by the same reference numerals although they are shown in different drawings. In the following description, specific details such as detailed configurations and components are merely provided to assist with the overall understanding of the embodiments of the present disclosure. Therefore, it should be apparent to those skilled in the art that various changes and modifications of the embodiments described herein may be made without departing from the scope of the present disclosure. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness. The terms described below are terms defined in consideration of the functions in the present disclosure, and may be different according to users, intentions of the users, or customs. Therefore, the definitions of the terms should be determined based on the contents throughout this specification.

The present disclosure may have various modifications and various embodiments, among which embodiments are described below in detail with reference to the accompanying drawings. However, it should be understood that the present disclosure is not limited to the embodiments, but includes all modifications, equivalents, and alternatives within the scope of the present disclosure.

The electronic device according to an embodiment may be one of various types of electronic devices. An electronic device may include a portable communication device (e.g., a smart phone), a computer, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. However, an electronic device is not limited to those described above.

The terms used in the present disclosure are not intended to limit the present disclosure but are intended to include various changes, equivalents, or replacements for a corresponding embodiment. With regard to the descriptions of the accompanying drawings, similar reference numerals may be used to refer to similar or related elements. A singular form of a noun corresponding to an item may include one or more of the things, unless the relevant context clearly indicates otherwise. As used herein, terms such as "<NUM>st," "2nd," "first," and "second" may be used to distinguish a corresponding component from another component, but are not intended to limit the components in other aspects (e.g., importance or order). It is intended that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with," "coupled to," "connected with," or "connected to" another element (e.g., a second element), it indicates that the element may be coupled with the other element directly (e.g., wired), wirelessly, or via a third element.

As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may interchangeably be used with other terms, for example, "logic," "logic block," "part," and "circuitry. " A module may be a single integral component, or a minimum unit or part thereof, adapted to perform one or more functions. For example, according to one embodiment, a module may be implemented in a form of an application-specific integrated circuit (ASIC).

As described above, in the 3GPP specification, FG <NUM>-<NUM> to FG <NUM>-<NUM> define UE capabilities for processing uplink or downlink channels per slot. Further, 3GPP specification defines UE behavior to cancel an uplink or downlink transmission. However, the 3GPP specification does not specify how to count the cancelled channels or if counting channels should be based on the MAC layer or PHY layer.

As described below, the present disclosure provides different methods for counting the number of uplink and/or downlink channels per slot for a UE capability in order to determine a maximum number of channels that a UE is capable of processing per slot. In one method, any cancelled, scheduled, partially or fully dropped, CG (configured grant) uplink or downlink transmission is counted towards the UE capability. In another method, a UE counts the uplink and/or downlink channels from a PHY layer or MAC layer point of view, based on whether the channel includes a TB. According to these methods, UE processing complexity is reduced. That is, if a cancelled channel is not counted towards the capability, it will result in increased UE complexity and burden.

Counting the cancelled channels as a processed channel is also important from the baseband processing point of view, as resources are consumed for a cancelled channel. For example, processing components, such as a demodulator, channel estimator, decoder, etc., may be partially used for a cancelled channel. By counting the cancelled channels, UE complexity may be mitigated, thereby providing more flexibility towards processing other non-cancelled channels.

From a UE implementation point of view, completely processing a channel and dropping a channel may not precisely take the same amount of time or utilize the same hardware or software resources because when a UE drops a channel, it is often possible to empty the pipeline and processing elements, e.g., channel estimation, fast Fourier transform (FFT), demodulation, decoding, etc. However, to drop an already scheduled channel whose reception or transmission may be ongoing can still utilize a significant amount of processing resources on the UE transceiving chipset.

In 3GPP Rel-<NUM>, as part of a UE feature set, UE capabilities are defined to indicate the maximum number of PDSCHs or PUSCHs that a UE can process in one slot per serving cell.

Tables <NUM> and <NUM> below show some of the related NR UE features from TR <NUM> and TS <NUM> indicating the maximum number of PDSCH or PUSCH which a UE can process per slot.

While a UE may drop a lower priority channel, as described above and shown in Tables <NUM> and <NUM>, it is not clear how to count the dropped PDSCH/PUSCH channels. For example, if a UE is capable of processing two PUSCHs per slot, and the scenario illustrated in <FIG> occurs, if a gNB counts the dropped PUSCH as one channel, it will count two PUSCHs overall, and therefore, will not schedule another channel in the same slot for the UE. However, if the dropped channel is not counted, the gNB may schedule another channel because the UE is capable of processing two PUSCHs per slot.

Because dropping PUSCHs and/or PDSCHs can still take a significant amount of time, and/or utilize significant hardware or software resources, according to an method of the disclosure a dropped channel is counted as one processed channel in the above UE feature list, regardless of whether the channel has started being processed or not.

In the case of a DG PUSCH overlapping in time with a CG PUSCH, any type or a DG PDSCH overlapping in time with an SPS PDSCH, the configured grant PUSCH or the SPS PDSCH do not count towards the UE capability. This is based on a condition that there should be a sufficient time gap between the end of the DCI scheduling the DG PUSCH/PDSCH and the beginning of the CG-PUSCH/SPS-PDSCH in order for UE to be able to drop the transmission/reception of the CG-PUSCH/SPS-PDSCH. Herein, the phrase "the UE capability" may refer to FG <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> in 3GPP TR <NUM> or may refer to any other capability by which a UE reports the number of PUSCH or PDSCH per slot that it is capable of processing.

According to Embodiment which is covered by the claims, , all PDSCHs/PUSCHs that a UE is scheduled or configured to receive/transmit are counted for the purpose of the UE capability, regardless of dynamically occurring dropping/cancellation/skip decoding of them, except for the following <NUM> cases. For the following cases, the DG PUSCH is prioritized over a the CG PUSCH and the DG PDSCH is prioritized over a configured SPS-PDSCH, and the dropped channels are not counted.

For any of the above cases, a UE has enough time to cancel the CG PUSCH/PDSCH and prioritize the DG PUSCH/PDSCH. Therefore, the CG channel is not counted towards the UE capability. The cases in which the aforementioned timeline is not satisfied are considered as error cases.

<FIG> illustrates Case A in which a DG PUSCH is prioritized over a CG PUSCH according to one embodiment.

Referring to <FIG>, a UE receives a PDCCH, which ends in symbol i and includes DCI scheduling a DG-PUSCH that overlaps in time with a CG PUSCH starting in symbol j on the same serving cell. Because the beginning of symbol j is at least N_2 symbols after the end of symbol i, the UE has enough time to cancel the CG PUSCH and prioritize the DG PUSCH. Herein, the value of N_2 can be set any suitable number that provides the UE enough time to cancel the CG PUSCH and prioritize the DG PUSCH.

<FIG> illustrates Case B in which a DG PUSCH is prioritized over a CG PUSCH according to one embodiment.

Referring to <FIG>, a UE receives a PDCCH, which ends in symbol i and includes DCI scheduling a DG-PUSCH on a serving cell for a given HPN (e.g., HPN = k ), while the UE is allowed to transmit a CG PUSCH with the same HPN starting in symbol j. Because the beginning of symbol j is at least N_2 symbols after the end of symbol i, the UE has enough time to cancel the CG PUSCH and prioritize the DG PUSCH.

<FIG> illustrates Case C in which a DG PDSCH is prioritized over a configured SPS-PDSCH according to one embodiment.

Referring to <FIG>, a UE receives a PDCCH, which ends in symbol i and includes DCI scheduling a DG PDSCH with a C-RNTI or an MCS-C-RNTI overlapping in time with an SPS PDSCH starting in symbol j in the same serving cell. Because the beginning of symbol j is at least N_2 symbols after the end of symbol i, the UE has enough time to cancel the CG PUSCH and prioritize the DG PUSCH.

<FIG> is flow chart illustrating a method of a UE for counting a number of PDSCH or PUSCH per slot in order to determine a capability of the UE, according to one embodiment.

Referring to <FIG>, in step <NUM>, the UE counts all PDSCHs/PUSCHs that the UE is scheduled or configured to receive/transmit, except for any of the Cases A, B, and C described above.

In step <NUM>, the UE generates UE capability information based on the counted number of the PDSCH or PUSCH per slot.

In step <NUM>, the UE transmits the generated UE capability information to a serving base station.

<FIG> is flow chart illustrating a method of a serving base station for counting a number of PDSCH or PUSCH per slot in order to determine a capability of a UE, according to one embodiment.

Referring to <FIG>, in step <NUM>, the serving base station counts all PDSCHs/PUSCHs that the UE is scheduled or configured to receive/transmit, except for any of the Cases A, B, and C described above.

In step <NUM>, the serving base station generates UE capability information based on the counted number of the PDSCH or PUSCH per slot.

In step <NUM>, the serving base station allocates resources to the UE based on the generated UE capability information.

According to Embodiment <NUM> not covered by the claims, , all PDSCHs/PUSCHs that a UE is scheduled or configured to receive/transmit are counted for the purpose of UE capability, regardless of dynamically occurring dropping/cancellation/skip decoding of them.

For example, in the case of a DG PDSCH/PUSCH overlapping an SPS-PDSCH/CG-PUSCH, both the DG PDSCH/PUSCH and SPS-PDSCH/CG-PUSCHs are counted towards the UE capability.

In the above-described embodiments, the uplink/downlink transmissions in the slot are assumed to contain data. That is, the transmissions are assumed to transmit/receive one or more TBs. However, in the embodiments described below, PUSCH/PDSCH without TB may also be counted towards the UE capability as well.

According to Embodiment <NUM> not covered by the claims, , all PDSCHs/PUSCHs that a UE is scheduled or configured to receive/transmit are counted for the purpose of UE capability, regardless of dynamically occurring dropping/cancellation/skip decoding and regardless of whether they convey a TB or not.

For example, a PUSCH without data (e.g., an uplink shared channel (UL-SCH)) is counted towards the UE capability. A PUSCH triggered to transmit an aperiodic CSI report is an example of such a PUSCH.

According to Embodiment <NUM>, not covered by the claims, all PDSCHs/PUSCHs that a UE is scheduled or configured to receive/transmit are counted for the purpose of UE capability, regardless of dynamically occurring dropping/cancellation/skip decoding. However, the channels without a TB do not count towards the UE capability.

Counting of a PDSCH or PUSCH towards the UE capability can be different from the viewpoint of MAC layer or the PHY layer. For example, when a CG-PUSCH overlaps with a DG-PUSCH (as illustrated in <FIG>, Case A) and the DG-PUSCH is scheduled to carry an aperiodic-CSI report without any data, the DG-PUSCH does not include a TB. Therefore, from the PHY layer point of view, the DG-PUSCH should be counted as it is a PHY layer transmission anyways, regardless of whether it contains data or not. However, from the PHY layer point of view, the CG-PUSCH is not counted because the MAC layer has not delivered a TB for the CG-PUSCH. In general, there are two types of counting the channels towards the UE capability.

According to Embodiment <NUM> not covered by the claims, , all PDSCHs/PUSCHs that a UE is scheduled or configured to receive/transmit are counted for the purpose of UE capability, based on the whether they are the CG or SPS channels as described in Embodiment <NUM> and/or whether or not they include a TB, according to Table <NUM> below.

As shown in Table <NUM>, counting is done according to one of four possible methods.

In Table <NUM>, Method <NUM> is counted according to the MAC layer point of view. That is, when no TB is delivered for CG-PUSCH or SPS-PDSCH the channel is not counted. Also, when there is no TB for the physical channel, the channel is not counted.

In Method <NUM>, counting is performed from the PHY layer point of view in that the CG-PUSCH/SPS-PDSCH is not delivered to the PHY layer for the CG-PUSCH and SPS-PDSCH. Also, from the PHY layer point of view, it does not matter if the channel includes a TB or not.

In Methods <NUM> and <NUM>, depending on the amount of resources used in a PHY or MAC layer, different counting methods can be employed towards the UE capability.

<FIG> illustrates a block diagram of electronic devices <NUM>, <NUM> and <NUM> in a network environment <NUM>, according to one embodiment. Each electronic device is an example of a UE configured to perform a method as described above for counting a number of physical downlink shared channels (PDSCHs) or physical uplink shared channels (PUSCHs) per slot in order to determine a capability of the UE.

Referring to <FIG>, a first electronic device <NUM> in the network environment <NUM> may communicate with a second electronic device <NUM> via a first network <NUM> (e.g., a short-range wireless communication network), or a third electronic device <NUM> or a server <NUM> via a second network <NUM> (e.g., a long-range wireless communication network). The first electronic device <NUM> may also communicate with the third electronic device <NUM> via the server <NUM>. The first electronic device <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a sound output device <NUM>, a display device <NUM>, an audio module <NUM>, a sensor module <NUM>, an interface <NUM>, a haptic module <NUM>, a camera module <NUM>, a power management module <NUM>, a battery <NUM>, a communication module <NUM>, a subscriber identification module (SIM) <NUM>, or an antenna module <NUM>. In one embodiment, at least one (e.g., the display device <NUM> or the camera module <NUM>) of the components may be omitted from the first electronic device <NUM>, or one or more other components may be added to the first electronic device <NUM>. In one embodiment, some of the components may be implemented as a single integrated circuit (IC). For example, the sensor module <NUM> (e.g., a fingerprint sensor, an iris sensor, or an illuminance sensor) may be embedded in the display device <NUM> (e.g., a display).

The processor <NUM> may execute, for example, software (e.g., a program <NUM>) to control at least one other component (e.g., a hardware or a software component) of the first electronic device <NUM> coupled with the processor <NUM>, and may perform various data processing or computations. As at least part of the data processing or computations, the processor <NUM> may load a command or data received from another component (e.g., the sensor module <NUM> or the communication module <NUM>) in volatile memory <NUM>, process the command or the data stored in the volatile memory <NUM>, and store resulting data in nonvolatile memory <NUM>. Additionally or alternatively, the auxiliary processor <NUM> may be adapted to consume less power than the main processor <NUM>, or execute a particular function. The auxiliary processor <NUM> may be implemented as being separate from, or a part of, the main processor <NUM>.

The auxiliary processor <NUM> may control at least some of the functions or states related to at least one component (e.g., the display device <NUM>, the sensor module <NUM>, or the communication module <NUM>) among the components of the first electronic device <NUM>, instead of the main processor <NUM> while the main processor <NUM> is in an inactive (e.g., sleep) state, or together with the main processor <NUM> while the main processor <NUM> is in an active state (e.g., executing an application). According to one embodiment, the auxiliary processor <NUM> (e.g., an ISP or a CP) may be implemented as part of another component (e.g., the camera module <NUM> or the communication module <NUM>) functionally related to the auxiliary processor <NUM>.

The memory <NUM> may store various data used by at least one component (e.g., the processor <NUM> or the sensor module <NUM>) of the first electronic device <NUM>. The memory <NUM> may include the volatile memory <NUM> or the nonvolatile memory <NUM>.

The input device <NUM> may receive a command or data to be used by another component (e.g., the processor <NUM>) of the first electronic device <NUM>, from the outside (e.g., a user) of the first electronic device <NUM>.

The sound output device <NUM> may output sound signals to the outside of the first electronic device <NUM>.

The display device <NUM> may visually provide information to the outside (e.g., a user) of the first electronic device <NUM>.

According to one embodiment, the audio module <NUM> may obtain the sound via the input device <NUM>, or output the sound via the sound output device <NUM> or a headphone to the second electronic device <NUM> directly (e.g., wired) or wirelessly coupled with the first electronic device <NUM>.

The sensor module <NUM> may detect an operational state (e.g., power or temperature) of the first electronic device <NUM> or an environmental state (e.g., a state of a user) external to the first electronic device <NUM>, and then generate an electrical signal or data value corresponding to the detected state.

The interface <NUM> may support one or more specified protocols to be used for the first electronic device <NUM> to be coupled with the external electronic device (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or the server <NUM>) directly (e.g., wired) or wirelessly.

A connecting terminal <NUM> may include a connector via which the first electronic device <NUM> may be physically connected with the external electronic device (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or the server <NUM>).

According to one embodiment, the camera module <NUM> may include one or more lenses, image sensors, ISPs, or flashes.

The power management module <NUM> may manage power supplied to the first electronic device <NUM>.

The battery <NUM> may supply power to at least one component of the first electronic device <NUM>.

The communication module <NUM> may support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the first electronic device <NUM> and the external electronic device (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or the server <NUM>) and performing communication via the established communication channel. The communication module <NUM> may include one or more CPs that are operable independently from the processor <NUM> (e.g., the AP) and supports a direct (e.g., wired) communication or a wireless communication.

A corresponding one of these communication modules may communicate with the external electronic device via the first network <NUM> (e.g., a short-range communication network, such as Bluetooth™, wireless-fidelity (Wi-Fi) direct, or a standard of the Infrared Data Association (IrDA)) or the second network <NUM> (e.g., a long-range communication network, such as a cellular network, the Internet, or a computer network (e.g., LAN or wide area network (WAN)). These various types of communication modules may be implemented as a single component (e.g., a single IC), or may be implemented as multiple components (e.g., multiple ICs) that are separate from each other. The wireless communication module <NUM> may identify and authenticate the first electronic device <NUM> in a communication network, such as the first network <NUM> or the second network <NUM>, using subscriber information (e.g., international mobile subscriber identity (IMSI)) stored in the subscriber identification module <NUM>.

The antenna module <NUM> may transmit or receive a signal or power to or from the outside (e.g., the external electronic device) of the first electronic device <NUM>. The antenna module <NUM> may include one or more antennas, and, therefrom, at least one antenna appropriate for a communication scheme used in the communication network, such as the first network <NUM> or the second network <NUM>, may be selected, for example, by the communication module <NUM> (e.g., the wireless communication module <NUM>). The signal or the power may then be transmitted or received between the communication module <NUM> and the external electronic device (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or the server <NUM>) via the selected at least one antenna.

According to one embodiment, commands or data may be transmitted or received between the first electronic device <NUM> and the external electronic device (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or the server <NUM>) via the server <NUM> coupled with the second network <NUM>. Each of the second electronic device <NUM> and third electronic device <NUM> may be a device of a same type as, or a different type, from the electronic device <NUM>. All or some of operations to be executed at the first electronic device <NUM> may be executed at one or more of the external electronic devices (e.g., the second electronic device <NUM>, the third electronic device <NUM>, or server <NUM>). For example, if the first electronic device <NUM> should perform a function or a service automatically, or in response to a request from a user or another device, the first electronic device <NUM>, instead of, or in addition to, executing the function or the service, may request the one or more external electronic devices to perform at least part of the function or the service. The one or more external electronic devices receiving the request may perform the at least part of the function or the service requested, or an additional function or an additional service related to the request, and transfer an outcome of the performing to the first electronic device <NUM>. The first electronic device <NUM> may provide the outcome, with or without further processing of the outcome, as at least part of a reply to the request.

One embodiment may be implemented as software (e.g., the program <NUM>) including one or more instructions that are stored in a storage medium (e.g., internal memory <NUM> or external memory <NUM>) that is readable by a machine (e.g., the first electronic device <NUM>). For example, a processor of the first electronic device <NUM> may invoke at least one of the one or more instructions stored in the storage medium, and execute it, with or without using one or more other components under the control of the processor.

<FIG> illustrates a base station according to one embodiment, which is configured to perform a method as described above for counting a number of physical downlink shared channels (PDSCHs) or physical uplink shared channels (PUSCHs) per slot in order to determine a capability of a user equipment (UE).

Referring to <FIG>, the base station, e.g., a gNB, includes a transceiver <NUM>, a controller <NUM>, and a memory <NUM>. The controller <NUM> may be defined as a circuit, an ASIC, or a processor.

The transceiver <NUM> may transmit/receive a signal to/from another network entity. The transceiver <NUM> may transmit system information to, e.g., the UE, and may transmit a synchronization signal or a reference signal. Further, the transceiver <NUM> may transmit and receive information related to initial access operation, random access operation, and handover operation to and from the UE.

The controller <NUM> may control the overall operation of the base station. The controller <NUM> may control to perform the operation according to the above-described flowchart of <FIG>.

The memory <NUM> may store at least one piece of information transmitted/received through the transceiver <NUM> and information generated through the controller <NUM>. For example, the memory <NUM> may store the counted number of PDSCHs/PUSCHs that the UE is scheduled or configured to receive/transmit.

The memory <NUM> may store a basic program for the operation of a communication processor, an application, and data such as configuration information. Further, the memory <NUM> may include at least one storage medium among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., an SD memory, an extreme digital (XD) memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a random access memory (RAM), a static RAM (SRAM), a read only memory (ROM), a programmable ROM (PROM), and an electrically erasable PROM (EEPROM).

The controller <NUM> may perform various operations using a variety of programs, content, and data stored in the memory <NUM>.

The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc ROM (CD-ROM)), or be distributed (e.g., downloaded or uploaded) online via an application store (e.g., Play Store™), or between two user devices (e.g., smart phones) directly.

According to one embodiment, each component (e.g., a module or a program) of the above-described components may include a single entity or multiple entities. One or more of the above-described components may be omitted, or one or more other components may be added. In this case, the integrated component may still perform one or more functions of each of the plurality of components in the same or similar manner as they are performed by a corresponding one of the plurality of components before the integration. Operations performed by the module, the program, or another component may be carried out sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be executed in a different order or omitted, or one or more other operations may be added.

According to the above-described embodiments, a system and method are provided for counting a number of uplink and/or downlink channels per slot for a UE capability in order to determine a maximum number of channels a UE is capable of processing per slot.

Claim 1:
A user equipment, UE, (<NUM>) for counting a number of physical downlink shared channels, PDSCHs, or physical uplink shared channels, PUSCHs, per slot in order to determine a capability of the UE (<NUM>), the UE comprising:
a transceiver; and
a processor (<NUM>) configured to:
count all PDSCHs or PUSCHs that the UE (<NUM>) is scheduled or configured to receive or transmit per slot, respectively, except for:
exception <NUM>: when the UE (<NUM>) receives a physical downlink control channel, PDCCH, which ends in a symbol i and includes downlink control information, DCI, scheduling a dynamic grant, DG,-PUSCH that overlaps in time with a configured grant, CG, PUSCH starting in a symbol j on a same serving cell, wherein a beginning of the symbol j is at least N_2 symbols after an end of the symbol i, the CG PUSCH is not counted, wherein N_2 is a number that provides the UE enough time to cancel the CG PUSCH and prioritize the DG PUSCH,
exception <NUM>: when the UE (<NUM>) receives a PDCCH, which ends in a symbol i and includes DCI scheduling a DG PUSCH on a serving cell for a hybrid automatic repeat request, HARQ, process number, HPN, and the UE (<NUM>) is allowed to transmit a CG PUSCH with the same HPN starting in a symbol j, wherein a beginning of the symbol j is at least N_2 symbols after an end of the symbol i, the CG PUSCH is not counted, wherein N_2 is a number that provides the UE enough time to cancel the CG PUSCH and prioritize the DG PUSCH;
and generate UE capability information based on the counted number of the PDSCH or PUSCH per slot.