Communication method, scheduling method, resource configuration method and related apparatus

Abstract

The present application relates to the technical field of wireless communications. Provided are a communication method, a scheduling method, a resource configuration method and a related apparatus. The communication method is applied to a UE, and comprises: on the basis of configuration information and / or a predefined rule, sending a PUSCH for enabling an OCC function, wherein the configuration information includes, but is not limited to, one or more of the following pieces of information: first configuration information, second configuration information, third configuration information, fourth configuration information, fifth configuration information and sixth configuration information; and the predefined rule includes, but is not limited to, one or more of the following rules: a first predefined rule, a second predefined rule and a third predefined rule.

Description

Communication method, scheduling method, resource configuration method and related devices TECHNICAL FIELD

[0001] The present application relates to the technical field of wireless communication, and in particular to a communication method, a scheduling method, a resource configuration method and related devices. BACKGROUND

[0002] In a non-terrestrial network (NTN) system, compared with a traditional ground network, due to a larger transmission distance between a satellite and a user equipment (UE), a satellite beam has a larger coverage range, such as a diameter of a satellite cell being up to 1000 km. Given the larger coverage range of the satellite beam, the number of UEs in the coverage range is very large. The NTN network currently supports access of IoT devices, and the R19 topic also needs to be able to support a Redcap device based on a light terminal of NR, which inevitably causes a sharp increase in the number of devices in the range, resulting in very limited uplink spectrum resources used by each device in the NTN network. In addition, in order to achieve different degrees of coverage, satellites are generally divided according to height, and even the minimum height has reached 600 km, so the uplink signal will undoubtedly experience a large path loss in the transmission process. Limited by the transmit power of the device end and the limited resources of the uplink, the uplink is considered to be a bottleneck channel in the NTN network.

[0003] Starting from R16, research on uplink channel enhancement in a new radio (NR) system has begun, and a UE can implement uplink coverage enhancement by repeatedly transmitting a physical uplink shared channel (PUSCH) / physical uplink control channel (PUCCH) channel multiple times. Although multiple repeated transmissions improve communication reliability, it means that more resources are used to transmit the same data, at the expense of the transmission capacity of the system. Therefore, an orthogonal cover code (OCC) has been introduced to enhance the PUSCH channel, and different OCC codes can be multiplied on the repeated signals, so that multiple UEs can be multiplexed on the same time-frequency domain resources, thereby improving the system capacity and throughput. In R19, it is mentioned that OCC codes across orthogonal frequency division multiplexing (OFDM) symbols, across slots, and within OFDM symbols can be considered to enhance the PUSCH channel.

[0004] Some problems caused by enabling OCC function, for example: relationship with repetition transmission, uplink control information (UCI) multiplexing, Transport Block Size (TBS) calculation, available slot counting and the like. In addition, there are some other associated problems, for example: multi-UE scheduling, R19 EDT reduces the probability of UE collision, and the like. In view of this, how to solve these problems has become a research focus.

[0005] SUMMARY

[0006] Embodiments of the present application provide a communication method, a scheduling method, a resource configuration method and related devices, to solve some problems caused by using OCC extended mapping mode.

[0007] To achieve the above object, the present application adopts the following technical solutions:

[0008] The first aspect of the present application provides a communication method for a user equipment (UE), comprising: transmitting a physical uplink shared channel (PUSCH) enabling an orthogonal cover code (OCC) function based on configuration information and / or a predefined rule, wherein the configuration information comprises but is not limited to one or more of the following information: first configuration information, second configuration information, third configuration information, fourth configuration information, fifth configuration information and sixth configuration information; and the predefined rule comprises but is not limited to one or more of the following rules: a first predefined rule, a second predefined rule and a third predefined rule.

[0009] The second aspect of the present application provides a communication method for a base station, comprising: transmitting configuration information, and / or receiving a PUSCH enabling an OCC function based on a predefined rule, wherein the configuration information comprises but is not limited to one or more of the following information: first configuration information, second configuration information, third configuration information, fourth configuration information, fifth configuration information and sixth configuration information; and the predefined rule comprises but is not limited to one or more of the following rules: a second predefined rule and a third predefined rule.

[0010] The third aspect of the present application provides a scheduling method, applied to a base station, for scheduling multiple UEs to send OCC-enabled PUSCH, comprising: sending a common DCI, wherein the common DCI includes a unique information field, the unique information field is a field not shared among the N UEs, and the unique information field at least includes an OCC-Index field, wherein the OCC-Index sequence field is used to indicate the OCC sequence that needs to be multiplexed by the UE; and sending configuration information to each UE, wherein the configuration information includes a sub-index parameter, and the sub-index parameter is used to determine the target subfield of each UE in the unique information field among the N UEs.

[0011] The fourth aspect of the present application provides a scheduling method, applied to a UE, comprising: receiving a common DCI, wherein the common DCI includes a unique information field, the unique information field is a field not shared among the N UEs, and the unique information field at least includes an OCC-Index field, wherein the OCC-Index sequence field is used to indicate the OCC sequence that needs to be multiplexed by the UE; receiving configuration information, wherein the configuration information includes a sub-index parameter, and the sub-index parameter is used to determine the target subfield of each UE in the unique information field among the N UEs; and determining the target subfield in the unique information field according to the common DCI and the configuration information.

[0012] The fifth aspect of the present application provides a communication method, applied to a UE, comprising: receiving OCC configuration information for enabling OCC function for a physical downlink control channel (PDCCH); and receiving the PDCCH.

[0013] The sixth aspect of the present application provides a communication method, applied to a base station, comprising: sending OCC configuration information for enabling OCC function for a PDCCH; and sending the PDCCH.

[0014] The seventh aspect of the present application provides a resource configuration method, applied to an Internet of Things (IoT) NTN system, comprising: receiving configuration information of a common resource pool broadcasted, wherein the common resource pool is divided into M groups of grouped resources according to a target system information grouping basis, and the configuration information includes ID information of each grouped resource; receiving a first target system information, and determining a target group ID corresponding to the first target system information according to a value of the first target system information; and when the target group ID is included in the ID information of each grouped resource pool, performing information transmission and reception based on the grouped resource corresponding to the target group ID.

[0015] The eighth aspect of the present application provides a resource configuration method, comprising: broadcasting configuration information of a common resource pool, wherein the common resource pool is divided into M groups of grouped resources according to a grouping basis of target system information, and the configuration information comprises ID information of the grouped resources; transmitting first target information, so that a UE determines a corresponding target group ID according to a value of the first target information; and communicating with the UE based on a grouped resource corresponding to the target group ID.

[0016] The ninth aspect of the present application provides a wireless communication device, comprising: a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the method according to any one of the above aspects. BRIEF DESCRIPTION OF DRAWINGS

[0017] Fig. 1 is an example diagram of a possible communication method provided by an embodiment of the present application;

[0018] Fig. 2 is a flow diagram of another possible communication method provided by an embodiment of the present application;

[0019] Fig. 3 is a flow diagram of a possible scheduling method provided by an embodiment of the present application;

[0020] Fig. 4 is a flow diagram of a possible resource configuration method provided by an embodiment of the present application;

[0021] Fig. 5 is a storage diagram of a possible wireless communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0022] For the convenience of understanding, the related technologies involved in the embodiments of the present application will be described first.

[0023] The technical solutions in the embodiments of the present application will be described below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present application.

[0024] It should be understood that the term "and / or" herein is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the existence of A alone, the existence of A and B together, and the existence of B alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects. It should be noted that the naming of each parameter herein is for the convenience of description, and other naming can be used in practice, and the specific application does not limit it.

[0025] By introducing OCC to enhance the PUSCH channel, different OCC codes can be multiplied on the PUSCH signal, and multiple UEs can be multiplexed on the same time-frequency domain resource, thereby improving system capacity and throughput. However, in the existing protocol, there are many scenarios that do not consider the OCC function, causing many problems, for example: 1. After enabling OCC for PUSCH, the relationship with the existing repetition transmission mechanism; 2. After enabling OCC function within a symbol, the redundancy version (RV) system bit number is insufficient due to discrete fourier transform (DFT); 3. Multiplexing problem of UCI; 4. TBS calculation of Transport Block with Multiple Slots (TBoMS); 5. Scheduling problem of multi-UE uplink transmission; 6. Resource configuration problem of RACH-less early data transmission (EDT) in IoT NTN, etc. Based on this, the embodiments of the present application will provide corresponding solutions based on the above problems.

[0026] For problem 1, if OCC is implemented by extension, it will be implemented by repeat, and the extended elements are multiplexed on the OCC sequence. In this case, the extension acts as a repetition function. For example, taking slot OCC as an example, it will be repeated according to the length of the OCC sequence. At this time, whether the repetition number configured by the system needs to be enabled; if the repetition number needs to be enabled, when the final repetition number does not consider the OCC function, the final repetition number is scaled according to the length of the OCC sequence, for example: the OCC sequence length is 2, and the configured repetition number is 2, then the final repetition number is 4; if the repetition number is enabled and the OCC extension length is considered, the actual repetition number needs to be divided by the OCC sequence length, for example: the OCC sequence length is 2, and the configured repetition number is 8, then the repetition number is 3; or the OCC sequence length is 2, and the configured repetition number is 2, then no additional repetition transmission is needed; if the repetition number is not enabled, the OCC enables the repeat function. Therefore, the relationship between the sequence length and the repetition number needs to be determined.

