Transmission method and apparatus for device-triggered information, and device

Abstract

The present application relates to the technical field of communications, and discloses a transmission method and apparatus for device-triggered information, and a device. The transmission method for device-triggered information in an embodiment of the present application comprises: a device carrying at least one of device-triggered information and non-device-triggered information on a physical uplink shared channel (PUSCH) for transmission, wherein the device-triggered information is triggered on the basis of state information of the device and the non-device-triggered information is triggered on the basis of configuration or indication of the device by a node.

Description

A method, apparatus, and device for transmitting device trigger information.

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411974381.3, filed with the Chinese Patent Office on December 30, 2024, entitled "A Method, Apparatus and Device for Transmitting Device Trigger Information", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application belongs to the field of communication technology, and specifically relates to a method, apparatus and device for transmitting device trigger information. Background Technology

[0004] Current 5G mobile communication systems need to adapt to more diverse scenarios and service requirements, such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC). These scenarios place demands on the system to have high reliability, low latency, large bandwidth, and wide coverage.

[0005] User equipment (UE) may support different services, and the uplink control information (UCI) of the Physical Uplink Control Channel (PUCCH) for these different services will be multiplexed. For example, a UE may support both URLLC and high-capacity, high-speed eMBB services. During the transmission of an eMBB service, URLLC services may also need to be transmitted simultaneously. In this case, the control information related to the eMBB service and the URLLC service needs to be multiplexed together. Similarly, a UE may support URLLC, high-capacity, high-speed eMBB, and MMTC services. During the transmission of an eMBB service, URLLC and MMTC services may also need to be transmitted simultaneously. In this case, the control information related to the eMBB, URLLC, and MMTC services needs to be multiplexed together. However, the multiplexing of UCI from multiple PUCCHs complicates the multiplexing process. The more control information from different services that needs to be multiplexed, the more complex the multiplexing process becomes, potentially causing delays in the timely transmission of UE information. Furthermore, 6G mobile communication systems may have more types of services, and existing UCI multiplexing schemes are difficult to apply to service transmission in 6G mobile communication systems. Summary of the Invention

[0006] This application provides a method, apparatus, and device for transmitting device trigger information.

[0007] Firstly, a method for transmitting device trigger information is provided, executed by the device, the method comprising:

[0008] The device transmits at least one of device trigger information and non-device trigger information on the Physical Uplink Shared Channel (PUSCH).

[0009] The device triggering information is triggered based on the device's status information;

[0010] The non-device triggering information is triggered based on the node's configuration or instructions to the device.

[0011] Secondly, a method for transmitting device trigger information is provided, executed by a node, the method comprising:

[0012] The node configures transmission resources for the device, which are used to transmit information carried on the PUSCH.

[0013] The node receives the information carried on the PUSCH;

[0014] The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

[0015] Thirdly, a device for transmitting device trigger information is provided, the device comprising:

[0016] The first transmission module is used to carry at least one of device trigger information and non-device trigger information on the PUSCH for transmission;

[0017] The device triggering information is triggered based on the device's status information;

[0018] The non-device triggering information is triggered based on the node's configuration or instructions to the device.

[0019] Fourthly, a device for transmitting device trigger information is provided, the device comprising:

[0020] The first configuration module is used to configure transmission resources for the device, the transmission resources being used to transmit information carried on the PUSCH.

[0021] The first receiving module is used to receive the information carried on the PUSCH;

[0022] The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

[0023] Fifthly, an apparatus is provided, comprising a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method for transmitting device trigger information as described in the first aspect.

[0024] In a sixth aspect, a node is provided, the node including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the device trigger information transmission method as described in the second aspect.

[0025] In a seventh aspect, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the device trigger information transmission method as described in the first aspect, or implement the steps of the device trigger information transmission method as described in the second aspect.

[0026] Eighthly, a wireless communication system is provided, comprising: a device and a node, the device being configured to perform the steps of the device trigger information transmission method as described in the first aspect, and the node being configured to perform the steps of the device trigger information transmission method as described in the second aspect.

[0027] In a ninth aspect, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being configured to run a program or instructions to implement the steps of the device trigger information transmission method as described in the first aspect, or to implement the steps of the device trigger information transmission method as described in the second aspect.

[0028] In a tenth aspect, a computer program / program product is provided, the computer program / program product being stored in a storage medium, the computer program / program product being executed by at least one processor to implement the steps of the device trigger information transmission method as described in the first aspect, or to implement the steps of the device trigger information transmission method as described in the second aspect.

[0029] In this embodiment, the device transmits at least one of device triggering information and non-device triggering information on the PUSCH. The device triggering information is triggered based on the device's state information; the non-device triggering information is triggered based on the node's configuration or instruction to the device. This unifies information transmission between the device (e.g., UE) and the node (e.g., base station or network) within the PUSCH transmission framework, eliminating PUCCH transmission and avoiding the existing multiplexing process of reusing the UCI of PUCCHs from different services. Therefore, the device can promptly transmit all its relevant information (i.e., device triggering information and non-device triggering information) to the node via the PUSCH. Attached Figure Description

[0030] Figure 1 is a block diagram of a wireless communication system applicable to an embodiment of this application;

[0031] Figure 2 is a schematic diagram of UCI multiplexing on PUSCH;

[0032] Figure 3 is a flowchart of a device trigger information transmission method according to an embodiment of this application;

[0033] Figure 4 is a schematic diagram of a PUSCH and its accompanying reference signal in an embodiment of this application;

[0034] Figure 5 is a schematic diagram of a change in the direction of movement in an embodiment of this application;

[0035] Figure 6 illustrates a device trigger information reporting process in an embodiment of this application.

[0036] Figure 7 is a schematic diagram of a method of instructing the bearer device to trigger information via DL DCI in an embodiment of this application;

[0037] Figure 8 is a schematic diagram of the deletion of an uplink resource in an embodiment of this application;

[0038] Figure 9 is a schematic diagram of the configuration of a serving cell and frequency unit in an embodiment of this application;

[0039] Figure 10 is a schematic diagram of the structure of beam state information in an embodiment of this application;

[0040] Figure 11 is a schematic diagram of another beam state information structure in an embodiment of this application;

[0041] Figure 12 is a schematic diagram of the structure of buffer status information in an embodiment of this application;

[0042] Figure 13 is a schematic diagram of another buffer state information pair in an embodiment of this application;

[0043] Figure 14 is a structural schematic diagram of the suggested beam information or the restricted beam information of a device in an embodiment of this application;

[0044] Figure 15 is a channel structure for carrying PUSCH information in an embodiment of this application;

[0045] Figure 16 is a schematic diagram of channel multiplexing with overlapping time-domain resources in an embodiment of this application;

[0046] Figure 17 is a schematic diagram of the processing time of device trigger information in an embodiment of this application;

[0047] Figure 18 is a schematic diagram of a reuse timeline and processing time in an embodiment of this application;

[0048] Figure 19 is a flowchart of another method for transmitting device trigger information in an embodiment of this application;

[0049] Figure 20 is a schematic diagram of a device for transmitting device trigger information according to an embodiment of this application;

[0050] Figure 21 is a schematic diagram of another device trigger information transmission device in an embodiment of this application;

[0051] Figure 22 is a schematic diagram of the structure of a communication device according to an embodiment of this application;

[0052] Figure 23 is a schematic diagram of the structure of a device according to an embodiment of this application;

[0053] Figure 24 is a schematic diagram of the structure of a node in an embodiment of this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0055] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, the scope of protection for "A or B" covers at least three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. In addition, the terms "A and / or B," "at least one of A and B," and "at least one of A or B" also cover at least the above three scenarios. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0056] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as the sender explicitly informing the receiver of specific information, the required operation, or the requested result in the instruction sent. An indirect instruction can be understood as the receiver determining the corresponding information based on the instruction sent by the sender, or making a judgment and determining the required operation or requested result based on the judgment result.

[0057] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), or other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. The following description describes New Radio (NR) systems for illustrative purposes, and the term NR is used in most of the following description; however, these technologies can also be applied to systems other than NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0058] Figure 1 shows a block diagram of a wireless communication system applicable to an embodiment of this application. The wireless communication system includes a terminal 11 and a network-side device 12. The terminal 11 can also be referred to as User Equipment (UE), and can be a mobile phone, tablet computer, laptop computer, notebook computer, personal digital assistant (PDA), handheld computer, netbook, ultra-mobile personal computer (UMPC), mobile internet device (MID), augmented reality (AR), virtual reality (VR) device, robot, wearable device, flight vehicle, vehicle user equipment (VUE), shipboard equipment, pedestrian user equipment (PUE), smart home (home devices with wireless communication capabilities, such as refrigerators, televisions, washing machines, or furniture), game console, personal computer (PC), ATM, or self-service machine, etc. Wearable devices include: smartwatches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart chains, smart rings, smart necklaces, smart anklets, smart anklets, etc.), smart wristbands, smart clothing, etc. Among these, in-vehicle devices can also be referred to as in-vehicle terminals, in-vehicle controllers, in-vehicle modules, in-vehicle components, in-vehicle chips, or in-vehicle units, etc. It should be noted that the specific type of terminal 11 is not limited in this application embodiment. Network-side equipment 12 may include access network equipment or core network equipment, wherein access network equipment may also be referred to as Radio Access Network (RAN) equipment, radio access network function, or radio access network unit. Access network equipment may include base stations, Wireless Local Area Network (WLAN) access points (APs), or Wireless Fidelity (WiFi) nodes, etc.Among them, base stations can be referred to as Node B (NB), Evolved Node B (eNB), Next Generation Node B (gNB), New Radio Node B (NR Node B), Access Point, Relay Base Station (RBS), Serving Base Station (SBS), Base Transceiver Station (BTS), Radio Base Station, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Home Node B (HNB), Home Evolved Node B, Transmit / Receive Point (TRP), Non-Terrestrial Network (NTN) equipment (such as satellite or high altitude platform stations). The term "base station" can be any suitable term in the field, such as "station" or any other appropriate term in the relevant field, as long as the same technical effect is achieved. The term "base station" is not limited to specific technical terms. It should be noted that the embodiments of this application only use the base station in the NR system as an example for introduction, and do not limit the specific type of base station.

[0059] Core network equipment, also known as core network nodes, core network functions, or core network elements, includes, but is not limited to, at least one of the following: Mobility Management Entity (MME), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Policy Control Function (PCF), Policy and Charging Rules Function (PCRF), Edge Application Server Discovery Function (EASDF), Unified Data Management (UDM), Unified Data Repository (UDR), Home Subscriber Server (HSS), Centralized network configuration (CNC), Network Repository Function (NRF), Network Exposure Function (NEF), Local NEF (L-NEF), and Binding Support. Functions include BSF, Application Function (AF), Location Management Function (LMF), Gateway Mobile Location Centre (GMLC), Network Data Analytics Function (NWDAF), and Non-Terrestrial Network (NTN) equipment (such as satellite or high altitude platform station).It should be noted that the embodiments of this application only use the core network equipment in the NR system as an example for introduction, and do not limit the specific type of core network equipment. If the name of the core network equipment mentioned in the embodiments of this application changes in subsequent protocol versions (e.g., 6G), it is also within the scope of protection of this application.

[0060] Optionally, the core network equipment can be implemented by one or more functional modules in a single device, or by multiple devices working together; this application does not specifically limit this. It is understood that the aforementioned functional modules can be network elements in hardware devices, software functional modules running on dedicated hardware, or virtualized functional modules instantiated on a platform (e.g., a cloud platform).

[0061] To facilitate understanding of the technical solutions provided in this application, the main technical concepts involved in the embodiments of this application are briefly described below.

[0062] PUCCH resource determination method:

[0063] In Rel-15, the base station can configure one or more (up to four) PUCCH resource sets for each UE via Radio Resource Control (RRC) signaling. The RRC configuration or predefined maximum number of bits of UCI payload that each resource set (RESET) can carry (e.g., the first RESET has a maximum of 2 bits, the second and third RESETs are N1 and N2 respectively, and the fourth RESET has a maximum of 1706 bits, where N1 and N2 are RRC configurations). Each RESET can contain multiple PUCCH resources, with the first RESET containing a maximum of 32 PUCCH resources and each of the other RESETs containing a maximum of 8 PUCCH resources.

[0064] On the UE side, after receiving the Physical Downlink Shared Channel (PDSCH), the UE needs to send back Hybrid Automatic Repeat reQuest-ACK knowledge (HARQ-ACK). To determine the PUCCH resource where the HARQ-ACK is sent, the UE first needs to determine the slot of the PUCCH by using K1 in the PDCCH that schedules the PDSCH. Then, it needs to determine the RESET where the PUCCH is located by the number of bits of the HARQ-ACK that needs to be sent back. Within the determined RESET, it determines which PUCCH resource within the RESET is based on the PUCCH resource indicator (PRI) field of the PDCCH (when the RESET contains no more than 8 resources) or the index of the first control channel element (CCE index) of the PDCCH (when the RESET contains more than 8 resources). When multiple PDSCH HARQ-ACKs are fed back in one slot, the UE determines the PUCCH resource based on the PRI and the minimum CCE index in the last Downlink Control Information (DCI) that scheduled these PDSCHs.

[0065] UCI on PUSCH:

[0066] As shown in Figure 2, for UCI information multiplexed on the PUSCH, i.e., HARQ-ACK or Channel State Information (CSI) reports, the higher layers can dynamically or implicitly indicate an adjustment factor, beta_offset. This factor is used to adjust the number of Resource Elements (REs) occupied by UCI information on the PUSCH, thereby adjusting the code rate of UCI multiplexed on the PUSCH.

[0067] DCI format 0-1 and format 0-2 contain a priority indicator field, which indicates whether the scheduled PUSCH has a high or low priority.

[0068] A MAC PDU consists of one or more MAC sub-PDUs, each of which includes the following:

[0069] MAC header only (including padding);

[0070] One MAC header and one MAC SDU;

[0071] One MAC header and one MAC CE;

[0072] MAC header and padding.

[0073] In addition to the fixed-size MAC CE, padding, and MAC SDU containing UL CCCH, the MAC subheader consists of four header fields: R / F / LCID / L. The fixed-size MAC CE, padding, and MAC SDU containing UL CCCH consist of two header fields: R / LCID.

[0074] When multiple PUCCHs are multiplexed using UCI, the overlap of high-priority channels (HP channels) with low-priority channels (LP channels) will cause the LP channel to be canceled. Furthermore, any intermediate channels caused by multiplexing of high-priority channels will also cancel the LP channel transmission.

[0075] In summary, while the PUCCH indication in 5G mobile communication systems is flexible and can be updated using each DCI, if multiple PUCCH resources overlap, the UCIs of multiple PUCCHs will be reused together, leading to the following problems:

[0076] (1) Complex reuse process: UCI reuse of different UCI types and different priorities makes the UCI reuse process complex.

[0077] (2) Complex timeline design, including multiplexing timeline, cancellation timeline for high priority channel to cancel low priority channel, timeline for cancellation of low priority dynamic grant physical downlink control channel (High Priority Dynamic Grant PUSCH, HP DG PUSCH) to cancel low priority dynamic grant physical downlink control channel (Layer Priority Dynamic Grant PUSCH, HP DG PUSCH, LP CG PUSCH), SFI cancellation timeline, CI timeline.

[0078] (3) For high priority channels, low priority channels are cancelled. Every time a high priority downlink control information (HP DCI) arrives at the UE, a multiplexing process is performed and the transmission of low priority channels is cancelled. If the final HP UCI does not overlap with the low priority channel, the low priority channel will still be cancelled.

[0079] (4) For PUSCHs that overlap on multiple carriers, the PUSCH selection rules for UCI multiplexing are complex.

[0080] Therefore, the UCI multiplexing of multiple PUCCHs leads to a complex multiplexing process, resulting in delays in the timely transmission of UE information. Furthermore, 6G mobile communication systems may offer more diverse services, such as immersive human-computer interaction, comprehensive and diverse intelligent connectivity applications, high-fidelity extended reality applications, intelligent industry applications, and seamless global coverage. Consequently, existing UCI multiplexing schemes are difficult to apply to service transmission in 6G mobile communication systems.

[0081] This application proposes a unified uplink design framework that eliminates PUCCH transmission, with all uplink information transmitted via PUSCH. In 6G mobile communication systems, timely notification of terminal triggering information to the network is a technical problem that needs to be solved. Furthermore, for 6G mobile communication systems, there may be more UE-triggered information that needs to be reported to the network. This information is closely related to the UE's own state, and if the network wants to obtain this information, it often needs to allocate resources and instruct the UE to report it. These reports are sometimes not timely; therefore, ensuring the timeliness of reporting and controlling overhead is an urgent problem to be solved.

[0082] This application provides a method for transmitting device trigger information, eliminating PUCCH transmission and avoiding the existing multiplexing process of reusing the UCI of PUCCH from different services. This allows the device to transmit its relevant information to the node in a timely manner. The following detailed description, in conjunction with the accompanying drawings, provides a method for transmitting device trigger information based on several embodiments and application scenarios.

[0083] A first aspect of this application provides a method for transmitting device trigger information. This method is applied to a device. Referring to FIG3, FIG3 is a flowchart of a method for transmitting device trigger information according to an embodiment of this application. The method may include the following steps:

[0084] Step S310: The device transmits at least one of the device trigger information and non-device trigger information on the Physical Uplink Shared Channel (PUSCH).

[0085] The device triggering information is triggered based on the device's status information.

[0086] The non-device triggering information is triggered based on the node's configuration or instructions to the device.

[0087] In this embodiment of the application, the device can be a terminal, and the node can be a core network device or an access network device. Specifically, the device can be the terminal 11 in Figure 1, and the node can be the core network device or access network device 12 in Figure 1. Examples of the terminal 11 and the core network device or access network device 12 can be found above, and will not be repeated here.

[0088] Device triggering information is triggered based on the device's status information. For example, it is triggered when a change in the device's status information meets a triggering condition (threshold). In other words, device triggering information is not always required to be reported, and the number of device triggering information reports can vary at different times. That is, device triggering information is uplink information that a node cannot (in a timely or accurate manner) predict or deduce in advance and is not fully controllable.

[0089] Non-device-triggered information is triggered (or reported) based on the node's configuration or instruction to the device. In other words, non-device-triggered information is uplink reporting information that the node can obtain (in a timely or accurate manner) based on configuration information, DCI instructions, etc. The node can pre-configure / schedule / determine the corresponding reporting resources based on predefined rules and fully control the corresponding reporting operation (including the reporting timing, the amount of resources required, etc.).

