User equipment (UE) and method of UE initiated beam reporting
By introducing a retransmission mechanism for UEI beam reporting in the NR network, the inconvenience and signaling overhead caused by transmission failure in beam reporting are resolved, and a more timely and reliable beam reporting process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-17
- Publication Date
- 2026-04-07
AI Technical Summary
In NR networks, during UEI beam management, there is a lack of effective retransmission mechanisms in case of transmission failure, which makes it difficult to correct beam failures and results in large UL reporting and control signaling overhead as well as high latency.
By introducing a retransmission mechanism in the UEI beam reporting process, including retransmitting beam report indication messages and reports through the first and second channels after a communication failure is detected, failure detection and correction are performed using explicit or implicit ACK/NACK responses, DCI, and channel quality information.
It enables more timely beam reporting, reduces reporting and signaling overhead, and improves error detection and correction capabilities in the event of communication failure.
Smart Images

Figure CN121815284A_ABST
Abstract
Description
[0001] This application claims priority to U.S. Provisional Application No. 63 / 703,433, filed October 4, 2024, and U.S. Non-Provisional Application No. 19 / 339,907, filed September 25, 2025, the disclosures of which are incorporated by reference herein in their entireties, as if fully set forth herein. TECHNICAL FIELD
[0002] The present disclosure relates generally to New Radio (NR) networks. More specifically, the subject matter disclosed herein relates to improvements to User Equipment (UE) initiated (UEI) beam reporting. BACKGROUND
[0003] In NR networks, downlink (DL) beam management procedures require extensive communication exchanges between a base station and a UE. In addition, large uplink (UL) reporting and control signaling overhead and high latency are also drawbacks of conventional beam management procedures. Furthermore, a UE can have superior information about beam quality changes.
[0004] Accordingly, UEI beam management procedures have been developed that enable a UE to trigger beam reporting without network configuration and / or triggering. Such a scheme can provide more timely beam reporting, even while providing reduced reporting and signaling overhead. Such UEI beam management procedures can operate in Mode A or Mode B, where in Mode A a base station (e.g., a gNodeB or gNB) can dynamically schedule UL control information (UCI), and in Mode B the UCI can be located in one or more preconfigured resources for a second UL channel.
[0005] However, because UEI beam management does not handle retransmission in case of transmission failure (e.g., due to interference or poor channel quality), many approaches to UEI beam reporting can not facilitate correction of failures. Accordingly, to ensure reliable UEI / Event-Driven (ED) reporting, retransmission is a necessary mechanism that should be handled for both Mode A and the first and second UL channels of Mode B for UEI beam reporting. SUMMARY
[0006] To address these issues, systems and methods for retransmission in UEI beam reporting are described herein. The disclosed approaches improve upon previous methods by providing more timely beam reporting, reduced reporting and signaling overhead, and error detection and correction in case of communication failure.
[0007] In an embodiment, a method includes: performing, by a UE, a UE-initiated beam reporting procedure, the UE-initiated beam reporting procedure including transmitting, via a radio, a beam report indication message in a first channel to initiate a beam report and transmitting, via the radio, a beam report in a second channel; inferring a communication failure of the UE-initiated beam reporting procedure; and in response to inferring the communication failure of the UE-initiated beam reporting procedure, retransmitting, by the UE, the beam report indication message in the first channel and / or the beam report in the second channel.
[0008] In an embodiment, a system includes a UE including a radio and processing circuitry. The processing circuitry is configured to: perform a UE-initiated beam reporting procedure, wherein the beam reporting procedure includes transmitting, via the radio, a beam report indication message in a first channel to initiate a beam report and transmitting, via the radio, a beam report in a second channel; infer a communication failure of the UE-initiated beam reporting procedure; and in response to inferring the communication failure of the UE-initiated beam reporting procedure, retransmit the beam report indication message in the first channel and / or the beam report in the second channel. BRIEF DESCRIPTION OF DRAWINGS
[0009] In the following detailed description, aspects of the subject matter described herein will be described with reference to the accompanying drawings, wherein: Figure 1 is a communication flow diagram illustrating a method of UE I beam reporting.
[0010] Figure 2A is a communication flow diagram illustrating a method of retransmission in UE I beam reporting according to an embodiment.
[0011] Figure 2B is a communication flow diagram illustrating a method of retransmission based on an explicit negative acknowledgement (NACK) in UE I beam reporting according to an embodiment.
[0012] Figure 2C is a communication flow diagram illustrating a method of retransmission based on downlink control information (DCI) in UE I beam reporting according to an embodiment.
[0013] Figure 2D is a communication flow diagram illustrating a method of retransmission based on an unreceived message in UE I beam reporting according to an embodiment.
[0014] Figure 3 is a communication flow diagram illustrating a method of retransmission based on channel quality information in UE I beam reporting according to an embodiment.
[0015] Figure 4is a flow diagram illustrating a method of retransmission in a UEI beam report according to embodiments.
[0016] Figure 5 is a block diagram of an electronic device in a network environment according to embodiments.
[0017] Figure 6 illustrates a system including a UE and a gNB in communication with each other. DETAILED DESCRIPTION
[0018] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the disclosed aspects can be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the subject matter disclosed herein.
[0019] Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the disclosure. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” or “according to one embodiment” (or other phrases having similar meanings) throughout this specification or claims should not be construed as necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In this regard, the term “exemplary” as used herein means “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Additionally, particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Moreover, according to the context of discussion herein, a singular term can include its plural aspect, and a plural term can include its singular aspect. Similarly, a hyphenated term can occasionally be used in conjunction with its non-hyphenated counterpart, and vice versa. Such occasional use of a hyphenated or non-hyphenated version of a term should not be interpreted as a requirement that the hyphenated or non-hyphenated version be used exclusively.
[0020] It is also noted that the various figures (including component diagrams) illustrated and discussed herein are for illustrative purposes only and are not drawn to scale. For example, the dimensions of some elements in the figures can be exaggerated relative to other elements for clarity. Further, if considered appropriate, reference numerals can be repeated among the figures to indicate corresponding and / or analogous elements.
[0021] The terminology used herein is for the purpose of describing some example embodiments only and is not intended to be limiting of the claimed subject matter. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.
[0022] It will be understood that when an element or layer is referred to as being "on" or "connected to" or "coupled to" another element or layer, it can be directly on, connected or coupled to the other element or layer or intervening elements or layers can be present. In contrast, when an element is referred to as being "directly on," "directly connected to," or "directly coupled to" another element or layer, there are no intervening elements or layers present. Like reference numerals refer to like elements throughout. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.
[0023] As used herein, the terms "first," "second," and the like, are used as labels for nouns that they follow so that one element is distinguished from another, but do not otherwise limit the elements. Also, the terms "first," "second," and the like, can be used interchangeably with "one," "the," and / or "said" to refer to a similar or the same element. The terms "left," "right," "back," "front," "top," "bottom," "over," "under," and the like describe the orientation of aspects of the components but not necessarily their actual position. Like reference numerals refer to like parts throughout the specification. As used herein, the terms "first," "second," and the like are used as adjectives to modify nouns that they follow, and do not imply any type of order (e.g., spatial, temporal, logical, etc.) unless specifically defined as such. Also, the use herein of the terms "including," "comprising," "having," and the like, are used in the sense of "including and / or comprising," but not limited to, "consisting only of."
[0024] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
[0025] As used herein, the term "module" refers to any combination of software, firmware, and / or hardware configured to provide the functionality described herein with respect to the module. For example, software can be embodied in software packages, code, and / or instructions set or instruction sets, and the term "hardware" as used herein can encompass, for example, assemblies, hardwired circuitry, programmable circuitry, state machine circuitry, and / or firmware that stores instructions for execution by programmable circuitry, individually or in any combination. A module can collectively or individually be embodied as circuitry forming a portion of a larger system, such as, but not limited to, an integrated circuit (IC), a system on a chip (SoC), an assembly, and / or the like.
[0026] In NR networks, there are two procedures related to downlink (DL) beam management. The first procedure is to establish a DL beam between a gNB and a UE, which relies on scanning different reference signals (RSs) at different stages and reporting corresponding measurement results at some stages. The second procedure is to maintain the established beam, and is referred to as a beam failure recovery procedure. Both procedures require a large amount of communication exchange between the gNB and the UE. The disclosed embodiments can reduce the number of transmitted reference signals and / or reported measurement results.
[0027] Beam management procedures are typically based on specific network configurations and triggers. To quickly acquire the best (e.g., preferred) beam provided by a base station (e.g., gNB), periodic, semi-persistent, and / or aperiodic beam reporting can be activated or triggered. For example, a UE can report a number N of best beams and their corresponding layer 1 (L1)-reference signal received power (RSRP).
[0028] Some drawbacks of such conventional beam management procedures are large UL reporting and control signaling overhead and high latency. In addition, a UE can have superior information about beam quality changes. Therefore, there is a need for a UE beam management procedure in which a UE can trigger beam reporting without network configuration and / or triggering. Such a UEI scheme can enable more timely beam reporting while reducing reporting and signaling overhead. Nonetheless, UEI beam management can have the drawback that it does not specify ways to handle failed transmissions.
[0029] Figure 1 is a communication flow diagram illustrating a method 100 of UEI beam reporting for a UE 102 in communication with a base station (e.g., gNB) 104 serving a local cell of a mobile network. As described above, UEI beam reporting can provide advantages such as more timely beam reporting while reducing reporting and signaling overhead.
[0030] The UEI beam management procedure 100 can operate in either mode A or mode B. In mode A of operation, the UCI can be dynamically scheduled by the base station 104, while in mode B, the UCI can be located in one or more pre-configured resources for the second UL channel. In mode A, the transmission in the first UL channel (e.g., the beam report indication message) 106 can be a request to carry the beam report 108 for a dynamic UL resource allocation, while in mode B, the transmission in the first UL channel (e.g., the beam report indication message) 106 can simply inform the base station 104 that the beam report 108 will be carried in the second UL channel. In both mode A and mode B, the first UL channel carries one or more periodic physical UL control channel (PUCCH) resources configured by dedicated radio resource control (RRC) signaling. Thus, the UE 102 can send the transmission of the first UL channel as an UL resource request in mode A, or as a notification of a subsequent second UL channel in mode B. The UE can then send the transmission of the second UL channel as the actual beam report.
[0031] Thus, with reference to Figure 1 , the UE 102 can first send a beam notification message 106 (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to the base station 104 via a first channel (also referred to as channel 1). For example, as described above, if the UE 102 is operating in mode A, the beam notification message 106 can be an UL resource request, and if the UE 102 is operating in mode B, the beam notification message 106 can be a notification (e.g., an announcement) of a pending beam report in the second UL channel. However, in this example, the first channel can be noisy and can suffer from interference 110.
[0032] Next, the UE 102 can send a beam report 108 to the base station 104 via a second channel (also referred to as channel 2). In this example, the second channel can be noisy and can suffer from interference 110. Moreover, the interference 110 can cause the transmission of the beam notification message 106 and / or the beam report 108 to fail.
[0033] However, because UEI beam management does not handle retransmission in case of failure, the method 100 of UEI beam reporting can not facilitate correction of such failures. Thus, to ensure reliable UEI or ED reporting, retransmission should be handled for both the first and second UL channels for mode A as well as mode B. The disclosed embodiments can address this challenge by providing methods for retransmission in UEI beam reporting. For example, according to various embodiments, a UE can infer a communication failure in various ways and can thus retransmit one or more messages it previously sent to a base station. These ways can improve previous methods by providing more timely beam reporting, reduced reporting and signaling overhead, and error detection and correction in case of communication (e.g., transmission or reception) failure.
[0034] Figure 2A is a communication flow diagram illustrating a method 200 of retransmission in UEI beam reporting according to an embodiment. In some embodiments, the method 200 can be performed by a UE 202 in communication with a base station (e.g., gNB) 204 serving a local cell of a mobile network. For example, the UE 202 can correspond to the UE 605 in the example of Figure 6 , and can include radio and processing circuitry. The base station 204 can correspond to the gNB 610 in the example of Figure 6
[0035] Referring to Figure 2A , the UE 202 can first send a beam notification message 206 (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to the base station 204 via a first channel (e.g., a first UL channel). In an example, the UE 202 can send the beam notification message 206 via a radio of the UE 202. For example, if the UE 202 is operating in mode A, the beam notification message 206 can be a UL resource request, and if the UE 202 is operating in mode B, the beam notification message 216 can be a notification (e.g., announcement) of a pending beam report in a second UL channel.
[0036] Next, the UE 202 can send a beam report 208 to the base station 204 via a second channel (e.g., a second UL channel).
[0037] In some cases, the first channel used to transmit the beam notification message 206 and / or the second channel used to transmit the beam report 208 can comprise multiple channels. Thus, in various embodiments, the UE 202 and the base station 204 can communicate via a number M of first channels or M resources configured for the first channels and a single second channel, via a single first channel and a number M of second channels or M resources configured for the second channels, or via an equal number M of first channels or resources and a number M of second channels or resources, where M can be an integer greater than or equal to 1. For example, the method 200 can utilize a resource mapping and / or configuration of M to 1 for first UL channel retransmissions, 1 to M for second UL channel retransmissions, or M to M for both first UL channel retransmissions and second UL channel retransmissions.
[0038] Next, the UE 202 can infer a communication failure 210. For example, the communication failure 210 can be caused by interference as in the example of FIG. 2, and / or can have a different cause (such as a low battery level or malfunction of the UE 202, or a power outage of the base station 204), and is not limited by the present disclosure. Figure 1
[0039] The UE 202 can infer the communication failure 210 using various modalities, as will be described in the examples of FIGs. 3-5 below, without limitation. Figure 2B to Figure 2C and Figure 3 In some cases, inferring the communication failure can be based on direct information (e.g., can be deterministically known), such as an explicit acknowledgement (ACK) or NACK from the base station 204, while in other cases, the communication failure can be inferred indirectly, e.g., based on an un-received message or channel quality information, and is not limited by the present disclosure.
[0040] In response to (e.g., based on) inferring the communication failure 210, the UE 202 can transmit a retransmission 212. For example, if the inferred communication failure 210 is in the beam notification message 206, the UE 202 can retransmit the beam notification message 206 to the base station 204 via the first channel. If the inferred communication failure 210 is in the beam report 208, the UE 202 can retransmit the beam report 208 to the base station 204 via the second channel. For example, the UE 202 can repeat the transmission of the same beam report 208. In another example, the UE 202 can update the beam report, and can transmit the updated beam report via the second channel. In some examples, the UE 202 can transmit the retransmission 212 via a radio of the UE 202 and based on (e.g., in response to) the inferred communication failure.
[0041] Method 200 can then end. Alternatively, method 200 can continue, for example, to Figure 3 Method 300 of Examples.
[0042] Figure 2B to Figure 2C and Figure 3 illustrate Figure 2A Particular embodiments of method 200, such as various modalities of inferring a communication failure 210. Figure 2B is a communication flow diagram illustrating a method 230 of retransmission based on explicit NACK responses in UEI beam reports, according to an embodiment. Method 230 can be performed by a UE 202 in communication with a base station 204. For example, UE 202 can correspond to UE 605 in the example of Figure 6 and base station 204 can correspond to gNB 610 in the example of Figure 6
[0043] In an embodiment, base station 204 can send explicit ACK / NACK responses. For example, method 230 can be an embodiment of method 200 of Figure 2A inferring a communication failure 210 based on explicit ACK / NACK responses.
[0044] Referring to Figure 2B UE 202 can first send a beam notification 232 (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to base station 204 via a first channel. For example, UE 202 can send beam notification 232 via a radio in UE 202. For example, if UE 202 is operating in mode A, beam notification 232 can be an UL resource request, and if UE 202 is operating in mode B, beam notification 232 can be a notification of a second UL channel.
[0045] Next, UE 202 can send a beam report 234 to base station 204 via a second channel.
[0046] Next, base station 204 can send a NACK response 236 to UE 202. UE 202 can thereby be informed that a communication failure has occurred, such as Figure 2A communication failure 210 of the example of
[0047] For example, applicable to both operating mode A and operating mode B, an explicit ACK / NACK response can be sent from the base station 204 to the UE 202 in response to transmission of the first UL channel (e.g., beam notification 232). In some embodiments, as described in more detail below, the UE 202 can wait for a particular duration (e.g., a time gap) after sending the first UL channel (e.g., beam notification 232) to receive an ACK / NACK response (such as NACK response 236) from the base station 204. Such a time gap can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202, and can be implemented via a timer of the UE 202 (e.g., a timer implemented by the processing circuitry 620 of the example of FIG. 6). Figure 6
[0048] Next, in response to receiving the NACK response 236, the UE 202 can send a retransmission 238. For example, if the communication failure is determined to be in the beam notification 232 (e.g., if the UE 202 receives the NACK response 236 shortly after sending the beam notification 232), the UE 202 can retransmit the beam notification 232 to the base station 204 via the first channel. If the communication failure is determined to be in the beam report 234 (e.g., if the UE 202 receives the NACK response shortly after sending the beam report 234), the UE 202 can retransmit the beam report 234 to the base station 204 via the second channel. For example, the UE 202 can repeat the transmission of the same beam report 234, or can update the beam report and send the updated beam report via the second channel. In some examples, the UE 202 can send the retransmission 238 via a radio of the UE 202 and based on (e.g., in response to) the inferred communication failure.
[0049] In some embodiments, the determination of a failure in the first or second channel (e.g., inference 210) can be based on a duration (e.g., a time gap) after transmission of the first or second UL channel. For example, in some embodiments, unless the UE 202 receives an explicit ACK, it can default to retransmitting 238 the first UL channel. For example, if the UE 202 receives an explicit ACK within the time gap, the UE 202 can consider the first UL channel to have been successfully received. Otherwise, the UE 202 can consider the first UL channel to have failed, and accordingly can begin retransmitting 238 the first UL channel. Alternatively, in some embodiments, unless the UE 202 receives an explicit NACK, it can default to not retransmitting the first UL channel. In this case, if (as in the example of FIG. 6) the UE 202 receives an explicit NACK, the UE 202 can consider the first UL channel to have failed, and accordingly can begin retransmitting 238 the first UL channel. Figure 2B In an example, if UE 202 receives an explicit NACK response 236 within a time gap after transmission of the first UL channel (e.g., beam notification 232), UE 202 can consider the first UL channel to have failed, and accordingly can start retransmission 238 of the first UL channel. Otherwise, UE can consider the first UL channel to have been successfully received.
[0050] In some cases, although base station 204 can not be able to decode the second UL channel, it can still be able to detect some received power. Thus, another possible solution is for base station 204 to broadcast a common NACK in the serving cell, which includes information such as time and frequency grid for which reception has failed. This can provide an implicit NACK to UE 202 for which it has the same time and frequency allocation for one or more configured resources for the second UL channel. In such embodiments, if UE 202 does not receive a NACK within a certain time duration (e.g., time gap) after transmission of the second UL channel (e.g., beam report 234), UE 202 can consider this to be an implicit ACK, and thus can consider the second UL channel to have been successfully received. Such a time gap can be predefined, semi-statically configured, and / or dynamically indicated to UE 202, and can be implemented via a timer of UE 202, e.g., implemented by processing circuitry 620 of UE 202. Figure 6 In an example, if UE 202 receives an explicit NACK response 236 within a time gap after transmission of the second UL channel (e.g., beam report 234), UE 202 can consider the second UL channel to have failed, and accordingly can start retransmission 238 of the second UL channel. Figure 2B
[0051] Optionally, an explicit ACK / NACK response can be sent from base station 204 to UE 202 in response to transmission of the second UL channel (e.g., beam report 234). If UE 202 does not receive an ACK / NACK response within a certain time duration after transmission of the second UL channel (e.g., beam report 234), UE 202 can consider this to be an implicit NACK / ACK response, respectively. Such a time gap can be predefined, semi-statically configured, and / or dynamically indicated to UE 202, and can be implemented via a timer of UE 202, e.g., implemented by processing circuitry 620 of UE 202. Figure 6
[0052] In some embodiments, the UE 202 can default to retransmitting the second UL channel unless it receives an explicit ACK. For example, if the UE 202 receives an explicit ACK within a time gap following transmission of the second UL channel (e.g., the beam report 234), the UE 202 can consider the second UL channel to have been successfully received. Otherwise, the UE 202 can consider the second UL channel to have failed, and accordingly can begin retransmitting 238 the second UL channel. Alternatively, in some embodiments, the UE 202 can default to not retransmitting the second UL channel unless it receives an explicit NACK. In this case, if the UE 202 receives an explicit NACK response 236 (as in the example of Figure 2B the time gap following transmission of the second UL channel (e.g., the beam report 234), the UE 202 can consider the second UL channel to have failed, and accordingly can begin retransmitting 238 the second UL channel. Otherwise, the UE can consider the second UL channel to have been successfully received.
[0053] Method 230 can then end. Alternatively, method 230 can continue, for example, to the method 300 of the example of Figure 3
[0054] Figure 2C is a communication flow diagram illustrating a method 260 of retransmitting based on DCI in a UE I beam report, according to an embodiment. The method 260 can be performed by a UE 202 in communication with a base station 204. For example, the UE 202 can correspond to the UE 605 in the example of Figure 6 and the base station 204 can correspond to the gNB 610 in the example of Figure 6
[0055] In embodiments, the base station 204 can transmit DCI that can include (e.g., be interpreted as) an implicit ACK / NACK response. For example, the method 260 can be an embodiment of the method 200 of Figure 2A
[0056] Referring to Figure 2C the UE 202 can first transmit a beam notification 262 (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to the base station 20 via a first channel. For example, the UE 202 can transmit the beam notification 262 via a radio in the UE 202. For example, if the UE 202 is operating in mode A, the beam notification 262 can be an UL resource request, and if the UE 202 is operating in mode B, the beam notification 262 can be a notification of a second UL channel.
[0057] Next, the UE 202 can transmit a beam report 264 to the base station 204 via the second channel.
[0058] Next, the base station 204 can transmit a DCI 266 to the UE 202 (e.g., in the second channel). For example, the DCI 266 can include an indication (such as an implicit indication) that a communication failure (such as the communication failure 210 of the example) has occurred. In another example, the UE 202 can fail to receive an expected DCI 266, as shown in the example below. Figure 2A Figure 2D In a third example, the UE 202 can fail to receive an expected update from the base station 204 in the second channel. The UE 202 can thereby infer that a communication failure has occurred.
[0059] In examples applicable to both mode A of operation and mode B of operation, although the base station 204 can not be able to decode the first UL channel, it can still be able to detect some receive power. Thus, in some embodiments, the base station 204 broadcasts a common NACK in the serving cell, which includes information such as the time and frequency grid for which reception has failed. This can provide an implicit NACK for the UE 202 for which one or more configured resources for the first UL channel have the same time and frequency allocation. In such a case, if the UE 202 does not receive a NACK within a certain time duration (e.g., a time gap) after the transmission of the first UL channel (e.g., the beam notification 262), the UE 202 can consider this to be an implicit ACK, and thus can consider the first UL channel to have been successfully received. Such a time gap can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202, and can be implemented via a timer of the UE 202 (e.g., a timer implemented by the processing circuitry 620 of the example). Figure 6 If the UE 202 receives an explicit NACK within the time gap, the UE 202 can consider the first UL channel to have failed, and can accordingly initiate the retransmission 268 of the first UL channel. In some examples, the UE 202 can transmit the retransmission 268 via the radio and based on (e.g., in response to) the communication failure.
[0060] For the second UL channel retransmission, under Mode A or Mode B, since dynamic indication or configured grant (CG) UL resources can be provided to the UE 202, the base station 204 can infer a reception failure in case of any collision or failure detection. Thus, the base station 204 can schedule a retransmission 268 via a dynamic grant (DG), which can act as an implicit indication (e.g., implicit NACK) to the UE 202 that the second UL channel was not received. The base station 204 can transmit a DCI 266, which can be a scheduling DCI scrambled by a configured scheduling radio network temporary identifier (CS-RNTI) and with the same hybrid automatic repeat request (HARQ) process in case the new data indicator (NDI) bit is set to 1. The scheduling DCI can be DCI format 0-0, DCI format 0-1, and / or DCI format 0-2. The DCI 266 can act as an implicit NACK for the second UL channel. For example, if the UE 202 receives the DCI 266 within a time gap after the transmission of the second UL channel (e.g., beam report 264), the UE 202 can consider the second UL channel to have failed and accordingly start the retransmission 268 of the second UL channel. The time gap can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202 and can be implemented via a timer of the UE 202. If the UE 202 does not receive such a DCI within the time gap after the transmission of the second UL channel (e.g., beam report 264), the UE 202 can consider the second UL channel to have been successfully received (e.g., implicit ACK).
[0061] In operation mode B, the second UL channel can be configured with granted physical UL shared channel (PUSCH) resources. The first UL channel can be transmitted to inform (e.g., via beam notification 262) the base station 204 that a beam report 264 will be subsequently carried in the configured second UL channel. If the reception of the first UL channel fails, the base station 204 will not receive the notification 262 that the UE I beam report 264 will be carried, and thus, to improve resource utilization efficiency, the base station 204 can re-allocate one or more of those CG PUSCH resources. Thus, one or more CG PUSCH resources can be re-allocated by the base station 204 to the UE 202 (e.g., the same UE) for a different purpose, such as for dynamic grant. If such other activities (e.g., dynamic grant) occur, the UE 202 can thereby be aware that the transmission of the first UL channel (e.g., beam notification 262) has failed, thereby providing an implicit NACK indication to the UE 202. If the UE 202 receives such an implicit NACK, the UE 202 can consider the first UL channel to have failed and can accordingly start retransmission 268 of the first UL channel. Otherwise, the UE 202 can consider the first UL channel to have been successfully received. In this embodiment, the base station 204 can only be allowed to re-allocate one or more CG PUSCH resources for the second UL channel to the UE 202 (e.g., to the same UE).
[0062] For operation mode B, the one or more pre-configured resources for the second channel (e.g., for transmission of the beam report 264) can also be Type 2 CG PUSCH. In Type 2 CG, resource allocation is via semi-static configuration as well as DCI (e.g., DCI 266). That is, after the transmission of the first UL channel (e.g., beam notification 262), the base station 204 can transmit a DCI 266 to inform the UE 202 about activation, deactivation, change, and / or adjustment of the semi-static CG PUSCH resources for the second UL channel. The DCI 266 can serve as an implicit ACK for the first UL channel. In the case that the Type 2 CG PUSCH resources for the second UL channel have not been activated, if the transmission of the first UL channel has failed, the base station 204 can not transmit an activation DCI 266 to the UE 202 as an implicit ACK for the second UL channel. Since the resources for the second UL channel have not been activated, the UE 202 can infer that the transmission of the first channel (e.g., beam notification 262) has failed and needs to be retransmitted. If the UE 202 receives the activation DCI 266 as an implicit ACK, the UE 202 can consider the first UL channel to have been successfully received. Otherwise, the UE 202 can consider the first UL channel to have failed and can accordingly start retransmission 268 of the first UL channel.
[0063] Optionally, in a case where Type 2 CG PUSCH resources for the second UL channel have been activated, in response to a missed or failed reception of the first UL channel (e.g., beam notification 262), the base station 204 can transmit a DCI 266 to deactivate the semi-static CG PUSCH resources for the second UL channel. In this case, the base station 204 can transmit the deactivation DCI 266 prior to the transmission of the second UL channel (e.g., beam report 264). Thus, the deactivation DCI 266 can act as an implicit NACK for the first UL channel transmission. If the UE 202 receives the deactivation DCI as an implicit NACK, the UE 202 can consider the first UL channel to have failed and can start retransmission 268 of the first UL channel. Otherwise, the UE 202 can consider the first UL channel to have been successfully received.
[0064] Generally, for the case of UEI reporting for multiple events, in response to the transmission of the first UL channel (e.g., beam notification 262), the base station 204 can transmit a DCI 266 to inform the UE 202 of an activation, deactivation, change, and / or adjustment of the semi-static CG PUSCH resources for the second UL channel. The DCI 266 can act as an implicit ACK / NACK for the first UL channel. In an example, if the UE 202 receives an implicit ACK (e.g., an activation DCI), the UE 202 can consider the first UL channel to have been successfully received. In another example, if the UE 202 receives an implicit NACK (e.g., a deactivation DCI, a change DCI, or an adjustment DCI), the UE 202 can consider the first UL channel to have failed and can start retransmission 268 of the first UL channel.
[0065] For example, in mode B of operation, the second UL channel can be CG PUSCH resources. A notification (e.g., beam notification 262) can be transmitted in the first UL channel to inform the base station 204 that a beam report 264 will be carried in the configured second UL channel. If the reception of the first UL channel fails, the base station 204 does not receive the notification 262 from the UE 202 that the UEI beam report 264 will be carried, and thus, to improve resource utilization efficiency, the base station 204 can reallocate one or more of those CG PUSCH resources. In such a scenario, the base station 204 can infer the interference and / or collision that can have resulted due to the detection failure in those PUSCH resources. Thus, the base station 204 can schedule one or more dynamic grant PUSCH resources for retransmission of the second UL channel.
[0066] Additionally, if those CG PUSCH resources are reallocated by the base station 204 to the UE 202 (e.g., to the same UE) for a different purpose, the UE 202 can thereby realize that the transmission of the first UL channel (e.g., the beam notification 262) has failed, and the UE 202 must reinitiate the UEI reporting procedure using the next available UL resource.
[0067] Next, in response to receiving the DCI 266 (e.g., the implicit NACK response), the UE 202 can infer that a communication failure has occurred (such as, Figure 2A the example of the communication failure 210), and in response can send a retransmission 268. For example, if the communication failure is inferred to be in the beam notification 262, the UE 202 can retransmit the beam notification 262 to the base station 204 via the first channel. If the communication failure is determined to be in the beam report 264, the UE 202 can retransmit the beam report 264 to the base station 204 via the second channel. For example, the UE 202 can repeat the transmission of the same beam report 264, or can update the beam report and send the updated beam report via the second channel.
[0068] Then, the method 260 can end. Alternatively, the method 260 can continue, for example, to Figure 3 the example of the method 300.
[0069] Figure 2D is a communication flow diagram illustrating a method 280 for retransmission based on an un-received (e.g., missed) message (e.g., DCI or expected update) in a UEI beam report, according to an embodiment. The method 280 can be performed by a UE 202 in communication with a base station 204. For example, the UE 202 can correspond to the UE 605 in the example of Figure 6 and the base station 204 can correspond to the gNB 610 in the example of Figure 6 .
[0070] In an embodiment, the UE 202 can fail to receive an expected message, such as a DCI or an update. For example, the method 260 can be an embodiment in which the inferred communication failure 210 of the method 200 is based on a failure to receive an expected message. Figure 2A
[0071] Referring to Figure 2D , the UE 202 can first send a beam notification 282 (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to the base station 204 via the first channel. For example, if the UE 202 is operating in mode A, the beam notification 282 can be an UL resource request, and if the UE 202 is operating in mode B, the beam notification 282 can be a notification of the second UL channel.
[0072] Next, the UE 202 can send a beam report 284 to the base station 204 via the second channel.
[0073] Next, the base station 204 can send a message 286 (such as, e.g., a DCI 266 and / or an update) to the UE 202 (e.g., in the second channel). Figure 2C However, in this example, the message 286 suffers from interference 288 and thus can not be successfully sent to the UE 202, similar to the example of Figure 1 As a result, the UE 202 can fail to receive the expected message 286 (e.g., the expected DCI and / or update) and can thus infer that a communication failure has occurred, such as the example of Figure 2A the communication failure 210 of the example of
[0074] Next, in response to failing to receive the expected message 286 and inferring a communication failure, the UE 202 can send a retransmission 290. For example, if the UE 202 infers a communication failure in the beam notification 282, it can retransmit the beam notification 282 to the base station 204 via the first channel. If the UE 202 determines a communication failure in the beam report 284, it can retransmit the beam report 284 to the base station 204 via the second channel. For example, the UE 202 can repeat the same transmission of the beam report 284, or can update the beam report and send the updated beam report via the second channel.
[0075] Then, the method 280 can end. Alternatively, the method 280 can continue, e.g., to the method 300 of the example of Figure 3 the method 300 of the example of
[0076] Given all the retransmission schemes as discussed in the examples of Figure 2A to Figure 2D In various embodiments, the base station 204 can handle multiple retransmissions received from the UE 202 in the first UL channel and / or the second UL channel in various ways. For example, under mode A of operation, the base station 204 can successfully receive the beam notification in the first UL channel, but for some reason (such as, e.g., high traffic conditions and limited available UL resources), the base station 204 can delay sending the DCI format 266 to the UE 202. In such a scenario, the UE 202 can start retransmitting the first UL channel, and the base station 204 can receive multiple retransmissions of the exact same first UL channel, as described in the example of Figure 3 One solution can be to specify a minimum necessary time gap between every two consecutive retransmissions, such as the prohibit timer described in the example of Figure 3 This time gap can be predefined, semi-statically configured, or dynamically indicated by the base station 204 to the UE 202 based on the channel and traffic conditions. This solution also applies to the second UL channel retransmissions.
[0077] Figure 3 is a communication flow diagram illustrating a method 300 for retransmission based on channel quality information in a UE I beam report, according to an embodiment. The method 230 can be performed by a UE 202 in communication with a base station 204. For example, the UE 202 can correspond to the UE 605 in the example of Figure 6 , and the base station 204 can correspond to the gNB 610 in the example of Figure 6 .
[0078] In an embodiment, the UE 202 can transmit multiple retransmissions of the first UL channel without expecting a response from the base station 204. In some embodiments, where the inferring a communication failure 210 is based on channel quality information, the method 300 can be a continuation of the method 200 of Figure 2A . Thus, as in the example of Figure 2A , the UE 202 can first transmit the beam notification message 206 and the beam report 208 before inferring a communication failure 210 and transmitting retransmissions 212. The inferring a communication failure 210 can be based on channel quality information (e.g., evaluated channel quality information). For example, the UE 202 can make a direct evaluation (e.g., measurement) of the channel quality, or can determine the channel quality based on errors in transmissions received from the base station 204.
[0079] For example, in embodiments where the inferring a communication failure 210 is based on channel quality information indicating poor channel quality, the UE 202 can transmit multiple retransmissions (such as the retransmissions 212 of Figure 2A , and the retransmissions 302, 306, and 310 in this example) in order to compensate for the poor channel quality. To address possible reception failures of the first UL channel or the second UL channel, applicable to both Mode A and Mode B, in one embodiment, the UE 202 can transmit multiple retransmissions of the first UL channel or the second UL channel without expecting a response from the base station 204. However, these multiple retransmissions can be limited, delayed, or otherwise controlled by the prohibit timer and / or prohibit counter logic as disclosed herein.
[0080] In some examples, such multiple retransmissions can be feasible by one or more one-to-M or M-to-M mapping schemes in which multiple UL resources are granted to all of the second UL channels corresponding to each of the first UL channels.
[0081] Referring to Figure 3 , the UE 202 can first transmit the retransmission 302 to the base station 204. In one example, the retransmission 302 can be the same as the retransmission 212, but is not limited by the present disclosure.
[0082] Next, the UE 202 can follow a prohibit timer logic (also referred to as a prohibit timer) 304. For example, the prohibit timer logic 304 can require a predetermined time interval between retransmissions, such as 50 ms, 100 ms, 1 s, 5 s, or 25 s. In this case, the UE 202 can wait for the predetermined time interval after sending the retransmission 302.
[0083] Next, the UE 202 can send a retransmission 306 to the base station 204. For example, the UE 202 can send the retransmission 306 to the base station 204 in response to the prohibit timer logic 304 being satisfied.
[0084] Next, the UE 202 can follow a prohibit timer logic 308. For example, the prohibit timer logic 308 can require a predetermined time interval between retransmissions, such as 50 ms, 100 ms, 1 s, 5 s, or 25 s. Thus, the UE 202 can wait for the predetermined time interval after sending the retransmission 306.
[0085] Finally, the UE 202 can send a retransmission 310 to the base station 204. For example, the UE 202 can send the retransmission 310 to the base station 204 in response to the prohibit timer logic 308 being satisfied. Then, the method 300 can end.
[0086] In this example, the UE 202 is shown as sending a total of three retransmissions 302, 306, and 310. However, in various embodiments, the UE 202 can send any number of retransmissions and is not limited by this disclosure. In some embodiments, the UE 202 can instead or additionally use a prohibit counter, which can limit the total number of retransmissions to, for example, 3, 5, 10, 50, or any other number of retransmissions.
[0087] In some embodiments, both a prohibit counter and a prohibit timer can be applied jointly in order to prevent redundant retransmissions. For example, the prohibit counter can start counting the number of first UL channel transmissions (e.g., retransmissions 212 or 302) immediately after sending a first UL channel transmission (e.g., retransmission 302). When the number of first UL channel transmissions reaches a maximum number, the prohibit timer (e.g., prohibit timers 304 and 308) can be triggered. Note that the maximum number of retransmissions can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202. Then, the prohibit timer will start running until it reaches a maximum time interval between retransmissions, after which both the prohibit counter and the prohibit timer can be reset to zero. The maximum time interval for the prohibit timer can also be predefined, semi-statically configured, and / or dynamically indicated to the UE 202. While the prohibit timer is timing, the UE 202 is prohibited from retransmitting the first UL channel.
[0088] Optionally, some embodiments can utilize only a prohibit timer (e.g., as shown in FIG. 6A), or only a prohibit counter. In some examples, the prohibit counter and / or prohibit timer can operate after the first UL channel transmission, and then can be reset when the UE 202 sends a transmission of the second UL channel. Only applicable to Mode A, the prohibit counter and / or prohibit timer can be reset when the UE 202 receives a DCI format 2 6 from the base station 204. In another embodiment, only applicable to Mode B, retransmission of the first UL channel by the UE 202 is allowed until X number of symbols (e.g., X = 2, 3, 4, or another number) before the first available symbol of the one or more UL resources of the second UL channel. Figure 3
[0089] In various embodiments, the method of performing multiple retransmissions without a response from the base station 204 can be configured and / or indicated to the UE 202 by the base station 204. Optionally, the multiple retransmission method can be triggered and / or initiated by the UE 202 itself. In an example, such a multiple retransmission method can improve UE I beam reporting when the channel quality is poor. In another example, multiple retransmissions can improve UE I beam reporting when no other UE I events are triggered within a certain time period, so the configured PUCCH resource for the first channel is not used and thus can be used to perform multiple retransmissions.
[0090] In some examples, the UL resources used by the UE 202 for such multiple retransmissions can be indicated or configured for the second UL channel (e.g., dynamically scheduled PUSCH in Mode A, or CG PUSCH in Mode B). In Mode A of operation, the base station 204 can dynamically schedule multiple UL resources. In Mode B, depending on the channel quality and whether channel state information (CSI) has been acquired, the base station 204 can define a small periodicity for the second UL channel, or can configure multiple Type 1 CG PUSCH resources through dedicated RRC signaling. For example, configuring multiple Type 1 CG PUSCH resources can be implemented with 1-to-M or M-to-M resource mapping and / or configuration between the first UL channel and the second UL channel for a given CSI configuration. This can provide M number of retransmission opportunities for the second UL channel for each transmitted first UL channel.
[0091] In some examples, when multiple retransmissions occur without a base station response, the base station 204 can be aware of the retransmissions and can treat all retransmissions as corresponding to a single UEI report configuration. For the first UL channel retransmissions, the base station 204 can only decode one of the multiple received first UL channels and discard decoding of the remaining retransmissions. To do so, the base station 204 can use a timer and / or a counter. For example, the base station 204 can include a timer that starts timing after the first successful reception of the first UL channel. In this example, the base station 204 can discard decoding of the received configured PUCCH resources for the first UL channel until the timer reaches a maximum value and is reset. In another example, the timer can be reset when the UE 202 receives a response from the base station 204 or when the UE 202 transmits a transmission of the second UL channel. This maximum timer value can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202. Similarly, the base station 204 can include a counter that starts counting the number of received periodic PUCCH resources after the first successful reception of the first UL channel. In one such example, the base station 204 can discard decoding of the received configured PUCCH resources for the first UL channel while the counter value is less than a maximum value, and then the counter can be reset when the maximum value is reached. Alternatively, the counter can be reset when the UE 202 receives a response from the base station 204 or when the UE 202 transmits a transmission of the second UL channel. The maximum counter value can be predefined, semi-statically configured, and / or dynamically indicated to the UE 202. Similar approaches can apply to the second UL channel retransmissions. Note, however, that for the second UL channel retransmissions, each second UL channel can have updated UEI report content, and accordingly, it can still be necessary for the base station 204 to decode all retransmissions of the second UL channel.
[0092] Further, all retransmissions can use configured and / or scheduled UL resources. Thus, the resource mapping and / or configuration between the first UL channel and the second UL channel for a given CSI configuration can be used to assist the base station 204 in distinguishing between retransmissions of the same UL channel and the first transmission of a new UEI report.
[0093] In some examples, the base station 204 can successfully decode multiple first UL channels and can treat them as separate first UL channels. In this case, mode B of operation can proceed normally as no response from the base station 204 is expected and the UL resources for the second UL channel have been CGed. This example can be based on the assumption that the base station 204 is prohibited from re-allocating the configured resources for the second UL channel for other purposes and / or other UEs in mode B.
[0094] However, in mode A of operation, since the first UL channel transmission can be a request for second UL channel allocation resources, in response to receiving multiple retransmissions of the first UL channel, the base station 204 can erroneously send multiple DCIs to the UE 202 and erroneously schedule multiple DG-PUSCH resources for a single second UL channel. In this case, the UE 202 can use the multiple scheduled resources for retransmissions of the second UL channel, with repetition (e.g., the same content) or with updated content.
[0095] Figure 4 is a flowchart illustrating a method 400 of retransmission in a UE I beam report, according to an embodiment. The method 400 can be performed by a UE, such as the UE 605 in the example of FIG. 6, in communication with a base station, such as the gNB 610 in the example of FIG. 6. Figure 6 Figure 6 is a flowchart illustrating a method 400 of retransmission in a UE I beam report, according to an embodiment. The method 400 can be performed by a UE, such as the UE 605 in the example of FIG. 6, in communication with a base station, such as the gNB 610 in the example of FIG. 6.
[0096] Referring to Figure 4 , the method 400 can begin, at 402, with the UE sending a beam notification (also referred to as a beam report indication message, beam report notification, notification, announcement, or message) to the base station via a first channel. For example, at 402, the UE can send the beam notification via a radio of the UE, such as the radio 615 in the example of FIG. 6. In some embodiments, in mode A, the beam notification can be a request for UL resources, while in mode B, the beam notification can be a notification of a pending beam report in a second UL channel. Figure 6
[0097] Next, at 404, the UE can send a beam report to the base station via a second channel.
[0098] Next, at 406, the UE can infer a communication failure. For example, the communication failure can be caused by interference (as in the example of FIG. 6), and / or caused by another cause, such as a power outage of the UE. Figure 1
[0099] At 406, the UE can infer the communication failure through various modalities, as described above. In some cases, the inference of the communication failure at 406 can be based on direct information, such as an ACK / NACK signal from the base station, while in other cases, the inference of the communication failure at 406 can be indirect.
[0100] Finally, in response to the inference of communication failure at 406, the UE may send a retransmission at 408. For example, if the inferred communication failure is in the beam notification, then at 408, the UE may retransmit the beam notification to the base station via a first channel, and / or if the inferred communication failure is in the beam report, then at 408, the UE may retransmit the beam report to the base station via a second channel. For example, the UE may repeat the transmission of the same beam report. In another example, the UE may update the beam report and may send the updated beam report via a second channel.
[0101] Then, method 400 can end. Alternatively, method 400 can continue, for example, as follows: Figure 3 In the example, multiple retransmissions continue.
[0102] Figure 5 This is a block diagram of an electronic device in a network environment 500 according to an embodiment. For example, Figure 1 , Figure 2A to Figure 2D , Figure 3 and Figure 4 The UE and / or base station may include electronic devices (such as electronic device 501).
[0103] Reference Figure 5 In network environment 500, electronic device 501 can communicate with electronic device 502 via a first network 598 (e.g., a short-range wireless communication network), or with electronic device 504 or server 508 via a second network 599 (e.g., a long-range wireless communication network). Electronic device 501 can communicate with electronic device 504 via server 508. Electronic device 501 may include processor 520, memory 530, input device 550, sound output device 555, display device 560, audio module 570, sensor module 576, interface 577, connection terminal 578, haptic module 579, camera module 580, power management module 588, battery 589, communication module 590, subscriber identification module (SIM) 596, or antenna module 597. In one embodiment, at least one component (e.g., display device 560 or camera module 580) may be omitted from electronic device 501, or one or more other components may be added to electronic device 501. Some components may be implemented as a single integrated circuit (IC). For example, sensor module 576 (e.g., fingerprint sensor, iris sensor, or illuminance sensor) may be embedded in display device 560 (e.g., display).
[0104] The processor 520 can run software (e.g., program 540) to control at least one other component (e.g., hardware or software component) of the electronic device 501 combined with the processor 520, and can perform various data processing or calculations.
[0105] As at least a part of data processing or computation, the processor 520 can load a command or data received from another component (e.g., the sensor module 576 or the communication module 590) into the volatile memory 532, process the command or the data stored in the volatile memory 532, and store resultant data in the non-volatile memory 534. The processor 520 can include a main processor 521 (e.g., a central processing unit (CPU) or an application processor (AP)) and an auxiliary processor 523 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that is operable independently from, or in conjunction with, the main processor 521. Additionally or alternatively, the auxiliary processor 523 can be adapted to consume less power than the main processor 521 or to perform a specific function. The auxiliary processor 523 can be implemented as the separate processor independent of the main processor 521 or as a part of the main processor 521.
[0106] The auxiliary processor 523, rather than the main processor 521, can control at least some of the functions or states related to at least one component (e.g., the display device 560, the sensor module 576, or the communication module 590) of the electronic device 501 while the main processor 521 is in an inactive (e.g., sleep) state, or together with the main processor 521, control at least some of the functions or states related to at least one component (e.g., the display device 560, the sensor module 576, or the communication module 590) of the electronic device 501 while the main processor 521 is in an active state (e.g., performs an application). The auxiliary processor 523 (e.g., an image signal processor or a communication processor) can be implemented as a part of another component (e.g., the camera module 580 or the communication module 590) functionally related to the auxiliary processor 523.
[0107] The memory 530 can store various data used by at least one component (e.g., the processor 520 or the sensor module 576) of the electronic device 501. The various data can include, for example, software (e.g., a program 540) and input data or output data for a command related thereto. The memory 530 can include the volatile memory 532 or the non-volatile memory 534. The non-volatile memory 534 can include the internal memory 536 and / or the external memory 538.
[0108] The program 540 can be stored in the memory 530 as software, and can include, for example, an operating system (OS) 542, middleware 544, or an application 546.
[0109] The input device 550 can receive a command or data to be used by another component (e.g., the processor 520) of the electronic device 501, from the outside (e.g., a user) of the electronic device 501. The input device 550 can include, for example, a microphone, a mouse, or a keyboard.
[0110] The sound output device 555 can output sound signals to the outside of the electronic device 501. The sound output device 555 can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as playing multimedia or videos, and the receiver can be used for receiving an incoming call. The receiver can be implemented as separate from, or as part of, the speaker.
[0111] The display device 560 can visually provide information to the outside (e.g., a user) of the electronic device 501. The display device 560 can include, for example, a display, a hologram device, or a projector, and a control circuit for controlling a corresponding one of the display, the hologram device, and the projector. The display device 560 can include a touch circuit adapted to detect a touch, or a sensor circuit (e.g., a pressure sensor) adapted to measure the intensity of force incurred by the touch.
[0112] The audio module 570 can convert a sound into an electrical signal, and vice versa. The audio module 570 can obtain sound from the input device 550, or output sound to the sound output device 555 or an external electronic device 502 (e.g., a speaker) using a wired or wireless connection.
[0113] The sensor module 576 can detect an operational state (e.g., power or temperature) of the electronic device 501 or an environmental state (e.g., a state of a user) external to the electronic device 501, and then generate an electrical signal or data value corresponding to the detected state. The sensor module 576 can include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.
[0114] The interface 577 can support one or more designated protocols to enable the electronic device 501 to be coupled with the external electronic device 502 directly (e.g., wiredly) or wirelessly. The interface 577 can include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.
[0115] The connection terminal 578 can include a connector to which the electronic device 501 can be physically connected with the external electronic device 502. The connection terminal 578 can include, for example, a HDMI connector, a USB connector, a SD card connector, or an audio connector (e.g., a headphone connector).
[0116] The haptic module 579 can convert electrical signal into a mechanical stimulus (e.g., vibration or movement) or electrical stimulus that is convertible to the stimulation that can be felt via the sense of touch, for example. The haptic module 579 can include, for example, a motor, a piezoelectric element, or an electrical stimuluser.
[0117] The camera module 580 can capture a still image or moving images. The camera module 580 can include one or more lenses, image sensors, image signal processors, or flashes. The power management module 588 can manage power supplied to the electronic device 501. The power management module 588 can be implemented as at least a part of, for example, a power management integrated circuit (PMIC).
[0118] The battery 589 can supply power to at least one component of the electronic device 501. The battery 589 can include, for example, a primary cell which is not rechargeable, a secondary cell which is rechargeable, or a fuel cell.
[0119] The communication module 590 can support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 501 and an external electronic device (e.g., the electronic device 502, the electronic device 504, or a server 508) and performing communication between the electronic devices 501, 502, 504, and 508 via the established communication channel. The communication module 590 can include one or more communication processors that operate independently of the processor 520 (e.g., an AP) and supports direct (e.g., wired) communication or wireless communication. The communication module 590 can include a wireless communication module 592 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 594 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). A corresponding one of these communication modules can communicate with the external electronic device via the first network 598 (e.g., a short-range communication network, such as Bluetooth TM , Wi-Fi direct, or an infrared data association (IrDA) standard) or the second network 599 (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 can be implemented as a single component (e.g., a single IC) or can be implemented as separate components (e.g., separate ICs) from each other. The wireless communication module 592 can identify and authenticate the electronic device 501 in a communication network, such as the first network 598 or the second network 599, using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module 596.
[0120] The antenna module 597 can transmit or receive a signal or power to or from an external electronic device (e.g., an external electronic device) of the electronic device 501. The antenna module 597 can include one or more antennas, and can therefore, for example, select at least one antenna appropriate for a communication scheme used in a communication network, such as the first network 598 or the second network 599, by the communication module 590 (e.g., the wireless communication module 592). Then, the signal or the power can be transmitted or received between the communication module 590 and the external electronic device via the selected at least one antenna.
[0121] Commands or data can be transmitted or received between the electronic device 501 and an external electronic device 504 via the server 508 connected with the second network 599. Each of the electronic devices 502 and 504 can be a device of a same type as or different from the electronic device 501. All or some of the operations performed by the electronic device 501 can be performed at one or more of the external electronic devices 502, 504, or server 508. For example, if the electronic device 501 is to perform a function or a service automatically, or in response to a request from a user or another device, the electronic device 501, instead of, or in addition to, performing the function or the service, can request one or more of the external electronic devices to perform at least part of the function or the service. The one or more external electronic devices receiving the request can perform the requested at least part of the function or the service, or an additional function or an additional service related to the request, and transmit a result of the performance to the electronic device 501. The electronic device 501 can provide the received result or further process the received result to provide a final result as a reply to the request, in whole or in part. For this, for example, a cloud computing, distributed computing, or client-server computing technology can be used.
[0122] Figure 6 A system including UEs 605 and a gNB 610 in communication is shown. A UE can include a radio 615 and processing circuitry (or means) 620 which can perform various methods disclosed herein, e.g., the methods illustrated in FIG. 6. For example, the processing circuitry 620 can receive a transmission from a network node (gNB) 610 via the radio 615, and the processing circuitry 620 can transmit a signal to the gNB 610 via the radio 615. Figure 1
[0123] Embodiments of the subject matter and operations described in this specification (including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them) can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs (i.e., one or more modules of computer program instructions) encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions can be encoded in a propagated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer storage medium can be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). Additionally, the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.
[0124] While this specification contains many specifics, these should not be construed as limitations on the scope of any patent claims, but rather as descriptors of particular embodiments thereof. Some features described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented separately or in any appropriate subcombination. Moreover, although features can be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination and the claimed combination can be directed to a subcombination or variation of a subcombination.
[0125] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring such an order nor limiting it to the illustrated order or sequential order, nor that all operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products.
[0126] Accordingly, particular embodiments of the subject matter have been described herein. Other embodiments are within the scope of the claims. In some cases, actions recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.
[0127] As will be recognized by the skilled person, the innovative concepts described herein can be modified and varied widely. Accordingly, the scope of the claimed subject matter is not to be limited to any particular exemplary teachings discussed above, but is instead defined by the following claims.
Claims
1. A user equipment (UE), comprising: radio; as well as The processing circuit is configured as follows: The UE-initiated beam reporting process is executed, wherein the UE-initiated beam reporting process includes: sending a beam reporting indication message via the radio in a first channel to initiate a beam report; and sending a beam report via the radio in a second channel; It is inferred that the communication of the beam reporting process initiated by the UE failed; and In response to the communication failure inferred from the beam report procedure initiated by the UE, the beam report indication message is retransmitted in the first channel and / or the beam report is retransmitted in the second channel.
2. The UE as described in claim 1, wherein, The steps for inferring the communication failure include: identifying the communication failure based on a negative acknowledgment (NACK) response received from the base station via the radio.
3. The UE as described in claim 1, wherein, The communication failure is inferred based on the following: Downlink DL control information (DCI) is received by the radio; or The DCI was expected but not received by the radio.
4. The UE as described in claim 1, wherein, The communication failure is inferred based on one or more of the following: An update was anticipated by the radio but was not received; Dynamic authorization; and The authorized resources have been reallocated by the base station.
5. The UE as described in claim 1, wherein, The communication failure is inferred based on the assessed channel quality information.
6. The UE as described in claim 5, wherein, The UE is also configured to implement the following: A disable counter is implemented to prevent exceeding a predetermined maximum number of retransmissions; and / or The disable timer is implemented as a predetermined time interval between required retransmissions.
7. The UE as claimed in claim 1, wherein, The steps for retransmitting the beam report in the second channel include: The beam report is repeated by the radio in the second channel; or The beam report is updated, and the updated beam report is transmitted by the radio in the second channel.
8. The UE as claimed in claim 1, wherein: The first channel includes M first channels or first uplink UL resources; and / or The second channel includes M second channels or second UL resources. Where M is an integer greater than or equal to 1.
9. The UE as claimed in claim 1, wherein: The first channel is the first uplink UL channel; and / or The second channel is the second UL channel.
10. The UE as claimed in claim 1, wherein: In response to the UE operating in Mode A, the beam report indication message in the first channel includes an uplink UL resource request; and / or In response to the UE operating in mode B, the beam report indication message in the first channel includes a notification of the beam report to be sent in the second channel.
11. A method for beam reporting initiated by a user equipment (UE), the method comprising: The UE executes a UE-initiated beam reporting process, wherein the UE-initiated beam reporting process includes: transmitting a beam reporting indication message via a radio in a first channel to initiate a beam report; and transmitting a beam report via the radio in a second channel. It is inferred that the communication of the beam reporting process initiated by the UE failed; and In response to the communication failure inferred from the beam report procedure initiated by the UE, the UE retransmits the beam report indication message in the first channel and / or retransmits the beam report in the second channel.
12. The method of claim 11, wherein, The steps for inferring the communication failure include: identifying the communication failure based on receiving a negative acknowledgment (NACK) response from the base station via the radio.
13. The method of claim 11, wherein, The communication failure is inferred based on the following: Receive downlink DL control information (DCI) via the radio; or The expected DCI was not received via the radio.
14. The method of claim 11, wherein, The communication failure is inferred based on one or more of the following: No expected update was received via the radio. Received dynamic authorization; and The authorized resources that were configured have been reallocated by the base station.
15. The method of claim 11, wherein, The communication failure is inferred based on the assessed channel quality information.
16. The method of claim 11, further comprising: Implement a disable counter to prevent exceeding the predetermined maximum number of retransmissions; and / or Implement a disable timer to require a predetermined time interval between retransmissions.
17. The method of claim 11, wherein, The steps for retransmitting the beam report in the second channel include: The beam report is repeated in a second channel via the radio; or The beam report is updated, and the updated beam report is transmitted via the radio in the second channel.
18. The method of claim 11, wherein: The first channel includes M first channels or first uplink UL resources; and / or The second channel includes M second channels or second UL resources. Where M is an integer greater than or equal to 1.
19. The method of claim 11, wherein: The first channel is the first uplink UL channel; and / or The second channel is the second UL channel.
20. The method of claim 11, wherein: In response to the UE operating in Mode A, the beam report indication message in the first channel includes an uplink UL resource request; and / or In response to the UE operating in mode B, the beam report indication message in the first channel includes a notification that the beam report will be sent in the second channel.