[0027] Therefore, the embodiments of the present application provide a communication method for determining the relationship between the OCC sequence length and the repetition number after enabling OCC for PUSCH, please refer to FIG. 1, which is an example diagram of a possible communication method provided by the embodiments of the present application, specifically including:

[0028] 101. The base station sends first configuration information to the UE, wherein the first configuration information is used to determine the repetition function when the PUSCH enables OCC;

[0029] 102. The UE sends a PUSCH to the base station.

[0030] Rules can be defined to disable the repeat transmission function when OCC is enabled. Optionally, the base station carries the OCCIndicateRep parameter in the first configuration information. This parameter is used to trigger whether to execute the repeat transmission function by enabling it. The first information can be carried in at least one of RRC signaling, medium access control-control element (MAC-CE), downlink control information (DCI), system information block (SIB), and random access response (RAR), without being limited here. Specifically, the OCCIndicateRep parameter is configured in PUSCH-Config or ConfiguredGrantConfig in PUSCH configuration. The parameter configuration can be: OCCIndicateRep ENUMERATED{enabled,disabled}.

[0031] Optionally, in this embodiment of the application, to disable the repetition function, the base station can also adjust the repetition number parameter numberofRepetitions or repk in PUSCH-Config or ConfiguredGrantConfig to configure the repetition number as 0, or not configure the repetition number.

[0032] When both OCC and retransmission functions are enabled on the PUSCH, i.e., the parameter OCCIndicateRep indicates that the retransmission function is triggered, the UE needs to determine the number of retransmissions of the PUSCH. This can be done in the following ways:

[0033] 1. After enabling the repeat transmission function, the PUSCH extended by OCC is transmitted repeatedly as a whole. The total number of repetitions needs to be scaled according to the extension factor. For example: configure the OCC sequence length parameter (i.e., extension factor) and the number of repetitions in RRC, or indicate the OCC sequence length parameter in MAC-CE. Let the OCC sequence length parameter be N and the configured number of repetitions be M, then the actual number of repetitions is determined to be N*M. For example: if the OCC sequence length is 2 and the configured number of repetitions is 2, then the actual number of repetitions is 4.

[0034] 2. Enable the repetitive transmission function. The total number of repetitions is based on scheduling, and the number of repetitions configured in RRC includes the number of repetitions extended by OCC. After enabling the OCC function, RRC configures the OCC sequence length or MAC-CE indicates the OCC sequence length. The UE determines the number of repetitions required after OCC extension based on the sequence length and the number of repetitions. For example: if the configured number of repetitions is K and the OCC sequence length is N, then after enabling the OCC function, ceil(K / N-1) or ceil(K / N)-1 repetitions are required. The ceil function is a rounding function. For example: if the OCC sequence length is 2 and the configured number of repetitions is 4, then the number of PUSCH repetitions after enabling OCC is 1; if the OCC sequence length is 2 and the configured number of repetitions is 2, then no repetition transmission is required.

[0035] In summary, after enabling the OCC function in PUSCH, you can choose to disable the repeat transmission function, such as by configuring the RRC trigger function or changing the repeat count configuration to 0 or not configuring the repeat count; or you can enable the repeat transmission function and explicitly or implicitly indicate the actual repeat count.

[0036] Regarding question 2, for intra-symbol OCC, if the spread factor is n, only one of the n subcarriers contains information. This will result in the output sequence length of the rate matching being too short and lacking sufficient system bits, which directly affects RV cycling.

[0037] To address this issue, this application provides a mapping method to resolve the problem of insufficient system bits caused by enabling the OCC function within a symbol. Specifically,

[0038] 1. Define frequency domain-based mapping rules