[0090] The device transmits at least one of device trigger information and non-device trigger information on the PUSCH. In some embodiments, when the device needs to transmit both device trigger information and non-device trigger information, it can transmit both simultaneously on the PUSCH. In some embodiments, when the device needs to transmit device trigger information, it transmits the device trigger information on the PUSCH. In some embodiments, when the device needs to transmit non-device trigger information, it transmits the non-device trigger information on the PUSCH.

[0091] In this context, the PUSCH can be a transmission resource configured or indicated by a node for a device. When a device needs to transmit at least one of device trigger information and non-device trigger information, it can transmit the corresponding information on the PUSCH configured by the node. The transmission method on the PUSCH can be configured or indicated by the node (e.g., a base station or network) or predefined by the protocol. When a device needs to transmit at least one of device trigger information and non-device trigger information, it can transmit the corresponding information on the PUSCH in accordance with the node configuration, indication, or protocol predefined method.

[0092] By adopting the technical solution of this application embodiment, the information transmission between the device (e.g., UE) and the node (e.g., base station or network) is unified under the PUSCH transmission framework, eliminating PUCCH transmission and avoiding the multiplexing process of UCI multiplexing of PUCCH of different services. Therefore, the device can transmit all its relevant information (i.e., device trigger information and non-device trigger information) to the node in a timely manner through PUSCH.

[0093] The following sections describe the transmission method of device trigger information in the embodiments of this application, namely: Section 1.1 Types and configurations of device trigger information; Section 1.2 Transmission method of device trigger information; Section 1.3 Carrying device trigger information in MAC CE mode; Section 1.4 Carrying device trigger information in UCI mode; Section 1.5 Transmission method of non-device trigger information; and Section 1.6 Transmission of information with overlapping channel time domains.

[0094] 1.1 Types and configurations of device trigger information:

[0095] 1.1.1 Types of device trigger information:

[0096] In one specific implementation, the device trigger information includes at least one or more of the following types:

[0097] Item A-1: ​​Beam status information of the device, used to indicate the beam status of the device;

[0098] Item A-2: Buffer status information of the device, used to indicate the amount of data in the buffer of the device;

[0099] Item A-3: The suggested beam information of the device, used to indicate the suggested beam of the device;

[0100] Item A-4: Limited beam information of the device, used to indicate the limited beam of the device;

[0101] Item A-5: Recommended power information of the device, used to indicate the recommended transmission power of the device;

[0102] Item A-6: Speed ​​change information of the device, used to indicate the degree of change in the moving speed of the device;

[0103] Item A-7: Information on changes in the movement direction of the device, used to indicate the degree of change in the movement direction of the device;

[0104] Item A-8: Environmental change information of the device, used to indicate the current environment of the device.

[0105] In this embodiment of the application, the device triggering information is triggered based on the status information of the device. The type of device triggering information includes one or more types from items A-1 to A-8 above. The device can carry one or more types of device triggering information on the PUSCH for transmission.

[0106] Regarding item A-1, due to the mobility of equipment (e.g., UE) and changes in the environment, the quality of the beam currently used by the equipment may change. For example, the quality of the current beam may deteriorate, or a higher-quality beam may appear. This beam status information may not be obtained by nodes (e.g., base stations) in a timely manner, which will affect the communication performance of the equipment and the system. Therefore, the beam status information of the equipment can be carried on the PUSCH and transmitted to the nodes, enabling the nodes to obtain the beam status information of the equipment in a timely manner, so as to take appropriate scheduling strategies based on the beam status information of the equipment and improve communication performance.

[0107] In some embodiments, a node can be configured to trigger an event. When the beam status information of the device meets the trigger event, the device transmits the device's beam status information to the node on the PUSCH.

[0108] Regarding item A-2, the arrival of data from the device exhibits a certain degree of randomness. The device's buffer status information can indicate the amount of data in the buffer, and can be granularized according to different data sizes. By informing nodes of the device's buffer status information, the scheduling resources required by the device can be communicated, assisting nodes in making appropriate scheduling and improving communication performance.

[0109] In section A-3, due to the mobility of equipment (e.g., UE) and changes in the environment, the interference (CLI) experienced by the equipment may change, and the beam proposed by the equipment may also change. The equipment can report a proposed beam to the node through its proposed beam information. The beam proposed by the equipment to the node can be a single beam or a beamset consisting of multiple beams. The beam proposed by the equipment to the node can be based on measurement results on CLI measurement resources between devices, which can use different receive beams. Thus, by transmitting the equipment's proposed beam information to the node on the PUSCH, the node can obtain the equipment's proposed beam information in a timely manner and adopt appropriate scheduling strategies based on the equipment's proposed beam information to improve communication performance.

[0110] Item A-4 states that due to changes in device (e.g., UE) mobility and environment, the interference (CLI) experienced by the device may change, and therefore, the recommended beam for the device may change. A restricted (i.e., not recommended) beam can be reported to the node via the device's restricted beam information. The device's restricted beam can be a single beam or a set of multiple beams. Furthermore, the device's restricted beam can be based on measurement results from CLI measurement resources between devices, which can utilize different receiving beams.

[0111] It is understandable that when a device needs to report the suggested beam and restricted beam to a node, it should simultaneously transmit the two types of device trigger information mentioned in items A-3 and A-4 above on the PUSCH. This allows the device to report the suggested beam and restricted beam through its suggested beam information and restricted beam information, thereby facilitating node scheduling and improving communication performance.

[0112] Regarding item A-5, due to device (e.g., UE) mobility and environmental changes, the CLI (Current Link Interference) experienced by the device may change, and the device's recommended receive power may also change. A suggested downlink transmit power (i.e., DL transmit power boost) can be reported to the node via the device's suggested power information to reduce CLI interference from nearby devices. This allows the node to adopt appropriate scheduling strategies based on the device's suggested power information to improve communication performance.

[0113] Regarding item A-6, the mobility of a device (e.g., a UE) may change rapidly. When the device's speed change exceeds a threshold, the device can report the speed change information to the node to indicate the extent of the speed change. If physical layer signaling is used (i.e., the device's speed change information is transmitted over PUSCH), the device's speed change information can be reported to the node more quickly, thereby helping the node to adopt appropriate scheduling strategies and improve communication performance.

[0114] In some embodiments, the measurement of the speed change of the device can be determined based on the device's own sensing process.

[0115] In some embodiments, the device transmits its speed change information on the PUSCH to the node, and the node can configure appropriate measurement resources between the devices based on the speed change information.

[0116] Regarding item A-7, the movement direction of a device (e.g., a UE) may change rapidly. When the device senses a change in movement direction exceeding a threshold, the device can report this change to the node to indicate the extent of the change. Using physical layer signaling (i.e., transmitting the device's movement direction change information over a PUSCH) allows for faster reporting of this information to the node, enabling the node to adopt appropriate scheduling strategies and improve communication performance.

[0117] Regarding item A-8, if the environmental information perceived by the device (e.g., UE) changes rapidly, the device can report the environmental change information to the node so that the node can take appropriate scheduling strategies to improve system performance. In some embodiments, the measurement of environmental change information can be determined based on the device's own sensing process.

[0118] By adopting the technical solution of this application embodiment, the device can transmit various types of device trigger information on the PUSCH. The PUSCH belongs to physical layer signaling. Using physical layer signaling, various types of device trigger information can be quickly reported to the node, thereby helping the node to take appropriate scheduling strategies based on the received device trigger information and improve communication performance.

[0119] 1.1.2 Configuration of device trigger information:

[0120] In one specific implementation, a type of device trigger information corresponds to a first index number, or a combination of types corresponds to a first index number; the first correspondence between each first index number and a type of device trigger information or a combination of types is indicated by the node to the device, configured by the node for the device, or predefined by the protocol; the combination of types includes multiple types of device trigger information.

[0121] In some embodiments, a table can be used to configure (indicator or protocol predefined) the first index number corresponding to a type of device trigger information, or the first index number corresponding to a combination of types. As shown in Table 1, each type of device trigger information can correspond to a first index number; for example, first index number 0 corresponds to type 1, and first index number 1 corresponds to type 2. A combination of types (multiple types of device trigger information) corresponds to a first index number; for example, first index number 2 corresponds to type combination {1,2}, and first index number 3 corresponds to type combination {1,2,3,4}.

[0122] Table 1. Example of the relationship between device trigger information type and first index number:

[0123] In this way, by using the first index number corresponding to a type of device trigger information or the first index number corresponding to a combination of types (multiple types of device trigger information), when a device reports the type of device trigger information, it can directly report the first index number corresponding to the type of device trigger information, without having to report the specific type of device trigger information, thus saving transmission resource overhead.

[0124] In one specific implementation, the method further includes:

[0125] Step B1: The device transmits the device trigger information by carrying the type of the device trigger information on the PUSCH;

[0126] Step B2: The device transmits the device trigger information by carrying the type of the device trigger information on the accompanying reference signal of the PUSCH, and the different sequences of the accompanying reference signal represent different types of device trigger information.

[0127] In this embodiment of the application, when the device reports the type of device trigger information, the type of device trigger information is transmitted through the manner described in step B1 or step B2 above. The PUSCH carrying the type of device trigger information can be the same as the PUSCH carrying the device trigger information, or it can be a different PUSCH from the device trigger information.

[0128] The accompanying reference signal of a PUSCH can be a Sounding Reference Signal (SRS) or Additional Reference Signal (RS). The location of the accompanying reference signal can be configured or indicated by the node, or it can be predefined by the protocol. Different sequences of the accompanying reference signal represent different types of device triggering information. When transmitting device triggering information carried on the accompanying reference signal of the PUSCH, the type of device triggering information is carried in the corresponding sequence.

[0129] In some embodiments, the accompanying reference signal can also assist the node in measuring the uplink channel and in controlling uplink power. In some embodiments, the device can use the accompanying reference signal to characterize the triggering of a specific event, and the correspondence between the reference signal sequence and the triggering event can be configured or indicated by the node.

[0130] As shown in Figure 4, the relationship between PUSCH and accompanying reference signal is illustrated. When the device needs to report device trigger information and the type of device trigger information, the device can transmit both device trigger information and the type of device trigger information simultaneously on PUSCH; or it can transmit device trigger information on PUSCH and the type of device trigger information on the accompanying reference signal of PUSCH.

[0131] It is understandable that the device may transmit the device trigger information type by carrying the index number corresponding to the device trigger information type on the PUSCH; similarly, the device may transmit the device trigger information type by carrying the accompanying reference signal on the PUSCH by carrying the accompanying reference signal on the PUSCH.

[0132] In this way, the device can flexibly transmit the type of device trigger information in a variety of ways.

[0133] 1.1.3 Specific configuration parameters for device triggering information:

[0134] Nodes can configure or indicate parameters to devices, enabling devices to report information based on these parameters. The parameters for device-triggered information differ from those for non-device-triggered information. For device-triggered information, the device configures a first set of parameters, including a first parameter, a second parameter, a third parameter, a fourth parameter, a fifth parameter, and a sixth parameter. For non-device-triggered information, the device configures a second set of parameters.

[0135] (1) The parameter corresponding to the beam status information of the device configured or indicated by the node to the device is a first parameter, and the first parameter includes at least one of the following:

[0136] E-1 item: Triggering event;

[0137] E-2: Beam count configuration;

[0138] The triggering event includes at least one of the following:

[0139] C-1: The quality of the current beam is below the threshold;

[0140] Item C-2: At least one new beam has a higher quality than the current beam;

[0141] C-3: At least one new beam has a quality higher than that of the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node;

[0142] The number of beams configuration includes at least one of the following:

[0143] D-1: First beam quantity configuration, indicating that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax;

[0144] Item D-2: Second beam quantity configuration, indicating that the device reports the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and the redundant bits corresponding to Nmax-N beams that do not satisfy the trigger event; wherein, the redundant bits occupied by the Nmax-N beams that do not satisfy the trigger event refer to: for the status information of Nmax beams reported by the device, in addition to the status information of the N beams that satisfy the trigger event, the remaining Nmax-N beams that do not satisfy the trigger event are reported as redundant bits.

[0145] D-3: Third beam quantity configuration, indicating that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax;

[0146] Item D-4: Fourth beam quantity configuration, indicating that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node;

[0147] D-5: Fifth beam quantity configuration, indicating that the device reports the status information of one beam that satisfies the triggering event;

[0148] Nmax is configured by the node.

[0149] In this embodiment, the device can determine whether it needs to report its beam status information based on the trigger event in item E-1. When the device's beam status meets the trigger event, the device's beam status information can be carried on the PUSCH for transmission to inform the node of the device's beam status. The device can determine the number of beams to report based on the beam number configuration in item E-2. When the device reports beam status information, it can report the status of the corresponding number of beams according to the beam number configuration.

[0150] Due to device mobility and environmental changes, the quality of the beam currently used by the device may change. For example, the current beam quality may deteriorate, or a higher quality beam may appear. This beam status information may not be obtained by nodes (e.g., base stations) in a timely manner, which will affect the device's communication performance. Therefore, in order to trigger the device to report its beam status information, the node configures at least one of the trigger events from items C-1 to C-3 for the device.

[0151] Specifically, for item C-1, if the quality of the current beam is below a threshold, it indicates that the quality of the current beam has deteriorated, and a poor-quality beam may affect the communication performance of the device. Treating the current beam quality falling below the threshold as a trigger event, and reporting the device's beam status information when the beam state meets this trigger event, helps nodes obtain the device's beam status information in a timely manner, thereby enabling them to adopt appropriate scheduling strategies and ensure the device's communication performance.

[0152] Regarding item C-2, if a new beam with higher quality than the current beam appears, the better-quality new beam can be used for communication to ensure the device's communication performance. Treating at least one new beam with higher quality than the current beam as a trigger event, and reporting the device's beam status information when the beam's state satisfies this trigger event, helps nodes obtain the device's beam status information in a timely manner, thereby enabling them to adopt appropriate scheduling strategies and ensure the device's communication performance.

[0153] Regarding item C-3, when the quality of a new beam is higher than the quality of the beam in the reference signal RS associated with the Qth active TCI state, it indicates the emergence of a new beam of higher quality. To ensure the communication performance of the device, the higher-quality beam can be used for communication. Here, Q represents the Radio Resource Control (RRC) configuration that meets the device's capabilities. Treating at least one new beam having a quality higher than the quality of the beam in the reference signal RS associated with the Qth active TCI state as a trigger event, and reporting the device's beam status information when the beam status satisfies this trigger event, helps nodes obtain the device's beam status information in a timely manner, thereby adopting appropriate scheduling strategies to ensure the device's communication performance.

[0154] It should be noted that the beam quality in items C-1 to C-3 can be measured by various indicators, and the embodiments of this application do not limit the method of measuring beam quality. For example, the beam quality can be evaluated by the Layer 1 Reference Signal Receiving Power (L1-RSRP); for example, the beam quality can be evaluated by the Reference Signal Receiving Quality (RSRQ).

[0155] Specifically, the beam count configuration configured for the device by the node includes at least one beam count configuration from item D-1 to item D-5. For item D-1, all beams reported by the device satisfy the trigger event, and the number of bits occupied by the status information of M beams reported varies according to the value of M, but the value of M does not exceed the maximum reporting number Nmax.

[0156] For item D-2, all beams reported by the device meet the trigger event, but the number of bits occupied by the status information of the beams reported by the device is fixed. The device reports the status information of Nmax beams. If the number N of beams that meet the trigger event is less than Nmax, redundant bits will be used (i.e., filled with 0 or 1) until the status information of the fed-back beams reaches the size of Nmax beams.

[0157] For item D-3, the device reports the status information of O beams. The number of bits used to report the status information of O beams varies depending on the value of O, but the value of O does not exceed the maximum number of reports Nmax. Furthermore, at least one beam in the status information of O beams needs to satisfy a trigger event, which may include beams that do not satisfy the trigger event.

[0158] For item D-4, the device reports the status information of P beams, where the number P is configured by the node. The number of bits used to report the status information of P beams is fixed. At least one of the P beams satisfies the trigger event, which may include beams that do not satisfy the trigger event.

[0159] For item D-5, only one beam that meets the trigger event is reported. Even if multiple beams meet the trigger event, only one of them is reported.

[0160] In this way, the node configures or indicates parameters such as trigger events and / or beam count configuration for the device, so that the device can report the beam status information of the device according to the beam count configuration when the beam status meets the trigger event. This helps the node to obtain the beam status information of the device in a timely manner, and then take appropriate scheduling strategies to ensure the communication performance of the device.

[0161] (2) The parameter corresponding to the buffer status information of the device configured or indicated by the node to the device is the second parameter. The second parameter includes: multiple data volume thresholds and the second index number corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number.

[0162] In this embodiment, the device indicates the buffer status information to the node, indicating that the device has different amounts of data to send, so that the node can adopt an appropriate scheduling strategy and allocate appropriate time-frequency resources. To facilitate the reporting of buffer status information, the node can configure or indicate multiple data volume thresholds and corresponding second index numbers for the device, and then the device can report the buffer status information of the device through the second index number.

[0163] The data volume threshold can also be a device-specific configuration. Considering that devices in 6G mobile communication systems may support a larger volume of traffic, and the traffic volume of different devices may vary greatly, device-specific configuration allows devices to report data volume information to nodes in a more precise manner, so that nodes can allocate resources appropriately.

[0164] In some specific embodiments, a node can indicate or configure multiple data size thresholds and corresponding second index numbers through a table, as shown in Table 2. A node configures or indicates a second index number for a data size threshold, where A, B, C, ..., K can be configured or indicated by the node or configured by device-specific signaling.

[0165] Optionally, nodes can configure the K value and the signaling size for different devices. The corresponding data volume threshold for each second index number can be allocated sequentially at equal intervals. For example, if the data volume threshold K = 16, the signaling size is 6 second index numbers, and each index number corresponds to an interval of size 4, the data volume thresholds fall in the following intervals: equal to 0, (0, 4], (4, 8], (8, 12], (12, 16], >16.

[0166] Table 2 Example of the relationship between data volume threshold and second index number:

[0167] (3) The parameter corresponding to the suggested power information of the device configured or indicated by the node to the device is a third parameter, which includes: multiple power thresholds and a third index number corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number.

[0168] In this embodiment, the power threshold represents the downlink transmission power suggested by the device to the node. The node configures or indicates multiple power thresholds and corresponding third index numbers for the device. When the device indicates the suggested power information of the device to the node, it can report the buffer status information of the device through the third index number.

[0169] In some specific embodiments, a node can use a table to indicate or configure multiple power thresholds and corresponding third index numbers, as shown in Table 3. Taking a 2dB size as an example, a node configures a third index number for a power threshold step.

[0170] Table 3 Example of the relationship between power threshold and third index number:

[0171] (4) The parameter corresponding to the speed change information of the device configured or indicated by the node to the device is the fourth parameter. The fourth parameter includes: multiple speed thresholds and the fourth index number corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number.

[0172] In this embodiment, the speed threshold characterizes the degree of change in movement speed (speed change indication), and the speed threshold can be expressed as an absolute value or a relative value. Nodes configure or indicate multiple speed thresholds and corresponding fourth index numbers for the device. When the device indicates its speed change information to the node, it can report the device's speed change information through the fourth index number.

[0173] In some specific embodiments, a node can indicate or configure multiple speed thresholds and corresponding fourth index numbers through a table, as shown in Table 4, where a node indicates or configures a fourth index number for a speed threshold.

[0174] Table 4 Example of the relationship between velocity change values ​​and the fourth index number:

[0175] (5) The parameter corresponding to the movement direction change information of the device configured or indicated by the node to the device is the fifth parameter. The fifth parameter includes: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number.

[0176] In this embodiment, the movement direction change threshold characterizes the degree of change in the movement direction of the device, as shown in Figure 5. The movement direction change threshold refers to the offset angle θ in one direction. Nodes configure or indicate multiple movement direction change thresholds and corresponding fifth index numbers for the device. When the device indicates its movement direction change information to the node, it can report the device's movement direction change information through the fifth index number.

[0177] In some specific embodiments, a node can indicate or configure multiple movement direction change thresholds and corresponding fifth index numbers through a table, as shown in Table 5. Taking 30° as an example, a node indicates or configures a fifth index number for a movement direction change threshold.

[0178] Table 5 Example of the relationship between the threshold for change in direction of movement and the fifth index number:

[0179] (6) The parameter corresponding to the environmental change information of the device configured or indicated by the node to the device is the sixth parameter. The sixth parameter includes: multiple environmental information and the sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

[0180] In this embodiment, the environmental information represents the current environment of the device (or the situation of environmental information changes). The node is configured or indicates multiple environmental information and corresponding sixth index number for the device. When the device indicates the environmental change information of the device to the node, it can report the environmental change information of the device through the sixth index number.

[0181] In some specific embodiments, a node can indicate or configure multiple environmental information and corresponding sixth index numbers through a table, as shown in Table 6, where a node indicates or configures a sixth index number for one environmental information.

[0182] Table 6 Example of the relationship between environmental information and the sixth index number:

[0183] 1.1.4 Method for sending device trigger information:

[0184] In one specific implementation, the device transmits the device trigger information carried on the PUSCH, including:

[0185] When the device trigger information meets the triggering conditions, the device will transmit the device trigger information that meets the triggering conditions by carrying it on the PUSCH.

[0186] In this embodiment, device trigger information is reported only when certain triggering conditions are met; that is, device trigger information that meets the triggering conditions is carried on the PUSCH for transmission. If the device trigger information does not meet the triggering conditions, the device does not report the information, thereby saving transmission resources.

[0187] Different types of devices require different triggering conditions. Specifically:

[0188] 1) When the device trigger information is the device's beam status information, the trigger condition can refer to the trigger event configured in Section 1.1.3 above (e.g., the quality of the current beam is lower than the threshold, the quality of at least one new beam is higher than the quality of the current beam, or the quality of at least one new beam is higher than the quality of the beam in the reference signal RS associated with the Qth active TCI state). When the device's beam status satisfies a trigger event, the device's beam status information is carried on the PUSCH for transmission.

