Communication method, apparatus, storage medium, and computer program product

Abstract

Embodiments of the present disclosure provide a communication method and apparatus. In the method, a first device transmits an uplink wake-up signal (UL WUS). The first device determines a physical uplink shared channel (PUSCH) resource, wherein the PUSCH resource is determined based on the UL WUS. The first device transmits buffer status report (BSR) information and identification information of a terminal device on the PUSCH resource. In this way, in embodiments of the present disclosure, the probability of a conflict occurring on the network side when uplink resources are scheduled based on contention can be reduced, and the success rate of decoding a report from the first device can be improved.

Description

Technical Field

[0001] This disclosure generally relates to the field of communications, and more specifically to a communication method, apparatus, computer-readable storage medium, and computer program product. Background Technology

[0002] In current communication networks, different equipment manufacturers and operators have adopted various energy-saving methods. The current overall 5G energy-saving technology system includes equipment-level, site-level, and network-level energy saving. At the equipment level, research focuses on hardware energy-saving solutions from the perspectives of device and hardware design. At the site level, research focuses on software energy-saving solutions from aspects such as symbol shutdown, channel shutdown, carrier shutdown, and deep sleep. Network-level energy-saving terminals perform intelligent energy saving from the perspective of multi-network coordination. On the other hand, in order to obtain uplink resources, terminal devices can report the status of their uplink data buffers to network devices. However, when multiple terminal devices need to obtain uplink resources, conflicts may occur on the network side. Summary of the Invention

[0003] Embodiments of this disclosure provide a communication technology solution, such as a method and apparatus for scheduling uplink resources, which can reduce the probability of network-side conflicts when scheduling uplink resources based on contention.

[0004] Firstly, a communication method is provided. The executing entity of the method provided in this disclosure can be a first device. Unless otherwise specified, the first device in this embodiment can refer to the first device itself (e.g., in some examples, it can refer to a terminal device), a module in the first device (e.g., a processor, chip, or chip system), or a logic module or software that can implement all or part of the functions of the first device. In this method, the first device sends an uplink wake-up signal UL WUS. The first device determines the physical uplink shared channel (PUSCH) resource, wherein the PUSCH resource is determined based on UL WUS. The first device sends buffer status report (BSR) information and the identification information of the terminal device on the PUSCH resource. In this way, the probability of network-side conflicts when scheduling uplink resources based on contention can be reduced, thereby improving the success rate of decoding reports from the first device.

[0005] In some exemplary embodiments, during the process of the first device determining PUSCH resources, the first device receives configuration information for at least one PUSCH resource, wherein the at least one PUSCH resource is allocated according to the UL WUS and the PUSCH resource belongs to the at least one PUSCH resource. In other exemplary embodiments, during the process of the first device determining PUSCH resources, the first device receives configuration information for the PUSCH resources, wherein the PUSCH resources are determined according to UL WUS. Therefore, PUSCH resources can be flexibly configured based on UL WUS, enabling network devices to schedule uplink resources more efficiently.

[0006] In some exemplary embodiments, there is a one-to-one correspondence between PUSCH resources and UL WUS. Therefore, after detecting UL WUS, the network device can detect the content of the PUSCH resource at the corresponding time-domain and frequency-domain resource locations.

[0007] In some exemplary embodiments, during the process of the first device determining the PUSCH resource, the first device determines the PUSCH resource based on the ULWUS system frame number, the ULWUS subframe number, the ULWUS frequency domain location, or any combination thereof. Thus, after detecting ULWUS, the network device can determine which pre-configured PUSCH resource the terminal device will use.

[0008] In some exemplary embodiments, during the process of the first device determining the PUSCH resource, the first device determines the time-domain resource of the PUSCH resource based on the timing offset between ULWUS and the PUSCH resource, and the first device determines the frequency-domain resource of the PUSCH resource based on the frequency offset between ULWUS and the PUSCH resource. Thus, after detecting ULWUS, the network device can detect the content of the PUSCH resource at the corresponding time-domain and frequency-domain resource locations of the PUSCH based on the timing offset and frequency offset.

[0009] In some exemplary embodiments, the first device further receives System Information Block 1 (SIB1) and determines PUSCH resources based on the instructions in SIB1. In this way, the network device can flexibly configure PUSCH resources for terminal devices.

[0010] In some exemplary embodiments, the BSR information includes a BSR Media Access Control Unit (MAC CE) message, and the format used for the content in the PUSCH resource is based on identification information including the UE-ID MAC CE, the Cell Radio Network Temporary Identifier (C-RNTI) MAC CE, or the Initial Radio Network Temporary Identifier (I-RNTI) MAC CE. Thus, the network device detects the corresponding UE identification information and is able to determine which UE sent the BSR information.

[0011] In some exemplary embodiments, the format used for the content in the PUSCH resource is also based on the BSR information being scrambled using a public Radio Network Temporary Identifier (RNTI), or the BSR information and identification information being scrambled using a public RNTI. This can reduce signaling overhead and resource consumption, and enhance privacy protection and anti-interference capabilities.

[0012] In some exemplary embodiments, the first device also sends a PUSCH header on the PUSCH resource, wherein the PUSCH header indicates the format used by the content in the PUSCH resource. In this way, the second device can quickly know which identification information the first device used for transmission. That is, the second device can quickly know the format used by the content in the PUSCH resource.

[0013] In some exemplary embodiments, different PUSCH resources among at least one PUSCH resources determined based on UL WUS correspond to the respective formats to be used by the content in the PUSCH resources, and the first device further selects a PUSCH resource from the at least one PUSCH resource based on the format to be used by the content in the PUSCH resource. In this way, the second device can improve resource utilization while being able to quickly determine the format used by the content in the PUSCH resource.

[0014] In some exemplary embodiments, BSR information and identification information are repeatedly transmitted, and the number of retransmissions is determined based on the size of the content in the PUSCH resource (e.g., the payload in the PUSCH resource), the quality of the channel between the terminal device and the network device, or a combination of both. This can improve the success rate of transmission on the PUSCH resource.

[0015] In some exemplary embodiments, the first device also transmits auxiliary information on the PUSCH resource, wherein the auxiliary information includes the transmit power used by the terminal device, the transmit power margin of the terminal device, the number of MIMO streams supported by the terminal device, the bandwidth supported by the terminal device, the number of carriers supported by the terminal device, the number of codewords supported by the terminal device, or any combination thereof. This helps the network device to better schedule the terminal device and speed up the data transmission preparation process. After receiving the auxiliary information, for example, the network device can estimate the path loss based on the transmit power used by the terminal device. Alternatively, the network device can adjust the transmit power of the next transmission and adjust the step size of the repeated transmission based on the transmit power margin of the terminal device.

[0016] Secondly, a communication method is provided. The execution entity of the method provided in this second aspect can be a second device. Unless otherwise specified, the second device in this embodiment can refer to the second device itself (e.g., in some examples, it can involve a network device), a module within the second device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the second device. In this method, the second device receives an uplink wake-up signal UL WUS. The second device receives buffer status report (BSR) information and terminal device identification information on the Physical Uplink Shared Channel (PUSCH) resource, wherein the PUSCH resource is determined based on UL WUS. In this way, the probability of network-side conflicts when scheduling uplink resources based on contention can be reduced, thereby improving the success rate of decoding reports from the first device.

[0017] In some exemplary embodiments, the second device further allocates at least one PUSCH resource according to UL WUS and sends configuration information for at least one PUSCH resource, wherein the PUSCH resource belongs to at least one PUSCH resource. In other exemplary embodiments, the second device further determines the PUSCH resource according to UL WUS and sends configuration information for the PUSCH resource. Thus, PUSCH resources can be flexibly configured based on UL WUS, enabling network devices to schedule uplink resources more efficiently.

[0018] In some exemplary embodiments, there is a one-to-one correspondence between PUSCH resources and UL WUS. Therefore, after detecting UL WUS, the network device can detect the content of the PUSCH resource at the corresponding time-domain and frequency-domain resource locations.