[0039] The frequency domain resource allocation (FDRA) specifies the starting position of the frequency domain resources on the RV ring. The frequency domain resources are grouped according to the OCC sequence length, and the starting bit index of each group is determined by a mapping rule. System bits are distributed across each group of frequency domain resources. The mapping rule is as follows: k0=(k'0+H+τ)modN cb

[0040] Where k0 represents the starting bit index of the frequency domain resources of the other groups except the first group, k'0 represents the starting bit index of the previous group, H represents the total number of available bits of the original sequence occupied in the previous group, τ represents the number of filter bits skipped and the number of bits occupied by UCI multiplexing in the previous group, and N represents the total number of bits occupied by UCI multiplexing in the previous group. c ' b This indicates the length written to the buffer.

[0041] It should be noted that in this embodiment, the frequency domain resource can be a resource block (RB) or a resource element (RE). The number of frequency domain resources is configured as N, the OCC sequence as M, and the number of groups as ceil(N / M). For example, if the FDRA is configured with 6 RBs and an OCC sequence length of 2, the RB resources can be divided into 6 / 2 = 3 groups. The starting bit position of the RV0 version in the data buffer is 0. The system bits occupied by the RV are divided into 3 groups, each group corresponding to a part of the RV0 system bits. The 3 groups are connected in sequence (e.g., if the total number of bits is 90, the first group maps 1-30, the second group maps 31-60, and the third group maps 61-90) to form the complete system bits of RV0. For a single RB, the frequency domain resource is the RE within the RB, and the OCC sequence is 2. The RE resources can be divided into 12 / 2 = 6 groups, each group corresponding to a part of the RV0 system bits. The 6 groups are connected in sequence to form the complete system bits of RV0.

[0042] 2. Additional system bits on extra frequency domain resources

[0043] Without altering the RV mapping, system bits can be supplemented in the time or frequency domain. Specifically, an additional frequency domain resource, such as one or more RBs, can be configured within the FDRA of a symbol to supplement the system bits lost during the DFT process onto the configured additional RB resource; or system bits can be supplemented by configuring one or more additional RBs within the symbol of an adjacent symbol.

[0044] Regarding question 3, UCI can be transmitted via PUCCH or PUSCH. When a single PUCCH and repeatedly transmitted PUSCHs overlap, UCI will multiplex the overlapping PUSCHs. However, current UCI multiplexing rules do not consider the scenario where PUSCHs utilize OCC functionality. Therefore, this application proposes solutions for different granularities of OCC schemes, including scenarios based on different time and frequency domains, and scenarios where the overlapping portion appears in different locations, as detailed below:

[0045] Please refer to Figure 2, which is a flowchart illustrating a communication method provided in an embodiment of this application, including:

[0046] 201. The base station sends the fourth configuration information to the UE. The fourth configuration information carries the UCIMul parameter, which is used to determine the UCI multiplexing function when PUSCH enables OCC.

[0047] 202. The UE sends a PUSCH to enable OCC;

[0048] 203. UE sends PUCCH.

[0049] The base station sends fourth configuration information to the UE via RRC or DCI. This fourth configuration information carries the UCIMul parameter, which is used to determine the UCI multiplexing function when OCC is enabled for PUSCH. The specific parameter configuration can be UCIMul ENUMERATED{enabled, disabled}. Based on the received fourth configuration information, the UE sends PUSCH and PUCCH to the base station. When there is overlap between the transmissions of PUCCH and PUSCH, UCI multiplexing is performed on the PUSCH overlap portion. In this embodiment, a solution is provided based on UCI multiplexing at both the time slot and symbol levels to maintain orthogonality.

[0050] First, we will discuss the case where the UCI multiplexing function is also enabled when the UCIMul parameter indicates that PUSCH enables OCC.

[0051] A. UCI multiplexing after OCC is enabled in a time slot

[0052] Understandably, after enabling OCC, in order to maintain orthogonality, it is necessary to keep the repeating units of the reused OCC sequence the same.

[0053] a. When the overlap of PUCCH and PUSCH appears in the PUSCH of the first multiplexed OCC, and the multiplexed HARQ-ACK is greater than 2 bits;

[0054] For slot-level OCC multiplexing, if the OCC function is enabled, the multiplexed UCI and the information are enabled together and the OCC sequence is multiplexed together. The number of repeated transmissions is consistent with the number of repetitions of PUSCH or the length of the OCC sequence.

[0055] Alternatively, the PUCCH can be transmitted n times, with the number of transmissions n being consistent with the number of PUSCH repetitions or the length of the OCC sequence, so that the PUCCH and PUSCH completely overlap after the transmission.

[0056] b. When the overlapping portion is within the PUSCH of the first multiplexed OCC, and the multiplexed HARQ-ACK is no greater than 2 bits;

[0057] When multiple HARQ-ACKs have fewer than 2 bits, they can be transmitted directly by punching holes in the PUSCH or multiplexed Channel State Information (CSI). The punched PUSCH is then repeatedly transmitted or OCC extended. This ensures that each repeated PUSCH is punched at the same location as the first multiplexed PUSCH, without affecting orthogonality. For example, according to the multiplexing rules, CSI is divided into part 1 and part 2, starting from the first non-demodulation reference signal (DMRS) symbol. The HARQ-ACK will be mapped to the first symbol after the DMRS. When the positions of CSI part 2 and HARQ-ACK conflict, HARQ-ACKs can be directly punched and multiplexed.

[0058] c. When the overlapping portion of PUCCH and PUSCH does not appear in the PUSCH of the first multiplexed OCC;

[0059] By delaying the UCI multiplexing slot. Specifically, the multiplexing of UCI is delayed to other slots. Specifically, the multiplexing of UCI can be postponed to the first PUSCH after the last symbol of an overlapping OCC span, or to the first PUSCH of the next OCC span, or, with the first PUSCH within the OCC span as a reference point, the UCI can be multiplexed on the (N+1)th PUSCH, or, with the PDCCH slot M used for scheduling PUSCH as a reference, the UCI can be multiplexed on slots M+K2+N+1, where M+K2 represents the slot where the scheduled PUSCH transmission is located, N represents the length of the OCC sequence, and the OCC span is associated with the length of the OCC sequence. If, at this time, the UCI is multiplexed on the first PUSCH of the next OCC span (which also enables OCC functionality), methods a and b above can be used, and will not be elaborated further here.

[0060] B. UCI multiplexing based on symbol-level OCC enabling

[0061] a. When CSI and HARQ-ACK are carried on the UCI, and the OCC application is based on symbol groups.

[0062] If UCI carries both CSI and HARQ-ACK, CSI is divided into two parts, CSIPart1 and CSIPart2, and mapping will begin on the first non-DMRS symbol. HARQ-ACK will begin mapping on the first symbol after DMRS. If symbol group-level OCC is applied at this time, and each symbol group occupies the first four symbols, then this symbol group will be extended and repeatedly transmitted. To improve transmission capacity and efficiency, the parameter ScalingOCCSymbol can be configured in PUSCH-Config or ConfiguredGrantConfig to indicate the proportion of UCI occupied in the OCC symbol group or TBS. For example, the value of this parameter ScalingOCCSymbol can be f0p25, f0p50, f0p75, and f1, representing occupancy rates of 25%, 50%, 75%, and 100%, respectively. The specific value can be set according to the actual scenario and is not limited here. In addition, the base station configures a threshold for the number of bits occupied by UCI. If this preset threshold is exceeded, it is considered that too many bits are occupied by UCI multiplexing. For example, in practical applications, the preset threshold value can be set to 50%, 60%, or other values. When the preset threshold for occupied bits is exceeded, in order to ensure normal transmission, the information in the multiplexed UCI can be selectively multiplexed according to preset rules so that the ScalingOCCSymbol parameter corresponding to the selected multiplexed information is less than the preset threshold value. The information in the multiplexed UCI includes, but is not limited to, one or more of the following: HARQ-ACK, CSI, where CSI is divided into CSIPart1 and CSIPart2. In the embodiments of this application, the information in UCI can be selectively multiplexed according to the following rules: the information to be multiplexed is determined according to the priority of each piece of information in the multiplexed UCI from high to low. For example, according to the priority in the existing protocol, HARQ-ACK > CSIPart1 > CSIPart2, selective multiplexing can be performed according to this priority, multiplexing one or more of HARQ-ACK or CSIPart1 or CSIPart2 to meet the bit occupancy ratio during normal transmission.

[0063] Alternatively, the information can be sorted by the number of bits occupied by each piece of information in the UCI to determine the information to be reused, and one or more of HARQ-ACK, CSIPart1, or CSIPart2 can be reused to ensure normal transmission.

[0064] b. UCI carries CSI and HARQ-ACK, while OCC functionality is based on a single symbol.

[0065] Since there is only one symbol at this time, the existing mapping rules for CSI and HARQ-ACK are no longer applicable. In order to ensure normal transmission, the UCI multiplexing function is no longer enabled.

[0066] The above discussion addressed the scenario where the UCI multiplexing function is enabled when the UCIMul parameter instructs the PUSCH to enable OCC. In this embodiment, the UCIMul parameter can be configured to disable the UCI multiplexing function when preset conditions are met. These preset conditions include, but are not limited to, the following: the priority of the OCC function is higher than the priority of the UCI multiplexing function; the overlapping portion is not within the PUSCH of the first multiplexed OCC; or the OCC function is based on a single symbol. When the preset conditions are met, the UCI multiplexing function is disabled.

[0067] Regarding question 4 concerning the TBS calculation for TBoMS, after the PUSCH applies the OCC function, the number of time slots indicated by the Time Domain Resource Allocation (TDRA) is after OCC is enabled. Therefore, the existing TBS calculation method for TBoMS needs to be adjusted. Based on this, this application provides a method to adjust the calculation rules for the number of available REs within a transmission time unit and associate it with the OCC extension factor. Specifically, as follows:

[0068] Define the calculation rules: First, the UE needs to calculate the number of available REs within a single PRB used for PUSCH transmission.

[0069] in This represents the number of subcarriers in the frequency domain. This indicates the number of symbols configured for the PUSCH. This represents the overhead of DMRS when there is no data allocated during the time interval. This indicates the overhead of configuring high-level parameters; if not configured, it is usually 0.

[0070] Next, the UE calculates the number of available REs within the transmission time unit, indicated by numberOfSlotsTBoMS, N. RE =ceil[N / L*min(156,N′)] RE )·n PRB ] or N RE =ceil[N / L]*min(156,N′) RE )·n PRB ,

[0071] Where N RE This represents the number of available REs within a time unit, L represents the OCC sequence length, N represents the number of time slots used for TBoMS, and n PRB This represents the total number of PRBs for the UE.

[0072] In this embodiment of the application, the number of available REs within a time unit is associated with the length of the OCC sequence.

[0073] Furthermore, the indication of the OCC sequence length can be implicitly indicated or explicitly indicated in this embodiment. Specifically, since the number of available REs can be scaled based on the OCC sequence length, the OCC sequence length is directly associated with the scaling factor in an implicit manner; the explicit indication can be configured directly through RRC signaling using the scaling factor Scalingfactor, or by indicating the scaling factor Scalingfactor through MAC-CE, to instruct the UE to scale the number of available REs. The configuration method can be: Scalingfactor ENUMERATED{n2,n4,n8}.

[0074] It is important to note that for PUSCH Type A and TBoMS multi-slot repetitive transmissions, if at least one PUSCH transmission symbol indicated by the index row of the time-domain resource allocation table overlaps with a DL symbol or an SSB block symbol (unavailable symbol) indicated by ssb-PositionsInBurst, then that slot is not counted in the N*K slots of the PUSCH repetitive transmission. However, when applying inter-symbol OCC based on TBoMS, the total number of symbols in the inter-symbol OCC scheme is related to the spread factor, which is equal to the number of symbols indicated in the TDRA multiplied by the scaling factor. This can lead to a situation where symbols before OCC expansion do not overlap with DL or unavailable symbols, but overlap after OCC is enabled, making the existing counting method unsuitable for PUSCHs with OCC enabled. Based on this, this application's embodiments, considering that the count of available slots after OCC is enabled needs to take into account the spread factor, also propose a solution, which may include the following:

[0075] 1. Skip unavailable time slots based on predetermined rules. That is, when OCC is enabled, if there is a conflict with downlink symbol resources or synchronization signal / PBCH block (SSB) reception or an unavailable symbol is encountered, the PUSCH retransmission will be postponed to the next conflict-free time slot.

[0076] 2. Based on configuration information, specifically, the symbol number configuration in the TDRA configuration can be adjusted. That is, for the number of symbols allocated in TDRA, considering the expansion factor, the total number of symbols is the original configured number of symbols M multiplied by the expansion factor or the OCC sequence length L.

[0077] 3. Define an available time window and calculate available time slots only within that time window.

[0078] Regarding question 5, downlink transmission requires multiple downlink control information (DCI) messages for scheduling downlink transmission, and each UE needs a separate DCI message for scheduling. Therefore, in order to achieve efficient scheduling of multiple UEs, two solutions are proposed: (1) using common DCI messages to call multiple UEs; (2) enabling OCC function on the PDCCH channel, that is, multiple DCI messages are multiplexed on the same time-frequency resource segment.

[0079] The following will describe them separately.

[0080] (1) Using common DCI to call multiple UEs

[0081] Please refer to Figure 3, which is a flowchart of a possible scheduling method provided in an embodiment of this application, for base station scheduling multiple UEs to transmit PUCCHs that enable OCC, including:

[0082] 301. The base station sends the common DCI;

[0083] 302. The base station sends configuration information;

[0084] 303. The UE determines the corresponding target subdomain based on the common DCI and configuration information.