[0189] 2) When the device trigger information is the device's buffer status information, the trigger condition can be that the amount of data in the current buffer meets the data reporting threshold. When the amount of data in the device's buffer exceeds the data reporting threshold, the device's buffer status information is carried on the PUSCH for transmission.

[0190] 3) When the device trigger information is the device's suggested beam information, the trigger condition can be that the quality of the beam is higher than the beam quality threshold. In this case, the beam with quality higher than the threshold can be reported as the device's suggested beam.

[0191] 4) When the device trigger information is the device's restricted beam information, the trigger condition can be that the quality of the beam is lower than the beam quality threshold. In this case, the beam with quality lower than the beam quality threshold can be reported as the device's restricted beam.

[0192] 5) When the device trigger information is the device's suggested power information, the trigger condition can be a change in the interference received by the device. When the interference received by the device changes, the device's suggested power information is carried on the PUSCH for transmission.

[0193] 6) When the device trigger information is the device speed change information, the trigger condition can be that the current speed change is higher than the speed reporting threshold. When the device speed change value is higher than the speed reporting threshold, the device speed change information is carried on the PUSCH for transmission.

[0194] 7) When the device trigger information is the device's movement direction change information, the trigger condition can be that the current movement direction change value is higher than the movement direction reporting threshold. When the device's movement direction change value is higher than the movement direction reporting threshold, the device's movement direction change information is carried on the PUSCH for transmission.

[0195] 8) When the device trigger information is the device's environmental change information, the trigger condition can be that the current environment of the device changes. When the environment of the device changes, the environmental change information of the device is carried on the PUSCH for transmission.

[0196] In some embodiments, the PUSCH used to carry device trigger information is configured by the node. The device transmits the device trigger information by carrying it on the PUSCH. The way the device trigger information is carried on the PUSCH can be configured, indicated, or predefined by the node. For example, as shown in Figure 6, the reporting process of device trigger information is as follows: the node configures a PUSCH for the device to carry device trigger information. When the device trigger information meets the trigger (reporting) conditions, the device uses the PUSCH configured by the node to carry the device trigger information for reporting.

[0197] 1.2 Method for transmitting device trigger information:

[0198] In one specific implementation, the device trigger information is carried on the PUSCH in any of the following ways:

[0199] Item F-1: Media Access Control (MAC) control element in CE mode;

[0200] F-2: Uplink Control Information (UCI) mode;

[0201] F-3: A combination of UCI and MAC CE.

[0202] In this embodiment of the application, the device can transmit device trigger information on the PUSCH based on the MAC CE (Media Access Control Control Element) method. The advantage of this method is that all device trigger information adopts the same encoding method as data, that is, encoding can be completed using a single encoding chain, which reduces the requirements for the number of device encoding chains (capability requirements).

[0203] The device can transmit device trigger information on the PUSCH using UCI. This method offers greater flexibility and speeds up information decoding at the node level. Since control information payloads are typically small, they can be decoded quickly. Transmitting device trigger information on the PUSCH via UCI facilitates rapid acquisition of UCI information. For example, the device trigger information can be placed at the beginning of the PUSCH.

[0204] The device can transmit device trigger information on the PUSCH using a hybrid approach of UCI and MAC CE. In some embodiments, for various types of device trigger information reported by the device, some types can be transmitted on the PUSCH using UCI, while others can be transmitted using MAC CE. For example, for device beam status information and device buffer status information, UCI can be used to transmit the beam status information on the PUSCH, while MAC CE can be used to transmit the buffer status information. In this way, the device can fully utilize the advantages of both MAC CE and UCI methods for transmitting device trigger information.

[0205] By adopting the technical solution of this application embodiment, the device can flexibly use different bearer methods according to actual needs to transmit device trigger information on the PUSCH, which improves the flexibility of the device reporting device trigger information, helps the node to receive device trigger information in a timely manner, and adopts appropriate scheduling strategies based on the received device trigger information to improve communication performance.

[0206] In one specific implementation, the device further performs the following steps:

[0207] Step G1: The device acquires PUSCH format configuration information;

[0208] Step G2: The device carries the device trigger information on the PUSCH according to the PUSCH format configuration information;

[0209] The PUSCH format configuration information includes any of the following:

[0210] The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH.

[0211] The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner and the PUSCH carries the uplink shared channel UL-SCH.

[0212] The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode and the PUSCH does not carry UCI.

[0213] Furthermore, the above three formats can be defined to support carrying non-triggering information of the device, that is, the device can carry the device triggering information on the PUSCH according to the above three formats.

[0214] Alternatively, a format that does not carry non-trigger information from the device can also be defined, for example:

[0215] The fourth format is used to instruct the device to carry device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH (i.e., does not use MAC CE) and does not carry device non-trigger information.

[0216] The fifth format is used to instruct the device to carry device trigger information on the PUSCH in a UCI manner, and the PUSCH carries the uplink shared channel UL-SCH, but does not carry device non-trigger information;

[0217] The sixth format is used to instruct the device to carry device trigger information on the PUSCH in MAC CE mode, and the PUSCH does not carry UCI, nor does it carry device non-trigger information.

[0218] In this embodiment of the application, device trigger information can be carried on the PUSCH in different ways. The way in which device trigger information is carried on the PUSCH can be configured by the node. After the device obtains the PUSCH format configuration information, it can carry the device trigger information on the PUSCH according to the PUSCH format configuration information and transmit it according to the configuration information.

[0219] In this context, the PUSCH does not carry the uplink shared channel UL-SCH, indicating that the device cannot carry device trigger information on the PUSCH in the MAC CE manner. Therefore, for the first format, the device can only carry device trigger information on the PUSCH in the UCI manner; for the second format, the device can carry device trigger information on the PUSCH in either the UCI or MAC CE manner; and for the third format, the device can only carry device trigger information on the PUSCH in the MAC CE manner.

[0220] Correspondingly, the node executes the following steps: The node sends PUSCH format configuration information to the device. The PUSCH format configuration information includes any one of the three formats mentioned above, in order to configure the device with PUSCH format configuration information for carrying device trigger information, so that the device can carry device trigger information on the PUSCH according to the PUSCH format configuration information.

[0221] Furthermore, the PUSCH format configuration information is a CG PUSCH configuration, configuring at least one or more of the following parameters: frequency hopping carrier; DMRS configuration; MCS table; precoding MCS table (mcs-TableTransformPrecoder); PUSCH multiplexing (uci-OnPUSCH); resource allocation; resource block size (rbg-Size); power control loop (powerControlLoopToUse); open-loop power control parameters (p0-PUSCH-Alpha); transmission precoding (transformPrecoder); number of HARQ processes (nrofHARQ-Processes); number of repetitions (repK); redundancy version during repetition (repK-RV); periodicity; time domain offset; time domain allocation; frequency domain allocation; antenna port; demodulation reference signal. Signal (DMRS) sequence initialization (dmrs-SeqInitialization); precoding and number of layers (precodingAndNumberOfLayers); Sounding Reference Signal (SRS) resource indicator (srs-ResourceIndicator); modulation and coding scheme and transport block size (mcsAndTBS); frequency hopping offset (frequencyHoppingOffset); pathlossReferenceIndex (pathlossReferenceIndex); physical layer priority index (phy-PriorityIndex).

[0222] Thus, configuring different PUSCH formats facilitates blind detection of CG PUSCH by the base station, thereby reducing the complexity of the base station.

[0223] In one specific implementation, the device further performs the following steps:

[0224] Step H1: The device obtains bearer configuration information, which indicates whether the bearer configuration information of each type of device triggering information on the PUSCH is UCI, MAC CE, or a combination of UCI and MAC CE.

[0225] Step H2: The device is configured with information according to the bearer mode, and the device trigger information is transmitted on the PUSCH.

[0226] In this embodiment of the application, different types of device trigger information can be carried on the PUSCH using different carrying methods. The carrying method of each type of device trigger information on the PUSCH can be configured by the node.

[0227] Correspondingly, the node executes the following steps: the node sends bearer configuration information to the device, so that the device can transmit device trigger information on the PUSCH based on the bearer configuration information sent by the node.

[0228] In this way, each type of device trigger information can be transmitted based on its own bearer method, improving the flexibility of device trigger information reporting.

[0229] In one specific implementation, the device further performs the following steps:

[0230] Step J1: The device receives a UL scheduling DCI, in which the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a hybrid of UCI and MAC CE.

[0231] Step J2: The device transmits the device trigger information on the PUSCH according to the UL scheduling DCI;

[0232] The UL scheduling DCI carries at least one of the following fields:

[0233] The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback.

[0234] The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

[0235] In this embodiment of the application, for different types of device trigger information, the device trigger information can be carried on the PUSCH in different ways. The way in which each type of device trigger information is carried on the PUSCH can be indicated by the node. The node can indicate the way in which at least one type of device trigger information is carried through the UL scheduling DCI.

[0236] The UL scheduling DCI can carry a device trigger information feedback field. This field can use a bitmap to indicate the type of device trigger information the node is requesting the device to provide. The UL scheduling DCI can also carry a feedback mode indication field, which is optional. If the node is configured via RRC parameters, this field can be ignored.

[0237] Correspondingly, the node executes the following steps: the node sends a UL scheduling DCI to indicate at least one type of device triggering information to the device, and indicates the bearing method of at least one type of device triggering information in the UL scheduling DCI.

[0238] In this way, the device can transmit the device trigger information requested by the node on the PUSCH according to the indicated bearer method, thereby helping the node to obtain the required device trigger information and take appropriate scheduling strategies based on the received device trigger information, thus improving system performance.

[0239] In some embodiments, a node can use DL DCI to indicate CG PUSCH or DG PUSCH, as shown in Figure 7. For DL ​​DCI, if a PDSCH is scheduled based on DL DCI and a HARQ-CK carried on the (CG or DG) PUSCH is fed back, then the device can use that PUSCH to carry device trigger information. For example, DL DCI can schedule a PDSCH while simultaneously triggering a CG PUSCH (the CG PUSCH was not previously activated; this is just a one-shot CG PUSCH trigger). Furthermore, device trigger information and non-device trigger information can be fed back together. Additionally, DL DCI can indicate whether to carry device trigger information.

[0240] Specifically, for a DL scheduling DCI to schedule a CG PUSCH, the DCI must carry at least one of the following:

[0241] K-1 item: Transmission parameters of the uplink shared channel.

[0242] K-2: Feedback mode indication field, used to indicate whether the trigger information of each type of device is carried on the PUSCH in UCI mode, MAC CE mode, or a mixture of UCI and MAC CE mode; the feedback mode indication field is optional configuration, and can be ignored if the node is configured through RRC parameters.

[0243] K-3 item: K_H, used to indicate the time slot interval from PDSCH to CG PUSCH.

[0244] K-4 items: CG PUSCH indexes, including different CG PUSCH indexes; wherein each CG PUSCH index may be associated with at least one of the following: PUSCH format configuration information (CG PUSCH format), such as first format, second format or third format, etc.; number of start symbols; number of continuous symbols.

[0245] K-5: Transmit Power Control (TPC), used to indicate power control information on the CG PUSCH.

[0246] K-6 item: Waveform indicator, used for CG PUSCH waveform.

[0247] K-7 item: Frequency hopping indicator, used to indicate whether the CG PUSCH is hopping frequencies.

[0248] By adopting the technical solution of this application embodiment, the device can carry at least one of device trigger information and non-device trigger information to the scheduling CG PUSCH for transmission, which helps the node to receive device trigger information in a timely manner, so as to take appropriate scheduling strategies based on the received device trigger information and improve system performance.

[0249] In one specific implementation, the device further performs the following steps:

[0250] Step L1: The device determines the bit rate of the information to be carried on the PUSCH;

[0251] Step L2: If the bit rate exceeds the maximum bit rate configured or indicated by the node, the device reports the information that needs to be carried on the PUSCH in descending order of priority, or the device sends a resource request to the node.

[0252] In this embodiment, the node can configure or indicate the maximum bit rate and priority for the device. If the bit rate of the information the device needs to carry on the PUSCH exceeds the maximum bit rate, the device can report device trigger information in one of the two methods described in step L2 above. The information to be carried on the PUSCH is at least one of device trigger information and non-device trigger information.

[0253] Specifically, the device reporting information that needs to be carried on the PUSCH in descending priority order means that the device prioritizes carrying high-priority information on the PUSCH, and the remaining information not carried on the PUSCH will be discarded or reported on subsequent available resources or scheduled resources. For example, for UCI, when the number of UCIs that need to be carried exceeds the maximum bit rate, the device will only report high-priority UCIs based on priority order, and the remaining uncarried UCIs can be discarded or reported on subsequent CG PUSCHs.

[0254] The device sends a resource request to the node, so that the node, upon receiving the resource request, allocates transmission resources to the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

[0255] Correspondingly, the node executes the following steps: the node instructs or configures at least one of the following to the device: maximum bit rate; priority of different information carried on the PUSCH; the priority is used to: report the order of different information to be carried on the PUSCH when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate, or to trigger the device to send a resource request to the node when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate; upon receiving the resource request, the node allocates transmission resources to the device.

[0256] In this way, even when the bit rate exceeds the maximum bit rate configured or indicated by the node, the device can still report the device trigger information to the node in a timely manner, which helps the node to make more appropriate scheduling based on the received device trigger information and improve system performance.

[0257] In one specific implementation, if the transmission resources configured on the node are insufficient to transmit the information carried on the PUSCH, the method further includes:

[0258] The device sends a resource request to the node;

[0259] The device transmits resource requests on the PUSCH; or the device transmits resource requests on the accompanying reference signal of the PUSCH, with different sequences of the accompanying reference signal representing different amounts of transmission resources requested.

[0260] The resource request is used to request the node to allocate transmission resources for the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

[0261] In this embodiment, the information carried on the PUSCH is at least one of device trigger information and non-device trigger information. The device transmits resource request information carried on the PUSCH, which can be transmitted together with the device trigger information or separately.

[0262] The device transmits resource requests carried on the accompanying reference signal of the PUSCH. The accompanying reference signal can be a channel sounding reference signal or additional reference information, and its position can be configured or indicated by the node, or it can be predefined by the protocol. Different sequences of the accompanying reference signal represent requests for different amounts of transmission resources; when transmitting resource requests carried on the accompanying reference signal of the PUSCH, the resource requests are carried on the corresponding sequences. In some embodiments, different frequency domain positions of the accompanying reference signal represent requests for different amounts of transmission resources; when transmitting resource requests carried on the accompanying reference signal of the PUSCH, the resource requests are carried at the corresponding frequency domain positions. In some embodiments, different bandwidths of the accompanying reference signal represent requests for different amounts of transmission resources; when transmitting resource requests carried on the accompanying reference signal of the PUSCH, the resource requests are carried on the corresponding bandwidths.

[0263] Correspondingly, the node performs the following steps: the node receives a resource request carried on the PUSCH; the node allocates transmission resources to the device so that the device can transmit at least one of device trigger information and non-device trigger information on the PUSCH.

[0264] Thus, when the transmission resources configured on a node are insufficient to transmit information carried on the PUSCH, the node can be requested to allocate transmission resources for the device. Based on the allocated transmission resources, the device trigger information or non-device trigger information can be reported to the node in a timely manner. This helps the node to make more appropriate scheduling based on the received information and improve the communication performance of the system.

[0265] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner, the following steps are also included:

[0266] The device adds actual resource usage information to the first part of the UCI and sends it to the node. This actual resource usage information represents the transmission resources actually used to transmit information carried on the PUSCH. When the node's configured transmission resources have spare capacity beyond transmitting information carried on the PUSCH, the device's resource usage can be reduced, thereby reducing interference to other devices or nodes and saving energy.

[0267] In this embodiment, the device can indicate the actual resource usage information to the node through the first part of the UCI, so that the node can receive and parse the first part of the UCI to obtain the time domain / frequency domain resource information actually used by the device, and avoid decoding the uplink resources (uplink resources include time domain resources and frequency domain resources) that the device has not transmitted based on the actual resource usage information. By avoiding decoding the uplink resources that the device has not transmitted, unnecessary uplink transmissions of the device can be reduced, the energy consumption of the device and the node can be reduced, and interference within the system can be reduced.

[0268] The first part of the UCI includes an indicator field for improving resource utilization efficiency or reliability. For example, the indicator field can indicate the time-domain or frequency-domain resources of the actual transmitted PUSCH. If it indicates the actual transmitted time-domain resources, it can be indicated by a Start and Length Indicator Value (SLIV) and the number of symbols to be reduced (e.g., indicating a reduction of 1, 2, ..., n symbols). If it indicates the actual transmitted frequency-domain resources, it can be indicated by a SLIV and the number of RBs to be reduced (e.g., indicating a reduction of 1, 2, ..., n RBs).

[0269] Similarly, when the device carries device trigger information on the PUSCH in the UCI manner, the device executes the following steps: the device adds actual resource usage information to the first part of the UCI and sends it to the node. The actual resource usage information represents the transmission resources actually used by the information carried on the PUSCH, so that the node receives and parses the first part of the UCI to obtain the actual resource usage information of the device. Based on the actual resource usage information of the device, the node avoids decoding unused uplink resources, which can reduce unnecessary uplink transmissions, reduce device power consumption, and reduce interference within the system.

[0270] As shown in Figure 8, the uplink resources used to transmit information carried on the PUSCH can be flexibly adjusted. When the transmission resources configured on the node have a margin in addition to transmitting information carried on the PUSCH, the node can reduce some uplink resources according to the actual resource usage information of the device, that is, delete the time domain and frequency domain of the uplink resources. This can reduce unnecessary uplink transmissions of the device, reduce device energy consumption, and reduce interference within the system.

[0271] In one specific implementation, the device transmits the device trigger information carried on the PUSCH, including:

[0272] Step M: When the device is configured with multiple frequency units, the device transmits the device trigger information and the corresponding frequency unit number on the PUSCH.

[0273] Step N: When the device is configured with multiple carriers, the device transmits the device trigger information and the corresponding carrier number on the PUSCH.

[0274] Step O: When the device is configured with multiple serving cells, the device transmits the device trigger information and the corresponding serving cell number on the PUSCH.

[0275] In this embodiment of the application, when the device is configured with multiple frequency units, the device trigger information corresponding to different frequency units may be different. Therefore, when the device reports the device trigger information, the device transmits the device trigger information and the corresponding frequency unit number on the PUSCH.

[0276] In some embodiments, the device transmits device trigger information and the corresponding frequency unit number on the PUSCH, including: transmitting each frequency unit number and device trigger information (device trigger information set) on the PUSCH respectively. As shown in Table 7, when the device is configured with multiple frequency units such as frequency unit A, frequency unit B, ..., frequency unit n, frequency unit A and device trigger information set A can be transmitted on the PUSCH respectively, and frequency unit B and device trigger information set B can be transmitted on the PUSCH respectively.

[0277] Table 7. One method for reporting device triggering information under multiple frequency units:

[0278] In some embodiments, the device transmits device trigger information and the corresponding frequency unit number on the PUSCH, including: transmitting the device trigger information as a device trigger information set field and the frequency unit number as a frequency unit indication field on the PUSCH. The frequency unit indication field can use a processing method similar to CSI part 1, and the device trigger information set field can use a processing method similar to CSI part 2.

[0279] As shown in Table 8, when the device is configured with multiple frequency units such as frequency unit A, frequency unit B, ..., frequency unit n, frequency unit A, frequency unit B, ..., frequency unit n are used as frequency unit indication fields, and device trigger information set A, device trigger information set B, ..., device trigger information set n are carried on the PUSCH as a device trigger information set field for transmission.

[0280] Table 8. Another method for reporting device triggering information under multiple frequency units:

[0281] Similarly, when the device is configured with multiple carriers, the device trigger information corresponding to different carriers may be different. When reporting device trigger information, the device transmits the device trigger information and the corresponding carrier number on the PUSCH. For example, each carrier number and device trigger information can be transmitted separately on the PUSCH; or the device trigger information can be transmitted as a device trigger information set field, and the carrier number can be transmitted as a carrier indication field on the PUSCH.

[0282] When the device is configured with multiple serving cells, the device trigger information corresponding to different serving cells may be different. When reporting device trigger information, the device transmits the device trigger information and the corresponding serving cell number on the PUSCH. For example, each serving cell number and device trigger information can be transmitted separately on the PUSCH; or, the device trigger information can be transmitted as a device trigger information set field, and the serving cell number can be transmitted as a serving cell indication field on the PUSCH.

[0283] In some embodiments, when a device reports device trigger information, it can report a combination of frequency unit number, carrier number, and serving cell number. As shown in Figure 9, when multiple frequency units are configured in a serving cell, the device can transmit the serving cell number and frequency unit number corresponding to the device trigger information on the PUSCH when reporting device trigger information.

[0284] It should be noted that the device triggering information corresponding to different frequency units / carriers / serving cells can be the same or different. Some types of device triggering information may be related to the frequency unit / carrier / serving cell, while others may be unrelated. For example, beam status, suggested beam, and suggested power are related to the frequency unit / carrier / serving cell, while device buffer status, device speed changes, device movement direction changes, and device environmental changes are unrelated. Therefore, when device triggering information unrelated to the frequency unit / carrier / serving cell is reported together with device triggering information related to the frequency unit / carrier / serving cell, the design format or arrangement order of UCI and MAC CE can be further considered separately. For example, the device triggering information related to the frequency unit / carrier / serving cell can be placed before the device triggering information unrelated to the frequency unit / carrier / serving cell; or, the device triggering information related to the frequency unit / carrier / serving cell can be placed after the device triggering information unrelated to the frequency unit / carrier / serving cell.

[0285] 1.3 Carrying device trigger information via MAC CE:

[0286] In one specific implementation, when the device trigger information is carried on the PUSCH in MAC CE mode, the device transmits the device trigger information on the PUSCH, including:

[0287] The device fills the uplink shared channel UL-SCH with the different types of device trigger information according to the logical channel ID corresponding to the different types of device trigger information, and then transmits the filled UL-SCH on the PUSCH.

[0288] In this embodiment of the application, corresponding logical channel IDs are defined for different types of device trigger information in the uplink shared channel UL-SCH, as shown in Table 9. Each logical channel ID from 33 to 40 in the reserved logical channel IDs in the uplink shared channel UL-SCH is defined as a device trigger information.

[0289] Thus, when the device transmits device trigger information on the PUSCH in MAC CE mode, different types of device trigger information can be filled into the uplink shared channel UL-SCH according to the logical channel ID corresponding to different types of device trigger information.

[0290] Table 9. Example of the relationship between a logical channel and device triggering information:

[0291] In one specific implementation, when the device triggering information is carried on the PUSCH in the MAC CE mode and the type of the device triggering information is beam status information, the device triggering information includes at least the following fields:

[0292] The beam count configuration ID field indicates the ID of the beam count configuration used by the device;

[0293] The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device;

[0294] The beam report field indicates the following information about the beam reported by the device:

[0295] The measurement resource number of the beam reported by the device;

[0296] Measurement results corresponding to measurement resources with different numbers.

[0297] In this embodiment, the fields in the device trigger information (i.e., beam status information) can vary depending on the configuration. When the device is configured with multiple beam counts, the device needs to report the ID of the beam count configuration used by the device, the ID of the trigger event satisfied by at least one beam of the device, and the beam reported by the device when reporting beam status information. In this case, the beam status information includes three fields: beam count configuration ID, trigger event ID, and beam report. As shown in Figure 10, the beam status information includes three fields: beam count configuration ID, trigger event ID, and beam report. The bits corresponding to different fields may be different. For example, in the beam status information, the beam count configuration ID field corresponds to 2 bits, the trigger event ID field corresponds to 2 bits, and the beam report field corresponds to 4 bits.

[0298] When a device is configured with a single beam count, it can report only the ID of the trigger event satisfied by at least one beam and the beam being reported when reporting beam status information. In this case, the beam status information may only include two fields: the trigger event ID field and the beam report field. As shown in Figure 11, this beam status information includes two fields: the trigger event ID field and the beam report field. The bits corresponding to different fields may be different. For example, the trigger event ID field in the beam status information corresponds to 2 bits, and the beam report field corresponds to 6 bits.