[0019] In some exemplary embodiments, the PUSCH resource is determined based on the UL WUS system frame number, the UL WUS subframe number, the UL WUS frequency domain location, or any combination thereof. Thus, after detecting UL WUS, the network device can determine which pre-configured PUSCH resource the terminal device will use.

[0020] In some exemplary embodiments, the second device further transmits a timing offset between the UL WUS and the PUSCH resource, the timing offset being used to determine the time-domain resource of the PUSCH resource, and the second device further transmits a frequency offset between the UL WUS and the PUSCH resource, the frequency offset being used to determine the frequency-domain resource of the PUSCH resource. Thus, after detecting the UL WUS, the network device can detect the content of the PUSCH resource at the corresponding time-domain and frequency-domain resource locations of the PUSCH based on the timing offset and frequency offset.

[0021] In some exemplary embodiments, the second device further transmits a system information block 1 (SIB1), wherein the indication in SIB1 specifies PUSCH resources specific to the terminal device. In this way, the network device can flexibly configure PUSCH resources for the terminal device.

[0022] In some exemplary embodiments, the BSR information includes a BSR Media Access Control Unit (MAC CE) message, and the format used for the content in the PUSCH resource is based on identification information including the UE-ID MAC CE, the Cell Radio Network Temporary Identifier (C-RNTI) MAC CE, or the Initial Radio Network Temporary Identifier (I-RNTI) MAC CE. Thus, the network device detects the corresponding UE identification information and is able to determine which UE sent the BSR information.

[0023] In some exemplary embodiments, the format used for the content in the PUSCH resource is also based on the BSR information being scrambled using a public Radio Network Temporary Identifier (RNTI), or the BSR information and identification information being scrambled using a public RNTI. This can reduce signaling overhead and resource consumption, and enhance privacy protection and anti-interference capabilities.

[0024] In some exemplary embodiments, the second device also receives a PUSCH header on the PUSCH resource, wherein the PUSCH header indicates the format used by the content in the PUSCH resource. In this way, the second device can quickly determine which identification information the first device used for transmission. That is, the second device can quickly determine the format used by the content in the PUSCH resource.

[0025] In some exemplary embodiments, different PUSCH resources in at least one PUSCH resource determined based on UL WUS correspond to the respective formats to be used by the content in the PUSCH resource, and the second device further determines the format used by the content in the PUSCH resource based on the PUSCH resource. In this way, the second device can improve resource utilization while being able to quickly know the format used by the content in the PUSCH resource.

[0026] In some exemplary embodiments, BSR information and identification information are repeatedly transmitted, and the number of retransmissions is determined based on the size of the content in the PUSCH resource (e.g., the payload in the PUSCH resource), the quality of the channel between the terminal device and the network device, or a combination of both. This can improve the success rate of transmission on the PUSCH resource.

[0027] In some exemplary embodiments, the second device also receives auxiliary information on the PUSCH resource, wherein the auxiliary information includes the transmit power used by the terminal device, the transmit power margin of the terminal device, the number of multiple-input multiple-output (MIMO) streams supported by the terminal device, the bandwidth supported by the terminal device, the number of carriers supported by the terminal device, the number of codewords supported by the terminal device, or any combination thereof. This can help the network device better schedule the terminal device and speed up the data transmission preparation process. After receiving the auxiliary information, for example, the network device can estimate the path loss based on the transmit power used by the terminal device. Alternatively, the network device can adjust the transmit power of the next transmission and adjust the step size of repeated transmissions based on the transmit power margin of the terminal device.

[0028] Thirdly, a communication apparatus is provided, including a first transmitting unit, a determining unit, and a second transmitting unit. In some embodiments, the first transmitting unit may be configured to transmit an uplink wake-up signal UL WUS, the determining unit may be configured to determine a physical uplink shared channel (PUSCH) resource, wherein the PUSCH resource is determined based on UL WUS, and the second transmitting unit may be configured to transmit buffer status report (BSR) information and terminal device identification information on the PUSCH resource.

[0029] Fourthly, a communication device is provided, including a first receiving unit and a second receiving unit. In some embodiments, the first receiving unit may be configured to receive an uplink wake-up signal UL WUS, and the second receiving unit may be configured to receive buffer status report (BSR) information and terminal device identification information on the Physical Uplink Shared Channel (PUSCH) resource, wherein the PUSCH resource is determined based on UL WUS.

[0030] The aforementioned communication device has the function of implementing the behavior in the method examples of the first or second aspect described above. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned function. The description of the first device of the first aspect or the second device of the second aspect also applies to the communication device of the third or fourth aspect; that is, the communication device of the third or fourth aspect can refer to the communication device itself, or to components within the communication device (e.g., processor, chip, or chip system), or to logic modules or software capable of implementing all or part of the functions of the communication device. In one possible design, the communication device includes a unit that performs the method of the first or second aspect or its implementations. The beneficial effects of the communication device provided in the third or fourth aspect can be found in the description of the first or second aspect, and will not be repeated here.

[0031] Fifthly, an apparatus is provided, including a processor and a memory storing a computer program or instructions, which, when executed by the processor, cause the apparatus to perform any method according to the first or second aspect and their implementations.

[0032] In a sixth aspect, a computer-readable storage medium is provided, which stores a computer program or instructions that, when executed by an electronic device, cause the electronic device to perform the methods described in the preceding aspects.

[0033] In a seventh aspect, a computer program or computer program product is provided, the computer program or computer program product including computer program instructions, which, when executed by an electronic device, cause the electronic device to perform the methods in the above aspects.

[0034] Eighthly, embodiments of this disclosure provide a chip system including a processor for implementing the functions of the apparatus in the methods of the above aspects. In one possible design, the chip system further includes a memory for storing computer programs or instructions and / or data. The chip system may be composed of chips or may include chips and other discrete devices.

[0035] In a ninth aspect, embodiments of this disclosure also provide a communication system including a second means for performing the first means of the first aspect or the method of the second aspect. Attached Figure Description

[0036] Figure 1A A schematic diagram of a standalone network communication scenario is shown.

[0037] Figure 1B A schematic diagram of a dual-connection communication scenario is shown.

[0038] Figure 1C A schematic diagram of a macro-micro communication scenario is shown.

[0039] Figure 1D A schematic diagram of a macro-micro communication scenario is shown.

[0040] Figure 2 A schematic diagram of a communication flow according to some embodiments of the present disclosure is shown.

[0041] Figure 3A A schematic diagram illustrating the association of UL WUS with PUSCH resources according to some embodiments of this disclosure is shown.

[0042] Figure 3B A schematic diagram illustrating the association of UL WUS with PUSCH resources according to some embodiments of this disclosure is shown.

[0043] Figure 4 A flowchart illustrating some embodiments of the present disclosure is shown.

[0044] Figure 5 A flowchart illustrating some embodiments of the present disclosure is shown.

[0045] Figure 6 A flowchart illustrating some embodiments of the present disclosure is shown.

[0046] Figure 7 A schematic diagram showing the identification information of a PUSCH carrying a terminal device according to some embodiments of the present disclosure is illustrated.

[0047] Figure 8 A schematic diagram showing the identification information of a PUSCH carrying a terminal device according to some embodiments of the present disclosure is illustrated.

[0048] Figure 9 A schematic diagram is shown illustrating the identification information as a terminal device identifier (UE-ID) according to some embodiments of the present disclosure.

[0049] Figure 10 A schematic diagram showing the identification information of a PUSCH carrying a terminal device according to some embodiments of the present disclosure is illustrated.

[0050] Figure 11 A schematic diagram is shown illustrating the identification information I-RNTI according to some embodiments of this disclosure.

[0051] Figure 12A A schematic diagram of a short format BSR according to some embodiments of the present disclosure is shown.

[0052] Figure 12B A schematic diagram of a long format BSR according to some embodiments of the present disclosure is shown.

[0053] Figure 13 A schematic flowchart illustrating implementation at a first device according to some embodiments of the present disclosure is shown.

[0054] Figure 14 A schematic flowchart illustrating implementation at a second device according to some embodiments of the present disclosure is shown.

[0055] Figure 15 This is a block diagram of a device that can be used to implement some embodiments of this application.

[0056] Figure 16 This is a schematic diagram of the structure of an apparatus according to some embodiments of this application.