[0085] When PUSCH enables OCC functionality, the OCC-Scheme parameter is configured in the PUSCH-Config or ConfiguredGrantConfig sent by the base station to indicate the OCC scheme. The OCC-Scheme parameter can take the values ​​{scheme0, scheme1, scheme2}, representing the inter-slot, inter-symbol, and intra-symbol OCC schemes, respectively. The OCC-Length parameter is also configured to indicate the OCC sequence length, with values ​​{2, 4, 8}. Different OCC sequence lengths are associated with OCC sequence tables of different lengths. In this embodiment, a common DCI is used to schedule one or more PUSCHs for multiple UEs, and the GU-Radio Network Temporary Identity (RNTI) is used for scrambling. The GU-RNTI is transmitted to the UE in the system message, and the RNTI is the same for each group of UEs. The common DCI scrambled by the GU-RNTI includes a shared information domain and a unique information domain. The shared information domain is shared among the N UEs, and the unique information domain is not shared among the N UEs. The unique information domain is divided into N target subdomains, each corresponding to one of the N UEs; alternatively, block information corresponding to each UE is transmitted within the unique information domain. To enable the UE to determine the corresponding target subdomain within the unique information domain, a subdomain index parameter is configured in the configuration information and sent to the UE.

[0086] In practical applications, the common DCI includes the following fields: FDRA, TDRA, Frequency Hopping flag, MCS, RV, HARQ, Transform precoder indicator, Transmit power control (TPC), and Sounding Reference Symbols (SRS) resource set. To enable the invocation of common DCI in an OCC-enabled PUSCH scenario, in this embodiment, the unique information field includes at least the OCC-Index field. Possibly, the unique information field may also include one or more of the following: MCS field, RV field, HARQ field, and TPC field.

[0087] To facilitate a better understanding of this scheme, the following descriptions will focus on the different information included in the unique information domain.

[0088] a. When the unique information field is the OCC-Index field

[0089] The OCC-Index field is used to indicate the OCC sequence that the UE needs to reuse. Due to the OCC mechanism, multiple UEs can reuse the same time-frequency resources. Therefore, the time-frequency resources of different UEs can be shared. FDRA, TDRA, MCS, HARQ, and RV configurations can be shared among multiple UEs. However, different UEs reuse different OCC sequences and need to be configured separately. Here, the OCC-Index field can be split into several subfields, such as OCC-Index 1, OCC-Index 2, ..., OCC-Index N, each associated with a UE, representing the index of the OCC sequence of different UEs. The configuration parameter OCC-PUSCH is used to instruct the UE to select its own OCC sequence through RRC signaling, ignoring the information of other OCC-Index fields. The configuration parameter can be configured as: OCC-PUSCH SetupRelease{PUSCH-OCC-CommandConfig}.

[0090] Alternatively, the following information can be transmitted in the OCC-Index domain:

[0091] OCC Block number 1, OCC Block number 2,..., OCC Block number N

[0092] N represents the number of UEs. The configuration parameter OCC-PUSCH is sent to the UE via RRC signaling to select its own OCC sequence, while ignoring block information in other OCC-Index fields.

[0093] b. When the unique information domains are the OCC-Index domain and the MCS domain

[0094] To configure different MCS and OCC sequences for multiple UEs, the MCS field is divided into several subfields: MCS1, MCS2, ..., MCSN. The OCC-Index field is divided into several subfields: OCC-Index1, OCC-Index2, ..., OCC-IndexN, where N represents the number of UEs. These subfields represent the indices of the MCS and OCC sequences for different UEs. The configuration parameters MCS-PUSCH and OCC-PUSCH are used to indicate the corresponding MCS and OCC sequence fields for each UE via RRC signaling, while information from other MCS and OCC-Index fields is ignored.

[0095] Alternatively, the following information can be transmitted in the OCC-Index domain:

[0096] OCC Block number 1, OCC Block number 2,..., OCC Block number N

[0097] Transmit the following information in the MCS domain

[0098] MCS Block number 1, MCS Block number 2,..., MCS Block number N

[0099] RRC signaling uses the parameters MCS-PUSCH and OCC-PUSCH to indicate the specific index of the block number. After receiving the configured block number, each UE reads the MCS and OCC configurations within the block and ignores other block information. Specific parameter configurations can be as follows:

[0100] OCC-PUSCH SetupRelease{PUSCH-OCC-CommandConfig}

[0101] MCS-PUSCH SetupRealease{PUSCH-MCS-CommandConfig}

[0102] c. When the unique information domain is the OCC-Index domain, MCS domain, or RV domain

[0103] To configure different RV, MCS, and OCC sequences for different UEs' PUSCH, the RV field is divided into several subfields: RV1, RV2, ..., RVN; the MCS field is divided into several subfields: MCS1, MCS2, ..., MCSN; and the OCC-Index field is divided into several subfields: OCC-Index1, OCC-Index2, ..., OCC-IndexN, where N represents the number of UEs. These subfields represent the RV, MCS, and OCC sequence indices for different UEs. The configuration parameters RV-PUSCH, MCS-PUSCH, and OCC-PUSCH are used to indicate the corresponding RV, MCS, and OCC sequence fields for each UE via RRC signaling, while ignoring information from other RV, MCS, and OCC-Index fields.

[0104] Alternatively, the following information can be transmitted in the OCC-Index domain:

[0105] OCC Block number 1, OCC Block number 2,..., OCC Block number N

[0106] Transmit the following information in the MCS domain

[0107] MCS Block number 1, MCS Block number 2,..., MCS Block number N

[0108] Transmit the following information in the RV domain

[0109] RV Block number 1, RV Block number 2,..., RV Block number N

[0110] RRC signaling uses the parameters RV-PUSCH, MCS-PUSCH, and OCC-PUSCH to indicate the specific index of the block number. After receiving the configured block number, each UE reads the MCS and OCC configurations within the block and ignores other block information. Specific parameter configurations can be as follows:

[0111] OCC-PUSCH SetupRelease{PUSCH-OCC-CommandConfig}

[0112] MCS-PUSCH SetupRealease{PUSCH-MCS-CommandConfig}

[0113] RV-PUSCH SetupRealease{PUSCH-RV-CommandConfig}

[0114] d. When the unique information domain is the OCC-Index domain, MCS domain, RV domain, or HARQ domain

[0115] To configure different RV, MCS, HARQ, and OCC sequences for different UEs' PUSCH, the RV field is divided into several subfields: RV1, RV2, ..., RVN; the MCS field is divided into several subfields: MCS1, MCS2, ..., MCSN; the HARQ field is divided into several subfields: HARQ1, HARQ2, ..., HARQN; and the OCC-Index field is divided into several subfields: OCC-Index 1, OCC-Index 2, ..., OCC-Index N, where N represents the number of UEs. These subfields represent the RV, MCS, and OCC sequence indices for different UEs. The configuration parameters RV-PUSCH, MCS-PUSCH, and OCC-PUSCH are used to indicate the corresponding RV, MCS, and OCC sequence fields for each UE via RRC signaling, while ignoring information from other RV, MCS, and OCC-Index fields.

[0116] Alternatively, the following information can be transmitted in the OCC-Index domain:

[0117] OCC Block number 1, OCC Block number 2,..., OCC Block number N

[0118] Transmit the following information in the MCS domain

[0119] MCS Block number 1, MCS Block number 2,..., MCS Block number N

[0120] Transmit the following information in the RV domain

[0121] RV Block number 1, RV Block number 2,..., RV Block number N

[0122] Transmit the following information in the HARQ domain

[0123] HARQ Block number 1, HARQ Block number 2,..., HARQ Block number N

[0124] RRC signaling uses the parameters RV-PUSCH, MCS-PUSCH, HARQ-PUSCH, and OCC-PUSCH to indicate the specific index of the block number. After receiving the configured block number, each UE reads the MCS and OCC configurations within the block and ignores other block information. Specific parameter configurations can be as follows:

[0125] e. When the unique information domain is the OCC-Index domain, MCS domain, RV domain, HARQ domain, or TPC domain.

[0126] To enable different RV, MCS, HARQ, and OCC sequences for the PUSCH of different UEs, the RV field is divided into RV1, RV2, ..., RVN; the MCS field is divided into MCS1, MCS2, ..., MCSN; the HARQ field is divided into HARQ1, HARQ2, ..., HARQN; the TPC field is divided into TPC1, TPC2, ..., TPCN; and the OCC-Index field is divided into OCC-Index 1, OCC-Index 2, ..., OCC-Index N. N fields, where N represents the number of UEs, represent the RV, MCS, and OCC sequence indexes of different UEs respectively. The configuration parameters RV-PUSCH, MCS-PUSCH, and OCC-PUSCH are used to indicate the RV, MCS, and OCC sequence fields of the UE through RRC signaling, while ignoring other RV fields, MCS fields, and OCC-Index fields.

[0127] Alternatively, the following information can be transmitted in the OCC-Index domain:

[0128] OCC Block number 1, OCC Block number 2,..., OCC Block number N

[0129] Transmit the following information in the MCS domain

[0130] MCS Block number 1, MCS Block number 2,..., MCS Block number N

[0131] Transmit the following information in the RV domain

[0132] RV Block number 1, RV Block number 2,..., RV Block number N

[0133] Transmit the following information in the HARQ domain

[0134] HARQ Block number 1, HARQ Block number 2,..., HARQ Block number N

[0135] Transmit the following information in the TPC domain

[0136] TPC Block number 1, TPC Block number 2,..., TPC Block number N