[0299] In some embodiments, the structure of the beam report field is shown in Table 10. The beam report field includes the measurement resource number of the beam reported by the device (e.g., CRI or SSBRI#1, CRI or SSBRI#2, ..., CRI or SSBRI#N), and the measurement results corresponding to the measurement resources with different numbers (e.g., L1-RSRP#1). The measurement results corresponding to the measurement resources with different numbers can also be reported in a differential manner (e.g., Differential L1-RSRP#2, Differential L1-RSRP#N).

[0300] Table 10 shows the structure of the beam report fields:

[0301] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner and the type of the device trigger information is buffer status information, the device trigger information includes at least the following fields:

[0302] The Logical Channel Group ID field is used to indicate the ID of the logical channel group;

[0303] The index field indicates the index number of the cached data corresponding to the logical channel group.

[0304] In this embodiment of the application, the index number of the data volume corresponding to the logical channel group refers to the index number corresponding to the data volume threshold satisfied by the data volume of the logical channel group. The index number corresponding to the data volume threshold is the parameter configured or indicated for the device node in 1.1.3 above. That is, the node configures or indicates multiple data volume thresholds and corresponding index numbers for the device, and one data volume threshold corresponds to one index number.

[0305] In some embodiments, when reporting buffer status information, the device may report a logical channel group ID field and an index field. As shown in Figure 12, the buffer status information includes a logical channel group ID field and an index field. The bits corresponding to different fields may be different. For example, the logical channel group ID field corresponds to 3 bits, and the index field corresponds to 5 bits. The index field can be used to report the device buffer size.

[0306] In some embodiments, when reporting buffer status information, the device may report multiple logical channel group ID fields and multiple index fields. As shown in Figure 13, the buffer status information includes multiple logical channel group ID fields and multiple index fields. The bits corresponding to different fields may be different. For example, each logical channel group ID field corresponds to 1 bit, and each index field corresponds to 8 bits. The index fields can be used to report the device buffer size.

[0307] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the device trigger information includes at least the following fields:

[0308] Resource Configuration ID, used to indicate the parameters of Radio Resource Control (RRC) configuration and the Resource Configuration ID;

[0309] Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to;

[0310] Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device;

[0311] The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present.

[0312] The number of cell configuration identifiers indicates the number of cell configurations associated with the Resource set IDi indicated beam.

[0313] The resource set ID associated with the device-suggested beam or restricted beam can be any of the following: TCI state ID; SSB ID; CSI-RS index; SRI. The number of cell configuration identifiers is the number of cells associated with the Resource set ID.

[0314] As shown in Figure 14, the suggested beam information or restricted beam information of the device includes five fields: resource configuration ID, number of beams, beam type ID, cell in-situ identifier, and number of cell configuration identifiers. The number of bits corresponding to different fields may be different. For example, the resource configuration ID corresponds to 8 bits, the number of beams corresponds to 8 bits, the beam type ID corresponds to 2 bits, the cell in-situ identifier corresponds to 1 bit, and the number of cell configuration identifiers corresponds to 8 bits.

[0315] 1.4 Carrying device trigger information via UCI:

[0316] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner, the method further includes:

[0317] Step P1: The device acquires UCI configuration information;

[0318] Step P2: The device encodes the information to be reported as a whole according to the UCI configuration information to obtain the information carried on the PUSCH;

[0319] Step P3: The device divides the information to be reported into a first part of UCI and a second part of UCI according to the UCI configuration information, encodes the first part of UCI with a first encoding method and encodes the second part of UCI with a second encoding method to obtain the information carried on the PUSCH.

[0320] In this embodiment, the device can flexibly employ any of the encoding methods in steps P2 and P3 to encode the information to be reported, so as to carry the information on the PUSCH. For the encoding method in step P2, the device encodes the information to be reported as a single part using one encoding method.

[0321] For the encoding method in step P3, the device divides the reported information into two parts (i.e., the first part UCI and the second part UCI), and each part is encoded independently. In some embodiments, the first part UCI can be processed in a manner similar to CSI part 1, and the second part UCI can be processed in a manner similar to CSI part 2.

[0322] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner, the device fills the device trigger information that meets the trigger conditions into the corresponding position according to the configured filling position information, and fills the position of the device trigger information that does not meet the trigger conditions with redundant bits.

[0323] Among them, the filling position information represents the filling position of the device trigger information. Different filling positions correspond to different types of device trigger information. The filling position information can be configured or indicated by the node. For example, taking the device's beam status information, device's buffer status information, device's suggested beam information, device's suggested power information, and device's speed change information as examples, the filling position information can be as shown in Table 11. When the device reports device trigger information, it can fill different types of device trigger information according to the filling position corresponding to the filling position information to obtain the reported information.

[0324] Table 11 Example of filling in location information:

[0325] In this embodiment of the application, the device reports device trigger information when the triggering conditions are met. Therefore, when the device reports device trigger information, the device trigger information that meets the triggering conditions is filled in the corresponding position. For device trigger information that does not meet the triggering conditions, redundant bits are filled in the corresponding position of the device trigger information.

[0326] For example, regarding the filling position information in Table 11 above, if the device's suggested beam information does not meet the triggering conditions, redundant bits are filled at the position corresponding to the device's suggested beam information. After filling, the reported information is shown in Table 12.

[0327] Example of reported information after filling in Table 12:

[0328] In one specific implementation, the method further includes: the device using the device trigger information that meets the triggering conditions and the filled redundant bits as a first part of UCI.

[0329] In this embodiment, the filled device trigger information and redundant bits are transmitted as the first part of UCI, so that the node can parse the information at all filled positions in the received first part of UCI to obtain the device trigger information that meets the triggering conditions.

[0330] In one specific implementation, when the device trigger information is carried in the PUSCH in the form of UCI, the method further includes: the device taking the type of the device trigger information that meets the trigger conditions as the first part of UCI, and taking the device trigger information that meets the trigger conditions as the second part of UCI.

[0331] In this embodiment, for device triggering information that meets the triggering conditions, the type of the device triggering information is also reported. The type of the device triggering information can be reported in a UCI manner as the first part of the UCI, and the device triggering information that meets the triggering conditions is reported as the second part of the UCI. The information reported through the first part of the UCI and the second part of the UCI is carried on the PUSCH for transmission. For example, a channel structure for carrying information on the PUSCH is shown in Figure 15. In this way, the device only reports device triggering information that meets the triggering conditions, saving the reporting overhead of information that the device has not triggered.

[0332] Correspondingly, the node parses the first part of the received UCI to obtain the type of device trigger information that meets the triggering conditions. Then, based on the type of device trigger information that meets the triggering conditions, the node parses the information at the filling position corresponding to the device trigger information that meets the triggering conditions in the second part of the received UCI to obtain the device trigger information that meets the triggering conditions.

[0333] In this way, the node can obtain the device trigger information type carried by the PUSCH first by using the device trigger information type in the first part of the UCI. Then, it can parse only the position corresponding to the device trigger information of that type, thus avoiding parsing the redundant bits of the padding, which helps to reduce overhead and processing latency.

[0334] In some embodiments, a bitmap can be used to indicate the types of information carried in UCI format in the current PUSCH. For example, the beam status information of the node configuration device and the device's suggested beam information are carried on the PUSCH using UCI format. The first UCI can contain 2 bits to indicate whether the two device trigger information appear on the current PUSCH, where 1 indicates that the current PUSCH carries the device trigger information, and 0 indicates that the current PUSCH does not carry the device trigger information.

[0335] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner and the type of the device trigger information is beam status information, the method further includes: the device using the ID of the number of beams used by the device and the ID of the corresponding trigger event as the first part of the UCI, and the beam status information as the second part of the UCI; or, the device using the ID of the corresponding trigger event as the first part of the UCI, and the beam status information as the second part of the UCI.

[0336] In this embodiment of the application, considering that the reported beam number configuration, as well as the type and number of triggering events, will affect the size of subsequent beam status information, the beam number configuration, triggering events, and reporting content are reported separately when it is necessary to report the beam number configuration.

[0337] Specifically, if a node is configured with one beam number configuration, it does not need to report the beam number configuration. The device can use the ID of the triggering event as the first part of the UCI and the beam status information as the second part of the UCI. If a node is configured with multiple beam number configurations, it needs to report the beam number configuration. In this case, the device uses the ID of the beam number configuration used by the device and the ID of the corresponding triggering event as the first part of the UCI, and the beam status information as the second part of the UCI.

[0338] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner and the type of the device trigger information is buffer status information, the device transmits the device trigger information carried on the PUSCH, including:

[0339] The device uses the ID of the logical channel group and the index number of the data cached in the logical channel group as the first part of the UCI or as the second part of the UCI, and transmits information containing at least the first part of the UCI or the second part of the UCI on the PUSCH.

[0340] The index number of the data volume corresponding to the logical channel group refers to the index number of the data volume threshold that the data volume cached by the logical channel group meets. The index number corresponding to the data volume threshold is the parameter configured or indicated for the device node in 1.1.3 above. That is, the node configures or indicates multiple data volume thresholds and corresponding index numbers for the device, and one data volume threshold corresponds to one index number.

[0341] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the method further includes: the device using the resource configuration ID, number of beams, and cell in-situ identifier as the first part of the UCI, and using the beam type ID, associated resource set ID, and associated cell number as the second part of the UCI.

[0342] The number of associated cells refers to the number of cells associated with each resource configuration ID. For example, if there are 3 beam type IDs and a total of 3 Ci values, then the information reported by the second part of UCI is: the number of cells associated with resource configuration ID1, the number of cells associated with resource configuration ID2, and the number of cells associated with resource configuration ID3.

[0343] In some embodiments, the resource configuration ID, number of beams, Ci, resource configuration ID, number of beams, Ci can be used as the first part UCI or the first part UCI.

[0344] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner, the method further includes: the device using any one of the device's suggested beam information, the device's restricted beam information, the device's suggested power information, the device's speed change information, the device's movement direction change information, and the device's environmental change information as a first part of the UCI or as a second part of the UCI.

[0345] Understandably, if one type of device trigger information is used as the first part of the UCI, another type of device trigger information can be used as the second part of the UCI, and the first and second parts of the UCI can be transmitted via PUSCH. For example, the device's suggested beam information can be used as the first part of the UCI, and the device's restricted beam information can be used as the second part of the UCI.

[0346] 1.5 Transmission method for non-device-triggered information:

[0347] In one specific implementation, the device transmits the non-device trigger information on the PUSCH, including: the device transmits the non-device trigger information on the PUSCH according to the configured transmission period or the node indication.

[0348] In this embodiment of the application, non-device trigger information is at least one of uplink control information and data. That is, non-device trigger information can refer to uplink control information or data sent by the device through node configuration period (periodic resource) or through node dynamic instruction, so that the node can obtain the device information in a timely manner.

[0349] Section 1.6 Information Transmission with Overlapping Channel Time Domains:

[0350] In one specific implementation, when a time-domain overlap occurs between the device trigger information and the non-device trigger information, the method further includes:

[0351] The device determines the information to be transmitted from the device trigger information and the non-device trigger information according to the instructions or configuration of the node, or according to predefined rules;

[0352] The device carries the information to be transmitted on the PUSCH for transmission.

[0353] In this embodiment, if the channel carrying device trigger information overlaps in the time domain with the channel carrying non-device trigger information (e.g., HARQ, CSI, or data), the device determines the information to be transmitted from the device trigger information and non-device trigger information according to certain rules, and then transmits the information to be transmitted on the PUSCH to achieve information reporting. In some embodiments, the rules may be node-indicated or configured. If the node cannot know the transmission status of device trigger information in advance, it needs to determine the information to be transmitted according to this principle.

[0354] Specifically, when the non-device-triggered information is carried on the first PUSCH and the device-triggered information is carried on the second PUSCH, the device transmits the information to be transmitted on the PUSCH, including any of the following:

[0355] R-1: The device transmits the non-device trigger information carried on the first PUSCH and discards the device trigger information carried on the second PUSCH; in this way, the device can promptly report the non-device trigger information carried on the first PUSCH to the node, thereby realizing information transmission in a multi-PUSCH scenario in a simple way.

[0356] R-2: The device transmits the device trigger information carried on the second PUSCH and discards the non-device trigger information carried on the first PUSCH; in this way, the device can promptly report the device trigger information carried on the second PUSCH to the node, thereby realizing information transmission in a multi-PUSCH scenario in a simple way.

[0357] R-3: The device transmits one of the non-device trigger information and the non-device trigger information according to the priority of the first PUSCH and the second PUSCH; in this way, the device can promptly report one of the non-device trigger information carried on the first PUSCH and the device trigger information carried on the second PUSCH to the node, so as to realize information transmission in multi-PUSCH scenarios in a simple way.

[0358] R-4: The device merges (concatenates) the non-device trigger information and the device trigger information, and transmits the merged (concatenated) information on the first PUSCH or on the second PUSCH. In this way, the device can report both the non-device trigger information and the device trigger information to the node, avoiding the discarding of either piece of information.

[0359] In this embodiment of the application, the device can flexibly carry the information to be transmitted on the PUSCH for transmission according to any one of the transmission methods in items R-1 to R-4 above, so as to meet the transmission requirements of various information.

[0360] For item R-3, if the node indicates that the first PUSCH carrying non-device trigger information has a higher priority than the second PUSCH carrying device trigger information, then when the time domains of the first PUSCH and the second PUSCH overlap, the device will transmit the first PUSCH carrying non-device trigger information.

[0361] For item R-4, if the time domains of the first PUSCH carrying non-device trigger information and the second PUSCH carrying device trigger information overlap, as shown in Figure 16, if the node indicates that the first PUSCH is the target PUSCH for multiplexing, then the device will carry both device trigger information and non-device trigger information on the first PUSCH, and the device will not send the second PUSCH. This way, both device trigger information and non-device trigger information can be sent to the node at the same time, avoiding message loss and satisfying the single-carrier transmission characteristics of the device.

[0362] In some embodiments, a node can indicate which resource the device trigger information and non-device trigger information are multiplexed onto. Specifically, the processing time of the device trigger information can be defined as X, which includes the measurement time of an associated measurement signal and the preparation time for the reporting information. This processing time X can be defined as the time interval from the reference resource to the reporting of the device trigger information, as shown in Figure 17. The measurement resource associated with the device trigger information is the most recent measurement resource before the measurement of the reference resource. The time domain location of the reference resource must meet the following two conditions:

[0363] Condition 1: Greater than or equal to Y, where Y is configured by the node and may be related to the device's capabilities;

[0364] Condition 2: Ensure that the reference resource is the minimum effective downlink time slot.

[0365] As shown in Figure 18, if device trigger information and non-device trigger information are multiplexed, the multiplexing timeline should satisfy the processing time X. Furthermore, if the processing time Z of the non-device trigger information (e.g., the preparation time for scheduling DCI to PUSCH is Z), then the minimum processing time (the latest arrival time of DCI) is max(X, Z) + m or max(X, Z + m) before the starting symbol of the multiplexed information report, where m is an integer greater than or equal to 0, and the unit is symbols.

[0366] In addition, the following situations need to be considered when determining the timeline for reuse:

[0367] Case 1: When the timeline requirement is met; if the time domains of channel 1 and channel 2 overlap, and the timeline requirement for device-triggered information to be multiplexed to channel 2 is met, then the device-triggered information originally carried on channel 1 will be multiplexed to channel 2.

[0368] Case 2: If the multiplexing timeline is not met; if the time domains of channel 1 and channel 2 overlap, and the multiplexing timeline requirements are not met, one of the following processing methods can be adopted: Method 1: The node can configure the transmission priority of channel 1 and channel 2, that is, the high-priority channel will be transmitted and the low-priority channel will be discarded; Method 2: The device considers this an error case, which means that the node does not allow this scheduling.

[0369] Scenario 3: Channel 2 overlaps with multiple Channels 1, and some meet the multiplexing timeline while others do not. If a device is scheduled by a node to use Channel 2, which overlaps with multiple Channels 1 carrying device-triggered information, and if at least one PUSCH does not meet the multiplexing timeline requirements, then one of the following processing methods can be adopted: Method 1: The device only reuses device-triggered information that meets the multiplexing timeline and discards device-triggered information that does not meet the multiplexing timeline. In some embodiments, the node can configure the number of device-triggered information multiplexed, for example, only allowing the multiplexing of device-triggered information on one PUSCH, and discarding device-triggered information on the remaining channels. Method 2: The node can configure the transmission priority of Channel 2 and Channel 1 carrying device-triggered information, i.e., transmitting the higher-priority channel and discarding the lower-priority channel. For example, Channel 2 has a higher priority. Method 3: The device considers this an error case.

[0370] Case 4: Channel 1 overlaps with multiple channels 2, and some meet the multiplexing timeline while others do not. One of the following processing methods can be adopted: Method 1: The device can multiplex the device-triggered information onto the earliest channel 2 that meets the multiplexing timeline; Method 2: The node can configure the transmission priority of channel 2 and channel 1 carrying the device-triggered information, that is, the channel with higher priority will be transmitted and the channel with lower priority will be discarded; Method 3: The device considers this an error case.

[0371] By adopting the technical solution of this application embodiment, when there is temporal overlap between device trigger information and non-device trigger information, the device trigger information and / or non-device trigger information can be reported in a timely manner based on certain rules.

[0372] A second aspect of this application provides another method for transmitting device trigger information. This method is applied to a node. Referring to Figure 19, which is a flowchart of another method for transmitting device trigger information according to an embodiment of this application, the method may include the following steps:

[0373] Step S1910: The node configures transmission resources for the device, the transmission resources being used to transmit information carried on the PUSCH;

[0374] Step S1920: The node receives the information carried on the PUSCH;

[0375] The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

[0376] By adopting the technical solution of this application embodiment, the information transmission between the device (e.g., UE) and the node (e.g., base station) is unified under the PUSCH transmission framework, eliminating PUCCH transmission and avoiding the multiplexing process of UCI multiplexing of PUCCH of different services. Therefore, the device can transmit all its relevant information (i.e., device trigger information and non-device trigger information) to the node in a timely manner through PUSCH.

[0377] In one specific implementation, the device trigger information includes at least one or more of the following types:

[0378] The beam status information of the device is used to indicate the beam status of the device;

[0379] The buffer status information of the device is used to indicate the amount of data in the buffer of the device;

[0380] The device's suggested beam information is used to indicate the beam that the device suggests to the node;

[0381] The limited beam information of the device is used to indicate the limited beam of the device;

[0382] The device's suggested power information is used to indicate the transmit or receive power that the device suggests to the node;

[0383] The speed change information of the device is used to indicate the degree of change in the device's moving speed;

[0384] The information on the change in the movement direction of the device is used to indicate the degree of change in the movement direction of the device;

[0385] The environmental change information of the device is used to indicate the current environment in which the device is located.

[0386] In one specific implementation, a type of device triggering information corresponds to a first index number, or a combination of types corresponds to a first index number;

[0387] The first correspondence between each first index number and a type of device trigger information or a combination of types is predefined by the protocol; the combination of types includes multiple types of device trigger information.

[0388] In one specific implementation, the method further includes:

[0389] The node indicates or configures index information to the device, wherein the index information is: a first index number corresponding to each type of device trigger information, or a first index number corresponding to each type combination; wherein a type combination includes multiple types of device trigger information.

[0390] In one specific implementation, the method further includes:

[0391] The node receives the type of device trigger information carried on the PUSCH; or

[0392] The node receives the accompanying reference signal of the PUSCH, parses the accompanying reference signal of the PUSCH to obtain the type of the device triggering information, wherein different sequences of the accompanying reference signal represent different types of device triggering information.

[0393] In one specific implementation, when the type of the device trigger information includes the device's beam status information, the parameters configured or indicated to the device by the node include at least one of the following:

[0394] Trigger the event;

[0395] Beam count configuration;

[0396] The triggering event includes at least one of the following:

[0397] The current beam quality is below the threshold;

[0398] At least one new beam has a higher quality than the current beam;

[0399] At least one new beam has a higher quality than the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node;

[0400] The number of beams configuration includes at least one of the following:

[0401] The first beam number configuration indicates that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax;

[0402] The second beam count configuration instructs the device to report the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and Nmax-N redundant bits corresponding to beams that do not satisfy the trigger event, where N is a positive integer between 1 and Nmax.

[0403] The third beam number configuration indicates that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax;

[0404] The fourth beam quantity configuration indicates that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node;

[0405] The fifth beam number configuration indicates that the device reports the status information of one beam that satisfies the trigger event;

[0406] Nmax is configured by the node.

[0407] In one specific implementation, when the type of the device trigger information includes the device's buffer status information, the parameters configured or indicated by the node to the device include: multiple data volume thresholds and second index numbers corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number;

[0408] When the type of the device trigger information includes the device's suggested power information, the parameters configured or indicated by the node to the device include: multiple power thresholds and third index numbers corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number;

[0409] When the type of device trigger information includes the device's speed change information, the parameters configured or indicated by the node to the device include: multiple speed thresholds and fourth index numbers corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number;

[0410] When the type of device trigger information includes the device's movement direction change information, the parameters configured or indicated by the node to the device include: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number;

[0411] When the type of device trigger information includes environmental change information of the device, the parameters configured or indicated by the node to the device include: multiple environmental information and a sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

[0412] In one specific implementation, the method further includes:

[0413] The node sends PUSCH format configuration information to the device;

[0414] The PUSCH format configuration information includes any of the following:

[0415] The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH;

[0416] The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH carries the uplink shared channel UL-SCH;

[0417] The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode, and the PUSCH does not carry UCI.

[0418] In one specific implementation, the method further includes:

[0419] The node sends bearer configuration information to the device. The bearer configuration information is used to indicate whether the bearer method for each type of device trigger information carried on the PUSCH is UCI, MAC CE, or a combination of UCI and MAC CE.

[0420] In one specific implementation, the method further includes:

[0421] The node sends a UL scheduling DCI, in which the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a hybrid of UCI and MAC CE.

[0422] The UL scheduling DCI carries at least one of the following fields:

[0423] The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback.

[0424] The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

[0425] In one specific implementation, the method further includes:

[0426] The node instructs or configures at least one of the following to the device:

[0427] Maximum bitrate;

[0428] The priority of different information carried on the PUSCH;

[0429] The priority is used to: report the order of different information that needs to be carried on the PUSCH when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate; or to trigger the device to send a resource request to the node when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate.

[0430] Upon receiving the resource request, the node allocates transmission resources to the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

[0431] In one specific implementation, when the transmission resources configured on the node are insufficient to transmit the information carried on the PUSCH, the method further includes:

[0432] The node receives resource requests carried on the PUSCH; or

[0433] The node receives the accompanying reference signal of the PUSCH and parses the accompanying reference signal of the PUSCH to obtain the number of transmission resources requested by the device, wherein different sequences of the accompanying reference signal represent different numbers of transmission resources.

[0434] The node allocates transmission resources to the device so that the device can transmit at least one of device trigger information and non-device trigger information on the PUSCH.

[0435] In one specific implementation, the method further includes:

[0436] The node receives and parses the first part of the UCI to obtain the actual resource usage information of the device. The actual resource usage information represents the transmission resources actually used by the information carried on the PUSCH.

[0437] In one specific implementation, the method further includes at least one of the following:

[0438] The node indicates or configures multiple frequency units to the device, and the node receives frequency unit numbers corresponding to the device triggering information carried on the PUSCH.

[0439] The node indicates or configures multiple carriers to the device, and the node receives carrier numbers corresponding to the device triggering information carried on the PUSCH.

[0440] The node indicates or configures multiple serving cells to the device, and the node receives the serving cell number corresponding to the device triggering information carried on the PUSCH.

[0441] In one specific implementation, the method further includes:

[0442] The node indicates or configures information logical channel ID information to the device, wherein the information logical channel ID information is: the information logical channel ID corresponding to each type of device trigger information;

[0443] The node determines multiple types of device trigger information based on multiple information logical channel IDs in the uplink shared channel UL-SCH.

[0444] In one specific implementation, the method further includes:

[0445] The node parses the received device trigger information and obtains at least one of the following:

[0446] The ID configured for the number of beams used by the device;

[0447] The ID of the triggering event satisfied by at least one beam of the device;

[0448] The beams reported by the device include: the measurement resource number of the beams reported by the device; and the measurement results corresponding to the measurement resources with different numbers.

[0449] The device triggering information includes at least the following fields:

[0450] The beam count configuration ID field indicates the ID of the beam count configuration used by the device;

[0451] The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device;

[0452] The beam report field indicates the following information about the beam reported by the device:

[0453] The measurement resource number of the beam reported by the device;

[0454] Measurement results corresponding to measurement resources with different numbers.

[0455] In one specific implementation, the method further includes:

[0456] The node parses the received device trigger information to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID;

[0457] The device triggering information includes at least the following fields:

[0458] The Logical Channel Group ID field is used to indicate the ID of the logical channel group;

[0459] The index field indicates the index number of the cached data corresponding to the logical channel group.

[0460] In one specific implementation, the method further includes:

[0461] The node parses the received device trigger information and obtains at least one of the following:

[0462] The parameters of the RRC configuration and the ResourceConfigID;

[0463] The number of beam IDs suggested by the device, or the number of beam IDs restricted by the device;

[0464] The resource set ID associated with the suggested or restricted beam of the device;

[0465] Does the Idi bit in the Number of cell configurations exist?

[0466] The number of cell configurations associated with the beam indicated by Resource set IDi;

[0467] The device triggering information includes at least the following fields:

[0468] Resource Configuration ID, used to indicate the RRC configuration and the parameters of the ResourceConfigID;

[0469] Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to;

[0470] Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device;

[0471] The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present.

[0472] Cell in-situ identifier, used to indicate the number of cell configurations associated with the Resource set IDi indicated beam.

[0473] In one specific implementation, the method further includes:

[0474] The node indicates or configures UCI configuration information to the device;

[0475] The node decodes the information carried on the PUSCH according to the UCI configuration information; or

[0476] The node decodes the received first part of the UCI using a first decoding method and the received second part of the UCI using a second decoding method, based on the UCI configuration information.

[0477] In one specific implementation, the method further includes:

[0478] The node indicates or configures the filling position information to the device, and different filling positions correspond to different types of device trigger information.

[0479] The node parses the information at all the fill positions in the received first part of the UCI to obtain the device trigger information that meets the triggering conditions.

[0480] In one specific implementation, the method further includes:

[0481] The node parses the first part of the received UCI to obtain the type of device trigger information that meets the triggering conditions;

[0482] The node parses the information at the filling position corresponding to the device trigger information that meets the trigger conditions in the received second part of UCI according to the type of device trigger information that meets the trigger conditions, and obtains the device trigger information that meets the trigger conditions.

[0483] In one specific implementation, the method further includes:

[0484] The node parses the first part of the received UCI to obtain the ID of the number of beams configured by the device and the ID of the corresponding trigger event; and parses the second part of the received UCI to obtain the beam status information; or,

[0485] The node parses the first part of the received UCI to obtain the ID of the corresponding trigger event, and parses the second part of the received UCI to obtain the beam status information.

[0486] In one specific implementation, the method further includes:

[0487] The node parses the received first part or second part of the UCI to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID.

[0488] In one specific implementation, the method further includes:

[0489] The node parses the first part of the received UCI to obtain the resource configuration ID, number of beams, and cell in-situ identifier. It also parses the second part of the received UCI to obtain the beam type ID, associated resource set ID, and associated cell number.

[0490] In one specific implementation, the method further includes:

[0491] The node parses the received first part or second part of UCI to obtain one of the following: the device's suggested beam information, the device's restricted beam information, the device's suggested power information, the device's speed change information, the device's movement direction change information, and the device's environmental change information.

[0492] In one specific implementation, the method further includes:

[0493] The node indicates or configures the transmission period to the device;

[0494] The node receives the information carried on the PUSCH, including:

[0495] The node receives non-device trigger information carried on the PUSCH according to the transmission period.

[0496] In one specific implementation, the method further includes:

[0497] The node configures or instructs the device to determine the information to be transmitted, and the information to be transmitted determination rule is used to determine the information to be transmitted from the device trigger information and the non-device trigger information when there is a time domain overlap between the device trigger information and the non-device trigger information.

[0498] In one specific implementation, the rule for determining the information to be transmitted includes any of the following:

[0499] Transmit the non-device trigger information carried on the first PUSCH and discard the device trigger information carried on the second PUSCH;

[0500] Transmit the device trigger information carried on the second PUSCH and discard the non-device trigger information carried on the first PUSCH;

[0501] According to the priority of the first PUSCH and the second PUSCH, transmit one of the non-device trigger information and the non-device trigger information;

[0502] The non-device trigger information and the device trigger information are merged and then transmitted on the first PUSCH.

[0503] The non-device trigger information and the device trigger information are merged and then transmitted on the second PUSCH.

[0504] The device trigger information transmission method provided in this application can be executed by a device trigger information transmission device. This application uses the device trigger information transmission device executing the device trigger information transmission method as an example to illustrate the device trigger information transmission device provided in this application.

[0505] This application provides a device for transmitting device trigger information. As an example, the device for transmitting device trigger information can be a communication device or a component in a communication device, such as a chip. The communication device can be a terminal, a network-side device, or a server, etc. Exemplarily, the terminal can be, but is not limited to, the type of terminal 11 listed above, and the network-side device can be, but is not limited to, the type of network-side device 12 listed above. This application does not impose specific limitations.

[0506] The device trigger information transmission apparatus includes a receiving module, a transmitting module, and a processing module. These modules can be implemented in software or hardware. When implemented in hardware, the processing module can be implemented by a processor. For example, the processor can include general-purpose processors, special-purpose processors, etc., such as central processing units (CPUs), microprocessors, digital signal processors (DSPs), artificial intelligence (AI) processors, graphics processing units (GPUs), application-specific integrated circuits (ASICs), network processors (NPs), field-programmable gate arrays (FPGAs), or other programmable logic devices, gate circuits, transistors, discrete hardware components, etc. The receiving and transmitting modules can be implemented by a communication interface, which can include one or more of the following: transceivers, pins, circuits, buses, radio frequency units, etc.

[0507] Specifically, referring to Figure 20, when the device trigger information transmission device is a terminal or a component in the terminal, the device trigger information transmission device 2000 includes:

[0508] The first transmission module 2001 is used to transmit at least one of device trigger information and non-device trigger information on the PUSCH; wherein the device trigger information is triggered based on the status information of the device; and the non-device trigger information is triggered based on the configuration or instruction of the node to the device.

[0509] In one specific implementation, the device trigger information includes at least one or more of the following types:

[0510] The beam status information of the device is used to indicate the beam status of the device;

[0511] The buffer status information of the device is used to indicate the amount of data in the buffer of the device;

[0512] The suggested beam information of the device is used to indicate the suggested beam of the device;

[0513] The limited beam information of the device is used to indicate the limited beam of the device;

[0514] The device's recommended power information is used to indicate the device's recommended transmission power;

[0515] The speed change information of the device is used to indicate the degree of change in the device's moving speed;

[0516] The information on the change in the movement direction of the device is used to indicate the degree of change in the movement direction of the device;

[0517] The environmental change information of the device is used to indicate the current environment in which the device is located.

[0518] In one specific implementation, a type of device trigger information corresponds to a first index number, or a combination of types corresponds to a first index number;

[0519] The first correspondence between each first index number and a type of device trigger information or a combination of types is indicated by the node to the device, configured by the node for the device, or is predefined by the protocol;

[0520] The type combination includes multiple types of device trigger information.

[0521] In one specific embodiment, the device further includes:

[0522] The second transmission module is used to carry the type of the device trigger information on the PUSCH for transmission.

[0523] The third transmission module is used to transmit the type of the device trigger information on the accompanying reference signal of the PUSCH, and to represent different types of device trigger information through different sequences of the accompanying reference signal.

[0524] In one specific implementation, the parameter configured or indicated by the node to the device corresponding to the beam state information of the device is a first parameter, and the first parameter includes at least one of the following:

[0525] Trigger the event;

[0526] Beam count configuration;

[0527] The triggering event includes at least one of the following:

[0528] The current beam quality is below the threshold;

[0529] At least one new beam has a higher quality than the current beam;

[0530] At least one new beam has a higher quality than the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node;

[0531] The number of beams configuration includes at least one of the following:

[0532] The first beam number configuration indicates that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax;

[0533] The second beam count configuration instructs the device to report the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and Nmax-N redundant bits corresponding to beams that do not satisfy the trigger event, where N is a positive integer between 1 and Nmax.

[0534] The third beam number configuration indicates that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax;

[0535] The fourth beam quantity configuration indicates that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node;

[0536] The fifth beam number configuration indicates that the device reports the status information of one beam that satisfies the trigger event;

[0537] Nmax is configured by the node.

[0538] In one specific implementation, the parameter corresponding to the buffer status information of the device configured or indicated by the node to the device is a second parameter. The second parameter includes: multiple data volume thresholds and a second index number corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number.

[0539] The parameter corresponding to the suggested power information of the device configured or indicated by the node to the device is a third parameter, which includes: multiple power thresholds and third index numbers corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number;

[0540] The parameter corresponding to the speed change information of the device configured or indicated by the node to the device is the fourth parameter. The fourth parameter includes: multiple speed thresholds and fourth index numbers corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number.

[0541] The parameter corresponding to the movement direction change information of the device configured or indicated by the node to the device is the fifth parameter. The fifth parameter includes: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number.

[0542] The parameter corresponding to the environmental change information of the device configured or indicated by the node to the device is the sixth parameter. The sixth parameter includes: multiple environmental information and the sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

[0543] In one specific implementation, the first transmission module is further configured to, when the device trigger information meets the triggering conditions, transmit the device trigger information that meets the triggering conditions by carrying it on the PUSCH.

[0544] In one specific implementation, the device carries device trigger information in the PUSCH in any of the following ways:

[0545] Media Access Control (MAC) control element in CE mode;

[0546] Uplink control information (UCI) method;

[0547] A hybrid approach combining UCI and MAC CE.

[0548] In one specific embodiment, the device further includes:

[0549] The first acquisition module is used to acquire PUSCH format configuration information;

[0550] The first bearer module is used to carry the device triggering information on the PUSCH according to the PUSCH format configuration information;

[0551] The PUSCH format configuration information includes any of the following:

[0552] The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH.

[0553] The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner and the PUSCH carries the uplink shared channel UL-SCH.

[0554] The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode and the PUSCH does not carry UCI.

[0555] In one specific embodiment, the device further includes:

[0556] The second acquisition module is used to acquire bearer configuration information, which indicates whether the bearer configuration information of each type of device trigger information is carried on the PUSCH in a UCI mode, a MAC CE mode, or a mixed UCI and MAC CE mode.

[0557] The first transmission module is further configured to transmit the device trigger information on the PUSCH according to the bearer configuration information.

[0558] In one specific embodiment, the device further includes:

[0559] The second receiving module is used to receive UL scheduling DCI, wherein the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a mixed UCI and MAC CE mode.

[0560] The first transmission module is further configured to transmit the device trigger information on the PUSCH according to the UL scheduling DCI.

[0561] The UL scheduling DCI carries at least one of the following fields:

[0562] The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback.

[0563] The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

[0564] In one specific embodiment, the device further includes:

[0565] The first determining module is used to determine the bit rate of the information that needs to be carried on the PUSCH;

[0566] The second bearer module is used to report information that needs to be carried on the PUSCH in descending order of priority, or to send a resource request to the node, when the bit rate exceeds the maximum bit rate configured or indicated by the node.

[0567] In one specific implementation, if the transmission resources configured on the node are insufficient to transmit the information carried on the PUSCH, the method further includes:

[0568] The first sending module is used to send resource requests to the node;

[0569] The device transmits resource requests on the PUSCH; or the device transmits resource requests on the accompanying reference signal of the PUSCH, with different sequences of the accompanying reference signal representing different amounts of transmission resources requested.

[0570] The resource request is used to request the node to allocate transmission resources for the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

[0571] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner, the method further includes:

[0572] The second sending module is used to add actual resource usage information to the first part of the UCI and send it to the node. The actual resource usage information represents the transmission resources actually used by the information carried on the PUSCH.

[0573] In one specific implementation, the first transmission module is further configured to:

[0574] When the device is configured with multiple frequency units, the device trigger information and the corresponding frequency unit number are carried on the PUSCH for transmission;

[0575] When the device is configured with multiple carriers, the device trigger information and the corresponding carrier number are carried on the PUSCH for transmission;

[0576] When the device is configured with multiple serving cells, the device trigger information and the corresponding serving cell number are carried on the PUSCH for transmission.

[0577] In one specific implementation, when the device trigger information is carried on the PUSCH in the MAC CE mode, the first transmission module is further configured to fill the uplink shared channel UL-SCH with different types of device trigger information according to the logical channel ID corresponding to different types of device trigger information, and then carry the filled UL-SCH on the PUSCH for transmission.

[0578] In one specific implementation, when the device triggering information is carried on the PUSCH in the MAC CE mode and the type of the device triggering information is beam status information, the device triggering information includes at least the following fields:

[0579] The beam count configuration ID field indicates the ID of the beam count configuration used by the device;

[0580] The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device;

[0581] The beam report field indicates the following information about the beam reported by the device:

[0582] The measurement resource number of the beam reported by the device;

[0583] Measurement results corresponding to measurement resources with different numbers.

[0584] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner and the type of the device trigger information is buffer status information, the device trigger information includes at least the following fields:

[0585] The Logical Channel Group ID field is used to indicate the ID of the logical channel group;

[0586] The index field indicates the index number of the cached data corresponding to the logical channel group.

[0587] In one specific implementation, when the device trigger information is carried on the PUSCH in a MAC CE manner, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the device trigger information includes at least the following fields:

[0588] Resource Configuration ID, used to indicate the parameters of Radio Resource Control (RRC) configuration and the Resource Configuration ID;

[0589] Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to;

[0590] Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device;

[0591] The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present.

[0592] The number of cell configuration identifiers indicates the number of cell configurations associated with the Resource set IDi indicated beam.

[0593] In one specific embodiment, when the device trigger information is carried on the PUSCH in a UCI manner, the device further includes:

[0594] The configuration information acquisition module is used to acquire UCI configuration information;

[0595] The first encoding module is used to encode the information to be reported as a whole according to the UCI configuration information to obtain the information carried on the PUSCH; or according to the UCI configuration information, the information to be reported is divided into a first part UCI and a second part UCI, the first part UCI is encoded in a first encoding method and the second part UCI is encoded in a second encoding method to obtain the information carried on the PUSCH.

[0596] In one specific embodiment, when the device trigger information is carried on the PUSCH in a UCI manner, the device further includes:

[0597] The first filling module is used to fill the device trigger information that meets the triggering conditions into the corresponding positions according to the configured filling position information, and to fill the positions corresponding to the device trigger information that does not meet the triggering conditions with redundant bits.

[0598] In one specific implementation, the device trigger information that meets the triggering conditions and the filled redundant bits are used as the first part of the UCI.

[0599] In one specific implementation, when the device trigger information is carried in the PUSCH in the form of UCI, the type of device trigger information that meets the triggering conditions is taken as the first part of UCI, and the device trigger information that meets the triggering conditions is taken as the second part of UCI.

[0600] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner and the type of the device trigger information is beam status information, the ID of the number of beams used by the device and the ID of the corresponding trigger event are used as the first part of the UCI, and the beam status information is used as the second part of the UCI; or, the device uses the ID of the corresponding trigger event as the first part of the UCI and the beam status information as the second part of the UCI.

[0601] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner and the type of the device trigger information is buffer status information, the device transmits the device trigger information carried on the PUSCH. The first transmission module is further configured to use the ID of the logical channel group and the index number of the data volume corresponding to the logical channel group as the first part of the UCI or as the second part of the UCI. The device transmits information that includes at least the first part of the UCI or the second part of the UCI carried on the PUSCH.

[0602] In one specific implementation, when the device trigger information is carried on the PUSCH in the form of UCI, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the resource configuration ID, the number of beams, and the cell in-situ identifier are used as the first part of the UCI, and the beam type ID, the associated resource set ID, and the associated number of cells are used as the second part of the UCI.

[0603] In one specific implementation, when the device trigger information is carried on the PUSCH in a UCI manner, any one of the device's suggested beam information, the device's restricted beam information, the device's suggested power information, the device's speed change information, the device's movement direction change information, and the device's environmental change information is used as either the first part of the UCI or the second part of the UCI.

[0604] In one specific implementation, the first transmission module is further configured to transmit the non-device trigger information on the PUSCH according to the configured transmission period or the node indication.

[0605] In one specific embodiment, when there is temporal overlap between the device triggering information and the non-device triggering information, the device further includes:

[0606] The second determining module is used to determine the information to be transmitted from the device trigger information and the non-device trigger information according to the instructions or configuration of the node or predefined rules.

[0607] The first transmission module is also used for the device to carry the information to be transmitted on the PUSCH for transmission.

[0608] In one specific implementation, when the non-device trigger information is carried on the first PUSCH and the device trigger information is carried on the second PUSCH; the first transmission module is further configured to perform any of the following:

[0609] Transmit the non-device trigger information carried on the first PUSCH and discard the device trigger information carried on the second PUSCH;

[0610] Transmit the device trigger information carried on the second PUSCH and discard the non-device trigger information carried on the first PUSCH;

[0611] According to the priority of the first PUSCH and the second PUSCH, transmit one of the non-device trigger information and the non-device trigger information;

[0612] The non-device trigger information and the device trigger information are merged and transmitted on the first PUSCH or on the second PUSCH.

[0613] The device trigger information transmission apparatus provided in this application embodiment can implement the various processes implemented in the device trigger information transmission method embodiment provided in the first aspect above, and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0614] The embodiment of this application provides another method for transmitting device trigger information, in which the executing entity can be another frequency synchronization device. This embodiment uses an alternative device for transmitting device trigger information as an example to illustrate the alternative device for transmitting device trigger information provided in this application.

