Event-driven beam management method and apparatus
By actively reporting event-driven beam management information by terminal devices, the problem of large and time-delayed beam management signaling overhead is solved, and more flexible and efficient network coverage is achieved.
Patent Information
- Application Number
- PCT/CN2024/075846
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-02-04
- Publication Date
- 2025-08-07
AI Technical Summary
In the prior art, the signaling overhead of beam management is large, time-delayed, flexibility is limited, and the lack of event-driven beam management standardization leads to poor network coverage.
The terminal device receives the CSI reporting configuration information and/or SR resource configuration information sent by the network device, and actively reports event-driven beam management information, including beam switching information, etc., according to these configuration information, and reports it through UCI or PUSCH.
It effectively reduces the delay of beam management, reduces signaling overhead, and improves network coverage.
Smart Images

Figure CN2024075846_07082025_PF_FP_ABST
Abstract
Description
Event-driven beam management method and device Technical Field
[0001] The embodiments of the present application relate to the field of communication technologies. Background Art
[0002] High-band millimeter wave communication is one of the key technical directions of 5G NR (fifth-generation new wireless). Compared to low-band communications, such as those in the sub-6 GHz band, high-band communications face challenges such as high transmission path loss and susceptibility to obstruction. To overcome these challenges, the transmitter uses a large number of densely distributed antenna units and uses beamforming to form beams pointing in specific directions to improve coverage. Correspondingly, the receiver uses beamforming to receive beams in specific directions. This requires the transmitter to select an appropriate transmit beam and the receiver to select an appropriate receive beam to form a beam pair, which together maintain a good wireless link. Beam Management (BM) can establish and maintain such beam pairs.
[0003] In traditional communication systems (3GPP Rel-15 to Rel-18), beam management is primarily initiated by the base station. The base station configures a reference signal (RS) for beam management for the terminal. The terminal then reports its measurement results. The base station then decides whether to initiate beam management based on the terminal's measurement results and sends relevant signaling. The base station then performs the corresponding beam management operations based on the signaling. This type of beam management results in high signaling overhead, long latency, and significantly limited flexibility.
[0004] It should be noted that the above introduction to the technical background is only for the convenience of providing a clear and complete description of the technical solutions of this application and for the convenience of understanding by those skilled in the art. It cannot be considered that the above technical solutions are well known to those skilled in the art simply because these solutions are explained in the background technology part of this application.
[0005] Summary of the Invention
[0006] The inventors found that in 3GPP Rel-19, UE-initiated or event-driven beam management (hereinafter referred to as event-driven beam management) initiated by UE (called user equipment, terminal equipment, terminal, user, etc.) has been identified as one of the project contents. In the beam management initiated by UE, the UE can monitor the downlink beam quality. When an event related to beam management is detected, it can actively initiate a beam management (such as beam switching) request to the base station, which can effectively reduce the delay of beam management, reduce signaling overhead, and improve network coverage. At present, the standardization work on event-driven beam management has not yet begun. Therefore, how to report event-driven beam management events and the specific reporting content have become problems that need to be solved urgently.
[0007] In response to at least one of the above problems or other similar problems, an embodiment of the present application provides an event-driven beam management method and device to reduce the latency of beam management, reduce signaling overhead, and improve network coverage.
[0008] According to one aspect of an embodiment of the present application, an event-driven beam management method is provided, the method comprising:
[0009] The terminal device receives configuration information sent by the network device, where the configuration information includes CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management;
[0010] The terminal device sends event-driven beam management information based on the CSI reporting configuration information and / or the SR resource configuration information.
[0011] In some embodiments, the above-mentioned configuration information includes the above-mentioned CSI reporting configuration information and the above-mentioned SR resource configuration information. When the terminal device detects a beam management event, the terminal device sends a scheduling request (SR) information to the network device on the dedicated SR resource configured for event-driven beam management in the above-mentioned SR resource configuration information, and receives the uplink scheduling authorization information sent by the network device. According to the above-mentioned CSI reporting configuration information, the terminal device sends a CSI report, which includes the above-mentioned event-driven beam management information.
[0012] In other embodiments, the above-mentioned configuration information includes the above-mentioned CSI reporting configuration information, and the terminal device sends the above-mentioned event-driven beam management information according to the above-mentioned CSI reporting configuration information.
[0013] In some further embodiments, the above-mentioned configuration information includes the above-mentioned SR resource configuration information. When the terminal device detects a beam management event, it sends a scheduling request (SR) information to the network device on the dedicated SR resource configured for event-driven beam management according to the above-mentioned SR resource configuration information, and receives the uplink scheduling authorization information sent by the network device, and sends the above-mentioned event-driven beam management information on the PUSCH scheduled by the uplink scheduling authorization information.
[0014] One of the beneficial effects of the embodiments of the present application is that: according to the embodiments of the present application, by reporting event-driven beam management information (such as event-driven beam switching information) through uplink control information, the delay of beam management can be effectively reduced, the signaling overhead can be reduced, and the network coverage can be improved.
[0015] With reference to the following description and accompanying drawings, specific embodiments of the present application are disclosed in detail, indicating the manner in which the principles of the present application can be employed. It should be understood that the embodiments of the present application are not limited in scope. Within the spirit and scope of the appended claims, the embodiments of the present application include many variations, modifications and equivalents.
[0016] Features described and / or illustrated with respect to one embodiment may be used in the same or similar manner in one or more other embodiments, combined with features in other embodiments, or substituted for features in other embodiments.
[0017] It should be emphasized that the term "include / comprising" when used herein refers to the presence of features, integers, steps or components, but does not exclude the presence or addition of one or more other features, integers, steps or components. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] The elements and features described in one figure or one embodiment of the present application can be combined with the elements and features shown in one or more other figures or embodiments. In addition, in the accompanying drawings, similar reference numerals represent corresponding parts in several figures and can be used to indicate corresponding parts used in more than one embodiment.
[0019] FIG1 is a schematic diagram of an event-driven beam management method according to an embodiment of the present application;
[0020] FIG2 is a schematic diagram of a terminal device sending event-driven beam management information according to CSI reporting configuration information and SR resource configuration information;
[0021] FIG3 is a schematic diagram of a terminal device sending event-driven beam management information according to CSI reporting configuration information;
[0022] FIG4 is a schematic diagram of a terminal device reporting event-driven beam management information;
[0023] FIG5 is a schematic diagram of a terminal device sending event-driven beam management information according to SR resource configuration information;
[0024] FIG6 is a schematic diagram of a configuration method of event-driven beam management according to an embodiment of the present application;
[0025] FIG7 is a schematic diagram of an event-driven beam management device according to an embodiment of the present application;
[0026] FIG8 is a schematic diagram of a configuration device for event-driven beam management according to an embodiment of the present application;
[0027] FIG9 is a schematic diagram of a communication system according to an embodiment of the present application;
[0028] FIG10 is a schematic diagram of the structure of a terminal device according to an embodiment of the present application;
[0029] FIG11 is a schematic diagram of the structure of a network device according to an embodiment of the present application. DETAILED DESCRIPTION
[0030] The above and other features of the present application will become apparent through the following description with reference to the accompanying drawings. In the description and the accompanying drawings, specific embodiments of the present application are disclosed in detail, which illustrate some embodiments in which the principles of the present application can be adopted. It should be understood that the present application is not limited to the described embodiments. On the contrary, the present application includes all modifications, variations and equivalents that fall within the scope of the appended claims.
[0031] In the embodiments of the present application, the terms "first", "second", etc. are used to distinguish different elements from the name, but do not indicate the spatial arrangement or temporal order of these elements, and these elements should not be limited by these terms. The term "and / or" includes any one and all combinations of one or more of the associated listed terms. The terms "comprising", "including", "having", etc. refer to the presence of the stated features, elements, components or components, but do not exclude the presence or addition of one or more other features, elements, components or components.
[0032] In the embodiments of this application, the singular forms "a," "the," etc. include plural forms and should be broadly understood to mean "a" or "a type" rather than being limited to "one." Furthermore, the term "said" should be understood to include both singular and plural forms, unless the context clearly indicates otherwise. Furthermore, the term "according to" should be understood to mean "at least in part based on...", and the term "based on" should be understood to mean "at least in part based on...", unless the context clearly indicates otherwise.
[0033] In the embodiments of the present application, the term "communication network" or "wireless communication network" may refer to a network that complies with any of the following communication standards, such as Long Term Evolution (LTE), enhanced Long Term Evolution (LTE-A, LTE-Advanced), Wideband Code Division Multiple Access (WCDMA, Wideband Code Division Multiple Access), High-Speed Packet Access (HSPA, High-Speed Packet Access), 5G (5Generation) New Radio (NR, New Radio), etc.
[0034] Furthermore, communication between devices in the communication system may be carried out according to communication protocols of any stage, for example including but not limited to the following communication protocols: 1G, 2G, 2.5G, 2.75G, 3G, 4G, 4.5G and 5G new wireless, etc., and / or other communication protocols currently known or to be developed in the future.
[0035] In the embodiments of the present application, the term "network device" refers to, for example, a device in a communication system that connects a terminal device to the communication network and provides services to the terminal device. Network devices may include, but are not limited to, the following devices: base station (BS), access point (AP), transmission reception point (TRP), broadcast transmitter, mobile management entity (MME), gateway, server, radio network controller (RNC), base station controller (BSC), etc.
[0036] Base stations may include, but are not limited to, NodeB (NB), evolved NodeB (eNodeB or eNB), and 5G base stations (gNB), among others. They may also include remote radio heads (RRHs), remote radio units (RRUs), relays, or low-power nodes (e.g., femeto, pico, etc.). The term "base station" may include some or all of their functions, and each base station may provide communication coverage for a specific geographic area. The term "cell" may refer to a base station and / or its coverage area, depending on the context in which the term is used.
[0037] In the embodiments of the present application, the term "user equipment" (UE) or "terminal equipment" (TE) refers to, for example, a device that accesses a communication network through a network device and receives network services. A terminal device can be fixed or mobile and may also be referred to as a mobile station (MS), a terminal, a subscriber station (SS), an access terminal (AT), a station, and so on.
[0038] Among them, terminal devices may include but are not limited to the following devices: cellular phones, personal digital assistants (PDAs), wireless modems, wireless communication devices, handheld devices, machine-type communication devices, laptop computers, cordless phones, smart phones, smart watches, digital cameras, etc.
[0039] For another example, in scenarios such as the Internet of Things (IoT), the terminal device can also be a machine or device for monitoring or measurement, including but not limited to: machine type communication (MTC) terminal, vehicle-mounted communication terminal, device-to-device (D2D) terminal, machine-to-machine (M2M) terminal, and so on.
[0040] In addition, the term "network side" or "network device side" refers to one side of the network, which can be a base station or one or more network devices as described above. The term "user side" or "terminal side" or "terminal device side" refers to the user or terminal side, which can be a UE or one or more terminal devices as described above. Unless otherwise specified herein, "device" can refer to either network equipment or terminal equipment.
[0041] To facilitate understanding, some concepts involved in the embodiments of this application are explained below.
[0042] In the embodiment of the present application, uplink control information (UCI) mainly includes hybrid automatic repeat request acknowledgment (HARQ-ACK), scheduling request (SR), channel state information (CSI), etc. Uplink control information can be transmitted on the physical uplink control channel (PUCCH) or the physical downlink shared channel (PUSCH).
[0043] SR is a type of UCI sent by the UE to the gNB via the PUCCH to request uplink resources from the network. Radio Resource Control (RRC) pre-configures dedicated periodic PUCCH resources, which the UE uses to send SRs on the PUCCH. The RRC Information Element (IE) SchedulingRequestConfig configures SR parameters. The physical layer resources corresponding to the SR are configured in the schedulingRequestResourceToAddModList or schedulingRequestResourceToAddModListExt fields in PUCCH-Config. These two fields are lists, with the list elements representing the SR resource configuration, SchedulingRequestResourceConfig.
[0044] CSI is also a type of UCI. The UE feeds back CSI to the base station in the form of a CSI report, which can provide the base station with the parameters required for transmission. The relevant resources for CSI reporting are configured by the high-level parameter CSI-ReportConfig, and the specific CSI reporting content is configured by the reportQuantity field in CSI-ReportConfig. For example, reportQuantity can be configured as:
[0045] 'cri-RSRP' feedback includes the CSI-RS Resource Indicator (CRI) and Layer 1 Reference Signal Receiving Power (L1-RSRP), which are beam index information and beam quality information, respectively. It can be used for CSI-RS-based beam management.
[0046] 'ssb-Index-RSRP': This feedback includes the synchronization signal block resource indicator (SSBRI) and L1-RSRP, which are beam index information and beam quality information, respectively. This can be used for SSB-based beam management.
[0047] ●And so on.
[0048] Currently, the protocol does not include reporting content related to event-driven beam management. If event-driven beam management is introduced, the UE will detect events (events) that require initiation of beam management according to specific criteria. The beam management here includes at least beam switching. The specific criteria are not limited in this application. For the sake of convenience, events related to beam management (including beam switching events) are collectively referred to as "beam management events" below. In the embodiments of this application, "beam switching events" are used as an example for explanation.
[0049] After detecting a beam switching event, the UE may proactively report the event and other information related to the beam switching, such as one or more of the following information about the new beam (the target beam to be selected, also known as the candidate beam):
[0050] CRI / SSBRI information;
[0051] L1-RSRP / L1-SINR (Layer 1 Signal Interference Noise Ratio) information;
[0052] Physical cell ID information;
[0053] ●Unified Transmission Configuration Indication State ID (TCI-StateId);
[0054] ●And so on.
[0055] For ease of explanation, this information is collectively referred to as “beam switching information” below. It is worth noting that the beam switching information may belong to CSI, that is, may be a type of CSI, but the present application is not limited thereto, and the beam switching information may not belong to CSI.
[0056] In addition, the current protocol does not include how to report event-driven beam switching events and beam switching information. The UE may report beam switching events and beam switching information through different channels, such as through MAC-CE (Media Access Control Element), through UCI, and so on.
[0057] The embodiments of the present application are described below with reference to the accompanying drawings and specific implementation methods.
[0058] Embodiments of the first aspect
[0059] An embodiment of the present application provides an event-driven beam management method, which is described from the perspective of a terminal device.
[0060] FIG1 is a schematic diagram of an event-driven beam management method according to an embodiment of the present application. As shown in FIG1 , the method includes:
[0061] 110. The terminal device receives configuration information sent by the network device, where the configuration information includes CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management.
[0062] 120. The terminal device sends event-driven beam management information according to the above-mentioned CSI reporting configuration information and / or the above-mentioned SR resource configuration information.
[0063] It is worth noting that FIG1 above is merely a schematic illustration of an embodiment of the present application, and the present application is not limited thereto. For example, other operations may be added or some operations may be reduced, and the objects of the above operations may be adjusted. Those skilled in the art may make appropriate modifications based on the above content, and are not limited to the description of FIG1 above.
[0064] According to an embodiment of the present application, by reporting event-driven beam management information (such as beam switching information) through UCI, the delay of beam management is effectively reduced, the signaling overhead is reduced, and the network coverage is improved.
[0065] In the above embodiment, the event-driven beam switching information has been described above and will not be repeated here.
[0066] In some embodiments, in operation 120, the terminal device sends the event-driven beam management information according to the CSI reporting configuration information and the SR resource configuration information. FIG2 is a schematic diagram of this embodiment. As shown in FIG2, the method includes:
[0067] 210: The terminal device receives configuration information sent by the network device, where the configuration information includes CSI reporting configuration information and SR resource configuration information associated with event-driven beam management.
[0068] 220: When the terminal device detects a beam management event, it sends a scheduling request (SR) message to the network device on the dedicated SR resource configured for event-driven beam management.
[0069] 230: The terminal device receives uplink scheduling grant information sent by the network device. The uplink scheduling grant information can be used to trigger aperiodic CSI reporting.
[0070] 240: The terminal device sends a CSI report on the PUSCH scheduled by the uplink scheduling authorization information according to the above CSI reporting configuration information, and the CSI report includes the above event-driven beam management information.
[0071] In the above embodiment, the CSI reporting configuration information is, for example, a signal element CSI-ReportConfig. Optionally, its time domain characteristic, that is, the reporting type (reportConfigType), is aperiodic. After receiving the above uplink scheduling authorization information sent by the network device, the terminal device can send a CSI report containing the above event-driven beam management information according to the CSI reporting configuration information.
[0072] In the above embodiment, the SR resource configuration information may be included in the information element PUCCH-Config. For example, a new field may be added to the information element PUCCH-Config to configure the SR resource configuration information associated with event-driven beam management.
[0073] For example, the SR resource configuration information may be a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management. The list element in the SR resource configuration information may be SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
[0074] In the above embodiment, the SchedulingRequestResourceConfigExt-EventBM may include a switch field for indicating whether event-driven beam management is used. For example, this switch field is called eventBeamManagementFlag and has a single value, such as "enabled." If this switch field is configured, it indicates that the current SR resource is used for event-driven beam management.
[0075] In the above embodiment, the SchedulingRequestResourceConfigExt-EventBM may also include a field indicating priority, such as phy-PriorityIndex, whose value can be any one of p0, p1, and p2, with the corresponding priorities from high to low being p2>p1>p0. If this field is not configured, the default priority is p0, which is the lowest priority.
[0076] The following is an example of the SR resource configuration information according to the above embodiment:
[0077] It is worth noting that the above is just an example. In the above embodiment, the SR resource configuration information may also be in other forms, or called other. The above switch field and / or the field indicating the priority contained in the SR resource configuration information may also be called other, and is not limited to the examples in the above example.
[0078] In the above embodiment, in operation 220, when the terminal device detects a beam management event, it can send the above SR information to the network device. The SR information can be carried by the dedicated SR resources configured for event-driven beam management by the above RRC resource configuration information, so as to inform the network device that the SR information is used for event-driven beam management.
[0079] In the above embodiment, in operation 230, the terminal device may receive uplink scheduling authorization information sent by the network device. The uplink scheduling authorization information is used to schedule PUSCH and may be carried by DCI (downlink control information) format 0_1 or DCI format 0_2 or DCI format 0_3 (DCI format 0_1 / 0_2 / 0_3).
[0080] In the above embodiment, the uplink scheduling grant information also needs to include a CSI request field, and the CSI request field is used to trigger aperiodic CSI reporting.
[0081] In the above embodiment, in operation 240, after receiving the above uplink scheduling authorization information sent by the network device, the terminal device can send a CSI report on the PUSCH scheduled by the above uplink scheduling authorization information according to the above CSI reporting configuration information, and the CSI report includes the above event-driven beam management information.
[0082] In the above embodiment, the PUSCH scheduled by the uplink scheduling grant information may carry uplink control information (UCI), which is the CSI report and includes event-driven beam management information. For example, if the UL-SCH indicator field in the uplink scheduling grant information is set to 0, the scheduled PUSCH only carries the UCI (CSI report).
[0083] The present application is not limited thereto, and the PUSCH scheduled by the uplink scheduling grant information may also carry an uplink shared channel (UL-SCH). For example, if the UL-SCH indicator field in the uplink scheduling grant information is set to 1, then the scheduled PUSCH carries not only the UL-SCH but also the UCI (CSI reporting), i.e., the UCI (CSI reporting) is multiplexed on the PUSCH.
[0084] According to the above embodiment, the terminal device can report event-driven beam management information based on the CSI reporting configuration information and SR resource configuration information, which effectively reduces the delay of beam management, reduces signaling overhead, and improves network coverage.
[0085] In some other embodiments, in operation 120, the terminal device sends event-driven beam management information according to the above CSI reporting configuration information. FIG3 is a schematic diagram of this embodiment. As shown in FIG3, the method includes:
[0086] 310: The terminal device receives configuration information sent by the network device, where the configuration information includes CSI reporting configuration information associated with event-driven beam management.
[0087] 320: The terminal device sends event-driven beam management information according to the CSI reporting configuration information.
[0088] In the above embodiment, the CSI reporting configuration information is, for example, a symbol CSI-ReportConfig, and its time domain characteristics, i.e., the reporting type (reportConfigType), is periodic (periodic) or semi-persistent (semiPersistentOnPUCCH or semiPersistentOnPUSCH). The terminal device sends corresponding event-driven beam management information after detecting an event-driven beam management event based on the CSI reporting configuration information.
[0089] In the above embodiment, optionally, the CSI reporting configuration information may include a first field, and the first field is used to indicate that the CSI reporting configuration information is used for event-driven beam management.
[0090] In the above embodiment, the first field may be a new field in CSI-ReportConfig, used to indicate that the user's current CSI reporting configuration information is used to report events and information related to event-driven beam management. The first field may be called, for example, eventBeamManagementFlag, which may be a switch field with a single value, called "enabled". If the eventBeamManagementFlag field is configured, it indicates that the current CSI-ReportConfig is used for event-driven beam management.
[0091] The following is an example of the eventBeamManagementFlag included in the CSI-ReportConfig: … eventBeamManagementFlag ENUMERATED{enabled} OPTIONAL,--Need M …
[0092] The above takes the first field called eventBeamManagementFlag as an example, but the present application is not limited to this. The first field can also be called other names as long as it can be used to indicate that the CSI reporting configuration information is used for event-driven beam management.
[0093] In the above embodiment, optionally, existing fields in CSI-ReportConfig may be reused. For example, the CSI reporting configuration information includes a second field, the value of which includes a first reporting option, and the first reporting option is used for event-driven beam management.
[0094] In the above embodiment, the second field is, for example, the existing field reportQuantity in CSI-ReportConfig, and the first reporting option is, for example, the field EventBMInfo. The field EventBMInfo can be in a list format, and the list content is zero to multiple candidate beam information. For example, the value of EventBMInfo is newBeamToAddModList in the form of a list (SEQUENCE), and the specific content of the list is zero to multiple candidate beam information (NewBeamInfo), with the maximum number not exceeding maxNrofNewBeam. The specific content of the candidate beam information is as described above and will not be repeated here.
[0095] The following is an example of adding the new field EventBMInfo to the existing field reportQuantity in the CSI-ReportConfig:
[0096] In the above embodiment, in operation 320, the terminal device may send event-driven beam management information according to the above CSI reporting configuration information when the above CSI reporting configuration information is effective or activated.
[0097] For example, as shown in Figure 4, the terminal device receives a dedicated periodic CSI reporting configuration information and the configuration takes effect, or receives a dedicated semi-continuous CSI reporting configuration and is activated through MAC-CE or DCI, then the terminal device reports the information of the new beam A and the new beam B at a reporting time (time T1) that meets the requirements of the CSI reporting configuration information, reports the information of the new beam A, the new beam B, and the new beam C at the next reporting time (time T2), does not report any new beam information at the next reporting time (time T3), and reports the new beam A and the new beam C information at the next reporting time (time T4)... until the terminal device receives a new high-level configuration, or receives a signaling to deactivate the reporting of the "event-driven beam management event".
[0098] According to the above embodiment, the terminal device can report event-driven beam management information based on the CSI reporting configuration information, which effectively reduces the delay of beam management, reduces signaling overhead, and improves network coverage.
[0099] In some other embodiments, in operation 120, the terminal device sends event-driven beam management information according to the above SR resource configuration information. FIG5 is a schematic diagram of this embodiment. As shown in FIG5, the method includes:
[0100] 510: The terminal device receives configuration information sent by the network device, where the configuration information includes SR resource configuration information associated with event-driven beam management.
[0101] 520: When the terminal device detects a beam management event, it sends a scheduling request (SR) message to the network device on the dedicated SR resource configured for event-driven beam management.
[0102] 530: The terminal device receives uplink scheduling authorization information sent by the network device;
[0103] 540: The terminal device sends the above-mentioned event-driven beam management information on the PUSCH scheduled by the above-mentioned uplink scheduling authorization information.
[0104] In the above embodiment, the SR resource configuration information may be included in the information element PUCCH-Config. For example, a new field may be added to the information element PUCCH-Config to configure the SR resource configuration information associated with event-driven beam management.
[0105] For example, the SR resource configuration information may be a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management. The list element in the SR resource configuration information may be SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
[0106] In the above embodiment, the SchedulingRequestResourceConfigExt-EventBM may include a switch field for indicating whether event-driven beam management is used. For example, it is called eventBeamManagementFlag, which has only one value, such as "enabled". If the switch field eventBeamManagementFlag is configured, it indicates that the current SR resource is used for event-driven beam management.
[0107] In the above embodiment, the SchedulingRequestResourceConfigExt-EventBM may also include a field indicating priority, such as phy-PriorityIndex, whose value can be any one of p0, p1, and p2, with the corresponding priorities from high to low being p2>p1>p0. If this field is not configured, the default priority is p0, which is the lowest priority.
[0108] The following is an example of the SR resource configuration information according to the above embodiment:
[0109] It is worth noting that the above is just an example. In the above embodiment, the SR resource configuration information may also be in other forms, or called other. The above switch field and / or the field indicating the priority contained in the SR resource configuration information may also be called other, and is not limited to the examples in the above example.
[0110] In the above embodiment, in operation 520, when the terminal device detects a beam management event, it can send the above SR information to the network device. The SR information can be carried by the dedicated SR resources configured for event-driven beam management by the above RRC resource configuration information, so as to inform the network device that the SR information is used for event-driven beam management.
[0111] In the above embodiment, in operation 530, the terminal device may receive uplink scheduling grant information sent by the network device. The uplink scheduling grant information is used to schedule PUSCH and may be carried by DCI format 0_1, DCI format 0_2, or DCI format 0_3 (DCI format 0_1 / 0_2 / 0_3).
[0112] In the above embodiment, in operation 540, after receiving the above uplink scheduling grant information sent by the network device, the terminal device can send the above event-driven beam management information on the PUSCH scheduled by the above uplink scheduling grant information.
[0113] In the above embodiment, the PUSCH scheduled by the uplink scheduling grant information carries an uplink shared channel (UL-SCH), and the UL-SCH includes the above event-driven beam management information. In this embodiment, the value of the UL-SCH indicator field in the uplink scheduling grant information is 1, indicating that the UL-SCH includes the above event-driven beam management information.
[0114] According to the above embodiment, the terminal device can report event-driven beam management information based on the SR resource configuration information, which effectively reduces the delay of beam management, reduces signaling overhead, and improves network coverage.
[0115] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.
[0116] According to the method of the embodiment of the present application, based on the configuration of the network equipment, the delay of beam management is effectively reduced, the signaling overhead is reduced, and the network coverage is improved.
[0117] Embodiments of the second aspect
[0118] An embodiment of the present application provides a configuration method for event-driven beam management, which is explained from the side of the network device. This method is the processing on the network device side corresponding to the method of the embodiment of the first aspect, and the content that is the same as the embodiment of the first aspect is not repeated.
[0119] FIG6 is a schematic diagram of a configuration method for event-driven beam management according to an embodiment of the present application. As shown in FIG6 , the method includes:
[0120] 610: The network device sends configuration information to the terminal device, where the configuration information includes CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management.
[0121] 620: The network device receives event-driven beam management information sent by the terminal device.
[0122] It is worth noting that FIG6 above is only a schematic illustration of the embodiment of the present application, and the present application is not limited thereto. For example, other operations may be added or some operations may be reduced. Those skilled in the art may make appropriate modifications based on the above content, and are not limited to the description of FIG6 above.
[0123] According to an embodiment of the present application, the network device configures CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management for the terminal device, so that the terminal device can report event-driven beam management information, effectively reducing the delay of beam management, reducing signaling overhead, and improving network coverage.
[0124] In some embodiments, corresponding to the method shown in Figure 2 in the embodiment of the first aspect, the network device may also receive scheduling request information sent by the terminal device, and send uplink scheduling authorization information to the terminal device, and the uplink scheduling authorization information can be used to trigger non-periodic CSI reporting. Thus, the terminal device can send a CSI report containing the above-mentioned event-driven beam management information to the terminal device according to the above-mentioned CSI reporting configuration information. Accordingly, the network device can receive a CSI report containing the above-mentioned event-driven beam management information sent by the terminal device according to the above-mentioned CSI reporting configuration information.
[0125] In some embodiments, corresponding to the method shown in Figure 3 in the embodiment of the first aspect, the network device can also receive event-driven beam management information sent by the terminal device according to the above-mentioned CSI reporting configuration information.
[0126] In some embodiments, corresponding to the method shown in FIG5 of the embodiment of the first aspect, the network device may further receive scheduling request information sent by the terminal device and send uplink scheduling authorization information to the terminal device. Thus, the terminal device may send the above-mentioned event-driven beam management information on the PUSCH scheduled by the uplink scheduling authorization information. Correspondingly, the network device may receive the above-mentioned event-driven beam management information sent by the terminal device on the PUSCH scheduled by the above-mentioned uplink scheduling authorization information.
[0127] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.
[0128] According to the method of the embodiment of the present application, the delay of beam management is effectively reduced, the signaling overhead is reduced, and the network coverage is improved through the configuration of network equipment.
[0129] Embodiments of the third aspect
[0130] The embodiment of the present application provides an event-driven beam management device. The device may be, for example, a terminal device, or one or more components or assemblies configured in the terminal device. The contents that are the same as those in the first and second aspects are not repeated here.
[0131] FIG7 is a schematic diagram of an event-driven beam management device according to an embodiment of the present application. As shown in FIG7 , the event-driven beam management device 700 according to an embodiment of the present application includes:
[0132] a receiving unit 710 configured to receive configuration information sent by a network device, the configuration information including CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management;
[0133] A sending unit 720 sends event-driven beam management information according to the CSI reporting configuration information and / or the SR resource configuration information.
[0134] In some embodiments, the sending unit 720 sends event-driven beam management information according to the above-mentioned CSI reporting configuration information and the above-mentioned SR resource configuration information.
[0135] In the above embodiment, when the terminal device detects a beam management event, the sending unit 720 sends a scheduling request (SR) information to the network device on the dedicated SR resource configured for event-driven beam management in the above SR resource configuration information; the receiving unit 710 receives the uplink scheduling authorization information sent by the network device, and the uplink scheduling authorization information can be used to trigger non-periodic CSI reporting; the sending unit 720 sends a CSI report on the PUSCH scheduled by the above uplink scheduling authorization information according to the above CSI reporting configuration information, and the CSI report includes the above event-driven beam management information.
[0136] In the above embodiment, optionally, the reporting type (reportConfigType) of the CSI reporting configuration information is aperiodic.
[0137] In the above embodiment, optionally, the SR resource configuration information may be included in the information element PUCCH-Config.
[0138] In the above embodiment, optionally, the SR resource configuration information is a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management.
[0139] In some possible implementations, the list element in the SR resource configuration information is SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
[0140] In the above implementation, SchedulingRequestResourceConfigExt-EventBM may further include a switch field (eventBeamManagementFlag) for indicating whether to use event-driven beam management and / or a field indicating priority (phy-PriorityIndex).
[0141] In the above embodiment, the uplink scheduling grant information may be carried by DCI format 0_1, DCI format 0_2, or DCI format 0_3.
[0142] In the above embodiment, the uplink scheduling grant information may further include a CSI request field, and the CSI request field is used to trigger aperiodic CSI reporting.
[0143] In the above embodiment, the PUSCH scheduled by the uplink scheduling grant information can carry the above CSI reporting (including event-driven beam management information).
[0144] In the above embodiment, the PUSCH scheduled by the uplink scheduling grant information may also carry an uplink shared channel (UL-SCH).
[0145] In other embodiments, the sending unit 720 sends event-driven beam management information according to the above-mentioned CSI reporting configuration information.
[0146] In the above embodiment, the reporting type (reportConfigType) of the above CSI reporting configuration information is periodic (periodic) or semi-persistent (semiPersistentOnPUCCH or semiPersistentOnPUSCH).
[0147] In the above embodiment, the CSI reporting configuration information may include a first field, where the first field is used to indicate that the CSI reporting configuration information is used for event-driven beam management.
[0148] In the above embodiment, the CSI reporting configuration information may be the information element CSI-ReportConfig, the first field may be eventBeamManagementFlag, and the first field may be a switch field.
[0149] In the above embodiment, the CSI reporting configuration information may include a second field, the value of the second field includes a first reporting option, and the first reporting option is used for event-driven beam management.
[0150] In the above embodiment, the CSI reporting configuration may be the information element CSI-ReportConfig, the second field may be reportQuantity, and the first reporting option may be the field EventBMInfo. The field EventBMInfo is in list form, and the list content is zero to multiple candidate beam information.
[0151] In the above embodiment, the terminal device may send event-driven beam management information according to the CSI reporting configuration information when the above CSI reporting configuration information is effective or activated.
[0152] In some further embodiments, the sending unit 720 sends event-driven beam management information according to the above-mentioned SR resource configuration information.
[0153] In the above embodiment, when the terminal device detects a beam management event, the sending unit 720 sends a scheduling request (SR) information to the network device on a dedicated SR resource whose SR resource configuration information is event-driven beam management configuration; the receiving unit 710 receives the uplink scheduling authorization information sent by the network device; the sending unit 720 sends the above-mentioned event-driven beam management information on the PUSCH scheduled by the uplink scheduling authorization information.
[0154] In the above embodiment, the SR resource configuration information may be included in the information element PUCCH-Config.
[0155] In the above embodiment, the SR resource configuration information may be a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management.
[0156] In the above embodiment, the list element in the SR resource configuration information may be SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
[0157] In the above embodiment, SchedulingRequestResourceConfigExt-EventBM may include a switch field (eventBeamManagementFlag) for indicating whether to use event-driven beam management and / or a field indicating a priority (phy-PriorityIndex).
[0158] In the above embodiment, the uplink scheduling grant information may be carried by DCI format 0_1, DCI format 0_2, or DCI format 0_3.
[0159] In the above embodiment, the PUSCH scheduled by the uplink scheduling grant information may carry the UL-SCH, which includes the above event-driven beam management information.
[0160] In the above embodiment, the value of the UL-SCH indicator field in the uplink scheduling grant information is 1.
[0161] The present application also provides an event-driven beam management configuration device. The device can be, for example, a network device, or one or more components or assemblies configured on the network device. The same contents as those in the first and second aspects are not repeated here.
[0162] FIG8 is a schematic diagram of a configuration device for event-driven beam management according to an embodiment of the present application. As shown in FIG8 , the configuration device 800 for event-driven beam management according to an embodiment of the present application includes:
[0163] a sending unit 810 configured to send configuration information to a terminal device, the configuration information including CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management;
[0164] The receiving unit 820 receives event-driven beam management information sent by the terminal device.
[0165] In some embodiments, corresponding to the method shown in Figure 2 in the embodiment of the first aspect, the receiving unit 820 can also receive scheduling request information sent by the terminal device, and the sending unit 810 can also send uplink scheduling authorization information to the terminal device, and the uplink scheduling authorization information can be used to trigger non-periodic CSI reporting. The receiving unit 820 can also receive the CSI report containing the above-mentioned event-driven beam management information sent by the terminal device according to the above-mentioned CSI reporting configuration information.
[0166] In some embodiments, corresponding to the method shown in FIG3 in the embodiment of the first aspect, the receiving unit 820 may also receive event-driven beam management information sent by the terminal device according to the above-mentioned CSI reporting configuration information.
[0167] In some embodiments, corresponding to the method shown in Figure 5 in the embodiment of the first aspect, the receiving unit 820 can also receive scheduling request information sent by the terminal device, the sending unit 810 can also send uplink scheduling authorization information to the terminal device, and the receiving unit 820 can also receive the above-mentioned event-driven beam management information sent by the terminal device on the PUSCH scheduled by the above-mentioned uplink scheduling authorization information.
[0168] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.
[0169] It is worth noting that the above description only describes the components or modules related to the present application, but the present application is not limited thereto. Apparatuses 700 and 800 may also include other components or modules, and for details of these components or modules, reference may be made to related art.
[0170] In addition, for the sake of simplicity, Figures 7 and 8 only illustrate the connection relationships or signal paths between various components or modules. However, those skilled in the art should be aware that various related technologies such as bus connections can be used. The above-mentioned components or modules can be implemented by hardware facilities such as processors, memories, transmitters, and receivers; this application is not limited to this.
[0171] According to the device of the embodiment of the present application, the delay of beam management is effectively reduced, the signaling overhead is reduced, and the network coverage is improved.
[0172] Embodiments of the fourth aspect
[0173] An embodiment of the present application also provides a communication system, which includes a network device and a terminal device.
[0174] FIG9 is a schematic diagram of a communication system according to an embodiment of the present application, schematically illustrating a situation using a terminal device and a network device as an example. As shown in FIG9 , a communication system 900 may include a network device 901 and terminal devices 902 and 903. For simplicity, FIG9 illustrates only two terminal devices and one network device as an example, but the embodiments of the present application are not limited thereto.
[0175] In this embodiment of the present application, existing services or future services can be transmitted between the network device 901 and the terminal devices 902 and 903. For example, these services may include, but are not limited to, enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable and low-latency communication (URLLC).
[0176] It is worth noting that Figure 9 shows that both terminal devices 902 and 903 are within the coverage range of network device 901, but the present application is not limited thereto. Both terminal devices 902 and 903 may not be within the coverage range of network device 901, or one terminal device 902 may be within the coverage range of network device 901 while the other terminal device 903 is outside the coverage range of network device 901.
[0177] In some embodiments, the terminal device includes the apparatus 700 described in the embodiment of the second aspect, and is configured to perform the method described in the embodiment of the first aspect. Since the method has been described in detail in the embodiment of the first aspect, its content is incorporated herein and will not be repeated.
[0178] In some embodiments, the network device includes the apparatus 800 described in the embodiment of the second aspect, and is configured to perform the method described in the embodiment of the second aspect. Since the method has been described in detail in the embodiment of the second aspect, its content is incorporated herein and will not be repeated.
[0179] An embodiment of the present application further provides a terminal device, which may be, for example, a UE, but the present application is not limited thereto and may also be other devices.
[0180] Figure 10 is a schematic diagram of a terminal device according to an embodiment of the present application. As shown in Figure 10 , terminal device 1000 may include a processor 1010 and a memory 1020. Memory 1020 stores data and programs and is coupled to processor 1010. It should be noted that this diagram is exemplary; other types of structures may be used to supplement or replace this structure to implement telecommunication or other functions.
[0181] For example, the processor 1010 may be configured to execute a program to implement the method described in the embodiment of the first aspect.
[0182] As shown in Figure 10 , the terminal device 1000 may further include: a communication module 1030, an input unit 1040, a display 1050, and a power supply 1060. The functions of these components are similar to those in the prior art and are not described in detail here. It is worth noting that the terminal device 1000 does not necessarily include all of the components shown in Figure 10 , and these components are not essential. Furthermore, the terminal device 1000 may also include components not shown in Figure 10 , for which reference may be made to the prior art.
[0183] An embodiment of the present application further provides a network device, which may be a gNB, for example, but the present application is not limited thereto and may also be other network devices.
[0184] Figure 11 is a schematic diagram illustrating the structure of a network device according to an embodiment of the present application. As shown in Figure 11 , network device 1100 may include a processor 1110 (e.g., a central processing unit (CPU)) and a memory 1120 ; the memory 1120 is coupled to the processor 1110 . The memory 1120 may store various data and may also store an information processing program 1130 , which is executed under the control of the processor 1110 .
[0185] For example, the processor 1110 may be configured to execute a program to implement the method as described in the embodiment of the second aspect.
[0186] In addition, as shown in FIG11 , the network device 1100 may further include: a transceiver 1140 and an antenna 1150, etc.; wherein, the functions of the above components are similar to those in the prior art and are not described in detail here. It is worth noting that the network device 1100 does not necessarily include all the components shown in FIG11 ; in addition, the network device 1100 may also include components not shown in FIG11 , and reference may be made to the prior art for details.
[0187] An embodiment of the present application further provides a computer program, wherein when the program is executed in a terminal device, the program causes the terminal device to execute the method described in the embodiment of the first aspect.
[0188] An embodiment of the present application further provides a storage medium storing a computer program, wherein the computer program enables a terminal device to execute the method described in the embodiment of the first aspect.
[0189] An embodiment of the present application further provides a computer program, wherein when the program is executed in a network device, the program causes the network device to execute the method described in the embodiment of the second aspect.
[0190] An embodiment of the present application further provides a storage medium storing a computer program, wherein the computer program enables a network device to execute the method described in the embodiment of the second aspect.
[0191] The above devices and methods of the present application can be implemented by hardware or by a combination of hardware and software. The present application relates to such a computer-readable program that, when executed by a logic component, enables the logic component to implement the devices or components described above, or enables the logic component to implement the various methods or steps described above. The present application also relates to a storage medium for storing the above program, such as a hard disk, a magnetic disk, an optical disk, a DVD, a flash memory, etc.
[0192] The method / device described in conjunction with the embodiments of the present application can be directly embodied as hardware, a software module executed by a processor, or a combination of the two. For example, one or more of the functional block diagrams shown in the figure and / or one or more combinations of functional block diagrams can correspond to various software modules of the computer program flow or to various hardware modules. These software modules can respectively correspond to the various steps shown in the figure. These hardware modules can be implemented by solidifying these software modules, for example, using a field programmable gate array (FPGA).
[0193] The software module may be located in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium; or the storage medium may be an integral part of the processor. The processor and the storage medium may be located in an ASIC. The software module may be stored in the memory of the mobile terminal or in a memory card that can be inserted into the mobile terminal. For example, if the device (such as a mobile terminal) uses a large-capacity MEGA-SIM card or a large-capacity flash memory device, the software module may be stored in the MEGA-SIM card or the large-capacity flash memory device.
[0194] One or more of the functional blocks and / or one or more combinations of functional blocks described in the accompanying drawings may be implemented as a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, or any appropriate combination thereof for performing the functions described in this application. One or more of the functional blocks and / or one or more combinations of functional blocks described in the accompanying drawings may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in communication with a DSP, or any other such configuration.
[0195] The present application has been described above in conjunction with specific embodiments. However, those skilled in the art should understand that these descriptions are merely illustrative and are not intended to limit the scope of protection of the present application. Those skilled in the art may make various modifications and variations to the present application based on the spirit and principles of the present application, and such modifications and variations are also within the scope of the present application.
[0196] 1. A terminal device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to implement the following method:
[0197] receiving configuration information sent by a network device, where the configuration information includes CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management;
[0198] Send event-driven beam management information according to the CSI reporting configuration information and / or the SR resource configuration information.
[0199] 2. A network device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to implement the following method:
[0200] Sending configuration information to the terminal device, where the configuration information includes CSI reporting configuration information and / or SR resource configuration information associated with event-driven beam management;
[0201] Receive event-driven beam management information sent by the terminal device according to the CSI reporting configuration information and / or the SR resource configuration information.
[0202] 3. A communication system comprising the network device described in Note 2 and the terminal device described in Note 1.
Claims
1. An event-driven beam management device, configured in a terminal device, wherein: The device comprises: a receiving unit configured to receive configuration information sent by a network device, wherein the configuration information includes channel state information (CSI) reporting configuration information and / or scheduling request (SR) resource configuration information associated with event-driven beam management; A sending unit, which sends event-driven beam management information according to the CSI reporting configuration information and / or the SR resource configuration information.
2. The device according to claim 1, wherein When the terminal device detects a beam management event, the sending unit sends a scheduling request (SR) message to the network device on a dedicated SR resource whose SR resource configuration information is configured for the event-driven beam management; The receiving unit receives uplink scheduling grant information sent by the network device, where the uplink scheduling grant information can be used to trigger aperiodic CSI reporting; The sending unit sends a CSI report on a physical uplink control channel (PUSCH) scheduled by the uplink scheduling grant information according to the CSI reporting configuration information, where the CSI report includes the event-driven beam management information.
3. The device according to claim 2, wherein The SR resource configuration information is included in the information element PUCCH-Config.
4. The device according to claim 3, wherein The SR resource configuration information is a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management. The list element in the SR resource configuration information is SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
5. The device according to claim 4, wherein The SchedulingRequestResourceConfigExt-EventBM includes a switch field for indicating whether to use event-driven beam management and / or a field indicating priority.
6. The device according to claim 2, wherein The uplink scheduling grant information is in the form of downlink control information (DCI) format 0_1 or DCI format 0_2 or DCI Carried in format 0_3.
7. The device according to claim 2, wherein The uplink scheduling grant information includes a CSI request field, and the CSI request field is used to trigger aperiodic CSI reporting.
8. The device according to claim 2, wherein The PUSCH scheduled by the uplink scheduling grant information carries the CSI report, or carries the CSI report and an uplink shared channel (UL-SCH).
9. The device according to claim 1, wherein The reporting type of the CSI reporting configuration information is periodic or semi-continuous.
10. The device according to claim 9, wherein The CSI reporting configuration information includes a first field, where the first field is used to indicate that the CSI reporting configuration information is used for event-driven beam management.
11. The device according to claim 10, wherein The CSI reporting configuration information is a CSI-ReportConfig information element, the first field is eventBeamManagementFlag, and the first field is a switch field.
12. The device according to claim 9, wherein The CSI reporting configuration information includes a second field, the value of the second field includes a first reporting option, and the first reporting option is used for event-driven beam management.
13. The device according to claim 12, wherein The CSI reporting configuration is the information element CSI-ReportConfig, the second field is reportQuantity, the first reporting option is the field EventBMInfo, the field EventBMInfo is in a list form, and the list content is zero to multiple candidate beam information.
14. The device according to claim 9, wherein The sending unit sends event-driven beam management information, including: The sending unit sends event-driven beam management information according to the CSI reporting configuration information when the CSI reporting configuration information is effective or activated.
15. The device according to claim 1, wherein When the terminal device detects a beam management event, the sending unit sends a scheduling request (SR) message to the network device on a dedicated SR resource whose SR resource configuration information is an event-driven beam management configuration; The receiving unit receives uplink scheduling grant information sent by the network device; The sending unit sends the event-driven beam management information on the PUSCH scheduled by the uplink scheduling grant information.
16. The device according to claim 15, wherein The SR resource configuration information is included in the information element PUCCH-Config.
17. The device according to claim 16, wherein The SR resource configuration information is a list schedulingRequestResourceToAddModListExt-EventBM, which is used to add or adjust SR resources related to event-driven beam management. The list element in the SR resource configuration information is SchedulingRequestResourceConfigExt-EventBM, which is used to configure SR resources related to event-driven beam management.
18. The device according to claim 17, wherein The SchedulingRequestResourceConfigExt-EventBM includes a switch field for indicating whether to use event-driven beam management and / or a field indicating priority.
19. The device according to claim 15, wherein The PUSCH scheduled by the uplink scheduling authorization information carries an uplink shared channel (UL-SCH), the UL-SCH includes the event-driven beam management information, and the value of the UL-SCH indicator field in the uplink scheduling authorization information is 1.
20. The apparatus according to claim 15, wherein The uplink scheduling grant information is carried by DCI format 0_1, DCI format 0_2, or DCI format 0_3.
Citation Information
Patent Citations
Method and user equipment for executing beam recovery, and method and base station for supporting same
CN110447295A
Method by which terminal reports state information in wireless communication system, and terminal and base station for supporting same
US20220131583A1
Information reporting method and apparatus, beam switching method and apparatus, and storage medium
WO2023050049A1
Beam measurement result reporting method and apparatus
WO2024000606A1