[0137] RRC signaling uses the parameters RV-PUSCH, MCS-PUSCH, HARQ-PUSCH, and OCC-PUSCH to indicate the specific index of the block number. After receiving the configured block number, each UE reads the MCS and OCC configurations within the block and ignores other block information. Specific configurations can be:

[0138] The above describes a single-level DCI for scheduling multiple UEs. In this embodiment, a two-level DCI scheduling method can also be used. The first-level DCI is a UE-specific DCI associated with the second-level DCI. The second-level DCI uses a group common DCI to indicate the corresponding OCC sequence for different UEs. Details are as follows:

[0139] Similarly, in PUSCH-Config or ConfiguredGrantConfig, the configuration parameter OCC-Scheme indicates the OCC scheme, and the parameter OCC-Length indicates the OCC sequence length used to determine the mapping table of OCC sequences. A group-common DCI and OCC-PUSCH-RNTI are designed and used in conjunction with a UE-specific DCI. The UE-specific DCI transmits scheduling information for legacy UEs, including TDRA, FARA, MCS, and HARQ processes, and is associated with the group-common DCI. The UE-specific DCI contains resource location information from the group-common DCI. OCC-PUSCH-RNTI is configured by the base station, with a value range of 0001-FFF2. The group-common DCI is scrambled by OCC-PUSCH-RNTI to indicate the corresponding target subdomain in the unique information domain. For example, when the unique information field is OCC-index, the group common DCI is used to indicate the index of the OCC sequence that a group of UEs need to reuse. The group common DCI can transmit the following information: block number 1, block number 2, ..., block number N, where N represents the number of UEs and occupies ceil(log2(N)) bits. The RRC signaling will indicate the specific index of the block number through the parameter OCC-PUSCH. After each UE receives the configured block number, it reads the OCC instruction in the block and ignores other block information.

[0140] The above describes the efficient scheduling of multiple UEs using common DCI. Since the satellite beam has a large coverage area, a large number of UEs exist within that area, and the aggregation level is not high, the downlink channel is also a constrained channel. Therefore, in this embodiment, the PDCCH channel is enhanced by using OCC to multiplex multiple PDCCHs on the same time-frequency resource segment, thereby improving scheduling efficiency.

[0141] To enable OCC functionality on the PDCCH channel, configuration information is required. The parameters to be configured include the OCC scheme, OCC sequence length, and OCC sequence index. The OCC scheme includes inter-slot OCC, inter-symbol OCC, and intra-symbol OCC. The OCC sequence length is associated with OCC sequence tables of different lengths, and the OCC sequence index represents the specific OCC sequence in the table. Details are as follows:

[0142] Configure the sequence index in PUSCH-Config. Similar to PDSCH, some OCC-related parameters are also configured in PDCCH-Config, including the OCC scheme OCC-Scheme and the OCC sequence length OCC-Length. If OCC-Scheme indicates OCC-Scheme0, it represents inter-slot OCC; if it indicates OCC-Scheme1, it represents inter-symbol OCC; and if it indicates OCC-Scheme2, it represents intra-symbol OCC. OCC-Length indicates the OCC sequence length and is associated with the corresponding OCC table, with values ​​{2, 4, 8}. Additionally, the parameter OCC-Index is configured in PUSCH-Config. OCC-Index indicates the index of the OCC sequence and, through the UE-specific RRC instruction OCCIndexIndicate, instructs the UE to use the corresponding OCC sequence to receive the PDCCH. Specific parameter configurations can be as follows:

[0143] Configure the OCC-Scheme and OCC-Length parameters in PDCCH-config.

[0144] OCC-Scheme SetupRelease{PUSCH-OCCScheme-CommandConfig}

[0145] OCC-Length SetupRealease{PUSCH-MCS-CommandConfig}

[0146] Configure the OCC-Index parameter in PUSCH-Config.

[0147] OCC-Index INTEGER{0,...,7}

[0148] Optionally, sequence tables and sequence indices can also be configured in PUSCH-Config. Some OCC-related parameters, including the OCC scheme OCC-Scheme, are configured in PDCCH-Config. If OCC-Scheme indicates OCC-Scheme0, it represents inter-slot OCC; if it indicates OCC-Scheme1, it represents inter-symbol OCC; and if it indicates OCC-Scheme2, it represents intra-symbol OCC. The parameters OCC-Length and OCC sequence index OCC-Index are configured in PUSCH-Config. OCC-Length indicates the OCC sequence length and is associated with a corresponding OCC table, taking values ​​{2, 4, 8}. OCC-Index represents the index of the OCC sequence. The UE-specific RRC instruction OCCLengthIndicate instructs the UE to use a sequence table of the corresponding length, and OCCIndexIndicate instructs the UE to use the corresponding OCC sequence to receive the PDCCH. Specific parameter configurations can be as follows:

[0149] Configure the OCC-Scheme parameters in PDCCH-config.

[0150] OCC-Scheme SetupRelease{PUSCH-OCCScheme-CommandConfig}

[0151] Configure the OCC-Index parameter in PUSCH-Config.

[0152] OCC-Length INTEGER{2,4,8}

[0153] OCC-Index INTEGER{0,...,7}

[0154] In summary, to enable OCC functionality on the PDCCH channel, a sequence index can be configured in PUSCH-Config, and a UE-specific RRC command can indicate the OCC sequence; alternatively, the sequence length and sequence index can be configured in PUSCH-Config, and a UE-specific RRC command can indicate the OCC sequence table and the OCC sequences in the table.

[0155] Regarding question 6, concerning the resource configuration issue of RACH-less EDT in IoT NTN, when using broadcast messages to transmit common configuration data to configure the UE, different UEs will share the same MCS configuration. The advantage is that resource configuration is not required in RRC connected state. However, since a unified resource pool is configured, rules need to be defined to allow the UE to select the corresponding configuration resources, improving resource utilization efficiency. Furthermore, since only a unified resource pool is configured, resource conflict issues still need to be considered. To solve this problem, please refer to Figure 4, a flowchart of a possible resource configuration method provided in an embodiment of this application, including the following steps:

[0156] 401. The base station broadcasts the configuration information of the common resource pool;

[0157] 402. The UE receives the first target system information sent by the base station;

[0158] 403. The UE determines the corresponding target group ID based on the value of the first target system information;

[0159] 404. When the target packet ID is contained in the ID information of each packet resource pool, the UE sends and receives information based on the packet resources corresponding to the target packet ID.

[0160] Within the base station coverage area, a common resource pool is configured for all UEs, and the configuration information of the common resource pool is broadcast. The common resource pool is divided into M groups based on the target system information. The configuration information of the common resource pool includes the ID information of each group resource. It should be noted that in practical applications, the target system information can be the reference signal received power (RSRP), signal to interference plus noise ratio (SINR), or reference signal received quality (RSRQ) of the SSB. The number of common resource pools can be single or multiple; the following will describe different scenarios:

[0161] When there is only one common resource pool, the grouping is based on the value range of the target system information, with each group corresponding to a different range of target system information. After receiving the first target system information, the UE determines the corresponding target group ID based on its value. Specifically, this includes determining the range of the first target system information value and determining the ID information of the target group resource corresponding to that range as the target group ID. When the target group ID is included in the ID information of each group resource pool, the UE sends and receives information based on the group resource corresponding to the target group ID. For example, based on the RSRP, SINR, or RSRQ of the SSB, the common resources (e.g., time domain, frequency domain, or time-frequency domain) are divided into M groups, each corresponding to a fixed range of RSRP, SINR, or RSRQ, with each group associated with an ID. The resource pool configuration information sent in the system message includes group ID information. When the UE determines that the corresponding group ID is the same as the group ID in the configuration information of a certain resource pool based on the received RSRP, SINR, or RSRQ value, the UE can use that sending resource pool. For example, according to RSRP, common resources need to be divided into 4 groups. This can be done by dividing time-domain resources into 4 groups, or frequency-domain resources into 4 groups, or by dividing time-domain resources into 2 groups and frequency-domain resources into 2 groups.

[0162] Optionally, the configuration information may also include a set of MCS values. Each MCS value in the MCS set indicates the corresponding MCS configuration, and each MCS is associated with the ID information of each group resource. Therefore, after the UE determines the target group ID, it also determines the corresponding target MCS configuration based on the target group ID. For example, a common resource pool is configured for all UEs within the base station coverage area, and a set of modulation and coding scheme (MCS) values ​​are configured. This set of MCS values ​​is divided according to the RSRP, SINR, or RSRQ of the SSB. Each MCS value corresponds to an MCS configuration and is associated with a group ID. The resource pool information sent in the system message includes group ID information. When the group ID determined by the UE based on the received RSRP, SINR, or RSRQ value is the same as the group ID summarized in the configuration information of a certain resource pool, the UE can select the MCS configuration under the corresponding group ID. For example, taking MCS as an example, there are 8 RSRP values. If the common resources need to be divided into 4 groups, then the 8 RSRP values ​​are divided into 4 groups from largest to smallest. The corresponding MCS is also divided into 4 groups and associated with RSRP groups. Each group has different MCS values, including parameters such as modulation order, coding rate and frequency efficiency.