[0057] Figure 17 This is a schematic diagram of the structure of an apparatus according to some other embodiments of this application. Detailed Implementation

[0058] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that embodiments of this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0059] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0060] Figure 1A A schematic diagram of a standalone (SA) communication scenario 100A is shown. For example... Figure 1A As shown, in the SA scenario, terminal device 102 is connected to a single network device 104, and the network device 104 connected to terminal device 102 and the core network 110 connected to network device 104 are of the same standard. For example, core network 110 is a 5G core network, and correspondingly, network device 104 is a 5G network device, and the 5G network device is directly connected to the 5G core network; or core network 110 is the core network of a future communication network, and correspondingly, network device 104 is a network device of the future communication network, and the network device of the future communication network is directly connected to the core network of the future communication network.

[0061] Figure 1B A schematic diagram of a dual connectivity (DC) communication scenario 100B is shown. (For example...) Figure 1B As shown, in the DC scenario, terminal device 102 connects simultaneously to network devices of different or the same standard. This scenario applies to connected UEs. For example, if core network 110 is a 5G core network, terminal device 102 connects simultaneously to 5G network device 104-1 and future communication network device 104-2, where 5G network device 104-1 acts as the master station and future communication network device 104-2 acts as the slave station. Alternatively, if core network 110 is the core network of future communication network, terminal device 102 connects simultaneously to 5G network device 104-1 and future communication network device 104-2, where future communication network device 104-2 acts as the master station and 5G network device 104-1 acts as the slave station. Yet another example: if core network 110 is the core network of future communication network, terminal device 102 connects simultaneously to both future communication network devices 104-1 and 104-2, meaning both the master and slave stations are network devices of the future communication network.

[0062] The above mainly describes the architecture applicable to some embodiments of this disclosure. From the perspective of scenarios, some embodiments of this disclosure are suitable for scenarios where both wide-coverage base stations and small-coverage base stations exist simultaneously, such as macro-micro communication scenarios in existing networks. Figure 1C A schematic diagram of a macro-micro communication scenario 100C is shown. Similarly, some embodiments of this disclosure also utilize macro-micro communication scenarios composed of base stations of different forms in future communication networks. Figure 1D The diagram illustrates a macro-micro communication scenario 100D, where the super station (Super BS) can take various forms, such as satellite, air balloon station, or drone station. Figure 1D The ground stations in the data can be current cellular stations (e.g., macro stations, small stations, micro stations, etc.).

[0063] Network equipment 104, 104-1, and 104-2, or Radio Access Network (RAN) equipment, can be a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system. It can also be a module or unit that performs some of the functions of a base station; for example, it can be a central unit (CU) or a distributed unit (DU). A CU can perform the functions of the base station's Radio Resource Control Protocol (RRCP) and Packet Data Convergence Protocol (PDCP), as well as the Service Data Adaptation Protocol (SDAP). A DU can perform the functions of the base station's Radio Link Control (RAN) and Medium Access Control (MAC) layers, and can also perform some or all of the physical layer functions. For detailed descriptions of the various protocol layers mentioned above, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). Radio access network equipment can be macro base stations, micro base stations, indoor stations, relay nodes, or donor nodes, etc. The embodiments disclosed herein do not limit the specific technologies or equipment forms used in the radio access network equipment.

[0064] Terminal equipment 102 can also be referred to as a terminal, user equipment (UE), mobile station, mobile terminal, etc. Terminal equipment 120 can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, wireless modem, computing device or other processing device connected to a wireless modem, augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, etc. It can also include a subscriber unit, cellular phone, smartphone, wireless data card, personal digital assistant (PDA) computer, tablet computer, netbook, handheld device, laptop computer, cordless phone or wireless local loop (WLL) station, machine type communication (MTC) terminal, or relay user equipment, etc. For example, a relay user equipment can be a residential gateway (RG).

[0065] Terminal device 102 can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, etc.