[0615] This application provides a device for transmitting device trigger information. As an example, the device for transmitting device trigger information can be a communication device or a component in a communication device, such as a chip. The communication device can be a terminal, a network-side device, or a server, etc. Exemplarily, the terminal can be, but is not limited to, the type of terminal 11 listed above, and the network-side device can be, but is not limited to, the type of network-side device 12 listed above. This application does not impose specific limitations.

[0616] The device trigger information transmission apparatus includes a receiving module, a transmitting module, and a processing module. These modules can be implemented in software or hardware. When implemented in hardware, the processing module can be implemented by a processor. For example, the processor can include general-purpose processors, special-purpose processors, etc., such as central processing units (CPUs), microprocessors, digital signal processors (DSPs), artificial intelligence (AI) processors, graphics processing units (GPUs), application-specific integrated circuits (ASICs), network processors (NPs), field-programmable gate arrays (FPGAs), or other programmable logic devices, gate circuits, transistors, discrete hardware components, etc. The receiving and transmitting modules can be implemented by a communication interface, which can include one or more of the following: transceivers, pins, circuits, buses, radio frequency units, etc.

[0617] Specifically, referring to Figure 21, when the device trigger information transmission device is a terminal or a component in the terminal, the device trigger information transmission device 2100 includes:

[0618] The first configuration module 2101 is used to configure transmission resources for the device, the transmission resources being used to transmit information carried on the PUSCH.

[0619] The first receiving module 2102 is used to receive the information carried on the PUSCH;

[0620] The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

[0621] In this way, the information transmission between the device (e.g., UE) and the node (e.g., base station) is unified under the PUSCH transmission framework, eliminating the PUCCH transmission and avoiding the multiplexing process of multiplexing the UCI of the PUCCH of different services together. Therefore, the device can transmit all its relevant information (i.e., device trigger information and non-device trigger information) to the node in a timely manner through the PUSCH.

[0622] In one specific implementation, the device trigger information includes at least one or more of the following types:

[0623] The beam status information of the device is used to indicate the beam status of the device;

[0624] The buffer status information of the device is used to indicate the amount of data in the buffer of the device;

[0625] The suggested beam information of the device is used to indicate the suggested beam of the device;

[0626] The limited beam information of the device is used to indicate the limited beam of the device;

[0627] The device's recommended power information is used to indicate the device's recommended transmission power;

[0628] The speed change information of the device is used to indicate the degree of change in the device's moving speed;

[0629] The information on the change in the movement direction of the device is used to indicate the degree of change in the movement direction of the device;

[0630] The environmental change information of the device is used to indicate the current environment in which the device is located.

[0631] In one specific implementation, a type of device trigger information corresponds to a first index number, or a combination of types corresponds to a first index number; the first correspondence between each first index number and a type of device trigger information or a combination of types is predefined by the protocol; the combination of types includes multiple types of device trigger information.

[0632] In one specific embodiment, the device further includes:

[0633] The second configuration module is used to indicate or configure index information to the device. The index information is: a first index number corresponding to each type of device trigger information, or a first index number corresponding to each type combination; the type combination includes multiple types of device trigger information.

[0634] In one specific embodiment, the device further includes:

[0635] The third receiving module is used to receive the type of device triggering information carried on the PUSCH; or to receive the accompanying reference signal of the PUSCH, parse the accompanying reference signal of the PUSCH to obtain the type of device triggering information, wherein different sequences of the accompanying reference signal represent different types of device triggering information.

[0636] In one specific implementation, the parameter configured or indicated by the node to the device corresponding to the beam state information of the device is a first parameter, and the first parameter includes at least one of the following:

[0637] Trigger the event;

[0638] Beam count configuration;

[0639] The triggering event includes at least one of the following:

[0640] The current beam quality is below the threshold;

[0641] At least one new beam has a higher quality than the current beam;

[0642] At least one new beam has a higher quality than the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node;

[0643] The number of beams configuration includes at least one of the following:

[0644] The first beam number configuration indicates that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax;

[0645] The second beam count configuration instructs the device to report the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and Nmax-N redundant bits corresponding to beams that do not satisfy the trigger event, where N is a positive integer between 1 and Nmax.

[0646] The third beam number configuration indicates that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax;

[0647] The fourth beam quantity configuration indicates that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node;

[0648] The fifth beam number configuration indicates that the device reports the status information of one beam that satisfies the trigger event;

[0649] Nmax is configured by the node.

[0650] In one specific implementation, the parameter corresponding to the buffer status information of the device configured or indicated by the node to the device is a second parameter. The second parameter includes: multiple data volume thresholds and a second index number corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number.

[0651] The parameter corresponding to the suggested power information of the device configured or indicated by the node to the device is a third parameter, which includes: multiple power thresholds and third index numbers corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number;

[0652] The parameter corresponding to the speed change information of the device configured or indicated by the node to the device is the fourth parameter. The fourth parameter includes: multiple speed thresholds and fourth index numbers corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number.

[0653] The parameter corresponding to the movement direction change information of the device configured or indicated by the node to the device is the fifth parameter. The fifth parameter includes: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number.