[0163] When there are M common resource pools, where M is greater than 1, the target system information is used as the basis for segmentation. Each common resource pool is associated with its corresponding target system information. In addition to the ID information of each common resource pool, the configuration information may also include one or more of the following: time-domain information, frequency-domain information, or MCS information corresponding to each common resource pool. For example, multiple common resources are configured for a UE within the base station coverage area, using the RSRP, SINR, or RSRQ of the SSB as the basis for segmentation. Each common resource includes configuration information such as time-domain, frequency-domain, or MCS. The resource pool configuration information sent in the system message includes the resource pool ID information. When the UE determines that the corresponding resource pool ID is the same as a certain resource pool ID based on the received RSRP, SINR, or RSRQ of the SSB, the UE uses that resource pool. For example, for the MCS, one or more parameters such as modulation order, coding rate, or spectral efficiency differ in the configuration of each Common MCS block, as shown in Table 1 below.

[0164] Table 1 MCS Grouping

[0165] For time-domain resource allocation, each block's common TDRA configuration has one or more different parameters, such as mapping type, timing offset, starting symbol within a time slot, or symbol length, as shown in Table 2 below.

[0166] Table 2 Time-Domain Resource Grouping Table

[0167] It should be noted that, unlike the typical UE-specific access process, a unified Common resource pool is configured. If multiple UEs select the same time frequency to transmit data, a conflict will occur. To reduce the probability of conflict, the embodiments of this application propose the following method:

[0168] Method 1: Use the method of listening first and then sending.

[0169] Before sending uplink data, the UE can listen to the channel. Data can only be uploaded if the channel listening result is idle. If the channel status is busy, it means the channel is occupied. The UE monitors the power within the channel; if it exceeds a threshold, the channel is considered occupied. As shown in Table 3, for dynamic channel listening, the `channelAccess` parameter is configured in the system message to indicate the channel access parameters, with values ​​{0, 1, 2, 3}. 0 represents a Type 2C channel access type with a cyclic prefix (CP) length of CP2, 1 represents a Type 2A channel access type with a CP length of CP3, 2 represents a Type 2A channel access type with a CP length of CP1, and 3 represents a Type 1 channel access type with a CP length of CP0. CP2, CP3, CP1, and CP0 are defined in the protocol, and C1, C2, and C3 are related to the subcarrier spacing. For the detection power threshold, the parameter `maxEnergyDetectionThreshold` is configured in the system message, with values ​​{-85...-52}, in dBm. Specific parameter configurations can be as follows:

[0170] Channelaccess INTER{0,1,2,3}

[0171] MaxEnergyDetectionThreshold Inter{-85...-52}

[0172] Table 3 Channel Access Methods and CPE Length

[0173] Alternatively, the terminal can send side-link control information to other devices, indicating the time-frequency resources to be used, including the N time-frequency resources currently being transmitted and retransmitted in the TB. Other terminals can then decode the control information to learn about and exclude the time-frequency resources reserved by other terminals, thereby avoiding resource collisions and improving communication reliability.

[0174] Method 2: The UE randomly selects different frequency points to transmit.

[0175] The base station configures frequency domain resources in the broadcast information and divides them into different frequency points. The UE randomly selects a frequency point to send uplink data, reducing the problem of not being able to receive data caused by conflicts in the same time slot.

[0176] Method 3: The UE transmits the same copy on different frequency points.

[0177] The base station configures frequency domain resources in the broadcast information, dividing them into different frequency points. The UE randomly selects different frequency points to send uplink data, but this can lead to reception conflicts on the same frequency in the same time slot. To solve this problem, the UE can randomly select N different frequency points, and send the same copy on each frequency point. For example, the UE can randomly select two frequency points from the different frequency points and send the same copy in different or the same time slots.

[0178] In summary, the UE sends msg3 PUSCH according to the corresponding configuration information. To reduce the probability of resource conflicts, the UE can take the following measures: 1. Listen before sending to check if the channel is occupied; 2. Select different frequency points to send; 3. Select different frequency points in the same or different time slots to send the copy.

[0179] It should be considered that, unlike the general UE-specific access process, the use of a unified configuration common resource pool may lead to conflicts if multiple UEs select the same time frequency to transmit data. Based on this, the embodiments of this application also propose the following conflict resolution solution:

[0180] Option a: After a conflict, the UE selects a time slot to retransmit.

[0181] The UE associates a temporary ID with the uplink data it sends. When the base station receives uplink data from multiple UEs in the same time slot, it uses the ACK mechanism to notify the UE whether the data has been successfully received. In order to avoid repeated collisions, the UE randomly selects a time slot to retransmit the data until there is no conflict.

[0182] Option b: After a conflict, notify the UE to retransmit at another time.

[0183] The UE associates a temporary ID with the uplink data it sends. When the base station receives uplink data from multiple UEs in the same time slot, it uses the ACK mechanism to notify whether the reception was successful. It also includes the time slot or frequency point for UE retransmission, which can be sent in different time slots, at the same frequency point in different time slots, or at different frequencies in different time slots.

[0184] In summary, the embodiments of this application provide specific solutions to multiple problems. For NR NTN communication systems, this application proposes enhanced resource configuration rules after introducing the OCC function, which can solve the problems of conflict between OCC and repetition, insufficient RV system bits caused by OCC enabling within a symbol, UCI multiplexing problems at different OCC granularities, effective RE calculation in TBoMS TBS calculation, and enhanced available time slot counting rules. For NTN communication systems, this application relates to a multi-UE scheduling method. By adopting the scheduling mode of common DCI and OCC-enabled PDCCH, it can improve the scheduling efficiency of multi-UEs and save scheduling overhead. For IoT NTN communication systems, this invention relates to a resource configuration method that can realize resource configuration of multiple UEs in non-RRC connected state and reduce the probability of resource conflict.

[0185] The figures above illustrate in detail the communication method, scheduling method, and resource allocation method provided in the embodiments of this application. Please refer to Figure 5, which is a storage diagram of the wireless communication device in the embodiments of this application. The storage medium 20 of the wireless communication device in the embodiments of this application stores instruction / program data 21. When the instruction / program data 21 is executed, it implements the method provided by any embodiment of the communication method of this application and any non-conflicting combination thereof. The instruction / program data 21 can be formed into a program file and stored in the storage medium 20 in the form of a software product, so that a computer device (which may be a personal computer, server, or network device, etc.) or processor can execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium 20 includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0186] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0187] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0188] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

[0189] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0190] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0191] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0192] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0193] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0194] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0195] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0196] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0197] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0198] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, 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.) to execute all or part of the steps of the methods described in 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.

[0199] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method for a user equipment (UE), comprising: The method comprises: sending a physical uplink shared channel (PUSCH) enabling an orthogonal cover code (OCC) function based on configuration information and / or a predefined rule, the configuration information comprises one or more of the following information: first configuration information, second configuration information, third configuration information, fourth configuration information, fifth configuration information, and sixth configuration information; the predefined rule comprises one or more of the following rules: a first predefined rule, a second predefined rule, and a third predefined rule.

2. The method of claim 1, wherein, Before the sending of the PUSCH enabling the OCC function, the method further comprises: receiving the first configuration information, which is used to determine a repetition transmission function when the PUSCH enables the OCC.

3. The method of claim 2, wherein, The first configuration information is carried in at least one of the following: RRC signaling, medium access control-control element (MAC-CE), downlink control information (DCI), system message block (SIB), and random access response (RAR).

4. The method of claim 3, wherein, The first configuration information carried on the RRC signaling or the MAC-CE carries an OCCIndicateRep parameter, which is used to trigger whether to perform the repetition transmission function in an enabling manner.

5. The method of claim 3, wherein, The first configuration information carries a repetition transmission number of 0. Or, the first configuration information does not configure the repetition transmission number.

6. The method of claim 4, wherein, When the OCCIndicateRep parameter indicates to perform the repetition transmission function, the method further comprises: determining an actual repetition number of repeatedly sending the PUSCH.

7. The method of claim 6, wherein, The RRC signaling carries an OCC sequence length parameter and a repetition transmission number. Or, the RRC signaling carries the repetition transmission number, and the MAC-CE indicates the OCC sequence length. The determination of the actual repetition number of repeatedly sending the PUSCH comprises: multiplying the OCC sequence length and the repetition transmission number to obtain the actual repetition number.

8. The method of claim 6, wherein, The RRC signaling carries a repetition number parameter, and the repetition transmission number is equal to an OCC sequence length. Or, the RRC signaling carries the repetition transmission number, and the MAC-CE indicates the OCC sequence length. The determination of the actual repetition number of repeatedly sending the PUSCH comprises: obtaining the actual repetition number according to a quotient of the repetition transmission number and the OCC sequence length.

9. The method of claim 1, wherein, Before the sending of the PUSCH enabling the OCC function, the method further comprises: receiving the second configuration information, which comprises an OCC sequence length.

10. The method of claim 9, wherein, The method further comprises determining a starting position of a frequency domain resource of a frequency domain resource allocation (FDRA) configuration on an RV cycle based on the first predefined rule, wherein the frequency domain resources are grouped according to the OCC sequence length, a starting bit index of each group of frequency domain resources is determined by the first predefined rule, and system bits are distributed on the each group of frequency domain resources.