[0066] Embodiments of this disclosure may be implemented according to any suitable communication protocol, including but not limited to, third-generation (3G), fourth-generation (4G), fifth-generation (5G), or future cellular communication protocols, wireless local area network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and / or any other protocols currently known or to be developed in the future. The technical solutions of the embodiments disclosed herein are applicable to communication systems that follow any suitable communication protocol, such as: General Packet Radio Service (GPRS), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), Universal Mobile Telecommunications Service (UMTS), Long Term Evolution (LTE) systems, Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access 2000 (CDMA2000), Time Division-Synchronization Code Division Multiple Access (TD-SCDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Fifth Generation Systems or New Radio (NR), and other future generations of communication systems, etc.

[0067] To meet the ever-increasing demand for data traffic, wireless networks are being rapidly deployed. As networks grow larger, energy consumption increases, significantly raising electricity costs for operators. The main reasons for this increased energy consumption can be summarized as follows:

[0068] First, in the era of 5G and future communication networks, active antenna units (AAUs) are being commercially deployed on a large scale, significantly increasing the number of antennas on the base station side. Compared to the 3G and 4G era, base station energy consumption has increased exponentially. Second, the 5G and future communication networks require support for higher data rates and greater bandwidth, thus increasing transmission bandwidth and consequently, base station energy consumption. Third, the use of millimeter waves and terahertz frequencies leads to denser site deployments, and more sites mean more energy consumption.

[0069] Besides the significant increase in costs for operators due to increased energy consumption, energy conservation and emission reduction are also a social responsibility for operators, requiring compliance with government regulatory requirements. Therefore, network-side energy conservation is an area that needs continuous optimization research, both for current and future wireless communication systems.

[0070] In current networks, different equipment manufacturers and operators have adopted various energy-saving methods. The current overall 5G energy-saving technology system includes equipment-level, site-level, and network-level energy saving. Among them, the equipment-level focuses on hardware energy-saving solutions researched from the perspective of device and hardware design; the site-level mainly focuses on software energy-saving solutions researched from aspects such as symbol shutdown, channel shutdown, carrier shutdown, and deep sleep; and the network-level energy-saving terminal performs intelligent energy saving from the perspective of multi-network coordination.

[0071] To conserve energy, terminal devices can use an uplink wake-up signal (UL WUS) to request system information from the base station on demand (e.g., requesting System Information Block 1 (SIB1) from the base station). On the other hand, to acquire uplink resources, terminal devices can report the status of their uplink data buffers to the network device. For example, in some examples, terminal devices can use Buffer Status Reports (BSRs) in the Physical Uplink Shared Channel (PUSCH) to inform the network device of the amount of data waiting to be transmitted in their buffers, enabling the network device to schedule uplink resources more efficiently.

[0072] When a terminal device uses UL WUS and reports the status of its uplink data buffer to the network device, uplink resources may be scheduled based on contention. In this case, when multiple terminal devices need to acquire the uplink resource, conflicts may occur on the network side, making it difficult for the network device to correctly detect the report.

[0073] In view of this, embodiments of this disclosure propose a communication technology solution, such as a method and apparatus for scheduling uplink resources, which can reduce the probability of network-side conflicts when scheduling uplink resources based on contention, thereby improving the success rate of decoding reports from terminal devices. Specific embodiments of this disclosure will be described later. Figures 2 to 17 The embodiments are further described below.

[0074] Figure 2 A schematic diagram of a communication flow according to some embodiments of this disclosure is shown. For example... Figure 2 As shown, process 200 involves a first device 202 and a second device 204. Unless otherwise specified, the device in this application may refer to the device itself, a module in the device (e.g., a processor, a chip, or a chip system), or a logic module or software that can implement all or part of the device functions.

[0075] An example of the first device 202 may involve a terminal device, such as terminal device 102. An example of the second device 204 may involve a network device, such as network device 104, 104-1, 104-2.

[0076] In process 200, at 210, the first device 202 sends an uplink wake-up signal UL WUS212. Correspondingly, at 214, the second device 204 receives the uplink wake-up signal UL WUS212.

[0077] In some examples, UL WUS can use dedicated or shared physical random access channel (PRACH) resources. UL WUS can be used to wake up the base station. Furthermore, the base station may already be in a woken-up state before receiving UL WUS, and UL WUS can be used for other purposes (e.g., the base station can configure PUSCH resources for terminal devices based on the received UL WUS).

[0078] Subsequently, at 220, the first device 202 determines the Physical Uplink Shared Channel (PUSCH) resources. It should be noted that the configuration and determination of PUSCH resources can involve both the first device 202 and the second device 204.

[0079] In some exemplary embodiments, the second device 204 allocates at least one PUSCH resource based on the UL WUS received at 214, and sends configuration information of the at least one PUSCH resource to the first device 202, and the first device 202 receives the configuration information of the at least one PUSCH resource. The PUSCH resource belongs to the at least one PUSCH resource.

[0080] For example, according to the exemplary embodiment described above, based on the received UL WUS, the second device allocates multiple PUSCH resources and sends configuration information of the multiple PUSCH resources to the first device; correspondingly, the first device receives the configuration information of the multiple PUSCH resources from the second device and selects a PUSCH resource from the multiple PUSCH resources. Thus, PUSCH resources can be flexibly configured based on UL WUS, enabling network devices to schedule uplink resources more efficiently.

[0081] In other exemplary embodiments, the second device 204 determines the PUSCH resource based on the UL WUS received at 214 and sends configuration information of the PUSCH resource to the first device 202, and the first device 202 receives the configuration information of the PUSCH resource. These other exemplary embodiments may include a PUSCH resource pre-configuration scheme.

[0082] For example, according to some other exemplary embodiments described above, based on the received UL WUS, the second device determines a PUSCH resource from the pre-configured PUSCH resources and sends the configuration information of the PUSCH resource to the first device; correspondingly, the first device receives the configuration information of the PUSCH resource from the second device.

[0083] For example, according to some other exemplary embodiments described above, based on the received UL WUS, the second device determines multiple PUSCH resources from pre-configured PUSCH resources and sends configuration information of the multiple PUSCH resources to the first device; correspondingly, the first device receives the configuration information of the multiple PUSCH resources from the second device and determines the PUSCH resource from the multiple PUSCH resources. Thus, PUSCH resources can be flexibly configured based on UL WUS, enabling network devices to schedule uplink resources more efficiently.

[0084] Subsequently, at 230, the first device 202 sends a Buffer Status Report (BSR) message on the PUSCH resource. Correspondingly, at 234, the second device 202 receives the BSR message on the PUSCH resource. In some exemplary embodiments, the BSR message includes a BSR Media Access Control Unit (MAC CE) message.

[0085] In the first embodiment, the UL WUS is device-specific (i.e., each terminal device has its own UL WUS), and the terminal device is pre-configured with PUSCH resources. In this case (i.e., the UL WUS is device-specific), the PUSCH resources determined from the pre-configured PUSCH resources correspond one-to-one with the UL WUS. Therefore, after detecting the UL WUS, the network device can detect the content of the PUSCH resources at the time and frequency domain resource locations of the corresponding PUSCH. The first embodiment described above may include a PUSCH resource pre-configuration scheme.

[0086] In some examples, the determined PUSCH resource may occupy the same bandwidth as the UL WUS, and the determined PUSCH resource may also occupy the same number of symbols as the UL WUS. Alternatively, the determined PUSCH resource may correspond to multiple UL WUS (i.e., one-to-many). Or, multiple PUSCH resources in a pre-configured PUSCH resource may correspond to the UL WUS (i.e., many-to-one). It should be noted that in this case, since the UL WUS is specific to the terminal device, the first device 202 may only send Buffer Status Report (BSR) information on the PUSCH resource. Correspondingly, the second device 202 may only receive the Buffer Status Report (BSR) information on the PUSCH resource. This can reduce resource consumption and improve data transmission efficiency.

[0087] For example, in the first embodiment described above, since the UL WUS is specific to the terminal device, the network device can detect the content of the PUSCH resource at the time and frequency domain resource locations of the corresponding PUSCH after detecting the UL WUS. The size of the content in the PUSCH resource (e.g., the payload in the PUSCH resource) (e.g., in bits) can be the number of bits of the BSR information plus the number of padding bits, and the number of padding bits can be calculated based on the size of the reserved resource transport block (TB) and the size of the BSR information.

[0088] For example, if a network device does not receive UL WUS from a terminal device, it can release the PUSCH resources pre-configured for the terminal device, thereby reducing resource consumption and improving data transmission efficiency. For instance, since this PUSCH resource is dedicated to the terminal device, configuring too many dedicated resources for the terminal device can affect resource allocation and data transmission efficiency; therefore, this PUSCH resource needs to be dynamically released. For example, the network device can notify the pre-configured PUSCH resource via a broadcast message, and when the network device does not detect UL WUS from the terminal device, it can notify other terminal devices that the PUSCH resource is available through Radio Resource Control (RRC) messages, broadcast messages, downlink control information (DCI), etc.

[0089] In some exemplary embodiments, during the process of the first device 202 determining the PUSCH resource, the first device 202 may determine the PUSCH resource based on the system frame number of the UL WUS, the subframe number of the UL WUS, the frequency domain position of the UL WUS, or any combination thereof. Thus, after detecting the UL WUS, the network device can determine which pre-configured PUSCH resource the terminal device will use.

[0090] For example, a terminal device can determine PUSCH resources based on the following formula: The sequence number of the determined PUSCH resource = (SFN + subframe index + frequency index) mod n, where SFN is the system frame number of UL WUS, subframe index is the subframe number of UL WUS, frequency index is the sequence number of the frequency domain start position of UL WUS, and n is a positive integer. Further, for example, the positive integer n can be determined based on the number of dedicated PUSCH resources pre-configured by the network device for the terminal device. In addition, the positive integer n can also be determined based on other parameters; for example, the positive integer n can be determined based on the number of dedicated PUSCH resources allocated by the network device and available to that specific terminal device. It should be noted that the determination of the positive integer n is not limited to the above methods and can also be based on other reasonable parameters; other methods of determining the positive integer n are also within the scope of this disclosure.

[0091] In some exemplary embodiments, during the process of the first device 202 determining the PUSCH resource, the first device 202 may further determine the time-domain resource of the PUSCH resource based on the timing offset between the UL WUS and the PUSCH resource, and determine the frequency-domain resource of the PUSCH resource based on the frequency offset between the UL WUS and the PUSCH resource. Thus, after detecting the UL WUS, the network device can detect the content of the PUSCH resource at the corresponding time-domain and frequency-domain resource locations of the PUSCH based on the timing offset and frequency offset.

[0092] For example, network devices can notify timing offset and frequency offset to configure PUSCH resources via base station broadcast. Figure 3A and Figure 3B A schematic diagram illustrating the association between UL WUS and PUSCH resources according to some embodiments of this disclosure in this scenario is shown. Figure 3A In this context, PUSCH 1 and PUSCH 2 occupy the same time-domain resources but different frequency-domain resources, and can be based on... Figure 3A The timing offset (e.g., the timing offset between UL WUS1 and PUSCH 1 / PUSCH 2) is used to determine the time-domain resources of PUSCH 1 and PUSCH 2.

[0093] exist Figure 3A In this diagram, PUSCH1 and PUSCH2 occupy the same time-domain location. The UE can determine the time-domain location of PUSCH1 and PUSCH2 based on a single timing offset between ULWUS1 and PUSCH1 / PUSCH2. Alternatively, the UE can determine the time-domain location of PUSCH1 based on the timing offset between ULWUS1 and PUSCH1, and determine the time-domain location of PUSCH2 based on another timing offset between ULWUS2 and PUSCH2 (not shown in the diagram).

[0094] exist Figure 3B In this context, PUSCH 1 and PUSCH 2 occupy different time-domain resources and different frequency-domain resources, which can be based on... Figure 3B The timing offsets (e.g., timing offset 1 and timing offset 2) are used to determine the time-domain resources of PUSCH 1 and PUSCH 2.

[0095] In some exemplary embodiments, during process 200, the first device 202 further receives System Information Block 1 (SIB1) and determines the PUSCH resource based on the indication in the SIB1. In this way, the network device can flexibly configure the PUSCH resource for the terminal device.

[0096] For example, PUSCH resources can be divided into a pre-configured first group (group1) and a second group (group2), where group1 is dedicated PUSCH resources and group2 is shared resources. A field PUSCH-allocation is added to the SIB message (e.g., the SIB1 message), where PUSCH-allocation = {group1-index1, group1-index2} represents the dedicated PUSCH resources determined by the network device and available for a specific end device. Subsequently, in the DCI message, the network device can indicate in DCI 0_0 / 0_1 the PUSCH resources scheduled for that specific end device for subsequent uplink data transmission.

[0097] In the second embodiment, the UL WUS is cell-specific (that is, terminal devices within the cell share the UL WUS). In this case, network devices may have difficulty identifying terminal devices through the UL WUS, so other methods are needed to enable network devices to identify terminal devices (that is, other methods are needed to transmit the identification information of terminal devices).

[0098] It should be noted that in the first embodiment described above (i.e., the UL WUS is specific to the terminal device), the network device may also have difficulty identifying the terminal device through the UL WUS, so it is also necessary to use other methods to transmit the identification information of the terminal device.

[0099] Therefore, further, at 230, the first device 202 not only sends the Buffer Status Report (BSR) information on the PUSCH resource, but also sends the terminal device identification information on the PUSCH resource (that is, the first device 202 sends the BSR information and the terminal device identification information 232 on the PUSCH resource). Correspondingly, at 234, the second device 202 not only receives the BSR information on the PUSCH resource, but also receives the terminal device identification information on the PUSCH resource (that is, the second device 204 receives the BSR information and the terminal device identification information 232 on the PUSCH resource).

[0100] For example, the PUSCH carries not only the BSR MAC CE, but also the UE-ID MAC CE, C-RNTI, I-RNTI, etc. Network devices detect the corresponding UE identification information, thus determining which UE sent the BSR information.

[0101] In this way, the probability of network-side conflicts can be reduced when uplink resources are scheduled based on contention, thereby improving the success rate of decoding reports from the first device.

[0102] Regarding the configuration of PUSCH resources, and in conjunction with the technical content described above for sending terminal device identification information, Figures 4 to 6 A flowchart illustrating some embodiments of the present disclosure is shown. Figures 4 to 6 The illustrated embodiments can be viewed as Figure 2 Extensions or variations of the illustrated embodiments.

[0103] like Figure 4 As shown, process 400 involves a first device 202 and a second device 204. An example of the first device 202 may be a terminal device, such as terminal device 102. An example of the second device 204 may be a network device, such as network device 104, 104-1, 104-2.

[0104] In process 400, at 404, the second device 204 sends pre-configuration information 406. For example, the pre-configuration information 406 may include PUSCH resources pre-configured for the second device 202. Accordingly, at 408, the first device 202 receives the pre-configuration information 406.

[0105] In 410 (similar to) Figure 2 In step 210), the first device 202 sends an uplink wake-up signal UL WUS 412 (similar to UL WUS 412). Figure 2 UL WUS212 in (in which case, correspondingly, in 414 (similar to) Figure 2 (214 in the middle), the second device 204 receives the uplink wake-up signal UL WUS 412.

[0106] Subsequently, at 416, the second device 204 sends configuration information 417 (e.g., an SIB1 message). For example, configuration information 417 may indicate the PUSCH resources available to the first device 202 from the aforementioned pre-configured PUSCH resources. Accordingly, at 418, the first device 202 receives configuration information 417. Since the PUSCH resources available to the terminal device are determined based on pre-configuration and subsequent configuration, PUSCH resources can be configured more flexibly.

[0107] Subsequently, in 420 (similar to) Figure 2 In 220), the first device 202 determines the Physical Uplink Shared Channel (PUSCH) resource, and in 430 (similar to ... Figure 2 In step 230), the first device 202 sends Buffer Status Report (BSR) information and terminal device identification information 432 (similar to 230) on the PUSCH resource. Figure 2(232 in the example). In some exemplary embodiments, the PUSCH resource is determined based on the UL WUS 412.