[0654] The parameter corresponding to the environmental change information of the device configured or indicated by the node to the device is the sixth parameter. The sixth parameter includes: multiple environmental information and the sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

[0655] In one specific embodiment, the device further includes:

[0656] The third sending module is used to send PUSCH format configuration information to the device;

[0657] The PUSCH format configuration information includes any of the following:

[0658] The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH.

[0659] The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner and the PUSCH carries the uplink shared channel UL-SCH.

[0660] The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode and the PUSCH does not carry UCI.

[0661] In one specific embodiment, the device further includes:

[0662] The fourth sending module is used to send bearer configuration information to the device. The bearer configuration information is used to indicate whether the bearer mode of the trigger information carried on the PUSCH for each type of device is UCI mode, MAC CE mode, or a mixture of UCI and MAC CE.

[0663] In one specific embodiment, the device further includes:

[0664] The fifth sending module is used to send UL scheduling DCI, wherein the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a mixed mode of UCI and MAC CE.

[0665] The UL scheduling DCI carries at least one of the following fields:

[0666] The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback.

[0667] The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

[0668] In one specific embodiment, the device further includes:

[0669] The fourth configuration module is used to instruct or configure at least one of the following to the device:

[0670] Maximum bitrate;

[0671] The priority of different information carried on the PUSCH;

[0672] The priority is used to: report the order of different information that needs to be carried on the PUSCH when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate; or to trigger the device to send a resource request to the node when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate.

[0673] The first allocation module is configured to allocate transmission resources to the device upon receiving the resource request, so that the device can transmit at least one of device trigger information and non-device trigger information on the PUSCH.

[0674] In one specific implementation, if the transmission resources configured for the node are insufficient to transmit information carried on the PUSCH, the apparatus further includes:

[0675] The fourth receiving module is used to receive resource requests carried on the PUSCH; or to receive the accompanying reference signal of the PUSCH and parse the accompanying reference signal of the PUSCH to obtain the number of transmission resources requested by the device, wherein different sequences of the accompanying reference signal represent different numbers of transmission resources.

[0676] The second allocation module is used to allocate transmission resources to the device so that the device can transmit at least one of device trigger information and non-device trigger information on the PUSCH.

[0677] In one specific embodiment, the device further includes:

[0678] The fifth receiving module is used to receive and parse the first part of UCI to obtain the actual resource information used by the device. The actual resource information represents the transmission resources actually used by the information carried on the PUSCH.

[0679] In one specific embodiment, the device further includes at least one of the following:

[0680] The sixth receiving module is used to indicate or configure multiple frequency units to the device and receive the frequency unit number corresponding to the device trigger information carried on the PUSCH.

[0681] The seventh receiving module is used to indicate or configure multiple carriers to the device and receive carrier numbers corresponding to the device triggering information carried on the PUSCH;

[0682] The eighth receiving module is used to indicate or configure multiple serving cells to the device and to receive the serving cell number corresponding to the device triggering information carried on the PUSCH.

[0683] In one specific embodiment, the device further includes:

[0684] The fifth configuration module is used to indicate or configure information logical channel ID information to the device, wherein the information logical channel ID information is: the information logical channel ID corresponding to each type of device trigger information;

[0685] The third determining module is used to determine multiple types of device triggering information based on multiple information logical channel IDs in the uplink shared channel UL-SCH.

[0686] In one specific embodiment, the device further includes:

[0687] The first parsing module is used to parse the received device trigger information to obtain at least one of the following:

[0688] The ID configured for the number of beams used by the device;

[0689] The ID of the triggering event satisfied by at least one beam of the device;

[0690] The beam reported by the device includes the following information: the measurement resource number of the beam reported by the device; the measurement results corresponding to the measurement resources with different numbers;

[0691] The device triggering information includes at least the following fields:

[0692] The beam count configuration ID field indicates the ID of the beam count configuration used by the device;

[0693] The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device;

[0694] The beam report field indicates the following information about the beam reported by the device:

[0695] The measurement resource number of the beam reported by the device;

[0696] Measurement results corresponding to measurement resources with different numbers.

[0697] In one specific embodiment, the device further includes:

[0698] The second parsing module is used to parse the received device trigger information to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID;

[0699] The device triggering information includes at least the following fields:

[0700] The Logical Channel Group ID field is used to indicate the ID of the logical channel group;

[0701] The index field indicates the index number of the cached data corresponding to the logical channel group.

[0702] In one specific embodiment, the device further includes:

[0703] The third parsing module is used to parse the received device trigger information to obtain at least one of the following:

[0704] The parameters of the RRC configuration and the ResourceConfigID;

[0705] The number of beam IDs suggested by the device, or the number of beam IDs restricted by the device;

[0706] The resource set ID associated with the suggested or restricted beam of the device;

[0707] Does the Idi bit in the Number of cell configurations exist?

[0708] The number of cell configurations associated with the beam indicated by Resource set IDi;

[0709] The MAC CE data packet includes at least the following fields:

[0710] Resource Configuration ID, used to indicate the RRC configuration and the parameters of the ResourceConfigID;

[0711] Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to;

[0712] Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device;

[0713] The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present.

[0714] Cell in-situ identifier, used to indicate the number of cell configurations associated with the Resource set IDi indicated beam.

[0715] In one specific embodiment, the device further includes:

[0716] The sixth configuration module is used to indicate or configure UCI configuration information to the device;

[0717] The first decoding module is used to decode the information carried on the PUSCH according to the UCI configuration information; or to decode the received first part of the UCI in a first decoding method according to the UCI configuration information, and to decode the received second part of the UCI in a second decoding method.

[0718] In one specific embodiment, the device further includes:

[0719] The seventh configuration module is used to indicate or configure filling position information to the device, and different filling positions correspond to different types of device trigger information;

[0720] The fourth parsing module is used to parse the information at all the filling positions in the received first part of the UCI to obtain the device triggering information that meets the triggering conditions.

[0721] In one specific embodiment, the device further includes:

[0722] The fifth parsing module is used to parse the received first part of the UCI to obtain the type of device triggering information that meets the triggering conditions;

[0723] The sixth parsing module is used to parse the information at the filling position corresponding to the device trigger information that meets the trigger conditions in the received second part of UCI according to the type of device trigger information that meets the trigger conditions, so as to obtain the device trigger information that meets the trigger conditions.

[0724] In one specific embodiment, the device further includes:

[0725] The seventh parsing module is used to parse the first part of the received UCI to obtain the ID of the number of beams configured by the device and the ID of the corresponding trigger event, and to parse the second part of the received UCI to obtain the beam status information; or, to parse the first part of the received UCI to obtain the ID of the corresponding trigger event, and to parse the second part of the received UCI to obtain the beam status information.

[0726] In one specific embodiment, the device further includes:

[0727] The eighth parsing module is used to parse the received first part of UCI or the second part of UCI to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID.

[0728] In one specific embodiment, the device further includes:

[0729] The ninth parsing module is used to parse the first part of the received UCI to obtain the resource configuration ID, number of beams, and cell in-situ identifier, and to parse the second part of the received UCI to obtain the beam type ID, associated resource set ID, and associated cell number.

[0730] In one specific embodiment, the device further includes:

[0731] The tenth parsing module is used to parse the received first part or second part of UCI to obtain any of the following: the device's suggested beam information, the device's restricted beam information, the device's suggested power information, the device's speed change information, the device's movement direction change information, and the device's environmental change information.

[0732] In one specific embodiment, the device further includes:

[0733] The eighth configuration module is used to indicate or configure the transmission period to the device;

[0734] The first receiving module is further configured to receive non-device triggering information carried on the PUSCH according to the transmission period.

[0735] In one specific embodiment, the device further includes:

[0736] The ninth configuration module is used to configure or instruct the device to determine the information to be transmitted, wherein the information to be transmitted determination rule is used to determine the information to be transmitted from the device trigger information and the non-device trigger information when there is a time domain overlap between the device trigger information and the non-device trigger information.

[0737] In one specific implementation, the rule for determining the information to be transmitted includes any of the following:

[0738] Transmit the non-device trigger information carried on the first PUSCH and discard the device trigger information carried on the second PUSCH;

[0739] Transmit the device trigger information carried on the second PUSCH and discard the non-device trigger information carried on the first PUSCH;

[0740] According to the priority of the first PUSCH and the second PUSCH, transmit one of the non-device trigger information and the non-device trigger information;

[0741] The non-device trigger information and the device trigger information are merged and then transmitted on the first PUSCH.

[0742] The non-device trigger information and the device trigger information are merged and then transmitted on the second PUSCH.

[0743] The device trigger information transmission apparatus provided in this application embodiment can implement the various processes implemented in the device trigger information transmission method embodiment provided in the second aspect above, and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0744] As shown in Figure 22, this application embodiment also provides a communication device 2200, including a processor 2201 and a memory 2202. The memory 2202 stores a program or instructions that can run on the processor 2201. For example, when the communication device 2200 is a terminal, when the program or instructions are executed by the processor 2201, they implement the various steps of the above-mentioned device trigger information transmission method embodiment and achieve the same technical effect. When the communication device 2200 is a network-side device, when the program or instructions are executed by the processor 2201, they implement the various steps of the above-mentioned device trigger information transmission method embodiment and achieve the same technical effect. To avoid repetition, this will not be described again here.

[0745] This application also provides a device including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the steps in the method embodiment shown in FIG3. This device embodiment corresponds to the above-described device-side method embodiment, and all implementation processes and methods of the above-described method embodiments can be applied to this device embodiment and can achieve the same technical effect. This device may be the device trigger information transmission device shown in FIG20. Specifically, FIG23 is a schematic diagram of the hardware structure of a device implementing an embodiment of this application.

[0746] The device 2300 includes, but is not limited to, at least some of the following components: radio frequency unit 2301, network module 2302, audio output unit 2303, input unit 2304, sensor 2305, display unit 2306, user input unit 2307, interface unit 2308, memory 2309, and processor 2310.

[0747] Those skilled in the art will understand that device 2300 may also include a power supply (such as a battery) for powering various components. The power supply may be logically connected to processor 2310 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. The device structure shown in Figure 23 does not constitute a limitation on the device. 23 may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0748] It should be understood that, in this embodiment, the input unit 2304 may include a graphics processor 23041 and a microphone 23042. The graphics processor 23041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 2306 may include a display panel 23061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 2307 includes at least one of a touch panel 23071 and other input devices 23072. The touch panel 23071 is also called a touch screen. The touch panel 23071 may include a touch detection device and a touch controller. Other input devices 23072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0749] In this embodiment, after receiving downlink data from the network-side device, the radio frequency unit 2301 can transmit it to the processor 2310 for processing; in addition, the radio frequency unit 2301 can send uplink data to the network-side device. Typically, the radio frequency unit x01 includes, but is not limited to, antennas, amplifiers, transceivers, couplers, low-noise amplifiers, duplexers, etc.

[0750] The memory 2309 can be used to store software programs or instructions, as well as various data. The memory 2309 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory x09 may include volatile memory or non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 2309 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0751] Processor 2310 may include one or more processing units; optionally, processor 2310 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 2310.

[0752] The radio frequency unit 2301 is used for the device to transmit at least one of device trigger information and non-device trigger information on the Physical Uplink Shared Channel (PUSCH); wherein the device trigger information is triggered based on the device's status information; and the non-device trigger information is triggered based on the node's configuration or instruction to the device.

[0753] In this way, the information transmission between devices and nodes is unified under the PUSCH transmission framework, eliminating the PUCCH transmission and avoiding the multiplexing process of UCI multiplexing of PUCCH for different services. As a result, devices can transmit all their relevant information to nodes in a timely manner through PUSCH.

[0754] It is understood that the implementation process of each implementation method mentioned in this embodiment can refer to the relevant description of the device trigger information transmission method in the method embodiment, and achieve the same or corresponding technical effects. To avoid repetition, it will not be described again here.

[0755] This application also provides a network-side device, including a processor and a communication interface. The communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the steps of the method embodiment shown in FIG. XXX. This network-side device embodiment corresponds to the above-described network-side device method embodiment. All implementation processes and methods of the above-described method embodiments can be applied to this network-side device embodiment and achieve the same technical effects.

[0756] This application embodiment also provides a node. As shown in FIG24, the node 2400 includes: a processor 2401, a network interface 2402, and a memory 2403. The network-side device may be the device trigger information transmission device shown in FIG21. The network interface 2402 is, for example, a common public radio interface (CPRI).

[0757] The network interface 2402 is used to configure transmission resources for the device, the transmission resources being used to transmit information carried on the PUSCH and to receive the information carried on the PUSCH; wherein the information carried on the PUSCH includes at least one of device trigger information and non-device trigger information; the device trigger information is triggered based on the device's status information; the non-device trigger information is triggered based on the node's configuration or instruction to the device.

[0758] In addition, node 2400 in this embodiment of the application also includes: a program or instructions stored in memory 2403 and executable on processor 2401. Processor 2401 calls the program or instructions in memory 2403 to execute the steps of the various methods shown in FIG19 and achieve the same technical effect. To avoid repetition, it will not be described in detail here.

[0759] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described device trigger information transmission method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0760] The processor mentioned above is either the processor in the device described in the above embodiments or the processor in the network-side device. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0761] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device trigger information transmission method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0762] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0763] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described device trigger information transmission method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0764] This application also provides a device trigger information transmission system, including: a device and a node, wherein the device can be used to perform the steps of the device-side method as described above, and the network-side device can be used to perform the steps of the node-side method as described above.

[0765] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0766] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.), and the computer software product includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0767] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. A method for transmitting device trigger information, wherein, include: The device transmits at least one of device trigger information and non-device trigger information on the Physical Uplink Shared Channel (PUSCH). The device triggering information is triggered based on the device's status information; The non-device triggering information is triggered based on the node's configuration or instructions to the device.

2. The method according to claim 1, wherein, The device trigger information includes at least one or more of the following types: The beam status information of the device is used to indicate the beam status of the device; The buffer status information of the device is used to indicate the amount of data in the buffer of the device; The suggested beam information of the device is used to indicate the suggested beam of the device; The limited beam information of the device is used to indicate the limited beam of the device; The device's recommended power information is used to indicate the device's recommended transmission power; The speed change information of the device is used to indicate the degree of change in the device's moving speed; The information on the change in the movement direction of the device is used to indicate the degree of change in the movement direction of the device; The environmental change information of the device is used to indicate the current environment in which the device is located.

3. The method according to claim 2, wherein, A device trigger information of one type corresponds to a first index number, or a combination of types corresponds to a first index number; The first correspondence between each first index number and a type of device trigger information or a combination of types is indicated by the node to the device, configured by the node for the device, or is predefined by the protocol; The type combination includes multiple types of device trigger information.

4. The method according to claim 2, wherein, The method further includes: The device transmits the device trigger information by carrying the type of the device trigger information on the PUSCH; or The device transmits the device trigger information by carrying the type of the device trigger information on the accompanying reference signal of the PUSCH, and the different sequences of the accompanying reference signal represent different types of device trigger information.

5. The method according to claim 2, wherein, The parameter corresponding to the beam status information of the device configured or indicated by the node is a first parameter, and the first parameter includes at least one of the following: Trigger the event; Beam count configuration; The triggering event includes at least one of the following: The current beam quality is below the threshold; At least one new beam has a higher quality than the current beam; At least one new beam has a higher quality than the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node; The number of beams configuration includes at least one of the following: The first beam number configuration indicates that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax; The second beam count configuration instructs the device to report the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and Nmax-N redundant bits corresponding to beams that do not satisfy the trigger event, where N is a positive integer between 1 and Nmax. The third beam number configuration indicates that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax; The fourth beam quantity configuration indicates that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node; The fifth beam number configuration indicates that the device reports the status information of one beam that satisfies the trigger event; Nmax is configured by the node.

6. The method according to claim 2, wherein, The parameter corresponding to the buffer status information of the device configured or indicated by the node to the device is the second parameter. The second parameter includes: multiple data volume thresholds and second index numbers corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number. The parameter corresponding to the suggested power information of the device configured or indicated by the node to the device is a third parameter, which includes: multiple power thresholds and third index numbers corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number; The parameter corresponding to the speed change information of the device configured or indicated by the node to the device is the fourth parameter. The fourth parameter includes: multiple speed thresholds and fourth index numbers corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number. The parameter corresponding to the movement direction change information of the device configured or indicated by the node to the device is the fifth parameter. The fifth parameter includes: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number. The parameter corresponding to the environmental change information of the device configured or indicated by the node to the device is the sixth parameter. The sixth parameter includes: multiple environmental information and the sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

7. The method according to claim 1, wherein, The device transmits the device trigger information carried on the PUSCH, including: When the device trigger information meets the triggering conditions, the device will transmit the device trigger information that meets the triggering conditions by carrying it on the PUSCH.

8. The method according to claim 1, wherein, The device triggering information is carried on the PUSCH in any of the following ways: Media Access Control (MAC) control element in CE mode; Uplink control information (UCI) method; A hybrid approach combining UCI and MAC CE.

9. The method according to claim 1, wherein, The method further includes: The device acquires PUSCH format configuration information; The device transmits the device trigger information carried on the PUSCH, including: The device carries the device trigger information on the PUSCH according to the PUSCH format configuration information; The PUSCH format configuration information includes any of the following: The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH; The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH carries UL-SCH; The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode, and the PUSCH does not carry UCI.

10. The method according to claim 2, wherein, The method further includes: The device obtains bearer configuration information, which is used to indicate whether the bearer method of each type of device trigger information carried on the PUSCH is UCI, MAC CE, or a mixture of UCI and MAC CE. The device transmits the device trigger information carried on the PUSCH, including: The device is configured with information according to the bearer mode, and the device trigger information is transmitted on the PUSCH.

11. The method according to claim 2, wherein, The method further includes: The device receives a UL scheduling DCI, in which the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a hybrid of UCI and MAC CE. The device transmits the device trigger information carried on the PUSCH, including: The device transmits its trigger information on the PUSCH according to the UL scheduling DCI. The UL scheduling DCI carries at least one of the following fields: The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback. The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

12. The method according to claim 1, wherein, The method further includes: The device determines the bit rate of the information that needs to be carried on the PUSCH; If the bit rate exceeds the maximum bit rate configured or indicated by the node, the device reports the information that needs to be carried on the PUSCH in descending order of priority, or the device sends a resource request to the node.

13. The method according to claim 1, wherein, If the transmission resources configured on the node are insufficient to transmit the information carried on the PUSCH, the method further includes: The device sends a resource request to the node; The device transmits resource requests on the PUSCH; or The device transmits the resource request on the accompanying reference signal of the PUSCH, and uses different sequences of the accompanying reference signal to represent different amounts of transmission resources requested. The resource request is used to request the node to allocate transmission resources for the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

14. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a MAC CE manner, the method further includes: The device adds actual resource usage information to the first part of the UCI and sends it to the node. The actual resource usage information represents the transmission resources actually used to transmit information carried on the PUSCH.

15. The method according to claim 1, wherein, The device transmits the device trigger information on the PUSCH, including: When the device is configured with multiple frequency units, the device transmits the device trigger information and the corresponding frequency unit number on the PUSCH. When the device is configured with multiple carriers, the device transmits the device trigger information and the corresponding carrier number on the PUSCH. When the device is configured with multiple serving cells, the device transmits the device trigger information and the corresponding serving cell number on the PUSCH.

16. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in MAC CE mode, the device transmits the device trigger information on the PUSCH, including: The device fills the uplink shared channel UL-SCH with the different types of device trigger information according to the logical channel ID corresponding to the different types of device trigger information, and then transmits the filled UL-SCH on the PUSCH.

17. The method according to claim 8, wherein, When the device triggering information is carried on the PUSCH in the MAC CE mode and the type of the device triggering information is beam status information, the device triggering information includes at least the following fields: The beam count configuration ID field indicates the ID of the beam count configuration used by the device; The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device; The beam report field indicates the following information about the beam reported by the device: The measurement resource number of the beam reported by the device; Measurement results corresponding to measurement resources with different numbers.

18. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in MAC CE mode and the type of the device trigger information is buffer status information, the device trigger information includes at least the following fields: The Logical Channel Group ID field is used to indicate the ID of the logical channel group; The index field indicates the index number of the cached data corresponding to the logical channel group.

19. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in the MAC CE mode, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the device trigger information shall include at least the following fields: Resource Configuration ID, used to indicate the parameters of Radio Resource Control (RRC) configuration and the Resource Configuration ID; Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to; Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device; The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present. The number of cell configuration identifiers indicates the number of cell configurations associated with the Resource set IDi indicated beam.

20. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a UCI manner, the method further includes: The device acquires UCI configuration information; The device encodes the information to be reported as a whole based on the UCI configuration information to obtain the information carried on the PUSCH; or The device divides the information to be reported into a first part of UCI and a second part of UCI according to the UCI configuration information, encodes the first part of UCI with a first encoding method and encodes the second part of UCI with a second encoding method to obtain the information carried on the PUSCH.

21. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a UCI manner, the method further includes: The device fills the device trigger information that meets the triggering conditions into the corresponding positions according to the configured filling position information, and fills the positions corresponding to the device trigger information that does not meet the triggering conditions with redundant bits.

22. The method according to claim 21, wherein, The method further includes: The device uses the device trigger information that meets the triggering conditions and the filled redundant bits as the first part of the UCI.

23. The method according to claim 21, wherein, When the device trigger information is carried in the PUSCH in a UCI manner, the method further includes: The device uses the type of device trigger information that meets the triggering conditions as the first part of the UCI, and uses the device trigger information that meets the triggering conditions as the second part of the UCI.

24. The method according to claim 8, wherein, When the device triggering information is carried on the PUSCH in a UCI manner and the type of the device triggering information is beam status information, the method further includes: The device uses the ID of the number of beams used by the device and the ID of the corresponding trigger event as the first part of the UCI, and the beam status information as the second part of the UCI; or, the device uses the ID of the corresponding trigger event as the first part of the UCI and the beam status information as the second part of the UCI.

25. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a UCI manner and the type of the device trigger information is buffer status information, the device transmits the device trigger information carried on the PUSCH, including: The device uses the ID of the logical channel group and the index number of the data cached in the logical channel group as the first part of the UCI or as the second part of the UCI, and transmits information containing at least the first part of the UCI or the second part of the UCI on the PUSCH.

26. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a UCI manner, and the type of the device trigger information is the device's suggested beam information or the device's restricted beam information, the method further includes: The device uses the resource configuration ID, number of beams, and cell in-situ identifier as the first part of the UCI, and the beam type ID, associated resource set ID, and associated cell number as the second part of the UCI.

27. The method according to claim 8, wherein, When the device trigger information is carried on the PUSCH in a UCI manner, the method further includes: The device may use any one of the following as the first part of the UCI: the device's proposed beam information, the device's restricted beam information, the device's proposed power information, the device's speed change information, the device's movement direction change information, or the device's environmental change information.

28. The method according to claim 1, wherein, The device transmits the non-device-triggered information on the PUSCH, including: The device transmits the non-device-triggered information on the PUSCH according to the configured transmission period or the node indication.

29. The method according to claim 1, wherein, In the event of temporal overlap between the device trigger information and the non-device trigger information, the method further includes: The device determines the information to be transmitted from the device trigger information and the non-device trigger information according to the instructions or configuration of the node, or according to predefined rules; The device transmits at least one of device trigger information and non-device trigger information on the PUSCH, including: The device carries the information to be transmitted on the PUSCH for transmission.

30. The method according to claim 29, wherein, When the non-device-triggered information is carried on the first PUSCH and the device-triggered information is carried on the second PUSCH, the device transmits the information to be transmitted on the PUSCH, including any of the following: The device transmits the non-device trigger information carried on the first PUSCH and discards the device trigger information carried on the second PUSCH; The device transmits the device trigger information carried on the second PUSCH and discards the non-device trigger information carried on the first PUSCH; The device transmits one of the non-device trigger information and the non-device trigger information according to the priority of the first PUSCH and the second PUSCH. The device merges the non-device trigger information and the device trigger information, and transmits the merged information on the first PUSCH or on the second PUSCH.

31. A method for transmitting device trigger information, wherein, include: The node configures transmission resources for the device, which are used to transmit information carried on the PUSCH. The node receives the information carried on the PUSCH; The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

32. The method according to claim 31, wherein, The device trigger information includes at least one or more of the following types: The beam status information of the device is used to indicate the beam status of the device; The buffer status information of the device is used to indicate the amount of data in the buffer of the device; The suggested beam information of the device is used to indicate the suggested beam of the device; The limited beam information of the device is used to indicate the limited beam of the device; The device's recommended power information is used to indicate the device's recommended transmission power; The speed change information of the device is used to indicate the degree of change in the device's moving speed; The information on the change in the movement direction of the device is used to indicate the degree of change in the movement direction of the device; The environmental change information of the device is used to indicate the current environment in which the device is located.

33. The method according to claim 32, wherein, A device trigger information of one type corresponds to a first index number, or a combination of types corresponds to a first index number; The first correspondence between each first index number and a type of device trigger information or a combination of types is predefined by the protocol; the combination of types includes multiple types of device trigger information.

34. The method according to claim 32, wherein, The method further includes: The node indicates or configures index information to the device, wherein the index information is: a first index number corresponding to each type of device trigger information, or a first index number corresponding to each type combination; wherein a type combination includes multiple types of device trigger information.

35. The method according to claim 32, wherein, The method further includes: The node receives the type of device trigger information carried on the PUSCH; or The node receives the accompanying reference signal of the PUSCH, parses the accompanying reference signal of the PUSCH to obtain the type of the device triggering information, wherein different sequences of the accompanying reference signal represent different types of device triggering information.

36. The method according to claim 32, wherein, The parameter corresponding to the beam status information of the device configured or indicated by the node is a first parameter, and the first parameter includes at least one of the following: Trigger the event; Beam count configuration; The triggering event includes at least one of the following: The current beam quality is below the threshold; At least one new beam has a higher quality than the current beam; At least one new beam has a higher quality than the beam in the reference signal RS associated with the Qth activated TCI state, where Q is configured by the node; The number of beams configuration includes at least one of the following: The first beam number configuration indicates that the device reports the status information of M beams that satisfy the triggering event, where M is a positive integer between 1 and Nmax; The second beam count configuration instructs the device to report the status information of Nmax beams. The status information of Nmax beams includes: the status information of N beams that satisfy the trigger event, and Nmax-N redundant bits corresponding to beams that do not satisfy the trigger event, where N is a positive integer between 1 and Nmax. The third beam number configuration indicates that the device reports the status information of O beams, at least one of the O beams satisfies the trigger event, and O is a positive integer between 1 and Nmax; The fourth beam quantity configuration indicates that the device reports the status information of P beams, at least one of the P beams satisfies the trigger event, and P is configured by the node; The fifth beam number configuration indicates that the device reports the status information of one beam that satisfies the trigger event; Nmax is configured by the node.

37. The method according to claim 32, wherein, The parameter corresponding to the buffer status information of the device configured or indicated by the node to the device is the second parameter. The second parameter includes: multiple data volume thresholds and second index numbers corresponding to the multiple data volume thresholds, wherein one data volume threshold corresponds to one second index number. The parameter corresponding to the suggested power information of the device configured or indicated by the node to the device is a third parameter, which includes: multiple power thresholds and third index numbers corresponding to the multiple power thresholds, wherein one power threshold corresponds to one third index number; The parameter corresponding to the speed change information of the device configured or indicated by the node to the device is the fourth parameter. The fourth parameter includes: multiple speed thresholds and fourth index numbers corresponding to the multiple speed thresholds, wherein one speed threshold corresponds to one fourth index number. The parameter corresponding to the movement direction change information of the device configured or indicated by the node to the device is the fifth parameter. The fifth parameter includes: multiple movement direction change thresholds and the fifth index number corresponding to the multiple movement direction change thresholds, wherein one movement direction change threshold corresponds to one fifth index number. The parameter corresponding to the environmental change information of the device configured or indicated by the node to the device is the sixth parameter. The sixth parameter includes: multiple environmental information and the sixth index number corresponding to the multiple environmental information, wherein one environmental information corresponds to one sixth index number.

38. The method according to claim 31, wherein, The method further includes: The node sends PUSCH format configuration information to the device; The PUSCH format configuration information includes any of the following: The first format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH does not carry the uplink shared channel UL-SCH; The second format is used to instruct the device to carry the device trigger information on the PUSCH in a UCI manner, and the PUSCH carries the uplink shared channel UL-SCH; The third format is used to instruct the device to carry the device trigger information on the PUSCH in MAC CE mode, and the PUSCH does not carry UCI.

39. The method according to claim 32, wherein, The method further includes: The node sends bearer configuration information to the device. The bearer configuration information is used to indicate whether the bearer method for each type of device trigger information carried on the PUSCH is UCI, MAC CE, or a combination of UCI and MAC CE.

40. The method according to claim 32, wherein, The method further includes: The node sends a UL scheduling DCI, in which the UL scheduling DCI indicates that at least one type of device trigger information is carried on the PUSCH in a UCI mode, or a MAC CE mode, or a hybrid of UCI and MAC CE. The UL scheduling DCI carries at least one of the following fields: The device trigger information feedback field is used to indicate the type of device trigger information that the node requests the device to provide feedback. The feedback mode indication field is used to indicate whether the transmission mode of at least one type of device trigger information carried on the PUSCH is UCI mode, MAC CE mode, or a combination of UCI and MAC CE.

41. The method according to claim 31, wherein, The method further includes: The node instructs or configures at least one of the following to the device: Maximum bitrate; The priority of different information carried on the PUSCH; The priority is used to: report the order of different information that needs to be carried on the PUSCH when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate; or to trigger the device to send a resource request to the node when the bit rate of the information that the device needs to carry on the PUSCH exceeds the maximum bit rate. Upon receiving the resource request, the node allocates transmission resources to the device so that the device can transmit at least one of the device trigger information and non-device trigger information on the PUSCH.

42. The method according to claim 31, wherein, If the transmission resources configured on the node are insufficient to transmit the information carried on the PUSCH, the method further includes: The node receives resource requests carried on the PUSCH; or The node receives the accompanying reference signal of the PUSCH and parses the accompanying reference signal of the PUSCH to obtain the number of transmission resources requested by the device, wherein different sequences of the accompanying reference signal represent different numbers of transmission resources. The node allocates transmission resources to the device so that the device can transmit at least one of device trigger information and non-device trigger information on the PUSCH.

43. The method according to claim 31, wherein, The method further includes: The node receives and parses the first part of the UCI to obtain the actual resource usage information of the device. The actual resource usage information represents the transmission resources actually used by the information carried on the PUSCH.

44. The method according to claim 31, wherein, The method further includes at least one of the following: The node indicates or configures multiple frequency units to the device, and the node receives frequency unit numbers corresponding to the device triggering information carried on the PUSCH. The node indicates or configures multiple carriers to the device, and the node receives carrier numbers corresponding to the device triggering information carried on the PUSCH. The node indicates or configures multiple serving cells to the device, and the node receives the serving cell number corresponding to the device triggering information carried on the PUSCH.

45. The method according to claim 31, wherein, The method further includes: The node indicates or configures information logical channel ID information to the device, wherein the information logical channel ID information is: the information logical channel ID corresponding to each type of device trigger information; The node determines multiple types of device trigger information based on multiple information logical channel IDs in the uplink shared channel UL-SCH.

46. ​​The method according to any one of claims 31-45, wherein, The method further includes: The node parses the received device trigger information and obtains at least one of the following: The ID configured for the number of beams used by the device; The ID of the triggering event satisfied by at least one beam of the device; The beam reported by the device includes the following information: the measurement resource number of the beam reported by the device; the measurement results corresponding to the measurement resources with different numbers; The device triggering information includes at least the following fields: The beam count configuration ID field indicates the ID of the beam count configuration used by the device; The trigger event ID field is used to indicate the ID of a trigger event satisfied by at least one beam of the device; The beam report field indicates the following information about the beam reported by the device: The measurement resource number of the beam reported by the device; Measurement results corresponding to measurement resources with different numbers.

47. The method according to any one of claims 31-41, wherein, The method further includes: The node parses the received device trigger information to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID; The device triggering information includes at least the following fields: The Logical Channel Group ID field is used to indicate the ID of the logical channel group; The index field indicates the index number of the cached data corresponding to the logical channel group.

48. The method according to any one of claims 31-41, wherein, The method further includes: The node parses the received device trigger information and obtains at least one of the following: The parameters of the RRC configuration and the ResourceConfigID; The number of beam IDs suggested by the device, or the number of beam IDs restricted by the device; The resource set ID associated with the suggested or restricted beam of the device; Does the Idi bit in the Number of cell configurations exist? The number of cell configurations associated with the beam indicated by Resource set IDi; The device triggering information includes at least the following fields: Resource Configuration ID, used to indicate the RRC configuration and the parameters of the ResourceConfigID; Beam count, used to indicate the number of beam IDs suggested by the device, or to indicate the number of beam IDs that the device is limited to; Beam type ID, used to indicate the resource set ID associated with the proposed or restricted beam of the device; The cell presence identifier is used to indicate whether the Number of cell configurations Idi bit is present. Cell in-situ identifier, used to indicate the number of cell configurations associated with the Resource set IDi indicated beam.

49. The method according to claim 31, wherein, The method further includes: The node indicates or configures UCI configuration information to the device; The node decodes the information carried on the PUSCH according to the UCI configuration information; or The node decodes the received first part of the UCI using a first decoding method and the received second part of the UCI using a second decoding method, based on the UCI configuration information.

50. The method according to claim 31, wherein, The method further includes: The node indicates or configures the filling position information to the device, and different filling positions correspond to different types of device trigger information. The node parses the information at all the fill positions in the received first part of the UCI to obtain the device trigger information that meets the triggering conditions.

51. The method according to claim 31, wherein, The method further includes: The node parses the first part of the received UCI to obtain the type of device trigger information that meets the triggering conditions; The node parses the information at the filling position corresponding to the device trigger information that meets the trigger conditions in the received second part of UCI according to the type of device trigger information that meets the trigger conditions, and obtains the device trigger information that meets the trigger conditions.

52. The method according to claim 31, wherein, The method further includes: The node parses the first part of the received UCI to obtain the ID of the number of beams configured by the device and the ID of the corresponding trigger event; and parses the second part of the received UCI to obtain the beam status information; or, The node parses the first part of the received UCI to obtain the ID of the corresponding trigger event, and parses the second part of the received UCI to obtain the beam status information.

53. The method according to claim 31, wherein, The method further includes: The node parses the received first part or second part of the UCI to obtain the ID of the logical channel group and the data volume threshold corresponding to the logical channel group ID.

54. The method according to claim 31, wherein, The method further includes: The node parses the first part of the received UCI to obtain the resource configuration ID, number of beams, and cell in-situ identifier. It also parses the second part of the received UCI to obtain the beam type ID, associated resource set ID, and associated cell number.

55. The method according to claim 31, wherein, The method further includes: The node parses the received first part or second part of UCI to obtain one of the following: the device's suggested beam information, the device's restricted beam information, the device's suggested power information, the device's speed change information, the device's movement direction change information, and the device's environmental change information.

56. The method according to claim 31, wherein, The method further includes: The node indicates or configures the transmission period to the device; The node receives the information carried on the PUSCH, including: The node receives non-device trigger information carried on the PUSCH according to the transmission period.

57. The method according to claim 31, wherein, The method further includes: The node configures or instructs the device to determine the information to be transmitted, and the information to be transmitted determination rule is used to determine the information to be transmitted from the device trigger information and the non-device trigger information when there is a time domain overlap between the device trigger information and the non-device trigger information.

58. The method according to claim 57, wherein, The rule for determining the information to be transmitted includes any of the following: Transmit the non-device trigger information carried on the first PUSCH and discard the device trigger information carried on the second PUSCH; Transmit the device trigger information carried on the second PUSCH and discard the non-device trigger information carried on the first PUSCH; According to the priority of the first PUSCH and the second PUSCH, transmit one of the non-device trigger information and the non-device trigger information; The non-device trigger information and the device trigger information are merged and then transmitted on the first PUSCH. The non-device trigger information and the device trigger information are merged and then transmitted on the second PUSCH.

59. A device for transmitting equipment trigger information, wherein, include: The first transmission module is used to carry at least one of device trigger information and non-device trigger information on the PUSCH for transmission; The device triggering information is triggered based on the device's status information; The non-device triggering information is triggered based on the node's configuration or instructions to the device.

60. A device for transmitting equipment trigger information, wherein, include: The first configuration module is used to configure transmission resources for the device, the transmission resources being used to transmit information carried on the PUSCH. The first receiving module is used to receive the information carried on the PUSCH; The information carried on the PUSCH includes at least one of device triggering information and non-device triggering information; the device triggering information is triggered based on the status information of the device; the non-device triggering information is triggered based on the node's configuration or instruction to the device.

61. A device, wherein, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the method for transmitting device trigger information as described in any one of claims 1 to 30.

62. A node, wherein, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the method for transmitting device trigger information as described in any one of claims 31 to 57.

63. A readable storage medium, wherein, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device trigger information transmission method as described in any one of claims 1-30, or implement the steps of the device trigger information transmission method as described in any one of claims 31-58.

Images