11. The method of claim 10, wherein, The first predefined rule comprises that when the number of RV system bits is insufficient, the frequency domain resource is supplemented by FDRA configuration, and the supplemented frequency domain resource is a reconfigured resource within the symbol or a resource within a symbol adjacent to the symbol.

12. The method of claim 1, wherein, The method further comprises: sending a physical uplink control channel (PUCCH); when there is an overlapping part between the transmission of the PUCCH and the PUSCH, uplink control information (UCI) is multiplexed on the overlapping part of the PUSCH, and the PUCCH or the PUSCH is processed to maintain orthogonality.

13. The method of claim 12, wherein, The processing of the PUCCH or the PUSCH comprises: processing the PUCCH or the PUSCH by enabling OCC in a time slot; or, processing the PUSCH by enabling OCC within a symbol.

14. The method of claim 13, wherein, When the overlapping part is within the first multiplexed OCC PUSCH, and the multiplexed hybrid automatic repeat request response (HARQ-ACK) is greater than 2 bits, the multiplexed HARQ-ACK is included in the UCI, The processing of the PUCCH by enabling OCC in a time slot comprises: repeating the PUCCH n times, where n is the number of repetitions of the PUSCH or the length of the OCC sequence, and the repeated PUCCH is completely overlapped with the repeated PUSCH.

15. The method of claim 13, wherein, When the overlapping part is within the first multiplexed OCC PUSCH, and the multiplexed HARQ-ACK is greater than 2 bits, The processing of the PUSCH by enabling OCC in a time slot comprises: enabling the OCC function of the UCI and the information on the PUSCH to perform repeated transmission of the UCI, and the number of repeated transmissions of the UCI is equal to the number of repetitions of the PUSCH or the length of the OCC sequence.

16. The method of claim 13, wherein, When the overlapping part is within the first multiplexed OCC PUSCH, and the multiplexed HARQ-ACK is not greater than 2 bits, the processing of the PUSCH by enabling OCC in a time slot comprises: puncturing the multiplexed HARQ-ACK on the PUSCH and repeatedly transmitting the punctured PUSCH; or, puncturing the multiplexed HARQ-ACK on the multiplexed channel state information (CSI), and the multiplexed CSI is included in the UCI.

17. The method of claim 14, wherein, When the overlapping part is not within the first OCC-enabled PUSCH, the processing of the PUSCH by enabling OCC in a time slot comprises: delaying multiplexing of the UCI to a PUSCH in another time slot; or, delaying multiplexing of the UCI to a target time slot.

18. The method of claim 17, wherein, The PUSCH in the other time slot includes but is not limited to one of the following: the first PUSCH after the last symbol of the OCC span with overlapping, or, the first PUSCH of the next OCC span; or, the N+1th PUSCH with the first PUSCH in the OCC span as a reference point.

19. The method of claim 17, wherein, The target time slot includes an (M+K2+N+1)th time slot, with reference to a time slot M in which a physical downlink control channel (PDCCH) for scheduling a PUSCH is received; wherein M+K2 represents a time slot in which a scheduled PUSCH transmission is located, and N represents an OCC sequence length associated with an OCC span that exists overlap.

20. The method of claim 13, wherein, Before the PUSCH is processed by enabling OCC within a symbol, the symbol is a symbol group, and the method further includes: The third configuration information is received, and the third configuration information carries a ScalingOCCSymbol parameter, which is used to indicate a bit occupancy ratio of the UCI in an OCC symbol group or a TBS.

21. The method of claim 20, wherein, When the ScalingOCCSymbol parameter is greater than a preset threshold value, the processing of the multiplexed UCI by OCC expansion within a symbol includes: The information in the multiplexed UCI is selectively multiplexed according to a preset rule, so that the multiplexed information after selection corresponds to a ScalingOCCSymbol parameter that is less than the preset threshold value, The information in the UCI includes but is not limited to one or more of the following information: HARQ-ACK, CSI, wherein the CSI is divided into CSIPart1 and CSIPart2.

22. The method of claim 21, wherein, The selective multiplexing of the information in the multiplexed UCI includes: The multiplexed information is determined according to the priority of each information in the UCI from high to low; Or, the multiplexed information is determined according to the bit number of each information in the UCI.

23. The method of claim 13, wherein, When there is an overlapping part between the transmission of the PUCCH and the PUSCH, the method further includes: The fourth configuration information is received, and the fourth configuration information carries a UCIMul parameter, which is used to determine the UCI multiplexing function when the PUSCH enables OCC; When a preset condition is met, the UCIMul parameter is configured to disable the UCI multiplexing function, and the preset condition includes but is not limited to the following conditions: the priority of the OCC function is higher than the priority of the UCI multiplexing function, the overlapping part is not in the PUSCH of the first multiplexed OCC, or the OCC function is based on a single symbol.

24. The method of claim 1, wherein, Before the PUSCH enabling the OCC function is transmitted, the method further includes: The fifth configuration information is received, and the fifth configuration information includes an OCC sequence length or a scaling factor.

25. The method of claim 24, wherein, The fifth configuration information is carried in the RRC signaling or indicated by the MAC-CE, and the fifth configuration information carries a Scalingfactor parameter, which is used to indicate scaling of the number of available REs in a time unit.

26. The method of claim 24, wherein, The method further includes: Based on the fifth configuration information, the TBS of the TBoMS is calculated according to the second predefined rule.

27. The method of claim 1, wherein, The PUSCH enabling the OCC function includes: PUSCH with inter-symbol OCC spreading based on TBoMS.

28. The method of claim 27, wherein, The PUSCH with inter-symbol OCC spreading includes: When transmitting the PUSCH with the OCC function, the available time slots are adjusted according to the third predefined rule.

29. The method of claim 27, wherein, The method further includes: Receiving the sixth configuration information, the sixth configuration information carrying a total symbol number, the total symbol number being used to indicate a symbol number of a time domain resource allocation (TDRA) allocation, the total symbol number being a product of an original configured symbol number and a spreading factor, or a product of the original configured symbol number and an OCC sequence length.

30. A communication method for a base station, comprising: Including: Sending configuration information, and / or, based on a predefined rule, Receiving the PUSCH with the OCC function enabled; The configuration information includes but is not limited to one or more of the following information: first configuration information, second configuration information, Third configuration information, fourth configuration information, fifth configuration information and sixth configuration information; the predefined rule includes but is not limited to one or more of the following rules: second predefined rule and third predefined rule.

31. The method of claim 30, wherein, The sending configuration information includes: Sending the first configuration information, the first configuration information being used to determine the repetition transmission function when the PUSCH with the OCC is enabled.

32. The method of claim 31, wherein, The first configuration information carries an OCCIndicateRep parameter, the OCCIndicateRep parameter being used to trigger whether to perform the repetition transmission function in an enabling manner.

33. The method of claim 31, wherein, The first configuration information carries a repetition transmission number of 0; Or, the first configuration information does not configure the repetition transmission number.

34. The method of claim 32, wherein, When the OCCIndicateRep parameter indicates to perform the repetition transmission function, the RRC signaling carries an OCC sequence length parameter and a repetition transmission number; or the RRC signaling carries the repetition transmission number, and the MAC-CE indicates the OCC sequence length.

35. The method of claim 34, wherein, When the OCCIndicateRep parameter indicates to perform the repetition transmission function, the RRC signaling carries a repetition transmission number, the repetition transmission number including an OCC sequence length; Or the RRC signaling carries the repetition transmission number, and the MAC-CE indicates the OCC sequence length.

36. The method of claim 30, wherein, Before the receiving the PUSCH with the OCC function enabled, the method further includes: Sending the second configuration information, the second configuration information including an OCC sequence length.

37. The method of claim 36, wherein, The method further includes determining a starting position of a frequency domain resource configured by the FDRA on an RV ring based on the second predefined rule, Wherein, the frequency domain resources are grouped according to the OCC sequence length, the starting bit index of each grouped frequency domain resource being determined by the second predefined rule, and system bits being distributed on the each grouped frequency domain resource.

38. The method of claim 30, wherein, The method further includes: The third configuration information is sent, and the third configuration information carries a ScalingOCCSymbol parameter and a UCI occupation bit threshold value. The ScalingOCCSymbol parameter is used to indicate the occupation proportion of UCI in an OCC symbol group or TBS. The UCI occupation bit threshold value is used to indicate the maximum value of the occupation proportion of UCI in normal transmission.

39. The method of claim 30, wherein, The method further comprises: The fourth configuration information is sent, and the fourth configuration information carries a UCIMul parameter. The UCIMul parameter is used to determine the UCI multiplexing function when there is an overlapping part in the transmission of the PUSCH and PUCCH, and the PUSCH enables OCC; When a preset condition is met, the UCIMul parameter is configured to disable the UCI multiplexing function. The preset condition includes but is not limited to the following conditions: the priority of the OCC function is higher than the priority of the UCI multiplexing function, the overlapping part is not in the PUSCH of the first multiplexing OCC, or the OCC function is based on a single symbol.