[0108] Accordingly, in 434 (similar to) Figure 2 (234) The second device 202 receives the buffer status report (BSR) information and the terminal device identification information (432) on the PUSCH resource.

[0109] Subsequently, at 440, the second device 204 sends a scheduling message 442 (e.g., a DCI message). For example, the scheduling message 442 may include PUSCH resources scheduled for the second device 202 for subsequent uplink data transmission. Accordingly, at 444, the first device 202 receives the scheduling message 442.

[0110] like Figure 5 As shown, process 500 involves a first device 202 and a second device 204. An example of the first device 202 may be a terminal device, such as terminal device 102. An example of the second device 204 may be a network device, such as network device 104, 104-1, 104-2.

[0111] In process 500, in 510 (similar to...) Figure 2 In step 210), the first device 202 sends an uplink wake-up signal ULWUS 512 (similar to ULWUS 512). Figure 2 UL WUS212 in [the relevant standard]. Accordingly, in 514 (similar to [the standard standard]). Figure 2 (214 in the middle), the second device 204 receives the uplink wake-up signal UL WUS 512.

[0112] Subsequently, at 516, the second device 204 sends configuration information 517 (e.g., an SIB1 message). For example, configuration information 517 may indicate the PUSCH resources available for the first device 202. Accordingly, at 518, the first device 202 receives configuration information 517. Since the PUSCH resources available for the terminal device are determined based on configuration, PUSCH resources can be configured more efficiently.

[0113] Subsequently, on 520 (similar to...) Figure 2 In step 220), the first device 202 determines the Physical Uplink Shared Channel (PUSCH) resource, and in step 530 (similar to step 220), the first device 202 determines the Physical Uplink Shared Channel (PUSCH) resource. Figure 2 In step 230), the first device 202 sends Buffer Status Report (BSR) information and terminal device identification information 532 (similar to 532) on the PUSCH resource. Figure 2 (232 in the example). In some exemplary embodiments, the PUSCH resource is determined based on the UL WUS 512.

[0114] Accordingly, in 534 (similar to) Figure 2 (234) The second device 202 receives the buffer status report (BSR) information and the terminal device identification information (532) on the PUSCH resource.

[0115] Subsequently, at 540, the second device 204 sends a scheduling message 542 (e.g., a DCI message). For example, the scheduling message 542 may include PUSCH resources scheduled for the second device 202 for subsequent uplink data transmission. Accordingly, at 544, the first device 202 receives the control message 542.

[0116] like Figure 6 As shown, process 600 involves a first device 202 and a second device 204. An example of the first device 202 may be a terminal device, such as terminal device 102. An example of the second device 204 may be a network device, such as network devices 104, 104-1, and 104-2.

[0117] In process 600, at 604, the second device 204 sends pre-configuration information 606. For example, the pre-configuration information 606 may include PUSCH resources pre-configured for the second device 202. Accordingly, at 608, the first device 202 receives the pre-configuration information 606.

[0118] Subsequently, since the second device 204 did not detect a UL WUS from the first device 202, at 610, the second device 204 sends a release instruction 612. Accordingly, at 614, the first device 202 receives the release instruction 612. Subsequently, at 620, the first device 202 releases the pre-configured PUSCH resources. This reduces resource consumption and improves data transmission efficiency.

[0119] As mentioned above, the PUSCH carries not only the BSR MAC CE, but also the UE-ID MACCE, C-RNTI, I-RNTI, etc. Network devices detect the corresponding UE identification information, thus determining which UE sent the BSR information. The UE identification information sent by the UE can be defined in the following ways.

[0120] Figure 7 A schematic diagram illustrating the identification information of a UL WUS carrying a terminal device according to some embodiments of this disclosure is shown in this case. Figure 7As shown, the PUSCH carries BSR information (e.g., BSR MAC CE) and terminal device identification information (e.g., UE-ID MACCE, C-RNTI, I-RNTI, etc.). It should be noted that in this case (i.e., the UL WUS is cell-specific), similar to the first embodiment described above (i.e., the UL WUS is terminal device-specific), the terminal device can also be pre-configured with PUSCH resources, and the PUSCH resources determined from the pre-configured PUSCH resources correspond one-to-one with the UL WUS. Alternatively, the determined PUSCH resources may correspond to multiple UL WUS (one-to-many), or multiple PUSCH resources in the pre-configured PUSCH resources may correspond to the UL WUS (many-to-one).

[0121] In some exemplary embodiments, the format used for the content in the PUSCH resource involves including the terminal device identifier (UE-ID) MAC CE in the identification information. Thus, the network device detects the corresponding terminal device identifier information and is able to determine which terminal device sent the BSR information. Figure 8 A schematic diagram illustrating the identification information (identification information is UE-ID) of a UL WUS portable terminal device according to some embodiments of the present disclosure is shown, and Figure 9 A schematic diagram illustrating the identification information as UE-ID according to some embodiments of this disclosure is shown. Figure 9 In English, Oct is short for octet, which represents a byte consisting of eight bits (i.e., an eight-bit byte). In some examples, when the number of bits for terminal device identification information is large, octet is used... Figure 8 and Figure 9 The UE-ID shown. For example, as... Figure 9 As shown, the UE-ID MAC CE message contains 48 bits of UE-ID information.

[0122] In other examples, the identification information of the terminal device can be implemented using simplified identifiers. For instance, the identification information can use the Cell Radio Network Temporary Identifier (C-RNTI) (a 16-bit identifier) ​​instead of the complete 48-bit UE-ID information. This temporary identifier is only valid within the current cell, significantly reducing signaling overhead. In this case, the network side avoids intra-cell identifier conflicts by dynamically allocating and managing C-RNTIs. If a conflict occurs (with a very low probability), the base station will trigger a reallocation process. As another example, in some scenarios, the identification information can also use the longer Initial Radio Network Temporary Identifier (I-RNTI) (a 40-bit identifier, but still shorter than 48 bits). The use of simplified identifiers for terminal device identification information will be further described below.

[0123] In other exemplary embodiments, the format used for the content in the PUSCH resource involves the identification information including the Cell Radio Network Temporary Identifier (C-RNTI) MAC CE. Thus, the network device detects the corresponding terminal device identification information, thereby determining which terminal device sent the BSR information.

[0124] In some further exemplary embodiments, the format used for the content in the PUSCH resource involves including the Initial Radio Network Temporary Identifier (I-RNTI) MAC CE in the identification information. Thus, the network device detects the corresponding terminal device identification information, thereby determining which terminal device sent the BSR information. Figure 10 A schematic diagram illustrating the identification information (identification information is I-RNTI) of a UL WUS portable terminal device according to some embodiments of the present disclosure is shown, and Figure 11 A schematic diagram illustrating identification information as I-RNTI according to some embodiments of the present disclosure is shown. In some examples, when the number of bits of the terminal device identification information is small, a method such as... Figure 10 and Figure 11 The I-RNTI is shown below. For example, the I-RNTI MAC CE message is identified using the identification information of the UE in an idle state.

[0125] In a further exemplary embodiment, the format used for the content in the PUSCH resource also involves the BSR information being scrambled using a public Radio Network Temporary Identifier (RNTI). Accordingly, in some examples, upon detecting the PUSCH resource, the network device parses the BSR information using the public RNTI and then detects the identification information. This reduces signaling overhead and resource consumption, and enhances privacy protection and anti-interference capabilities. For example, the public RNTI can be 0123, or it can be a fixed random number.

[0126] In other exemplary embodiments, the format used for the content in the PUSCH resource also involves the BSR information and the identification information being scrambled using a common RNTI. Accordingly, in some examples, when the PUSCH resource is detected, the network device parses the BSR information and the identification information using the common RNTI. This can further reduce signaling overhead and resource consumption, and further enhance privacy protection and anti-interference capabilities. For example, the common RNTI can be 0123, or the common RNTI can be a fixed random number.

[0127] In the above situation, the second device 204 needs to know which identification information the first device 202 used for transmission. That is, the second device 204 needs to know the format used by the content in the PUSCH resource.

[0128] In some exemplary embodiments, to determine the format used, in process 200, the first device 202 also sends a PUSCH header on the PUSCH resource. In some exemplary embodiments, the PUSCH header indicates the format used by the content in the PUSCH resource. In this way, the second device can quickly know which identification information the first device used for transmission. That is, the second device can quickly know the format used by the content in the PUSCH resource.

[0129] For example, a bit is set in the PUSCH header. A bit of 0 indicates that the UE-ID is used for identification, and a bit of 1 indicates that the I-RNTI is used for identification.

[0130] Alternatively, a bit is set in the PUSCH header. A bit of 0 indicates identification using the short format BSR and UE-ID, while a bit of 1 indicates identification using the long format BSR and I-RNTI. The resource usage in these two cases is relatively similar.

[0131] Alternatively, two bits are set in the PUSCH header to indicate the format of the BSR and identification information. For example, 00 bits represent the short format BSR and UE-ID, 01 bits represent the short format BSR and I-RNTI, 10 bits represent the long format BSR and UE-ID, and 11 bits represent the long format BSR and I-RNTI. See Table 1 below.

[0132] Table 1: Example settings for the format of BSR and identification information in the header

[0133] masthead content 00 Short format BSR+UE-ID 01 Short format BSR+I-RNTI 10 Long format BSR+UE-ID 11 Long format BSR+I-RNTI

[0134] In other exemplary embodiments, to determine the format used, different PUSCH resources among at least one PUSCH resources determined based on the UL WUS correspond to the corresponding format to be used by the content in that PUSCH resource, and such a correspondence can be set at the first device 202 and the second device 204. Accordingly, in process 200, the first device 202 selects the PUSCH resource from the at least one PUSCH resource based on the format to be used by the content in that PUSCH resource, and the second device 204 determines the format used by the content in that PUSCH resource based on the determined PUSCH resource. In this way, the second device can quickly determine the format used by the content in the PUSCH resource and also improve resource utilization.

[0135] Generally speaking, BSR (Background Status) primarily helps network devices understand the data transmission needs of terminal devices, thereby allocating uplink resources more rationally. Furthermore, BSR can reduce resource waste and improve network transmission efficiency. BSR can also ensure that high-priority data is transmitted in a timely manner, meeting the QoS requirements of different services.

[0136] Figure 12A A schematic diagram of a short format BSR according to some embodiments of the present disclosure is shown, and Figure 12B A schematic diagram of a long format BSR according to some embodiments of the present disclosure is shown. Figure 12A and Figure 12B These correspond to reporting one logical channel group (LCG) and reporting multiple LCGs, respectively.

[0137] In some exemplary embodiments, to improve the success rate of transmission on the PUSCH resource, the BSR information and the identification information may be repeatedly transmitted, and the number of retransmissions is determined based on the size of the content in the PUSCH resource (e.g., the payload in the PUSCH resource), the quality of the channel between the terminal device and the network device, or a combination of both. This can improve the success rate of transmission on the PUSCH resource.

[0138] For example, by default, the terminal device retransmits the BSR information and the identification information three times, and checks for acknowledgment (ACK) messages within a time window. The number of retransmissions can be related to the size of the content in the PUSCH resource (e.g., the payload in the PUSCH resource). For example, longer content formats require more retransmissions, and shorter content formats require fewer retransmissions.

[0139] Alternatively, the number of retransmissions can be related to channel quality. For example, if the reference signal received power (RSRP) is high, a longer content format and fewer retransmissions are used; if the RSRP is low, a shorter content format and more retransmissions are used.

[0140] In some exemplary embodiments, to help network devices better schedule terminal devices, in process 200, the first device 202 also transmits terminal device capability information or auxiliary information on the PUSCH resource. The terminal device capability information or auxiliary information may include the transmit power used by the terminal device, the transmit power margin of the terminal device, the number of multiple-input multiple-output (MIMO) streams supported by the terminal device, the bandwidth supported by the terminal device, the number of carriers supported by the terminal device, the number of codewords supported by the terminal device, or any combination thereof.

[0141] Accordingly, after receiving capability information or auxiliary information from the terminal device, the network device can estimate path loss based on the transmit power used by the terminal device. Alternatively, the network device can adjust the transmit power of the next transmission and the step size of repeated transmissions based on the transmit power margin of the terminal device. This helps the network device to better schedule the terminal device and speed up the data transmission preparation process.