40. The method of claim 30, wherein, The method further comprises: The fifth configuration information is sent, and the fifth configuration information includes an OCC sequence length or a scaling factor. The fifth configuration information is carried in the RRC signaling or indicated by the MAC-CE. The fifth configuration information carries the Scalingfactor parameter, which is used to indicate the scaling of the number of available REs in a time unit.

41. The method of claim 40, wherein, After the fifth configuration information is sent, the method further comprises: Based on the fifth configuration information, the TBS of the TBoMS is calculated according to the third predefined rule.

42. The method of claim 30, wherein, The method further comprises: The sixth configuration information is sent, and the sixth configuration information carries a total symbol number. The total symbol number is used to indicate the number of symbols allocated by TDRA. The total symbol number is the product of the originally configured symbol number and an expansion factor, or the product of the originally configured symbol number and the OCC sequence length.

43. A scheduling method applied to a base station, the method comprising: For scheduling multiple UEs to send PUSCHs that enable OCC, comprising A common DCI is sent, and the common DCI includes a unique information field. The unique information field is a field that is not shared among the N UEs. The unique information field at least includes an OCC-Index field. The OCC-Index sequence field is used to indicate the OCC sequence that needs to be multiplexed by the UE. Configuration information is sent to each UE. The configuration information includes a sub-index parameter. The sub-index parameter is used to determine the target subfield corresponding to each UE in the unique information field among the N UEs.

44. The method of claim 43, wherein, Before the configuration information is sent to each UE, the method further comprises: The unique information field is divided into N target subfields. The N target subfields correspond to the N UEs one by one. Or, the block number information of the target subfield corresponding to each UE is transmitted in the unique information field.

45. The method of claim 44, wherein, The unique information field further includes but is not limited to one or more of the following fields: A modulation and coding strategy MCS field, an RV field, a HARQ field, and a transmission power control TPC field.

46. The method of claim 43, wherein, The common DCI further comprises a shared information field, which is a field shared among the N UEs.

47. The method of claim 43, wherein, The resource location information of the common DCI is associated with a UE-specific specific DCI, and the common DCI is used to indicate the unique information field.

48. The method of claim 47, wherein, When the unique information field is an OCC-index field, the common DCI comprises an OCC block number corresponding to each UE. 49.A scheduling method applied to a UE, the method comprising: Comprise: Receiving a common DCI, the common DCI comprising a unique information field, the unique information field being a field not shared among the N UEs, the unique information field at least comprising an OCC-Index field, the OCC-Index sequence field being used to indicate the OCC sequence that needs to be multiplexed by the UE; Receiving configuration information, the configuration information comprising a sub-index parameter, the sub-index parameter being used to determine the target subfield corresponding to each UE in the N UEs in the unique information field; According to the common DCI and the configuration information, the target subfield corresponding to each UE in the unique information field is determined.

50. The method of claim 49, wherein, The unique information field is divided into N target subfields, and the N target subfields correspond to the N UEs one by one. Or the block information of the target subfield corresponding to multiple UEs in the unique information field is transmitted.

51. The method of claim 49, wherein, The unique information field further comprises one or more of the following fields, but is not limited to: MCS field, RV field, HARQ field and TPC field.

52. The method of claim 49, wherein, The common DCI further comprises a shared information field, which is a field shared among the N UEs.

53. The method of claim 49, wherein, The method further comprises: Determining the resource location information of the associated common DCI on the UE-specific DCI, the common DCI being used to indicate the unique information field; When the unique information field is an OCC-index field, the common DCI comprises an OCC block number corresponding to each UE. 54.A method of communication, implemented at a UE, comprising: Comprise: Receiving OCC configuration information for enabling OCC function for physical downlink control channel PDCCH; Receiving the PDCCH.

55. The method of claim 54, wherein, The OCC configuration information is carried in RCC signaling.

56. The method of claim 55, wherein, The receiving OCC configuration information comprises receiving PDCCH-Config information and PUSCH-Config information, The PDCCH-Config information comprises an OCC-Scheme parameter and an OCC-Length parameter, the OCC-Scheme parameter being used to indicate an OCC scheme, and the OCC-Length parameter being used to indicate the length of an OCC sequence, each length value of the OCC sequence being associated with an OCC sequence table of a corresponding length value; The PUSCH-Config information comprises an OCC-Index parameter, the OCC-Index parameter being used to indicate the index of an OCC sequence. ​ 57. The method of claim 56, wherein, The receiving OCC configuration information comprises: receiving PDCCH-Config information and PUSCH-Config information, The PDCCH-Config information comprises an OCC-Scheme parameter, which is used to indicate an OCC scheme; The PUSCH-Config information comprises an OCC-Length parameter and an OCC-Index parameter, the OCC-Length parameter is used to indicate the length of an OCC sequence, and each length value of the OCC sequence is respectively associated with an OCC sequence list of a corresponding length value, and the OCC-Index parameter is used to indicate the index of the OCC sequence.

58. A communication method applied to a base station, the method comprising: Comprise: Sending OCC configuration information for enabling OCC function for PDCCH; The PDCCH is sent.

59. The method of claim 58, wherein, The OCC configuration information is carried in RCC signaling.

60. The method of claim 59, wherein, The sending OCC configuration information comprises: sending PDCCH-Config information and PUSCH-Config information, The PDCCH-Config information comprises an OCC-Scheme parameter and an OCC-Length parameter, the OCC-Scheme parameter is used to indicate an OCC scheme, and the OCC-Length parameter is used to indicate the length of an OCC sequence, and each length value of the OCC sequence is respectively associated with an OCC sequence list of a corresponding length value; The PUSCH-Config information comprises an OCC-Index parameter, which is used to indicate the index of the OCC sequence.

61. The method of claim 59, wherein, The sending OCC configuration information comprises: sending PDCCH-Config information and PUSCH-Config information, The PDCCH-Config information comprises an OCC-Scheme parameter, which is used to indicate an OCC scheme; The PUSCH-Config information comprises an OCC-Length parameter and an OCC-Index parameter, the OCC-Length parameter is used to indicate the length of an OCC sequence, and each length value of the OCC sequence is respectively associated with an OCC sequence list of a corresponding length value, and the OCC-Index parameter is used to indicate the index of the OCC sequence. 62.A method for resource configuration applied to an Internet of Things (IoT) NTN system, comprising: Comprise: Receiving configuration information of a common resource pool broadcasted, wherein the common resource pool is divided into M groups of grouped resources according to a grouping basis of target system information, and the configuration information comprises ID information of the grouped resources; Receiving first target system information, and determining a corresponding target group ID according to the value of the first target system information; When the target group ID is contained in the ID information of the grouped resource pool, information transmission is performed based on the grouped resource corresponding to the target group ID.

63. The method of claim 62, wherein, The target system information comprises one or more of the following information: reference signal receiving power (RSRP) of SSB, signal to interference plus noise ratio (SINR), and reference signal receiving quality (RSRQ).

64. The method of claim 63, wherein, When the common resource pool is single, each of the grouped resources respectively corresponds to different interval of the target system information, based on the value interval of the target system information.

65. The method of claim 64, wherein, The determining of the target group ID corresponding to the value of the first target system information comprises: determining an interval in which the value of the first target system information is located; determining the ID information of the target group resource corresponding to the interval as the target group ID.

66. The method of claim 65, wherein, The configuration information further comprises a set of MCS values, each of the MCS values in the set of MCS values is used to indicate a corresponding MCS configuration, and each of the MCS values is associated with the ID information of each of the grouped resources, After the determining of the target group ID corresponding to the value of the first target system information, the method further comprises: determining a corresponding target MCS configuration based on the target group ID.

67. The method of claim 63, wherein, When the common resource pool is M groups, each of the common resource pools is associated with a corresponding target system information, based on the target system information as the grouping basis, The configuration information comprises the ID information of each of the common resource pools.

68. The method of claim 67, wherein, The configuration information further comprises one or more of the following information: time domain information, frequency domain information or MCS information corresponding to each of the common resource pools.

69. A method for resource configuration, comprising: comprises: broadcasting configuration information of a common resource pool, wherein the common resource pool is divided into M groups of grouped resources based on target system information as the grouping basis, and the configuration information comprises ID information of each of the grouped resources; sending first target information, so that a UE determines a corresponding target group ID according to a value of the first target information; communicating with the UE based on a grouped resource corresponding to the target group ID.

70. The method of claim 69, wherein, When the common resource pool is single, each of the grouped resources respectively corresponds to different interval of the target system information, based on the value interval of the target system information.

71. The method of claim 70, wherein, The configuration information further comprises a set of MCS values, each of the MCS values in the set of MCS values is used to indicate a corresponding MCS configuration, and each of the MCS values is associated with the ID information of each of the grouped resources.

72. The method of claim 69, wherein, When the common resource pool is M groups, each of the common resource pools is associated with a corresponding target system information, based on the target system information as the grouping basis, The configuration information comprises the ID information of each of the common resource pools.

73. A wireless communication device, comprising: a processor and a memory, the memory is used to store a computer program, and the processor is used to invoke and run the computer program stored in the memory to execute the method according to any one of claims 1 to 72.

Images