[0142] Figure 13 A schematic flowchart illustrating implementation at a first device according to some embodiments of the present disclosure is shown. Figure 13 As shown, process 1300 can be executed by a first device, such as terminal device 110 or a chip, module, or assembly within terminal device 110. In block 1310, the first device sends an uplink wake-up signal (UL WUS). In block 1320, the first device determines a Physical Uplink Shared Channel (PUSCH) resource, where the PUSCH resource is determined based on UL WUS. In block 1330, the first device sends a Buffer Status Report (BSR) and terminal device identification information on the PUSCH resource. In some embodiments, process 1300 may further include elements combined with those described in this disclosure. Figures 2 to 12B Other operations performed at the terminal device 102 or UE as described.

[0143] Figure 14 A schematic flowchart illustrating implementation at a second device according to some embodiments of the present disclosure is shown. Figure 14 As shown, process 1400 can be executed by a communication device, and the second device executing process 1400 may involve network device 120 or a chip, module, or assembly within network device 120. In block 1410, the second device receives an uplink wake-up signal UL WUS. In block 1420, the second device receives buffer status report (BSR) information and terminal device identification information on the Physical Uplink Shared Channel (PUSCH) resource, wherein the PUSCH resource is determined based on UL WUS. In some embodiments, process 1400 may further include elements combined with those described in this disclosure. Figures 2 to 15 Other operations described at network device 104 or base station (BS) or gNB.

[0144] Figure 15This is a block diagram of a device 1500 that can be used to implement some embodiments of the present application. In some embodiments, device 1500 may be an element of a communication network infrastructure, such as a base station (e.g., NodeB, evolved NodeB (eNodeB or eNB), next-generation NodeB (sometimes called next-generation NodeB, gNodeB or gNB), home subscriber server (HSS), gateway (GW), such as packet gateway (PGW) or serving gateway (SGW), or various other nodes or functions within a core network (CN) or Public Land Mobility Network (PLMN). In other embodiments, device 1500 may be a device connected to the network infrastructure via a wireless interface, such as a mobile phone, smartphone, or other such device that can be classified as user equipment (UE). In some embodiments, device 1500 may be machine-type communication (M2C). Communications (MTC) devices (also known as machine-to-machine (M2M) devices), or another type of device that, although not providing direct service to a user, can be classified as a UE. In some embodiments, device 1500 may be a roadside unit (RSU), a vehicle UE (V-UE), a pedestrian UE (P-UE), or an infrastructure UE (I-UE). In some scenarios, device 1500 may also be referred to as a mobile device, a term intended to reflect a device connected to a mobile network, regardless of whether the device itself is designed for or capable of being mobile. A particular device may utilize all or only a subset of the components shown, and the level of integration may vary depending on the device. Furthermore, device 1500 may contain multiple instances of components, such as multiple processors, memory, transmitters, receivers, etc.

[0145] Device 1500 typically includes a processor 1502, such as a central processing unit (CPU), and may further include a dedicated processor, such as a graphics processing unit (GPU) or other such processor, memory 1504, a network interface 1506, and a bus 1508 for connecting the components of device 1500. Optionally, device 1500 may also include components such as a mass storage device 1510, a video adapter 1512, and an I / O interface 1516 (shown in dashed lines).

[0146] Memory 1504 may include any type of non-transitory system memory readable by processor 1502, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In one embodiment, memory 1504 may include more than one type of memory, such as ROM used at boot time and DRAM used for program and data storage during program execution. Bus 1508 may be one or more of a plurality of bus architectures of any type, including a memory bus or memory controller, a peripheral bus, or a video bus. In some examples, memory 1504 and processor 1502 may be separate devices. In other examples, memory 1504 may be integrated with processor 1502 as a single device.

[0147] Device 1500 may also include one or more network interfaces 1506, which may include at least one of wired network interfaces and wireless network interfaces. For example... Figure 15 As shown, network interface 1506 may include a wired network interface for connecting to network 1522, and may also include a wireless access network interface 1520 for connecting to other devices via a wireless link. When device 1500 is a network infrastructure element, the wireless access network interface 1520 may be omitted for nodes or functions that are elements of a PLMN rather than elements at the wireless edge. When device 1500 is infrastructure at the wireless edge of the network, both wired and wireless network interfaces may be included. When device 1500 is a wirelessly connected device, such as a user equipment, the wireless access network interface 1520 may be present and may be supplemented by other wireless interfaces such as a Wi-Fi network interface. Network interface 1506 allows device 1500 to communicate with remote entities such as those connected to network 1522.

[0148] Mass storage 1510 may include any type of non-transitory storage device configured to store data, programs, and other information and make the data, programs, and other information accessible via bus 1508. Mass storage 1510 may include, for example, one or more of a solid-state drive, hard disk drive, disk drive, or optical disk drive. In some embodiments, mass storage 1510 may be located remotely from device 1500 and may be accessed using a network interface such as interface 1506. In the illustrated embodiment, mass storage 1510 is distinct from the memory 1504 that includes it, and mass storage 1510 typically performs storage tasks compatible with higher latency but typically provides low or no fluctuation. In some embodiments, mass storage 1510 may be integrated with heterogeneous memory 1504.

[0149] Optional video adapter 1512 and I / O interface 1516 (shown in dashed lines) provide interfaces for coupling device 1500 to external input and output devices. Examples of input and output devices include a display 1514 coupled to video adapter 1512 and an I / O device 1515, such as a touchscreen, coupled to I / O interface 1516. Other devices may be coupled to device 1500 and may utilize additional or fewer interfaces. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide interfaces for external devices. Those skilled in the art will understand that in embodiments where device 1500 is part of a data center, I / O interface 1516 and video adapter 1512 may be virtualized and provided via network interface 1506.

[0150] Figure 16 This is a schematic diagram of the structure of device 1600 according to some embodiments of this application. For example... Figure 16 As shown, the device 1600 includes a first transmitting unit 1602, a determining unit 1604, and a second transmitting unit 1606. The device 1600 can be applied to, for example... Figures 1A to 1DThe communication scenario shown can implement the methods provided in the preceding embodiments, such as method 1300. Optionally, the physical manifestation of device 1600 can be a communication device, such as a UE. Alternatively, device 1600 can be other devices capable of implementing the functions of a communication device, such as a processor or chip inside the communication device. Specifically, device 1600 can be a programmable chip, such as a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), or a system on a chip (SOC).

[0151] In some embodiments, the first transmitting unit 1602 can be configured to transmit an uplink wake-up signal (ULWUS). The determining unit 1604 can be configured to determine the physical uplink shared channel (PUSCH) resource, wherein the PUSCH resource is determined based on ULWUS. The second transmitting unit 1606 can be configured to transmit buffer status report (BSR) information and terminal device identification information on the PUSCH resource.

[0152] In some other embodiments, the apparatus 1600 may include various other units or modules that can be configured to perform the various operations or functions described with respect to the foregoing method embodiments. Specific details can be obtained by referring to the detailed description of the foregoing method embodiments, and will not be repeated here.

[0153] Figure 17 This is a schematic diagram of the structure of the device 1700 according to other embodiments of this application. For example... Figure 17 As shown, the device 1700 includes a first receiving unit 1702 and a second receiving unit 1704. The device 1700 can be applied to applications such as... Figures 1A to 1DThe illustrated communication scenario can implement the methods provided in the preceding embodiments, such as method 1400. Optionally, the physical manifestation of device 1700 can be a communication device, such as a network device. Alternatively, device 1700 can be other devices capable of implementing the functions of a communication device, such as a processor or chip within the communication device. Specifically, device 1700 can be a programmable chip, such as a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), or a system on a chip (SOC).

[0154] In some embodiments, the first receiving unit 1702 may be configured to receive an uplink wake-up signal ULWUS. The second receiving unit 1704 may be configured to receive buffer status report (BSR) information and terminal device identification information on the Physical Uplink Shared Channel (PUSCH) resource, wherein the PUSCH resource is determined based on ULWUS.

[0155] In some embodiments, apparatus 1700 may include various other units or modules that may be configured to perform the various operations or functions described with respect to the foregoing method embodiments. Specific details can be obtained by referring to the detailed description of the foregoing method embodiments, and will not be repeated herein.

[0156] It should be noted that the module division in the above embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or be integrated into one unit by two or more units. The integrated units described above can be implemented in hardware or as software functional units.

[0157] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or all or part of it, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0158] Based on the above embodiments, this application also provides a computer program that, when run on a computer, causes the computer to execute any of the methods provided in the above embodiments.

[0159] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a computer, it causes the computer to perform any of the methods provided in the above embodiments. The storage medium can be any available medium that can be accessed by a computer. By way of example, but not limited to, a computer-readable medium may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code having the form of instructions or data structures and that can be accessed by a computer.

[0160] Based on the above embodiments, this application also provides a chip for reading a computer program stored in a memory and implementing any of the methods provided in the above embodiments.

[0161] Based on the above embodiments, this application provides a chip system including a processor for supporting a computer device in implementing the functions involved in the communication devices in the above embodiments. In one possible design, the chip system further includes a memory for storing necessary programs and data of the computer device. This chip system may be composed of chips or may include chips and other discrete components.

[0162] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0163] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0164] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0165] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

Claims

1. A communication method, characterized in that, include: Send uplink wake-up signal UL WUS; Determine the Physical Uplink Shared Channel (PUSCH) resources, wherein the PUSCH resources are determined based on the UL WUS; and Send Buffer Status Report (BSR) information and terminal device identification information on the PUSCH resource.

2. The method according to claim 1, characterized in that, The determination of PUSCH resources includes: Receive configuration information for at least one PUSCH resource, wherein the at least one PUSCH resource is allocated according to the UL WUS and the PUSCH resource belongs to the at least one PUSCH resource; or Receive configuration information for the PUSCH resource, wherein the PUSCH resource is determined according to the UL WUS.

3. The method according to claim 1 or 2, characterized in that, The PUSCH resource and the UL WUS are in one-to-one correspondence.

4. The method according to claim 1, characterized in that, The determination of PUSCH resources includes: The PUSCH resource is determined based on at least one of the following: the system frame number of the UL WUS, the subframe number of the UL WUS, or the frequency domain location of the UL WUS.

5. The method according to claim 1, characterized in that, The determination of PUSCH resources includes: Based on the timing offset between the UL WUS and the PUSCH resource, the time-domain resources of the PUSCH resource are determined; and The frequency domain resources of the PUSCH resource are determined based on the frequency offset between the UL WUS and the PUSCH resource.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Receive system information block 1SIB1; and The PUSCH resource is determined based on the instructions in SIB1.

7. The method according to claim 1 or 2, wherein the BSR information includes a BSR Media Access Control Unit (MAC CE) message, and the format used for the content in the PUSCH resource is based on at least one of the following: The identification information includes the terminal device identifier UE-ID MAC CE; The identification information includes the temporary identifier of the cell wireless network, C-RNTI, MAC, and CE; or The identification information includes the Initial Radio Network Temporary Identifier (I-RNTI) and the MAC CE.

8. The method according to claim 7, characterized in that, The format used for the content in the PUSCH resource is also based on: The BSR information is scrambled using the public Radio Network Temporary Identifier (RNTI); or The BSR information and the identification information are scrambled using the common RNTI.

9. The method according to claim 7 or 8, characterized in that, The method further includes: A PUSCH header is sent on the PUSCH resource, wherein the PUSCH header indicates the format used by the content in the PUSCH resource.

10. The method according to claim 7 or 8, characterized in that, The method further includes: Different PUSCH resources in the at least one PUSCH resource correspond to the corresponding formats to be used for the content in the PUSCH resource; The PUSCH resource is selected from the at least one PUSCH resource based on the format to be used for the content in the PUSCH resource.

11. The method according to any one of claims 7 to 10, characterized in that, The BSR information and the identification information are sent repeatedly, and the number of times they are sent repeatedly is determined based on at least one of the following: The size of the content in the PUSCH resource; or The quality of the channel between the terminal device and the network device.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: Send auxiliary information on the PUSCH resource, wherein the auxiliary information includes at least one of the following: The transmit power used by the terminal equipment; The transmit power margin of the terminal equipment; The number of multiple-input multiple-output (MIMO) streams supported by the terminal device; The bandwidth supported by the terminal device; The number of carriers supported by the terminal device; or The number of codewords supported by the terminal device.

13. A communication method, characterized in that, include: Receive uplink wake-up signal UL WUS; as well as On the Physical Uplink Shared Channel (PUSCH) resource, receive Buffer Status Report (BSR) information and terminal device identification information, wherein the PUSCH resource is determined based on the UL WUS.

14. The method according to claim 13, characterized in that, The method further includes allocating at least one PUSCH resource according to the UL WUS and sending configuration information of the at least one PUSCH resource, wherein the PUSCH resource belongs to the at least one PUSCH resource; or The method further includes determining the PUSCH resource based on the UL WUS and sending the configuration information of the PUSCH resource.

15. The method according to claim 13 or 14, characterized in that, The PUSCH resource and the UL WUS are in one-to-one correspondence.

16. The method according to claim 13, characterized in that, The PUSCH resource is determined based on at least one of the following: the system frame number of the UL WUS, the subframe number of the UL WUS, or the frequency domain location of the UL WUS.

17. The method of claim 13, further comprising: Send the timing offset between the UL WUS and the PUSCH resource, the timing offset being used to determine the time domain resource of the PUSCH resource; as well as Send the frequency offset between the UL WUS and the PUSCH resource, the frequency offset being used to determine the frequency domain resource of the PUSCH resource.

18. The method according to any one of claims 13-17, characterized in that, The method further includes: Send System Information Block 1 (SIB1), wherein the indication in SIB1 specifies the PUSCH resource specific to the terminal device.

19. The method of claim 13 or 14, wherein the BSR information includes a BSR Media Access Control Unit (MAC CE) message, and the content in the PUSCH resource is in a format based on at least one of the following: The identification information includes the terminal device identifier UE-ID MAC CE; The identification information includes the temporary identifier of the cell wireless network, C-RNTI, MAC, and CE; or The identification information includes the Initial Radio Network Temporary Identifier (I-RNTI) and the MAC CE.

20. The method according to claim 19, characterized in that, The format used for the content in the PUSCH resource is also based on: The BSR information is scrambled using the public Radio Network Temporary Identifier (RNTI); or The BSR information and the identification information are scrambled using the common RNTI.

21. The method according to claim 19 or 20, characterized in that, The method further includes: Receive a PUSCH header on the PUSCH resource, wherein the PUSCH header indicates the format used by the content in the PUSCH resource.

22. The method according to claim 19 or 20, characterized in that, The method further includes determining that at least one PUSCH resource, based on the UL WUS, corresponds to a different PUSCH resource in the PUSCH resource in a specific format to be used for the content within that PUSCH resource. The format used by the content in the PUSCH resource is determined based on the PUSCH resource.

23. The method according to any one of claims 19 to 22, characterized in that, The BSR information and the identification information are sent repeatedly, and the number of times they are sent repeatedly is determined based on at least one of the following: The size of the content in the PUSCH resource; or The quality of the channel between the terminal device and the network device.

24. The method according to any one of claims 13-23, characterized in that, The method further includes: Receive auxiliary information on the PUSCH resource, wherein the auxiliary information includes at least one of the following: The transmission power used by the terminal device; The transmit power margin of the terminal equipment; The number of multiple-input multiple-output (MIMO) streams supported by the terminal device; The bandwidth supported by the terminal device; The number of carriers supported by the terminal device; or The number of codewords supported by the terminal device.

25. A communication device, comprising: Units or modules for performing the method according to any one of claims 1 to 12, or units or modules for performing the method according to any one of claims 13 to 24.

26. A communication device, comprising: The processor is configured to perform the method according to any one of claims 1 to 12, or to perform the method according to any one of claims 13 to 24.

27. A computer-readable storage medium storing instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 12, or cause the device to perform the method according to any one of claims 13 to 24.

28. A computer program product comprising instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 12, or cause the device to perform the method according to any one of claims 13 to 24.

Images