Satellite communication method and apparatus

Abstract

Provided in the present invention is a satellite communication method. The method comprises: a satellite base station determining beam hopping pattern information and transmitting same to a user equipment, wherein the pattern information at least comprises beam hopping dwell time information, beam hopping return visit time information or beam hopping start and end time information; and a satellite and the user equipment transmit and receive data on the basis of the pattern information. The method further provides a beam hopping pattern update mechanism. The present invention further provides an uplink control signal (e.g., a PUCCH) multiplexing method under a function in which an orthogonal cover code (OCC) is enabled in an uplink channel, thereby solving the problem of multiplexing when a repeatedly transmitted PUCCH overlaps with a PUSCH in which the OCC is enabled, and improving the resource utilization rate of a system.

Description

A satellite communication method and device Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a satellite communication method and apparatus. Background Technology

[0002] To extend the lifespan of satellites, energy-saving strategies are needed for both New Radio Non-Terrestrial Networks (NR-NTN) and Internet of Things Non-Terrestrial Networks (IoT-NTN) to reduce satellite power consumption.

[0003] During standardization discussions, some satellite companies proposed a Time Division Duplex (TDD) operating mode, which reduces the average power consumption of satellites through "selective activation." The specific operation is as follows: downlink transmission occupies only one out of N consecutive radio frames, and similarly, uplink reception also occupies only one out of N radio frames (selective activation, with N=9 as the baseline). This scheme is also applicable to NR-NTN, but the TDD mode currently proposed for IoT-NTN is mainly for compatibility with existing satellite products, implementing the satellite's TDD function. Such satellites can only transmit or receive at fixed times.

[0004] Based on existing satellite capabilities, satellites can transmit and receive signals during service. During standards discussions, some satellite companies proposed using beam hopping technology to improve satellite coverage and to enable TDD for User Equipment (UE). At a future 6G non-terrestrial network technology workshop, several companies proposed applying beam hopping technology to 6G NTN to improve satellite transmission efficiency. Additionally, some companies suggested that 6G NTN should support TDD mode.

[0005] Satellites cover ground users with fixed beams, dividing the coverage area into several cells, each corresponding to a specific beam position, with each beam serving a cell. However, given the limitations of current satellite capabilities, it's difficult to simultaneously activate hundreds of beams; only a few real beams can be supported at any given time. Therefore, to ensure coverage, real beams need to hop between virtual beams. Beam-hopping technology addresses the uneven spatiotemporal distribution of users through time slicing, utilizing all onboard bandwidth resources and improving system resource utilization and throughput.

[0006] Against this backdrop, this invention proposes a satellite communication method to improve the resource utilization and coverage of satellite systems. Summary of the Invention

[0007] One objective of this disclosure is to provide satellite communication methods, user equipment, and satellite base stations.

[0008] In a first aspect, the present invention proposes a satellite communication method applied to a satellite base station, comprising at least one of the following: sending the beam hopping pattern information to a user equipment, the beam hopping pattern information including at least one of: beam hopping dwell time, beam hopping return time, or beam hopping start and end time information; and sending downlink control signaling and data or receiving uplink control signaling and data to the user equipment according to the beam hopping pattern information; wherein, the beam hopping pattern information is used to indicate beam service time information and notify the user equipment to send and receive control information or service data within a specified time.

[0009] In a second aspect, the present invention proposes a satellite communication method applied to a satellite base station, comprising at least one of the following: configuring multiple sets of beam hopping pattern information, including a default pattern and at least one set of candidate patterns, wherein the beam hopping pattern information includes at least one of beam hopping dwell time, beam hopping pattern information index, beam hopping revisit time, or beam hopping start and end time information; and when it is determined that the beam hopping pattern needs to be updated, sending a beam hopping pattern update instruction to the user equipment, wherein the update instruction is used to activate a set of candidate patterns among the multiple sets of beam hopping pattern information.

[0010] In a third aspect, the present invention proposes a satellite communication method applied to a satellite base station, comprising at least one of the following: receiving a beam hopping pattern update request sent by a user equipment; determining the beam hopping pattern information that needs to be updated based on the update request; and sending the updated beam hopping pattern information to the user equipment.

[0011] Fourthly, the present invention proposes a satellite communication method applied to a satellite base station, comprising at least one of the following: receiving a physical uplink control channel of a user equipment or a physical uplink shared channel of an enabled OCC or a physical uplink shared channel carrying uplink control information of an enabled OCC, wherein the physical uplink control channel or the physical uplink shared channel of an enabled OCC or the physical uplink shared channel carrying uplink control information of an enabled OCC is based on a multiplexing rule between a repeatedly transmitted physical uplink control channel and a physical uplink shared channel of an enabled OCC.

[0012] Fifthly, this invention proposes a satellite communication method applied to a satellite base station, comprising at least one of the following: configuring relevant information for enabling the orthogonal coverage code (OCC) function of the uplink channel of a user equipment, wherein the relevant information for the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, and OCC sequence index; determining, through a predefined method, multiplexing rules between physical uplink control channels for multiple repeated transmissions and physical uplink shared channels with OCC enabled; and receiving, according to the multiplexing rules, uplink control information and uplink data transmitted by the user equipment through the physical uplink shared channel with OCC enabled.

[0013] In a sixth aspect, the present invention proposes a satellite communication method applied to a user equipment, comprising at least one of the following: receiving beam hopping pattern information transmitted by a satellite base station, wherein the beam hopping pattern information includes at least one of: beam hopping dwell time, beam hopping return time, and beam hopping start and end time information; and receiving downlink control signaling and data transmitted by the satellite base station or sending uplink control signaling and data to the satellite base station according to the beam hopping pattern information; wherein the beam hopping pattern information is used to indicate beam service time information and notify the user equipment to send and receive control information or service data within a specified time.

[0014] In a seventh aspect, the present invention proposes a satellite communication method applied to a user equipment, comprising at least one of the following: receiving a beam hopping pattern update instruction sent by a satellite base station, the update instruction being used to activate a set of candidate patterns from a plurality of sets of beam hopping pattern information, wherein the plurality of sets of beam hopping pattern information includes a set of default patterns and at least one set of candidate patterns, the beam hopping pattern information including at least one of beam hopping dwell time, beam hopping pattern information index, beam hopping revisit time, or beam hopping start and end time information; and communicating with the satellite base station according to the activated candidate pattern within the corresponding beam hopping dwell time.

[0015] Eighthly, the present invention proposes a satellite communication method applied to user equipment, comprising at least one of the following: sending a beam hopping pattern update request to a satellite base station; receiving updated beam hopping pattern information sent by the satellite base station; and communicating with the satellite base station according to the updated beam hopping pattern information within a corresponding beam hopping dwell time.

[0016] Ninthly, the present invention proposes a satellite communication method applied to user equipment, comprising at least one of the following: transmitting a physical uplink control channel or a physical uplink shared channel enabling OCC or a physical uplink shared channel carrying uplink control information enabling OCC to a satellite base station, wherein the physical uplink control channel or the physical uplink shared channel enabling OCC or the physical uplink shared channel carrying uplink control information enabling OCC is based on a multiplexing rule between a repeatedly transmitted physical uplink control channel and a physical uplink shared channel enabling OCC.

[0017] Tenthly, the present invention proposes a satellite communication method applied to user equipment, comprising at least one of the following: information related to the uplink channel enabling orthogonal coverage code (OCC) function configured by the satellite base station, wherein the information related to the OCC function includes at least one of OCC scheme type, OCC sequence length, and OCC sequence index; multiplexing rules based on predefined multiplexing rules between physical uplink control channels for multiple repeated transmissions and physical uplink shared channels enabling OCC; and transmitting uplink control information and uplink data to the satellite base station through the OCC-enabled physical uplink shared channel according to the multiplexing rules.

[0018] Eleventhly, the present invention proposes a satellite communication method applied to user equipment, comprising at least one of the following: when the OCC sequence length is less than the number of repeated transmissions of the physical uplink shared channel, enabling OCC from the earliest physical uplink shared channel position, retaining the portion of the repeated transmissions of the physical uplink shared channel that overlaps with the OCC sequence according to the OCC sequence length, and discarding the portion exceeding the sequence length; or continuing to map the remaining physical uplink shared channel to OCC sequences to form a nominal OCC group; and when the OCC sequence length is greater than the number of repeated transmissions of the physical uplink shared channel, forming a nominal OCC group, including the portion of the repeated transmissions of the physical uplink shared channel that overlaps with the OCC sequence; or continuing the repeated transmission of the physical uplink shared channel according to the length of the OCC sequence until it is aligned with the length of the OCC sequence.

[0019] One embodiment of the present invention provides a user device including a processor and memory, the processor being configured to invoke and execute a computer program stored in the memory to cause a device equipped with the processor to perform the disclosed method.

[0020] One embodiment of the present invention provides a satellite base station including a processor and memory, the processor being configured to invoke and execute a computer program stored in the memory to cause a device equipped with the processor to perform the disclosed method.

[0021] The disclosed methods can be programmed as computer-executable instructions stored on a non-transitory computer-readable medium. When loaded onto a computer, the non-transitory computer-readable medium instructs the computer's processor to execute the disclosed methods.

[0022] Non-transitory computer-readable media may include at least one of the following groups: hard disk, CD-ROM, optical storage device, magnetic storage device, read-only memory, programmable read-only memory, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory.

[0023] The disclosed methods can be programmed into a computer program product that enables a computer to perform the disclosed methods.

[0024] The disclosed methods can be programmed into a computer program that causes a computer to execute the disclosed methods. Attached Figure Description

[0025] One or more embodiments are illustrated by way of example with corresponding figures in the accompanying drawings. These illustrative examples do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements. Unless otherwise stated, the figures in the drawings do not constitute a limitation on scale. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of the invention. The various embodiments can be combined with and referenced to each other without contradiction.

[0026] Figure 1 shows a schematic diagram of the system, including the NTN and the terrestrial network.

[0027] Figure 2 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0028] Figure 3 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0029] Figure 4 is a schematic diagram showing the hopping beam pattern configuration.

[0030] Figure 5 is a schematic diagram showing an example of multiplexing a single retransmitted PUCCH.

[0031] Figure 6 is a schematic diagram illustrating an example of multiplexing of PUCCHs that are repeatedly transmitted.

[0032] Figure 7 is a schematic diagram showing the configuration and updating method of hopping beam patterns in satellite communication.

[0033] Figure 8 is a schematic diagram showing the repetitive transmission PUCCH multiplexing method under the uplink channel enabled OCC function.

[0034] Figure 9 is a schematic diagram showing the hopping beam pattern configuration.

[0035] Figure 10 is a schematic diagram showing the hop beam pattern configuration using offset.

[0036] Figure 11 is a schematic diagram showing the hopping beam pattern configuration using cell identifiers.

[0037] Figure 12 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0038] Figure 13 is a schematic diagram showing how to activate the default hop beam pattern configuration and the corresponding IDs of other hop beam patterns via MAC CE.

[0039] Figure 14 is a schematic diagram showing the addition of BeamhoppingpatternID to the MAC CE for reporting beamhopping pattern update requests during Timing Advance (TA) reporting.

[0040] Figure 15 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0041] Figure 16 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0042] Figure 17 shows a schematic diagram illustrating an example of the reuse of a single repeating PUCCH.

[0043] Figure 18 shows a schematic diagram of reserving a portion of time and frequency resources for PUCCH transmission.

[0044] The schematic diagram in Figure 19 shows that the number of repetitions of PUCCH is less than the length of the OCC group.

[0045] Figure 20 illustrates an example where a repeated PUCCH does not cross OCC groups when it overlaps with a non-first PUSCH within an OCC group.

[0046] Figure 21 shows an example of repeated PUCCH across OCC groups.

[0047] Figure 22 shows an example of multiple repeatedly transmitted PUCCHs overlapping with an OCC group.

[0048] Figure 23 illustrates an example of multiple PUCCHs being reused with higher priority than PUSCHs in the OCC group.

[0049] Figure 24 shows an example of multiple different PUCCHs overlapping within an OCC group.

[0050] Figure 25 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0051] Figure 26 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0052] Figure 27 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0053] Figure 28 shows a schematic diagram of an embodiment of the satellite communication method of the present invention.

[0054] Figure 29 shows an example where the touch OCC length is less than the number of repeated transmissions.

[0055] Figure 30 shows an example where the OCC length is greater than the number of repeated transmissions.

[0056] Figure 31 is a schematic diagram showing the user equipment of the present invention.

[0057] Figure 32 is a schematic diagram showing the network device of the present invention.

[0058] Figure 33 is a schematic diagram of the chip of the present invention.

[0059] Figure 34 is a schematic diagram of the chip of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this application clearer, some embodiments of this application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely for explaining this application and are not intended to limit this application.

[0061] Referring to Figure 1, the satellite communication method can be executed in a telecommunications system. The core network 300 connects to the access network R1 of the terrestrial network system and the access network R2 of the NTN system. The satellite communication method can operate in any one of the devices or entities in the core network 300, access network R1, and access network R2, or it can operate distributed across multiple devices or entities within the network.

[0062] The core network 300 connects to the data network 301 (e.g., the Internet). For example, the access network R1 of the terrestrial network system includes a base station 20 of the terrestrial network system, connecting multiple user equipment 10s of the terrestrial network system. For example, the access network R2 of the NTN system includes a satellite base station 40 of the NTN system, an NTN gateway 41, and an NTN ground station 42. The satellite base station 40 connects multiple user equipment 50s of the NTN system. The terrestrial network system includes the multiple user equipment 10s, the access network R1, and the core network 300. The NTN system includes the multiple user equipment 50s, the access network R2, and the core network 300.

[0063] The user equipment 50 may have the capability to connect to the base station 20 and the satellite base station 40, and may connect to both the base station 20 and the satellite base station 40 simultaneously. The user equipment 10 may have the capability to connect to the base station 20 and the satellite base station 40, and may connect to both the base station 20 and the satellite base station 40 simultaneously.

[0064] The satellite base station 40 is both a satellite and a base station, capable of providing cell services to the user equipment 50. The satellite base station 40 can have the complete functions of a base station. The satellite base station 40 can have a combination of base station functions: one or more of a Centralized Unit (CU) and a Distributed Unit (DU).

[0065] Examples of UEs described herein may include one of UE 10 or UE 50. Examples of base stations described herein may include satellite base station 40. Uplink (UL) transmission of control signals or data may be a transmission operation from the UE to the base station. Downlink (DL) transmission of control signals or data may be a transmission operation from the base station to the UE. DL control signals may include a Medium Access Control (MAC) control element (CE), Downlink Control Information (DCI), or Radio Resource Control (RRC) signal from the base station to the UE. UL control signals may include a MAC CE, Uplink Control Information (UCI), or Radio Resource Control signal from the UE to the base station.

[0066] In this patent specification, the entity that performs the system actions and features can be understood as follows:

[0067] The actions performed by the satellite base station include: determining the beam hopping pattern, sending beam hopping pattern information, initiating pattern updates, processing update requests sent by user equipment, configuring OCC function-related information and multiplexing rules, and receiving and demultiplexing UCI and uplink data transmitted from user equipment. These actions are typically implemented by satellites, base stations, space stations, or gateways, especially those involving network-side control functions such as resource allocation and configuration distribution.

[0068] The actions performed by the user equipment (e.g., UE 50) include: receiving beam hopping pattern information, determining the dwell time based on the pattern, transmitting and receiving data within a specified time, sending a pattern update request, and handling PUCCH and PUSCH overlap according to multiplexing rules. The user equipment (e.g., UE 50) performs corresponding operations based on the network-side configuration, especially during random access and UCI transmission.

[0069] When the description does not explicitly specify the implementing entity, it should be determined based on the functional characteristics: network control and configuration functions belong to the satellite base station side, while parameter application typically belongs to the user equipment side. The "system" mentioned in this article mainly refers to the satellite communication system, which can refer to the corresponding base station, user equipment, or protocol.

[0070] Referring to Figure 2, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0071] Step S001: The satellite base station 40 sends the beam hopping pattern information 111 to the user equipment (e.g., UE 50). The beam hopping pattern information 111 includes at least one of the following: beam hopping dwell time, beam hopping revisit time, or beam hopping start and end time information.

[0072] Step S002: The user equipment 50 receives beam hopping pattern information 111 sent by the satellite base station. The beam hopping pattern information 111 includes at least one of the following: beam hopping dwell time, beam hopping revisit time, and beam hopping start and end time information; and

[0073] Step S003: The satellite base station 40 sends downlink control signaling and data to the user equipment or receives uplink control signaling and data according to the beam hopping pattern information. The beam hopping pattern information is used to indicate beam service time information and notify the user equipment to send and receive control information or service data within a specified time.

[0074] Step S004: The user equipment 50 receives downlink control signaling and data sent by the satellite base station or sends uplink control signaling and data to the satellite base station according to the beam hopping pattern information. The beam hopping pattern information is used to indicate beam service time information and notify the user equipment to send and receive control information or service data within a specified time.

[0075] In one or more embodiments of the present invention, the hopping beam pattern information further includes at least one of the following: an index of the hopping beam pattern, a beam index, a synchronization signal block index, a ground position identifier ID or a coverage area identifier list, a physical cell identifier index, beam dwell information of adjacent positions or adjacent coverage areas, and a beam index of adjacent positions or adjacent coverage areas.

[0076] In one or more embodiments of the present invention, the method of sending the beam hopping pattern information includes: sending the beam hopping pattern information to the user equipment via at least one of system messages, downlink control information, media access control elements, or predefined methods.

[0077] In one or more embodiments of the present invention, the configuration method of the beam hopping pattern information includes: updating the pattern information of the service area each time a beam hop occurs; or associating the pattern information of the service area with the synchronization signal block index and polling all synchronization signal block indices to update the pattern information of the service area; or associating the pattern information of the service area with the cell identifier to configure the pattern information under all cell identifiers; or associating the pattern information of the service area with the cell identifier and determining the default beam hopping pattern in a predefined manner.

[0078] In one or more embodiments of the present invention, the configuration method of the start and end time information of the hopping beam includes: configuring the hopping beam start service time information, the start and end time information of a single hopping beam, the beam dwell time and the return time, wherein the start service time information is aligned with system frame 0 or has a fixed time offset; or configuring the hopping beam start service time information, the beam dwell time and the return time, implicitly indicating the start time information of each hopping beam by associating with the hopping beam identifier.

[0079] In one or more embodiments of the present invention, the beam hopping identifier includes at least one of the following: service area number, beam position index, synchronization signal block index, or cell identifier.

[0080] In one or more embodiments of the present invention, the units of the beam hopping start service time information, the start and end time information of a single beam hopping, the beam dwell time, and the return visit time include at least one of the following: radio frame, subframe, time slot, symbol, millisecond, or second.

[0081] In one or more embodiments of the present invention, the method further includes: determining a random access opportunity, wherein, based on the beam hopping pattern information, when the starting position of the random access opportunity is within the beam hopping dwell time, it is determined to be an available random access opportunity; and when the starting position of the random access opportunity is outside the beam hopping dwell time, it is determined to be an unavailable random access opportunity.

[0082] In one or more embodiments of the present invention, for unavailable random access opportunities, the method further includes: postponing the random access opportunity to the beginning of the next beam hopping dwell time.

[0083] In one or more embodiments of the present invention, the method further includes: determining a random access response window and a contention resolution window, and when the random access response window or the contention resolution window falls within a non-beam hopping dwell time, delaying the starting position of the random access response window or the contention resolution window to the starting subframe position of the next beam dwell time.

[0084] Referring to Figure 3, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0085] Step S202: The user equipment 50 sends a beam hopping pattern update request to the satellite base station 40.

[0086] Step S203: The satellite base station 40 receives a beam hopping pattern update request sent by the user equipment 50.

[0087] Step S205: The satellite base station 40 determines the hopping beam pattern information that needs to be updated according to the update request, and sends the updated hopping beam pattern information to the user equipment.

[0088] Step S206: The user equipment 50 receives the updated beam hopping pattern information sent by the satellite base station 40.

[0089] Step S208: The user equipment 50 communicates with the satellite base station 40 within the corresponding hopping beam dwell time according to the updated beam hopping pattern information. The satellite base station 40 communicates with the user equipment 50 within the corresponding hopping beam dwell time according to the updated beam hopping pattern information.

[0090] In one or more embodiments of the present invention, receiving a beam hopping pattern update request sent by the user equipment includes: receiving the beam hopping pattern update request via uplink control information; receiving the beam hopping pattern update request via a media access control element; or receiving the beam hopping pattern update request via radio resource control signaling.

[0091] The methods for sending the beam hopping pattern update request include: sending the beam hopping pattern update request via uplink control information; sending the beam hopping pattern update request via a media access control element; or sending the beam hopping pattern update request via radio resource control signaling.

[0092] In one or more embodiments of the present invention, the beam hopping pattern update request includes at least one of: an index of the beam hopping pattern; and the position information of the user equipment, the associated synchronization signal block index information, or the associated cell identifier information.

[0093] In one or more embodiments of the present invention, the satellite base station sends an indication of successful or failed beam hopping pattern update to the user equipment via radio resource control signaling, downlink control information, or media access control elements. The user equipment receives the indication of successful or failed beam hopping pattern update from the satellite base station via radio resource control signaling, downlink control information, or media access control elements.

[0094] Regarding the multiplexing of uplink control information (UCI) and uplink channels, when the Orthogonal Cover Code (OCC) function is enabled, how to handle the multiplexing between the Physical Uplink Control Channel (PUCCH) and the Physical Uplink Shared Channel (PUSCH) becomes a problem that needs to be solved. When the PUCCH overlaps with the PUSCH with OCC enabled, the traditional UCI multiplexing mechanism may no longer be applicable because the PUSCH with multiplexed UCI will interfere with other PUSCHs during the decoding process, affecting the orthogonality of OCC.

[0095] Regarding the multiplexing of PUCCH and PUSCH enabling OCC, different solutions have been proposed in the industry. One solution is to directly discard the UCI, but considering that control signaling generally has higher priority than data transmission, this solution is not widely accepted. Another solution is to transmit the UCI on the PUCCH while discarding all duplicate PUSCH transmissions within the OCC group. There are two different interpretations of this solution: one is that control signaling should be given priority, and overlapping PUSCHs should be discarded, allowing the PUCCH to be directly multiplexed on the PUSCHs of other user equipment; the other is that if an OCC group needs to be discarded, then all overlapping parts of the OCC group of all user equipment should be discarded, but when one user equipment (e.g., UE 50) discards an OCC group, it is impossible to notify other user equipment to perform the same operation. A third solution (which has more support) is to multiplex the UCI on the PUSCH enabling OCC, that is, to multiplex the UCI on all duplicate PUSCH transmissions within the OCC group.

[0096] However, there is currently no clear method for handling the overlap of duplicate PUCCH transmissions with OCC groups. The main issues include: 1. How to handle the overlap of duplicate PUCCH transmissions with OCC groups; 2. How to handle the overlap of multiple PUCCH transmissions with one OCC group; 3. How to handle situations where PUCCH and PUSCH have different priorities; 4. How to handle scheduling requests.

[0097] Furthermore, when OCC functionality is enabled, the OCC sequence length and the number of repetitions may not be consistent; that is, the OCC sequence length may be greater than or less than the number of repetitions. In this case, Redundancy Version (RV) cyclical operation is applied to transmissions across OCC groups, especially when the number of repetitions exceeds the OCC sequence length. Current technology does not optimize for pairing user equipment with OCC lengths of 2 and 4.

[0098] To address the above problems, this invention designs an effective UCI multiplexing method to achieve reliable UCI transmission while ensuring OCC orthogonality, thereby improving the overall system performance.

[0099] In the New Radio (NR) protocol, the transmission of System Information (SI) employs a flexible mechanism. System Information Block (SIB) messages are primarily transmitted in two ways: broadcasting and non-broadcasting.

[0100] Broadcast messages are system information that base stations (such as satellite base station 40) periodically send via broadcast. These messages are intended to be received by all user equipment (UEs). Non-broadcast messages, on the other hand, are sent on demand. When a UE needs specific system information, it first sends a request to the base station, which then responds and sends the relevant system information.

[0101] There are two main methods for obtaining information from non-broadcast systems:

[0102] The first method corresponds to non-contention random access, which avoids random access channel conflicts. The UE requests system information from the base station by sending a physical random access channel, and the base station responds to the UE with message 2 (msg2). In this case, the random access preamble identifier (RAPID) in msg2 needs to be consistent with the preamble index sent by the UE.

[0103] The second method does not specify the preamble index corresponding to the system information. In this configuration, the UE initiates a request via contention-based random access and includes the type of system information to be read in message 3 (msg3) of the Random Access Response (RAR) schedule. The UE can only read the requested system information after the random access contention is successfully resolved.

[0104] In the SI transmission mechanism, different SI messages are scheduled to be sent periodically within different SI windows. Although the SI window lengths of different SI messages are the same, their transmission periods can be configured individually. SI messages are transmitted via the Physical Downlink Shared Channel (PDSCH). The system can calculate and determine the starting position of each SI window, enabling the UE to correctly receive the required system information. In New Radio (NR), the setting of Random Access Opportunities (ROs) follows specific principles and mapping relationships. During random access, a user equipment (e.g., UE 50) can only transmit physical random access channel signals within the beam scan coverage of the Synchronization Signal Block (SSB), meaning that the RO needs to establish an explicit association with the SSB.

[0105] According to relevant technical reports, the following two types of satellite beam pattern mapping are currently supported: 1. Multiple satellite beams are associated with the same Physical Cell Identity (PCI). 2. Each satellite beam is associated with one PCI.

[0106] Each satellite beam can contain one or more synchronization signal block beams, and the maximum number of SSB beams under each PCI can be 4, 8 or 64.

[0107] An SSB block can be sent multiple times within a period (ssb-PositionsInBurst, lasting 5 milliseconds). The sending pattern corresponds to different cases (Case A / B / C / D / E). The maximum number of blocks sent (L) can be 4, 8, or 64. The actual number of SSBs sent is configured by the base station (e.g., satellite base station 40) according to network requirements.

[0108] The PRACH has multiple available transmission times distributed in the time and frequency domains. The system needs to establish a mapping relationship between each SSB block and the PRACH transmission time. The parameter "SSB-per-rach-occasion" (N) defines the mapping ratio between SSB and RO, while the number of preambles corresponding to one RO is specified by the parameter "totalNumberOfRA-Preambles".

[0109] When N is greater than 1, it means one RO is mapped to multiple SSBs; when N is less than 1, it means one SSB needs to be mapped to multiple ROs. Specifically, when SSB-perRACH-Occasion is less than 1 (i.e., one SSB corresponds to multiple ROs), the SSB indexes are mapped to ROs in the following determined order: 1. The contention-based (CB) preambles in each RO are arranged in ascending order of index. 2. When ROs are configured for frequency division multiplexing (FDM), they are mapped in ascending order of frequency domain index. 3. When multiple ROs are configured within a PRACH slot, they are mapped in ascending order of the slot index. 4. When multiple PRACH slots are configured, they are mapped in ascending order of the PRACH slot index.

[0110] This precise mapping mechanism ensures the orderly conduct of the random access process while reducing the possibility of access conflicts. During random access, the commencement of the Contention Resolution Window follows strict timing rules. According to system specifications, the Contention Resolution Timer (ra-ContentionResolutionTimer) begins counting after the last repeated transmission of Message 3 (Msg3), plus a Round Trip Time (RTT). This design ensures sufficient time intervals for the base station (e.g., satellite base station 40) to process Msg3 and send the corresponding contention resolution information.

[0111] As shown in the table below, the uplink scheduling parameter K2 plays a crucial role in the random access process. The K2 parameter defines the time slot interval between the downlink control information (DCI) and its scheduled physical uplink shared channel. In the Msg2-Msg3 scheduling relationship during the initial access phase, for the PUSCH (i.e., Msg3) transmission scheduled by the uplink grant of the random access response RAR, if the user equipment (e.g., UE 50) receives the end portion of the physical downlink shared channel containing the RAR message in time slot n, then the UE will be scheduled in time slot n+K2+Δ+2. μ *K cell,offset Send PUSCH in the middle.

[0112] Satellite communication systems face technical challenges in pattern configuration and updates when using Time Division Duplex (TDD) hopping beam mode.

[0113] Question 1: Pattern configuration and update method in beam skipping mode

[0114] 1.1 Method for configuring hopping beam patterns:

[0115] Referring to Figure 4, selecting a suitable beam hopping pattern configuration method is crucial for optimizing satellite resource utilization, improving system performance, and enhancing user experience. Under beam hopping conditions, satellite communication systems employ TDD technology to dynamically adjust the dwell time of the beam at each position to optimize resource allocation. However, according to existing protocols, the satellite beam or the satellite itself is invisible to user equipment (e.g., UE 50).

[0116] To ensure the smooth completion of the random access and data transmission phases, the system needs to configure the corresponding beam hopping time schedule to the UE before the random access procedure begins. This schedule must include at least the following key information: 1. Beam dwell time; 2. Dwell period; 3. Beam start position; 4. Beam end position.

[0117] Furthermore, the configuration mode of the beam-hopping pattern also needs careful consideration, and there are several possible implementation methods: 1. Configure the entire time schedule at once; 2. Configure it separately each time beam hopping occurs; 3. Configure it periodically according to a predetermined cycle.

[0118] 1.2 Method for updating hopping beam patterns

[0119] As network conditions and user needs change, satellite systems require dynamic adjustments and updates to beam hopping patterns. These updates can be triggered by various factors, including dynamic changes in service requirements, adjustments to existing resources, or proactive user requests. When a beam hopping pattern update is determined, the system should be able to quickly configure the updated pattern information to user equipment (e.g., UE 50). Therefore, the triggering conditions for pattern information updates, the method of sending update configurations, and the content of the updated configurations need to be appropriately designed to ensure the efficient operation of the communication system.

[0120] Question 2: Multiplexing of the physical uplink control channel under the condition of enabling orthogonal overlay codes.

[0121] 2.1 Multiplexing of a single repeated transmission of the physical uplink control channel

[0122] In existing communication protocols, uplink control information can be transmitted via the physical uplink control channel or the physical uplink shared channel. Referring to Figure 5, `rep` in the figure represents repeated transmission. When a single PUCCH overlaps with a repeatedly transmitted PUSCH in the time domain, the UCI will be multiplexed on the PUSCH that overlaps with the PUCCH, but will not be multiplexed on other repeatedly transmitted PUSCHs.

[0123] However, the situation becomes more complex when OCC is enabled on the PUSCH. OCC causes PUSCHs to be transmitted repeatedly. If UCI is only multiplexed on PUSCHs that overlap with PUCCHs, the multiplexed PUSCHs will interfere with other PUSCHs during decoding, affecting signal orthogonality. Existing UCI and PUSCH multiplexing mechanisms are no longer applicable in this situation.

[0124] Therefore, a new UCI and PUSCH multiplexing mechanism needs to be designed to ensure that, under the condition of enabling OCC function, the multiplexing of UCI will not adversely affect the PUSCH orthogonality of other UEs, thereby ensuring the reliability and efficiency of system communication.

[0125] In wireless communication systems, when the uplink channel enables Orthogonal Cover Code (OCC) functionality, the multiplexing of multiple repeatedly transmitted Physical Uplink Control Channels (PUCCHs) presents certain technical challenges. When using an extended OCC approach, multiplexing uplink control information (UCI) onto the Physical Uplink Shared Channel (PUSCH) and extending it together is a simple implementation method. However, this method is primarily suitable for scenarios involving the multiplexing of a single PUCCH.

[0126] When a PUCCH is repeatedly transmitted on a non-first PUSCH within an OCC group, if the UCI is only multiplexed onto the overlapping PUSCH, the transmission content of different PUSCHs within the same OCC span will be different, thereby destroying the orthogonality of the OCC and preventing the receiver from demodulating the signal correctly.

[0127] 2.2 Multiplexing of multiple repeatedly transmitted PUCCH

[0128] Referring to Figure 6, furthermore, when multiple repeated PUCCHs with different priorities overlap within the same OCC group, according to existing protocols, the overlapping portions must be arranged according to their priority. This will result in different PUCCH contents multiplexed on different PUSCHs within the same OCC group, further affecting the orthogonality of the OCCs and reducing system performance.

[0129] Therefore, a new multiplexing mechanism needs to be designed to effectively handle the multiplexing relationship between multiple repeatedly transmitted PUCCHs and PUSCHs that enable OCC while ensuring OCC orthogonality, so as to improve system resource utilization and transmission efficiency.

[0130] The technical solution provided by this invention can effectively solve the pattern configuration and update problems after introducing beam skipping mode in the prior art, and at the same time solve the multiplexing problem of repeated PUCCH transmission under the uplink channel enabled OCC function, thereby significantly improving system resource utilization efficiency and transmission capacity. Specific technical effects are as follows:

[0131] First, this invention proposes a method for configuring the beam timing schedule and a method for updating the beam hopping pattern in beam hopping mode. These methods can enable rapid updating of the beam hopping pattern according to actual service needs, thereby improving the flexible scheduling capability and utilization rate of satellite resources.

[0132] Secondly, this invention proposes an innovative solution to the multiplexing problem of repeatedly transmitted PUCCH under the uplink channel enabled OCC function. It effectively multiplexes the repeatedly transmitted PUCCH onto the enabled OCC PUSCH, which not only improves the transmission capacity of the system, but also avoids the negative impact of multiple UCI multiplexing on the orthogonality of the uplink channel by using the multiplexing method of multiple repeatedly transmitted PUCCH, thus ensuring the reliability of signal demodulation and the stability of system performance.

[0133] Based on the core concept of this invention, a method for configuring and updating beam hopping patterns in satellite communication is proposed. This method can effectively improve satellite resource utilization while ensuring downlink synchronization and random access performance. The solution of this invention mainly focuses on the following aspects:

[0134] Methods for configuring and updating beam hopping patterns in satellite communications:

[0135] Referring to Figure 7, to achieve the satellite's beam hopping transmission function, this invention proposes a series of key steps, mainly including beam hopping pattern configuration, beam hopping pattern updating, and other necessary steps required to complete communication. The detailed technical content of these steps will be described in subsequent chapters.

[0136] It should be noted that in actual implementation, this solution can flexibly select one or more steps to combine, and the execution order of these steps can be adjusted according to the specific application scenario. The examples provided in this article are for reference only and should not be regarded as mandatory limitations on the implementation of this invention.

[0137] In an embodiment of the present invention, the method for configuring and updating beam hopping patterns in satellite communication mainly includes the following steps:

[0138] Step 1: First, the base station (e.g., satellite base station 40) determines the satellite hopping beam pattern.

[0139] Step 2: The base station then sends beam hopping pattern information to the user equipment (e.g., UE 50) through various optional methods, including system messages, SIB1 / SIB19 / SIB31 / SIBX, DCI, MAC CE, or predefined methods. The sent beam hopping pattern may contain one or more pattern configurations, including at least one or more of the following information: beam hopping time schedule, beam index, beam hopping pattern validity period, SSB index, list of beam position identifiers or coverage area identifiers, cell identifier, beam camping information of adjacent beam positions or adjacent coverage areas, and beam index of adjacent beam positions or adjacent coverage areas.

[0140] The effective time of the hopping beam pattern is used to indicate the effective time of the hopping beam pattern configuration. Its reference time point is the start time information of the satellite hopping beam. It can be aligned with the system SFN#0, have a time offset from SFN#0, or be based on the timer configuration.

[0141] The beam hopping time schedule is used to indicate beam service times under different bands or coverage areas, and can be configured in one of the following ways: 1. Define or configure beam hopping start service time information, start and end time information for a single beam hop, beam dwell time, and return time. The start service time information can be aligned with system frame 0 or have a fixed time offset. The start and end time information for a single beam hop can be a specific radio frame number or an offset value between the start service time and the beam hopping start time. 2. Define or configure beam hopping start service time information, beam dwell time, and return time, implicitly indicating the start time information for each beam hop by associating it with a beam hopping identifier. The beam hopping identifier can be a service area number, band index, SSB index, or cell identifier.

[0142] For the configuration mode of the beam hopping time schedule, one of the following methods can be adopted: 1. Update the pattern information of the service area each time a beam hop occurs. 2. Associate the pattern information of the service area with the SSB index, and poll all SSB indexes to update the pattern information of the service area. 3. Associate the pattern information of the service area with the cell identifier and configure the pattern information under all cell identifiers. 4. Associate the pattern information of the service area with the cell identifier and determine the default beam hopping pattern through a predefined method.

[0143] Step 3a: The base station (e.g., satellite base station 40) can initiate beam hopping pattern updates in one of the following ways (details can be found in Examples 1-2): 1. Reconfigure the beam hopping pattern via RRC 2. Configure multiple sets of beam hopping patterns (including a default pattern and multiple candidate patterns), and activate the candidate beam hopping patterns in the following ways: a. RRC indicates update of candidate patterns b. MAC CE activation c. DCI indication can be done in the following ways: 1) Add a new field to indicate 2) Reinterpretation of some fields, such as: MCS field and HARQ 3) Joint coding with existing fields, such as: TDRA / FDRA 4) Reinterpretation of reserved bits 5) Obtain pattern update prompts through paging messages 6) Reinterpretation of reserved bits in P-RNTI scrambled DCI d. Based on the beam hopping validity time or timer, switch to candidate patterns upon timeout.

[0144] Step 3b: User equipment (e.g., UE 50) may also send a pattern update request message to initiate a beam skipping pattern update request to the satellite via UCI reporting, MAC CE reporting, or RRC request (which may be used alone or bundled with other RRC messages).

[0145] To determine whether the pattern has been updated successfully, a timer can be defined or a method based on a base station (e.g., satellite base station 40) indication can be used.

[0146] Step 4: Finally, the user equipment (e.g., UE 50) and the base station send and receive messages based on the updated beam hopping pattern.

[0147] Repetitive transmission PUCCH multiplexing method under uplink channel enabled OCC function:

[0148] Referring to Figure 8, to achieve effective multiplexing of the retransmitted physical uplink control channel (PUCCH) under the uplink channel enabled orthogonal coverage code (OCC) function, this invention proposes a novel solution. Its key steps include multiplexing a single retransmitted PUCCH, multiple retransmitted PUCCHs, and other necessary steps. It should be noted that in practical applications, one or more steps can be combined and implemented according to specific requirements. The specific execution flow of this solution is as follows:

[0149] Step 1: First, the user equipment (e.g., UE 50) obtains the relevant configuration information for enabling OCC for the Physical Uplink Shared Channel (PUSCH) / Narrowband Physical Uplink Shared Channel (NPUSCH). This information may include one or more parameters such as OCC scheme type, OCC sequence length, OCC sequence index, OCC offset value, delayed transmission offset value, and multiplexing priority information.

[0150] Among them, the OCC offset value is used to indicate that the UE reserves corresponding resources for transmitting PUCCH, PUSCH or PUSCH that reuses PUCCH; the delayed transmission offset value is used to indicate the time offset of the UE delaying the transmission of PUSCH with OCC enabled, which can be indicated explicitly or implicitly; the multiplexing priority parameter includes the priority of PUSCH and PUCCH, the priority of uplink control information (UCI), and the priority information of multiple repeated PUCCH transmissions.

[0151] Step 2: Subsequently, the UE and the base station perform subsequent steps based on a predefined multiplexing method (or multiplexing rule) for retransmitted PUCCH under enabled OCC conditions. The UE first determines the multiplexing method for retransmitted PUCCH, and then transmits PUCCH, PUSCH, or PUSCH carrying UCI based on this determined multiplexing method (or multiplexing rule). The multiplexing of retransmitted PUCCH may include one or more specific schemes to adapt to different application scenarios and network conditions.

[0152] This invention provides a multiplexing method for retransmitted PUCCHs under uplink channel enabled OCC function, specifically including the following two schemes: 1. A multiplexing method for a single retransmitted PUCCH; and 2. A multiplexing method for multiple retransmitted PUCCHs.

[0153] Multiplexing method for a single repeated transmission PUCCH:

[0154] For multiplexing between a single retransmitted PUCCH and an OCC group, one of the following methods can be used: 1. For the overlapping portion between the retransmitted PUCCH and the OCC group, it can be handled by retransmission, enabling OCC, truncation, or dropping. For the non-overlapping portion, it can be dropped or delayed for transmission on available resources. The overlapping portion can be a PUCCH or a PUSCH that overlaps with it, and the available resource can be the first PUSCH of the next OCC group or a resource in a non-OCC group. 2. Processing based on priority rules. Priorities can involve the priority between PUCCHs and PUSCHs, the priority of UCI types, or the priority between a retransmitted PUCCH and a PUSCH with OCC enabled. These priorities can be determined by predefinition or explicit indication. 3. Delaying the transmission of the retransmitted PUCCH, with the delay offset value determined based on a pre-configured delay offset value. The object of delayed transmission can be the entire retransmitted PUCCH or any one of the retransmitted PUCCHs. 4. Reserve some resources specifically for transmitting PUCCH, PUSCH, or OCC groups that reuse PUCCH. The configuration of reserved resources can be achieved by indicating the OCC offset value through RRC.

[0155] In the above method, an OCC group is a unit composed of multiple PUSCHs that enable OCC. Repeatedly transmitted PUSCHs may partially overlap with, completely overlap with, or span across OCC groups. The first PUSCH of a repeated transmission may overlap with the first PUSCH within an OCC group, and there may also be time slot offsets.

[0156] Multiplexing methods for multiple recurring PUCCH transmissions:

[0157] For the multiplexing of multiple duplicate transmission PUCCHs, the following schemes can be included: 1. When multiple duplicate transmission PUCCHs overlap with an OCC group, and the multiplexing priority of a single duplicate transmission PUCCH is higher, the duplicate PUCCHs to be multiplexed are determined based on the transmission order or UCI priority rules. These priorities can be determined through predefined or configuration parameters. 2. When multiple duplicate transmission PUCCHs overlap with an OCC group, and the multiplexing priority of multiple duplicate transmission PUCCHs is higher, the following processing methods can be adopted: 1) Retain the first PUCCH after multiplexing and discard the others, treating it as a single duplicate transmission PUCCH. 2) Treat the non-overlapping part (which can be a duplicate PUCCH or a single PUCCH) of the multiplexed duplicate transmission PUCCH as a single duplicate transmission PUCCH, and delay the overlapping part to be transmitted on available time-frequency resources. 3) Retain the overlapping part of the multiplexed duplicate transmission PUCCH and treat it as a single duplicate transmission PUCCH. 4) Only retain the non-overlapping part of the later transmitted duplicate PUCCH and treat it as a single duplicate transmission PUCCH.

[0158] In the multiplexing method of multiple retransmitted PUCCHs, the OCC group is also composed of multiple PUSCHs that enable OCC. The multiple retransmitted PUCCHs can partially overlap with the enabled OCC group, completely overlap with the enabled OCC group, or span across OCC groups, and can carry UCIs with the same or different priorities.

[0159] Example 1-1: Content and Configuration of Beam-hopping Information

[0160] The parameters used in the following explanations and examples are as follows:

[0161] Table 1

[0162] In satellite communication systems, satellites typically use phased array antenna technology to control beam pointing, achieving ground coverage through multiple different beams. Due to limitations in satellite capabilities and transmission power, the number of beams that can be activated simultaneously is usually no more than 16. Therefore, to achieve effective coverage of a large ground area, satellites need to use beam rotation, activating different beams sequentially.

[0163] Referring to Figure 9, these different beams serve different areas at different times. However, under the existing protocol framework, user equipment (e.g., UE 50) can only recognize basic access information such as cell identifiers and synchronization signal blocks (SSBs), while satellite beam information is completely invisible to the UE. This results in UEs in ground areas being unable to obtain beam camping information and not knowing when the satellite will serve their area. Therefore, it is necessary to configure the pattern information of the corresponding beams for the UE so that it can reasonably arrange the execution of communication.

[0164] Terminal equipment (e.g., user equipment 50) needs to be able to receive satellite beam hopping pattern information. This pattern table or pattern information is used to indicate the beam service time and notify the terminal to send and receive control information or service data within a specified time. Beam hopping pattern information includes at least the following: 1. Beam pattern index; 2. Beam dwell time (indicating the service time of the beam in the corresponding area); 3. Beam revisit time (indicating the cycle of the beam resuming service); 4. Beam start and end time information; 5. Beam index; 6. SSB index.

[0165] In addition to the basic information mentioned above, hopping beam pattern information may also include: 1. A list of ground position IDs or coverage area IDs; 2. A PCI index; 3. Beam dwell information for adjacent positions or adjacent coverage areas; 4. Beam indices for adjacent positions or adjacent coverage areas.

[0166] Configuring beam dwell information for adjacent beam positions or adjacent coverage areas is particularly useful for fast-moving terminal devices such as airplanes, drones, airships, vehicles, and trains. These devices may traverse different beam hopping patterns or different beam positions within a single beam hop during high-speed movement. Without pre-configuring adjacent beam position information, these terminals need to re-receive the new beam hopping pattern configuration when switching beam positions, which undoubtedly increases access latency. By pre-configuring beam dwell information for adjacent beam positions, these terminals can understand the beam hopping pattern of the next beam position before switching, thus achieving seamless switching and improving user experience.

[0167] Referring to Figure 10, this embodiment proposes several configuration methods for beam hopping patterns, the first of which is a service area-based configuration method. In this configuration, the satellite simultaneously serves multiple positions within a specific dwell time using beam hopping technology. The areas where these positions are located are uniformly classified as service area X. The satellite illuminates one service area at a time and sends beam dwell information for these areas via system messages at the start of each beam dwell time.

[0168] The advantage of this method is that it directly updates the pattern information each time beam hopping occurs, making it simple to implement and eliminating the need to consider complex mapping relationships. However, if only the beam dwell time and return visit time are configured, terminal devices within the service area can only know the service time but cannot determine when the beam service begins. Therefore, it is necessary to additionally configure the start time of satellite beam hopping and the start time of beam service in the current service area.

[0169] In practice, the hopping beam pattern information (beampattern-config) can be configured as the default hopping beam pattern in SIB1 / SIB19 / SIB31 / SIBX. Beam service time can be configured explicitly or implicitly; one method is as follows:

[0170] Method 1: The beam hopping start service time can be aligned with system frame #0, or the offset value `beampatternstart_offset` can be configured to indicate the offset between the beam hopping start service time and the position of system frame #0, thus determining the start time of beam hopping. Simultaneously, `beamstart N_offset` is configured to indicate the offset between the start time of different service areas N and the beam hopping start service time. The `beamstart N_offset` value needs to be updated each time a service area is switched. In addition, the dwell time `beamduration` and the beamperiodicity `beamiodicity N` also need to be configured. The beam dwell time can be configured to the same or different values ​​according to service requirements, where N represents the service area number. The time units for these parameters (`beampatternstart_offset`, `beamstart N_offset`, `beamduration`, and `beamperiodicity N`) can be flexibly selected, including radio frames, subframes, time slots, symbols, or milliseconds and seconds. The relevant configuration protocol is defined as follows: Beampattern-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart N_offset INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}

[0171] Method 2: In another configuration method, the hopping beam pattern can be configured by explicitly defining the start and end time points. According to the second option of this embodiment, the hopping beam start service time can be aligned with system frame #0, or the precise start time of the hopping beam can be determined by configuring the offset value beampatternstart_offset to indicate the offset between the hopping beam start service time and the position of system frame #0.

[0172] Unlike the first option, this solution configures `beamstart N_offset` to indicate the offset between the start time of different beam service areas and the start time of beam hopping, and configures `beamend N_offset` to indicate the offset between the end time of different beam service areas and the start time of beam hopping. The system needs to update `beamstart N_offset` and configure the beamperiodicity N each time it switches service areas. The beam dwell time can be configured to the same or different values ​​according to actual service requirements, where N represents the service area number.

[0173] The units for these time parameters (including `beampatternstart_offset`, `beamstart N_offset`, `beamend N_offset`, and `beamperiodicity N`) are flexible, and can be radio frames, subframes, time slots, symbols, or milliseconds, seconds, etc., to adapt to the precise time control requirements in different scenarios. The relevant configuration protocol definition is as follows: `Beampattern-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart N_offset INTEGER(0...1023) beamsend N_offset INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}`

[0174] Method 3: In the third configuration option of this invention, the beamhopping start service time is referenced to system frame #0, and the specific start service time of beamhopping is indicated by configuring the beamhoppingstartpoint parameter. The unit of this parameter can be a radio frame, subframe, or time slot. Simultaneously, beamstart N is configured to indicate the start time point of different service areas N for the beam. beamstart N needs to be updated each time the service area is switched. In addition, the dwell time beamduration and the beamperiodicity N also need to be configured. The beam dwell time can be configured to the same or different values ​​according to service requirements, where N represents the service area number. The units of these time parameters (beamstart N, beamduration, and beamperiodicity N) can be radio frames, subframes, time slots, symbols, or milliseconds or seconds. The relevant configuration protocol is defined as follows: Beampattern-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}

[0175] Method 4: In the fourth configuration option, the beamhopping start service time also refers to system frame #0. The `beamhoppingstartpoint` is configured to indicate the beamhopping start service time, and the unit can be a radio frame, subframe, or time slot. Unlike the third option, this scheme simultaneously configures `beamstart N` and `beamend N` to indicate the start and end times of different beam service areas, respectively. Each time the service area is switched, `beamstart N`, `beamend N`, and the beamperiodicity N need to be updated. The beam dwell time can be configured to be the same or different according to service requirements, where N represents the service area number. The units for these time parameters can be radio frames, subframes, time slots, symbols, or milliseconds or seconds. The relevant configuration protocol definition is as follows: `Beampattern-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N INTEGER(0...1023) beamend N INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}`

[0176] Method 5: The fifth configuration option adopts a more simplified approach, referring only to system frame #0 and configuring the beamduration N and beamperiodicity N. The beamduration and beamperiodicity can be configured to be the same or different according to service requirements, where N represents the service area number. In this scheme, the area number can be obtained implicitly. If the dwell time and beamperiodicity are denoted as W and T respectively, and M represents the number of subframes or time slots in each radio frame, then the following steps need to be performed to obtain the specific time of beam service: (1) Determine X = (N-1) * W (2) Determine the starting SFN frame number of beam service in area N by using SFN mod T = Floor(X / M) (3) Finally, determine the starting time slot or subframe by using X mod M. The protocol definition for related configuration is as follows: Beampattern-Config::=SEQUENCE{ beamduration N INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}

[0177] As an example, when beam hopping begins from system frame #0, the dwell times beamduration 1 and beamduration 2 for the first two beam hoppings can be configured as 20 radio frames each, and the revisit times beamperiodicity 1 and beamperiodicity 2 as 8 radio frames each. When the subcarrier spacing SCS = 30kHz, one radio frame contains 20 time slots. For the first beam hopping, the condition SFN1 mod 8 = 0 is satisfied; for the second beam hopping, the condition SFN2 mod 8 = 1 is satisfied. Therefore, the two beam hopping operations begin from system frames SFN#0 and SFN#1, respectively.

[0178] Method Two: This invention also proposes a second configuration method, which draws on the technical characteristics of NR systems where base stations transmit synchronization signal blocks (SSBs) using time-division multiplexing and continuously change beam direction to achieve full cell coverage. In beam-hopping mode, a similar method can be used, determining the number of SSBs N to be transmitted (which can be 4, 8, or 64) based on the transmission frequency. Each time a beam-hopping coverage area is reached, a specific SSB X is transmitted. The user equipment (e.g., UE 50) obtains the SSB index after decoding the SSB and establishes a beam-hopping pattern associated with that SSB index.

[0179] In SIB1, SIB19, SIB31, or SIBX, the system configures N satellite hopping beam pattern information (BeamHoppingpattern N-1-Config), with each hopping beam pattern information associated with an SSB index. After completing a beam scan of a set of SSB indices (0 to N-1), i.e., completing N hopping beams, the system updates the hopping beam pattern information once.

[0180] The significant advantage of this method is that it allows for pattern settings for multiple beam hoppings with a single configuration, eliminating the need to update the service beam pattern each time a beam hop occurs, thus improving satellite resource utilization. Furthermore, since the update cycle is related to the number of SSBs, the system can update the pattern configuration after polling a set of SSBs, balancing flexibility and efficiency. It is important to note that if only beam dwell time and return visit time are configured, user equipment (e.g., UE 50) can only know the service time but cannot determine when the beam service begins. Therefore, it is also necessary to configure the start service time for satellite beam hopping and the start service time for the current service area.

[0181] The configuration of beam service time can be done explicitly or implicitly. One specific configuration method is as follows:

[0182] Method 1: Align the beam hopping start service time with system frame #0, or configure the offset value `beampatternstart_offset` to indicate the offset between the beam hopping start service time and the position of system frame #0, thereby determining the precise start time of the beam hopping. The beam hopping start service time information can be configured as a fixed value (subsequent beam hopping service reference times are always based on the start time of the first set of beam hopping patterns), or it can be dynamically updated based on the end time of the beam hopping pattern corresponding to the previous set of SSB N-1.

[0183] The system configures the beamstart N-1_offset parameter to indicate the offset between the start time of each beam hopping and the start service time of the beam hopping, and configures the dwell time beamduration and the beamperiodicity N-1. The beam dwell time can be configured to the same or different values ​​according to service requirements, where N is associated with a specific SSB index. The units of these time parameters (beampatternstart_offset, beamstart N-1_offset, beamduration, and beamperiodicity N-1) can be radio frames, subframes, time slots, symbols, or milliseconds or seconds.

[0184] The protocol definition structure of the relevant configuration is as follows: BeamHoppingpattern 0-Config::=SEQUENCE{ beampatternstartpoint INTEGER(0...1023) beamstart 0 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 0 INTEGER(0...1023) SSB INDEX SSB0 ...} BeamHoppingpattern 2-Config::=SEQUENCE{ beampatternstartpoint INTEGER(0...1023) beamstart 2 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) SSB INDEX SSB1 ...} .. BeamHoppingpattern N-1-Config::=SEQUENCE{ beampatternstartpoint INTEGER(0...1023) beamstart N-1 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N-1 INTEGER(0...1023) SSB INDEX SSBN-1 ...}

[0185] Method 2: The second configuration option provides a method for configuring hopping beam patterns based on explicitly defined start and end times. In this method, the system configures N satellite hopping beam pattern information (BeamHoppingpattern N-Config) from SIB1, SIB19, SIB31, or SIBX. Each set of hopping beam pattern information is associated with a specific SSB index. After completing a beam scan of a set of SSB indices (0 to N-1), i.e., completing N hopping beams, the system updates the hopping beam pattern information once.

[0186] Regarding the time reference, the beam hopping start service time can be aligned with system frame #0, or the offset between the beam hopping start service time and the system frame #0 position can be indicated by configuring the offset value `beampatternstart_offset`, thereby accurately determining the start time of the beam hopping. The beam hopping start service time information can be configured as a fixed value, meaning that the reference time for subsequent beam hopping services is always based on the start time of the first set of beam hopping patterns; or it can be dynamically updated based on the end time of the beam hopping pattern corresponding to the previous set of SSB N-1.

[0187] In this scheme, the system configures `beamstart N-1_offset` to indicate the offset between the beam service start time and the hop beam start time, and `beamend N-1_offset` to indicate the offset between the beam service end time and the hop beam start time, as well as the beamperiodicity N-1 for the revisit time. The beam dwell time can be configured to the same or different values ​​according to actual service requirements, where N-1 is associated with a specific SSB index N-1. The units for these time parameters (beampatternstart_offset, beamstart N-1_offset, beamend N-1_offset, and beamperiodicity N-1) can be flexibly selected as radio frames, subframes, time slots, symbols, or milliseconds and seconds.The protocol definition structure of the relevant configuration is as follows: Beampattern 0-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 0_offset INTEGER(0...1023) beamsend 0_offset INTEGER(0...1023) beamperiodicity 0 INTEGER(0...1023) SSB INDEX SSB0 ...} Beampattern 1-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 1_offset INTEGER(0...1023) beamsend 1_offset INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) SSB INDEX SSB1 ...} Beampattern N-1-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart N-1_offset INTEGER(0...1023) beamsend N-1_offset INTEGER(0...1023) beamperiodicity N-1 INTEGER(0...1023) SSB INDEX SSB N-1...}.

[0188] Method 3: The third configuration option provides a simplified method for configuring hopping beam patterns based on a start time point. In this scheme, the system configures N satellite hopping beam pattern information (BeamHoppingpattern N-1-Config) through SIB1, SIB19, SIB31, or SIBX. Each set of hopping beam pattern information is associated with a specific SSB index. After completing a beam scan of a set of SSB indices (0 to N-1), i.e., completing N hopping beams, the system updates the hopping beam pattern information once.

[0189] Regarding the time reference, the beamhopping start service time is referenced to system frame #0. The `beamhoppingstartpoint` parameter is configured to precisely indicate the beamhopping start service time; the unit of this parameter can be a radio frame, subframe, or time slot. The system configures the `beamstartN-1` parameter to indicate the start time of different service areas N-1, and updates the `beamstartN-1` value each time a service area is switched. In addition, the `beamduration` and `beamperiodicityN-1` must also be configured. The beamduration can be configured to the same or different values ​​according to service requirements, where N-1 is associated with a specific SSB index.

[0190] The units of these time parameters (beampatternstartpoint, beamstart N-1, beamduration, and beamperiodicity N-1) can be flexibly selected as radio frames, subframes, time slots, symbols, or milliseconds or seconds to meet the precise time control requirements in different scenarios. The protocol definition structure of the relevant configuration is as follows: BeamHoppingpattern 0-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 0 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 0 INTEGER(0...1023) SSB INDEX SSB0 ...} BeamHoppingpattern 1-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 1 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) SSB INDEX SSB1 ...} ... BeamHoppingpattern N-1-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N-1 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N-1 INTEGER(0...1023) SSB INDEX SSBN-1 ...}

[0191] Method 4: The fourth configuration option provides a method for configuring hop beam patterns based on start and end time points. In this scheme, the system configures N satellite hop beam pattern information (BeamHoppingpattern N-1-Config) through SIB1, SIB19, SIB31, or SIBX. Each set of hop beam pattern information is associated with a specific SSB index. After completing a beam scan of a set of SSB indices (0 to N-1), i.e., completing N hop beams, the system updates the hop beam pattern information once.

[0192] Regarding the time reference, the beamhopping start service time is referenced to system frame #0. The `beamhoppingstartpoint` parameter is configured to precisely indicate the beamhopping start service time; the unit of this parameter can be a radio frame, subframe, or time slot. The system configures the `beamstartN-1` parameter to indicate the start time of different beam service areas and the `beamendN` parameter to indicate the end time of different beam service areas. Each time a service area is switched, the system needs to update `beamstartN-1`, `beamendN-1`, and the beamperiodicity N-1. The beam dwell time can be configured to the same or different values ​​according to service requirements, where N is associated with a specific SSB index N-1. The units of these time parameters (`beamstartN-1`, `beamendN-1`, and `beamperiodicityN-1`) can be radio frames, subframes, time slots, symbols, or milliseconds or seconds. The relevant configuration protocol is defined as follows: BeamHoppingpattern N-1-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N INTEGER(0...1023) beamend N INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) ...}

[0193] Method 5: The fifth configuration option provides an implicit beam hopping pattern configuration method based on algorithmic calculation. In this scheme, the system only needs to align with system frame #0 and configure the dwell time beamduration N-1 and the beamperiodicity N-1. The beam dwell time and beamperiodicity can be configured to be the same or different according to service requirements, where N-1 represents the beam position associated with the SSB index (N-1). Under this configuration, the area number can be obtained implicitly.

[0194] Assuming dwell time and revisit time are defined as W and T respectively, and M represents the number of subframes or time slots in each radio frame, the system needs to perform the following three steps to obtain the specific time of beam service: (1) Determine the calculation parameter X = (N-2) * W (2) Determine the starting SFN frame number of beam service in area N by calculating SFN mod T = Floor(X / M) (3) Finally, determine the specific starting time slot or subframe by calculating X mod M. The protocol definition structure related to the configuration is as follows: Beampattern-Config::=SEQUENCE{ beamduration N-1 INTEGER(0...1023) beamperiodicity N-1 INTEGER(0...1023) ...}

[0195] Method 3: Referring to Figure 11, the third configuration method of this invention proposes a beam-hopping scheme based on cell ID. In beam-hopping mode, the system can divide the satellite coverage area into N different groups according to the cell ID, and the area to be served by each beam hopping is uniformly assigned to the same cell ID. Here, the cell ID can be the Physical Cell ID (PCI), the satellite coverage position ID, or the Global Identification Number (GIN).

[0196] In system messages SIB1, SIB19, SIB31, or SIBX, the system configures the beam hopping pattern information BeamHoppingpattern N-Config corresponding to each cell ID under multiple beam hopping, where N is associated with a specific cell ID. For example, if the cell identifier is identified based on PCI, then BeamHoppingpattern 1-Config can be associated with PCI1.

[0197] The significant advantage of this configuration method is that the beam hopping pattern becomes public information, eliminating the need for satellites to update the beam hopping information multiple times for each beam hopping, thus greatly improving system efficiency. Furthermore, compared to the SSB-based method, the cell identifier-based method offers greater flexibility in selecting the direction of the beam hopping positions. With the SSB-index method, the positions illuminated in a single beam hopping typically need to be in the same direction, while the cell identifier-based method allows them to be in different directions, as long as these positions belong to the same cell identifier. This design significantly enhances system flexibility, making it particularly suitable for application scenarios with uneven spatiotemporal user distribution.

[0198] It is important to note that if only beam dwell time and return visit time are configured, terminal devices within the beam service area can only know the service time but cannot determine when the beam service begins. Therefore, the system also needs to configure the start time of satellite beam hopping and the start time of beam service in the current service area. The configuration of beam service time can be implemented explicitly or implicitly, as described below.

[0199] Method 1: In the cell-identifier-based beam hopping scheme, the first specific configuration option provides an implementation based on the start time offset. In this configuration, the beam hopping start service time can be aligned with system frame #0, or the offset value `beampatternstart_offset` can be configured to indicate the offset between the beam hopping start service time and the position of system frame #0, thereby accurately determining the start time of the beam hopping.

[0200] The system configures the beamstart N_offset parameter to indicate the offset between the start time of each beam hopping and the start service time of the beam hopping. It also configures the dwell time (beamduration) and the beamperiodicity N. The beam dwell time can be configured to the same or different values ​​according to actual service requirements, where N is associated with a specific cell ID. The units for these time parameters (beampatternstart_offset, beamstart N_offset, beamduration, and beamperiodicity N) can be flexibly selected as radio frames, subframes, time slots, symbols, or milliseconds (ms) or seconds (s). The protocol definition structure of the relevant configuration is as follows: BeamHoppingpattern 1-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 1 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) Cell ID Cell 1...} BeamHoppingpattern 2-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 2 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 2...} .. BeamHoppingpattern N-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart N INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) Cell ID Cell N ...}

[0201] Method 2: The second specific configuration option provides an implementation based on start and end time offsets. In this configuration, the beam hopping start service time can be aligned with system frame #0, or the offset value `beampatternstart_offset` can be configured to indicate the offset between the beam hopping start service time and the position of system frame #0, thereby accurately determining the start time of the beam hopping.

[0202] The system configures the `beamstart N_offset` parameter to indicate the offset between the beam service start time and the beam hopping start time, and the `beamend N_offset` parameter to indicate the offset between the beam service end time and the beam hopping start time, as well as the beamperiodicity N for the revisit time. The beam dwell time can be configured to the same or different values ​​according to actual service requirements, where N is associated with a specific cell ID. The units for these time parameters (`beamatternstart_offset`, `beamstart N_offset`, `beamend N_offset`, and `beamperiodicity N`) can be flexibly selected as radio frames, subframes, time slots, symbols, or milliseconds or seconds. The protocol definition structure of the relevant configuration is as follows: Beampattern 1-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 1_offset INTEGER(0...1023) beamsend 1_offset INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 1...} Beampattern 2-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart 2_offset INTEGER(0...1023) beamsend 2_offset INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 2...} Beampattern N-Config::=SEQUENCE{ beampatternstart_offset INTEGER(0...1023) beamstart N_offset INTEGER(0...1023) beamsend N_offset INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) Cell ID Cell N ...}

[0203] Method 3: The third specific configuration option provides an implementation based on absolute start time. In this configuration, the beamhopping start service time is referenced to system frame #0, and the beamhoppingstartpoint parameter is configured to accurately indicate the beamhopping start service time. The unit of this parameter can be a radio frame, subframe, or time slot.

[0204] The system configures the beamstart N parameter to indicate the start time of different areas N for beam service, and updates the beamstart N value each time the service area is switched. In addition, the dwell time beamduration and the return visit time beamperiodicity N also need to be configured. The beam dwell time can be configured to the same or different values ​​according to service requirements, where N is associated with a specific cell ID.

[0205] The units of these time parameters (beampatternstartpoint, beamstart N, beamduration, and beamperiodicity N) can be flexibly selected as radio frames, subframes, time slots, symbols, or milliseconds or seconds to meet the precise time control requirements in different scenarios. The protocol definition structure of the relevant configuration is as follows: BeamHoppingpattern 1-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 1 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) Cell ID Cell 1...} BeamHoppingpattern 2-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 2 INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 2 ...} ... BeamHoppingpattern N-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N INTEGER(0...1023) beamduration INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) Cell ID Cell N ...}

[0206] Method 4: The fourth specific configuration option provides an implementation based on explicit start and end times. In this configuration, the beamhopping start service time is referenced to system frame #0, and the beamhoppingstartpoint parameter is configured to precisely indicate the beamhopping start service time. The unit of this parameter can be a radio frame, subframe, or time slot.

[0207] The system configures the `beamstart N` parameter to indicate the start time of beam service in different areas, and configures the `beamend N` parameter to explicitly indicate the end time of beam service in different areas. In addition, the beamperiodicity N (before visit time) also needs to be configured. For the beam dwell time, it can be configured to the same or different values ​​according to actual service requirements, where N is associated with a specific cell ID.

[0208] The units of these time parameters (beamstart N, beamend N, and beamperiodicity N) can be flexibly selected as wireless frames, subframes, time slots, symbols, or milliseconds or seconds to meet the precise time control requirements in different scenarios. The protocol definition structure of the relevant configuration is as follows: BeamHoppingpattern 1-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 1 INTEGER(0...1023) beamend 1 INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) Cell ID Cell 1...} BeamHoppingpattern 2-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart 2 INTEGER(0...1023) beamend 2 INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 2 ...} ... BeamHoppingpattern N-Config::=SEQUENCE{ beamhoppingstartpoint INTEGER(0...1023) beamstart N INTEGER(0...1023) beamend N INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) Cell ID Cell N ...}

[0209] Method 5: In one implementation, the beam hopping pattern information can be configured to align with system frame #0, and simultaneously configure the beam duration N and beamperiodicity N parameters. These parameters can be configured to the same or different values ​​according to specific service requirements, where N is associated with the cell ID. The beam duration is set to W, the beamperiodicity time to T, and the number of subframes or time slots contained in each radio frame is M (associated with the subcarrier spacing SCS).

[0210] To determine the specific timing of beam service for a particular region N, the system employs the following steps: 1. First, calculate X = (N-1) * W. 2. Determine the starting system frame number (SFN) for beam service in region N by solving SFN mod T = Floor(X / M). 3. Finally, determine the starting time slot or subframe position by calculating X mod M.

[0211] For example, assuming beam hopping begins from frame #0, the dwell times (beamduration 1 and beamduration 2) for the first two beam hoppings are each configured to be 20 radio frames, and the revisit times (beamperiodicity 1 and beamperiodicity 2) are each 8 radio frames. When the subcarrier spacing (SCS) is 30 kHz, one radio frame contains 20 time slots. According to the above calculation method, the first beam hopping satisfies the condition SFN1 mod 8 = 0, and the second beam hopping satisfies the condition SFN2 mod 8 = 1. Therefore, these two beam hoppings begin from system frames SFN#0 and SFN#1, respectively. Specifically, the beam hopping pattern configuration for each associated cell ID can be represented as follows: BeamHoppingpattern 1-Config::=SEQUENCE{ beamduration 1 INTEGER(0...1023) beamperiodicity 1 INTEGER(0...1023) Cell ID Cell 1 ...} BeamHoppingpattern 2-Config::=SEQUENCE{ beamduration 2 INTEGER(0...1023) beamperiodicity 2 INTEGER(0...1023) Cell ID Cell 2 ...} ... BeamHoppingpattern N-Config::=SEQUENCE{ beamduration N INTEGER(0...1023) beamperiodicity N INTEGER(0...1023) Cell ID Cell N ...}

[0212] Where N represents the configuration sequence number associated with the cell ID. This configuration method avoids explicit configuration of specific beam start and end times, determining the beam service time through implicit calculation, effectively reducing configuration overhead.

[0213] Method 4: In one implementation, a cell-identifier-based beam hopping configuration method can be used. This method divides the satellite coverage area into N different groups based on cell IDs, and the area served by each beam hopping is assigned to the same cell ID. The cell ID here can be any of the physical cell ID, satellite coverage beam position ID, or Global Identification Number (GIN). A significant advantage of this method is that the satellite does not need to frequently update the beam hopping information when implementing beam hopping; a default initial beam hopping pattern can be determined through predefined methods. This makes the beam hopping pattern shared information, particularly suitable for scenarios where the terminal location is relatively fixed, such as unmanned farms and long-term climate observation stations. In these scenarios, the terminal devices are typically IoT devices with limited computing power, fixed locations, and simple service types. Frequent updates to the beam pattern are unnecessary, and using a fixed pattern can effectively save energy consumption and signaling overhead.

[0214] If only the beam dwell time and return time are configured, terminals within the beam service area can know the service duration, but cannot determine when the beam service begins. Therefore, it is necessary to configure the start service time of satellite beam hopping and the start time of beam service in the current service area. The start time of satellite beam hopping can be aligned with the system frame number SFN#0, or it can be maintained at a fixed interval of X time units from SFN#0 through a predefined method. This time unit can be a radio frame, subframe, time slot, symbol, second, millisecond, or microsecond.

[0215] The units for beam start time, end time, dwell time, and revisit time can also be radio frames, subframes, time slots, seconds, milliseconds, or microseconds. Specifically, when the beam hopping time is aligned with SFN#0, the beam hopping start and end times can indicate the specific radio frame or the subframe position within a particular radio frame, or they can indicate the time offset from the satellite beam hopping start time. When there is a time offset from SFN#0, the beam hopping start and end times indicate the time offset from the satellite beam hopping start time.

[0216] Table 2

[0217] Examples 1-2: Updating the hopping beam pattern table

[0218] The parameters used in the following explanations and examples are as follows:

[0219] Table 3

[0220] Referring to FIG12, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0221] Step S101: The satellite base station 40 is configured with multiple sets of beam hopping pattern information, including a default pattern and at least one set of candidate patterns. The beam hopping pattern information includes at least one of the following: beam hopping dwell time, beam hopping pattern information index, beam hopping revisit time, or beam hopping start and end time information; and

[0222] Step S103: When it is determined that the hopping beam pattern needs to be updated, the satellite base station 40 sends a hopping beam pattern update instruction 112 to the user equipment. The update instruction 112 is used to activate a set of candidate patterns among the multiple sets of hopping beam pattern information.

[0223] Step S104: The user equipment 50 receives a beam hopping pattern update instruction 112 sent by a satellite base station (e.g., satellite base station 40). The update instruction 112 is used to activate a set of candidate patterns from multiple sets of beam hopping pattern information. The multiple sets of beam hopping pattern information include a default pattern and at least one set of candidate patterns. The beam hopping pattern information includes at least one of the following: beam hopping dwell time, beam hopping pattern information index, beam hopping revisit time, or beam hopping start and end time information.

[0224] Step S106: The user equipment 50 communicates with the satellite base station 40 during the corresponding beam hopping dwell time according to the activated candidate pattern. The satellite base station 40 communicates with the user equipment 50 during the corresponding beam hopping dwell time according to the activated candidate pattern.

[0225] In one or more embodiments of the present invention, the triggering conditions for determining that the beam hopping pattern needs to be updated include: dynamic changes in service, resource adjustments, or user requests.

[0226] In one or more embodiments of the present invention, the method of sending the beam hopping pattern update indication to the user equipment includes: sending the beam hopping pattern update indication via radio resource control reconfiguration signaling; or sending the beam hopping pattern update indication via media access control control element; or sending the beam hopping pattern update indication via downlink control information.

[0227] In one or more embodiments of the present invention, sending the beam hopping pattern update indication via downlink control information includes: adding a beam hopping pattern indication field to the downlink control information to indicate a candidate beam hopping pattern; or encoding a portion of bits of a portion of a field in the downlink control information as the beam hopping pattern update indication; or jointly encoding the candidate beam hopping pattern indication with a portion of a field in the downlink control information; or encoding a reserved bit in the downlink control information as the beam hopping pattern update indication; or obtaining a system message update indication via downlink control information.

[0228] In one or more embodiments of the present invention, the hopping beam pattern information includes a default pattern or candidate pattern configuration effective time parameter, the effective time parameter being used to indicate the effective time of the hopping beam pattern configuration, wherein the reference time point of the effective time is the start time information of the satellite hopping beam, aligned with system frame 0 or having a time offset from system frame 0.

[0229] In one or more embodiments of the present invention, based on a beam-hopping pattern timer, when the timer expires, the system switches to a candidate beam-hopping pattern configuration or waits for a pattern update request from the user equipment. Triggering conditions for determining the need to update the beam-hopping pattern include: dynamic changes in service offerings, resource adjustments, or user requests.

[0230] In one or more embodiments of the present invention, the method of sending the beam hopping pattern update indication to the user equipment includes: sending the beam hopping pattern update indication via radio resource control reconfiguration signaling; or sending the beam hopping pattern update indication via media access control control element; or sending the beam hopping pattern update indication via downlink control information.

[0231] In one or more embodiments of the present invention, sending the beam hopping pattern update indication via downlink control information includes: adding a beam hopping pattern indication field to the downlink control information to indicate a candidate beam hopping pattern; or encoding a portion of bits of a portion of a field in the downlink control information as the beam hopping pattern update indication; or jointly encoding the candidate beam hopping pattern indication with a portion of a field in the downlink control information; or encoding a reserved bit in the downlink control information as the beam hopping pattern update indication; or obtaining a system message update indication via downlink control information.

[0232] Receiving the hopping beam pattern update indication via downlink control information includes: decoding a newly added hopping beam pattern indication field in the downlink control information to indicate a candidate hopping beam pattern; or decoding a portion of bits from a portion of a field in the downlink control information as the hopping beam pattern update indication; or jointly decoding the candidate hopping beam pattern indication with a portion of a field in the downlink control information; or decoding a reserved bit in the downlink control information as the hopping beam pattern update indication; or obtaining a system message update indication via downlink control information.

[0233] In one or more embodiments of the present invention, the hopping beam pattern information includes a default pattern or candidate pattern configuration effective time parameter, the effective time parameter being used to indicate the effective time of the hopping beam pattern configuration, wherein the reference time point of the effective time is the start time information of the satellite hopping beam, aligned with system frame 0 or having a time offset from system frame 0.

[0234] In one or more embodiments of the present invention, based on a beam-hopping pattern timer, when the timer expires, the satellite base station switches to a candidate beam-hopping pattern configuration or waits for a pattern update request from the user equipment. Based on the beam-hopping pattern timer, when the timer expires, the user equipment switches to a candidate beam-hopping pattern configuration or sends a pattern update request.

[0235] This embodiment proposes a method for updating satellite hopping beam patterns. The satellite can adjust its hopping beam pattern in real time based on dynamic changes in services or coverage requirements, which helps improve resource utilization and enhance the satellite's coverage capabilities. Specifically, the following method can be used:

[0236] Method 1: RRC signaling update method

[0237] In connected mode, to update the hopping beam pattern via RRC signaling, the user equipment (e.g., UE 50) must be notified of at least the following parameters: 1. Beam dwell time; 2. Beam return time; 3. Beam start and end time information.

[0238] Since the start and end times of the beam can be explicitly or implicitly indicated to the UE, the corresponding parameters can be updated based on the aforementioned configuration method. Taking the first option of the aforementioned method as an example, the UE can be instructed to update parameters such as the beam hopping start time (beampatternstart_offset), beam hopping start position (beamstart N_offset), beam dwell time, and beamperiodicity N via RRC signaling (beamhoppingUpdate). Its structure is as follows:

[0239] Method 2: Multi-pattern pre-configuration method

[0240] This method configures multiple sets of beam hopping patterns in the initial stage, including a default configuration pattern and multiple candidate configuration patterns. The number of candidate configurations depends on the capabilities of the satellite or UE. The default configuration pattern is used during the initial communication phase. This method of configuring multiple patterns improves the operational flexibility of the satellite base station (e.g., satellite base station 40) while reducing the signaling overhead required to update the patterns. Specifically, the beam hopping pattern configuration list (BeamhoopingConfiglist) can be configured in system messages SIB1 / SIB19 / SIB31 / SIBX, with the following structure:

[0241] Through these two methods, satellite communication systems can flexibly adjust beam skipping patterns according to actual needs, ensuring efficient use of resources.

[0242] In this embodiment, BeamHoppingpattern#0 is defined as the default pattern configuration, dedicated to the initial access process. If no other beam-hopping pattern is configured or no pattern switching command is received, the system will continue to use this default configuration as the satellite's beam-hopping pattern. For pattern switching, the present invention proposes the following method:

[0243] Option 1: RRC reconfiguration method

[0244] The beamhoppingpattern-ID parameter is reconfigured via RRC signaling RRCReconfiguration, releasing the default beamhoppingpattern#0 and activating other pre-configured beamhopping patterns. It is important to note that if a user equipment (e.g., UE 50) receives an RRC reconfiguration beamhopping pattern switching instruction during random access (RA) proceedings, the UE must first stop the current random access procedure, complete the beamhopping pattern switching, and then restart the random access procedure.

[0245] Option 2: MAC CE activation method

[0246] Referring to Figure 13, to reduce transmission latency, this option activates the default beam hopping pattern configuration via the Media Access Control (MAC) element (CE), and simultaneously activates the IDs corresponding to other beam hopping patterns. When the system is configured with N additional beam hopping patterns, ceil(log2(N)) bits are needed for indication. Ceil() represents the floor function. For example, if 4 additional beam hopping patterns are configured, 2 bits are needed for indication.

[0247] In its implementation, the Beamhoppingpattern MAC CE has a fixed bit size, consisting of a single octet, including: 1. R: Reserved bits for future expansion; 2. Beamhoppingpattern ID: This field indicates the corresponding ID for different beamhopping patterns, occupying 4 bits.

[0248] This design enables the satellite system to flexibly and quickly switch between different hopping beam patterns based on network conditions and service requirements, thereby optimizing system performance and resource utilization.

[0249] Option 3: Instruction via Downlink Control Information (DCI)

[0250] Method a: In another embodiment, the present invention proposes a method for indicating beamhopping pattern switching via downlink control information (DCI). Specifically, a beamhopping indicator field can be added to the DCI to indicate the target beamhopping pattern to be switched.

[0251] When the system is configured with N additional beamhopping patterns, this indicator field requires ceil(log2(N)) bits. Referring to the table below, for example, if the system is configured with 4 additional beamhopping patterns, then 2 bits are needed to indicate the switching target. The beamhopping indicator field can be encoded as follows: when the field value is "00", it indicates switching to pattern ID=1; "01" indicates switching to pattern ID=2; "10" indicates switching to pattern ID=3; and "11" indicates switching to pattern ID=4.

[0252] Table 4 In this embodiment, the present invention further proposes several methods for instructing beam hopping pattern switching via downlink control information (DCI):

[0253] Method b: Reinterpreting the DCI domain

[0254] This method indicates hopping beam patterns by reinterpreting certain fields in the DCI. When the system is configured with N additional hopping beam patterns, ceil(log2(N)) bits are required for indication. Fields that can be reinterpreted include, but are not limited to, the Modulation and Coding Scheme (MCS) field, the Hybrid Automatic Repeat reQuest (HARQ) field, the Frequency Domain Resource Allocation (FDR) field, or the Time Domain Resource Allocation (TDRA) field.

[0255] For example, if four additional beam hopping patterns are configured, 2 bits are needed for indication. In non-terrestrial network (NTN) scenarios, due to insufficient link budget and low transmission rate, the demand for higher-order modulation is limited. Considering that higher-order modulation has poorer anti-interference capability than lower-order modulation in long-distance transmission environments, 2 bits can be extracted from the MCS field to indicate the beam hopping pattern. This leaves 3 bits in the remaining MCS field, capable of indicating 8 states, retaining the first 8 rows of the existing MCS table. Alternatively, 2 bits can be extracted from the HARQ field, leaving 2 or 3 bits in the remaining HARQ field (depending on the configuration).

[0256] Method c: Joint encoding method

[0257] This method indicates beamhopping patterns by jointly encoding them with existing fields in the DCI. Fields that can be used for joint encoding include, but are not limited to, the TDRA field, FDRA field, or demodulation reference signal (DMRS) field. For example, a column "Beamhoppingpattern" can be added to the TDRA table to indicate the ID corresponding to the beamhopping pattern.

[0258] Method d: Reserved bit reinterpretation method

[0259] When two bits are needed to indicate the hopping beam pattern (e.g., when four candidate patterns are configured), this function can be achieved by reinterpreting the reserved bits in the DCI.

[0260] Method e: Paging-based system message update indication method

[0261] For UEs camped in a cell, if the beam hopping pattern is configured via system messages (SIB1 / SIB19 / SIB31 / SIBX), beam hopping pattern updates are considered partial system message updates. UEs can receive a system message update indication by receiving a DCI scrambled with the Paging Radio Network Temporary Identifier (P-RNTI). Idle or inactive terminals need to detect the P-RNTI-scrambled DCI at their respective paging times, while connected UEs can detect this type of DCI at any paging time within a paging cycle.

[0262] Method f: DCI reserved bits advanced reinterpretation method

[0263] For UEs camped in a cell, if the beam hopping pattern is configured via system messages (SIB1 / SIB19 / SIB31 / SIBX), beam hopping pattern updates are part of system message updates. The UE can receive a system message update indication via a DCI scrambled with the Paging Radio Network Temporary Identifier (P-RNTI). To further indicate the beam hopping pattern ID that needs to be switched, the reserved bits in the P-RNTI scrambled DCI can be reinterpreted. The interpretation of the remaining bits differs depending on the cell's spectrum access mode: (8-M) bits are required for cells with shared spectrum channel access in frequency range 1, or for cells operating in frequency range 2-2; (6-M) bits are required for cells without shared spectrum channel access. Here, M represents the number of bits in the Tracking Reference Signal Availability Indication field, which can be 0, 1, 2, 3, 4, or 5, depending on the base station (e.g., satellite base station 40) configuration. If four additional beam hopping patterns are configured, 2 bits are needed for indication, which can be indicated by reinterpreting the reserved bits.

[0264] To avoid impacting existing DCI interpretation, this invention introduces the RRC configuration parameter `beamhoppingpatternUpdate`. The DCI-based pattern switching function is only enabled when this parameter is present. Alternatively, the same functionality can be achieved by defining a new RNTI for scrambling DCI or by defining a new DCI format.

[0265] Method 3: Beam skipping pattern update mechanism based on effective time

[0266] In one embodiment, the present invention proposes to add an additional time parameter, beamhoppingvaluetime, when configuring beamhopping information parameters to indicate the effective time of the beamhopping pattern configuration. This effective time parameter can be applied only to the default beamhopping pattern configuration, only to candidate pattern configurations, or to all pattern configurations. The time unit can be flexibly set to a radio frame, subframe, second, millisecond, or X milliseconds (X can be any integer value, depending on the base station configuration). The reference time point for the effective time is the start time information of the satellite's beamhopping deployment, which can be aligned with the system frame number SFN#0, or have a time offset from SFN#0.

[0267] This invention also proposes a scheme for configuring a beamhopping timer, the working mechanism of which is as follows: 1. Start condition: The satellite starts beamhopping transmission or the user equipment (e.g., UE 50) receives relevant beamhopping configuration information. 2. Stop condition: The UE receives a radio resource control reconfiguration message, an RRC termination message, or the beam dwell time is insufficient to complete the service transmission. 3. Action after timeout: Automatically switch to the next candidate configuration according to the pattern configuration ID, or the UE notifies the base station (e.g., satellite base station 40) that it needs to switch the beamhopping pattern.

[0268] This time-based update mechanism is particularly suitable for satellite communication systems. Because satellites may need to correct their orbital parameters during motion, the visibility time across the entire service area needs to be adjusted. Furthermore, as satellite deployment density increases, hopping beam patterns also require corresponding updates. This method, by configuring the time-based update, can adaptively adjust the hopping beam pattern while saving signaling overhead.

[0269] Method 4: UE-initiated beam hopping pattern update method

[0270] The UE-initiated beam hopping pattern update method can adopt at least one of the following options: Option 1: receive the beam hopping pattern update request via UCI; or Option 2: receive the beam hopping pattern update request via SR; or Option 3: receive the beam hopping pattern update request via MAC CE; or Option 4: receive the beam hopping pattern update request via RRC signaling.

[0271] Option 1: When a UE needs to request a change in beam hopping pattern, beam dwell time, or backhaul time due to changes in service requirements, the method of reporting the handover request via uplink control information can be adopted.

[0272] The specific implementation method is as follows: Multiple sets of beam-hopping patterns are initially configured, including a default configuration pattern and multiple candidate configuration patterns. The number of candidate configurations depends on the satellite or UE capabilities. Each beam-hopping pattern is associated with a Beamhoppingpattern-ID. The default configuration pattern Beamhoppingpattern#0 is used during the initial communication phase. This invention designs a dedicated UCI type BUR (Beampattern update request) to notify the base station (e.g., satellite base station 40) to request a switch of the beam-hopping pattern. This includes the corresponding ID (Beamhoppingpattern-ID) for changing the pattern, as well as the UE's position information, associated synchronization signal block index information, or associated cell identifier. In the Medium Access Control (MAC) configuration, the logical channel associated BUR is configured with Beampatternupdaterequest, and at least one of the following is also configured: a timer BUR-Timer and a repetition number BUR-Num. The unit of the timer can be milliseconds, seconds, time slots, symbols, radio frames, or subframes. During the timer's operation, the UE no longer sends a handover request. One example is shown below:

[0273] Table 5

[0274] Table 6

[0275] Physical layer resource allocation mechanism

[0276] In this embodiment, the physical layer resource configuration method corresponding to the Beampattern Update Request (BUR) is as follows: the BeampatternupdaterequestResourceConfig is configured in the Physical Uplink Control Channel Configuration (PUCCH-Config). This configuration includes at least the PUCCH format configuration resource identifier (PUCCH-ResourceID) corresponding to the BUR, the pattern index (BeamhoppingpatternID) that must be transmitted, and the beamposition information (beampositionID) of the user equipment (e.g., UE 50), the associated Synchronization Signal Block index (SSB index) information, or the associated cell identifier information (cellID).

[0277] Based on the number of bits occupied by the Information Element (IE) corresponding to the update index, this invention dynamically selects different PUCCH formats: when the IE corresponding to the update index occupies more than 2 bits, PUCCH format 2, 3, or 4 is selected; when the switching type information is less than or equal to 2 bits, PUCCH format 0 or 1 is selected. This format selection mechanism based on information content can optimize the resource utilization efficiency of the uplink control channel while ensuring transmission reliability.

[0278] Table 7

[0279] Pattern update mechanism based on scheduling requests

[0280] This invention also proposes a method for reporting beam hopping pattern update requests using the existing Scheduling Request (SR) mechanism. In current wireless communication systems, users can configure up to eight SR types to support scheduling requests for different services. To achieve the function of reporting beam hopping pattern update requests via SR, this invention proposes adding a configuration type ID to the Scheduling RequestId at the Medium Access Control (MAC) layer, expanding the original eight types (0..7) to nine (0..8), as specifically defined below:

[0281] Table 8

[0282] In the MAC cell group configuration (MAC-CellGroupConfig), under the SR configuration item schedulingRequestConfig, when the schedulingRequestID value is 8, add at least one of the following parameters: SR prohibit timer (sr-ProhibitTimer) and maximum retransmission count (sr-TransMax). In the physical uplink control channel configuration (PUCCH-config), configure SR resources for the uplink bandwidth part (BWP), where the SR resource ID is associated with the corresponding SR configuration ID.

[0283] In the radio resource control signaling for SR resource configuration, this invention adds an Information Element (IE) BeamhoppingpatternID to indicate the pattern type for handover. When the system is configured with N beamhopping patterns, this IE occupies ceil(log2(N)) bits. Furthermore, user equipment (e.g., UE 50) can also report its own beam position information, associated synchronization signal block index (SSB index) information, or associated cell identifier information (cellID).

[0284] Based on the bit occupancy of the candidate hop beam pattern type, different PUCCH formats are dynamically selected: when the occupancy is greater than 2 bits, PUCCH format 2, format 3 or format 4 is selected; when the occupancy is less than or equal to 2 bits, PUCCH format 0 or format 1 is selected.

[0285] This invention also configures the `enableBeampatternUpdaterequest` parameter in the RRC signaling `PUCCH-Config` to enable the function of sending beamhopping pattern update requests via the SR. If this field does not exist, the SR pattern update function is disabled, and `BeamhoppingpatternID` is not configured, thus providing a flexible function control mechanism. A specific example is shown below:

[0286] Table 9

[0287] Dedicated scheduling request beam hopping pattern update mechanism

[0288] This invention also proposes a dedicated scheduling request mechanism for beam hopping pattern updates. In this mechanism, the scheduling request identifier parameter value corresponding to the dedicated SR depends on the base station (e.g., satellite base station 40) configuration. This dedicated SR is triggered entirely by the beam hopping pattern update request. Once triggered, the user equipment (e.g., UE 50) will transmit a Medium Access Control Protocol Data Unit (MAC PDU), which contains a MAC control element dedicated to indicating the beam hopping pattern update configuration.

[0289] The specific structure of the MAC CE follows the format described in the aforementioned method, including a reserved bit (R) and a Beamhopping Pattern ID field, the latter used to indicate the corresponding ID of different beamhopping patterns. This dedicated SR mechanism simplifies the pattern update process, reduces signaling overhead, and is particularly suitable for scenarios requiring frequent adjustments to beamhopping patterns. A specific example is as follows:

[0290] Table 10

[0291] Option 2: Pattern switching request mechanism based on RRC signaling

[0292] The present invention also proposes a method for sending a pattern switching request via radio resource control signaling. Specifically, a user equipment (e.g., UE 50) can request to switch beamhopping patterns by sending a beampatternupdate RRC signaling message, which includes the information element BeamhoppingpatternID indicating the target beamhopping pattern.

[0293] Considering the round-trip time (RTT) between the satellite and the ground terminal, to reduce signaling interaction, improve access efficiency, and reduce access time, this invention also proposes adding the BeamhoppingpatternID information element to the UE Assistance Information sent by the UE to the base station (e.g., satellite base station 40) to indicate different beam hopping pattern types. This approach fully utilizes existing assistance information mechanisms, requires no additional dedicated signaling interaction, and is more suitable for satellite communication environments.

[0294] Option 3: Pattern update request mechanism based on MAC CE

[0295] Referring to Figure 14, the present invention further proposes a method for sending pattern update requests via a Media Access Control (MAC) element. This method can be implemented by defining a new dedicated MAC CE or by adding relevant fields to an existing MAC CE.

[0296] In practical implementation, a BeamhoppingpatternID field can be added to the Timing Advance Report MAC CE that is submitted in advance (TA) to report beamhopping pattern update requests. This field includes N candidate pattern types and occupies ceil(log2(N)) bits. For example, when four candidate pattern types are included, this field occupies 2 bits. This design fully utilizes the existing MAC CE transmission mechanism, reduces implementation complexity, and improves spectrum utilization efficiency.

[0297] Considering that user equipment (e.g., UE 50) actively initiates beam hopping pattern update requests and needs to confirm their success status, this invention provides the following confirmation mechanism:

[0298] Method 1: Define a pattern update confirmation timer

[0299] When a user equipment (e.g., UE 50) needs to initiate a beam hopping pattern update request due to changes in service requirements, a timer mechanism can be used to confirm the success of the update. This timer indicates the validity of the beam hopping pattern update request initiated by the UE. If the timer does not expire, it indicates that the initiated pattern update request is still valid. The timer unit can be flexibly set to milliseconds, seconds, time slots, or symbols, and the UE will not send new pattern update requests during the timer's operation. The timer's operation mechanism is as follows: 1. Start conditions: 1) When the UE meets the trigger condition for sending a pattern update 2) After the UE sends a beam hopping pattern update request 2. Stop conditions: 1) No feedback is received from the base station (e.g., satellite base station 40) within the configured time 2) A pattern update success or failure indication is received from the base station within the configured time 3) The UE needs to send a new pattern update request due to changes in service requirements 3. Operation options after timeout: 1) Determine that the pattern update handover has failed 2) Repeat the update request until feedback is received from the base station 3) Repeat the update request a configured number of times; if the configured number is exceeded, determine that the handover has failed and stop sending.

[0300] Method 2: Confirmation mechanism based on base station indication

[0301] The base station (e.g., satellite base station 40) can indicate the result of the beam hopping pattern update to the UE via radio resource control signaling, downlink control information, or media access control elements. The indication content may include an index corresponding to success and failure. If the update fails, the indication information may include the reason for the failure, such as the target base station not having sufficient radio resources, the target satellite not being configured to allow the UE to perform beam hopping pattern updates, or the source base station not receiving the UE's update request, etc.

[0302] Examples 1-3: Mapping relationship of RO in beam skipping mode

[0303] The parameters used in the following explanations and examples are as follows:

[0304] In satellite communication systems, satellites control beam pointing using phased array antenna technology, utilizing multiple different beams to cover ground areas. However, due to limitations in satellite capabilities and transmission power, the number of beams that can be activated simultaneously is typically no more than 16. To achieve coverage of a wider ground area, satellites need to employ beam rotation, activating different beams sequentially. During this process, each beam resides in a specific ground area for a period of time, and user equipment (e.g., UE 50) can only perform uplink and downlink data transmission during the beam's residency period.

[0305] This beam polling mechanism can affect the transmission of random access opportunities (RO). To address this issue, this invention proposes the following methods:

[0306] Method 1: Defining Available ROs. Based on existing random access opportunity transmission rules and combined with the beam dwell time characteristics in beam hopping mode, an available RO determination mechanism is established. Specifically, when the starting subframe position of a random access opportunity falls within the beam dwell time, the RO is determined to be an available RO, and the user equipment (e.g., UE 50) can use this time-frequency resource to transmit the random access preamble; conversely, if the starting subframe position of the random access opportunity is not within the beam dwell time, it is determined to be an unavailable RO.

[0307] Method 2: Sliding RO. When a random access opportunity for a user equipment (e.g., UE 50) to send a preamble occurs outside the beam dwell time, a sliding mechanism is used to postpone the start subframe of the RO to the start subframe of the next beam dwell time. This method ensures that the random access process only occurs within the effective beam coverage period, improving the success rate of random access.

[0308] Examples 1-4: RAR window and contention resolution window design in beam skipping mode

[0309] In embodiments 1-4 of this invention, solutions are proposed for the design of the Random Access Response (RAR) window and contention resolution window in beam hopping mode. To prevent the RAR window and contention resolution window from falling outside the beam dwell time, thus causing random access failure, this invention employs the following method:

[0310] A window rule specific to beam-hopping mode is defined, stipulating that the starting positions of the RAR window and the contention resolution window must fall within the beam dwell time. When the calculated window starting position falls outside the beam dwell time, the system will determine that position as an unavailable window starting position and automatically delay the window starting time to the starting subframe position of the next beam dwell time. This mechanism ensures that each stage of the random access procedure occurs only within the effective beam coverage period, thereby improving the success rate of random access and system efficiency.

[0311] Referring to FIG15, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0312] Step S332: The user equipment 50 transmits a physical uplink control channel, an OCC-enabled physical uplink shared channel, or an OCC-enabled physical uplink shared channel carrying uplink control information to the satellite base station (e.g., satellite base station 40). The physical uplink control channel, the OCC-enabled physical uplink shared channel, or the OCC-enabled physical uplink shared channel carrying uplink control information is based on the multiplexing rules between the repeatedly transmitted physical uplink control channel and the OCC-enabled physical uplink shared channel.

[0313] Step S333: The satellite base station 40 receives the user equipment (e.g., UE 50) physical uplink control channel, or the physical uplink shared channel with OCC enabled, or the physical uplink shared channel carrying uplink control information with OCC enabled. The physical uplink control channel, the physical uplink shared channel with OCC enabled, or the physical uplink shared channel carrying uplink control information with OCC enabled is based on the multiplexing rules between the repeatedly transmitted physical uplink control channel and the physical uplink shared channel with OCC enabled.

[0314] In one or more embodiments of the present invention, the satellite base station configures uplink channel enable orthogonal coverage code (OCC) function related information for the user equipment. The OCC function related information includes at least one of the following: OCC scheme type, OCC sequence length, OCC enable indication, or OCC sequence index. The user equipment receives the uplink channel enable orthogonal coverage code (OCC) function related information, which includes at least one of the following: OCC scheme type, OCC sequence length, OCC enable indication, or OCC sequence index.

[0315] In one or more embodiments of the present invention, the relevant information of the OCC function further includes at least one of OCC offset value, delayed transmission offset value, and multiplexing priority information, wherein the OCC offset value is used to indicate that the user equipment reserves resources for transmitting physical uplink control channels or physical uplink shared channels or physical uplink shared channels that reuse physical uplink control channels, and the delayed transmission offset value is used to indicate the time offset value of the user equipment for delaying the transmission of a single physical uplink control channel or repeatedly transmitting physical uplink control channels.

[0316] In one or more embodiments of the present invention, the multiplexing rule includes: when a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, the user equipment multiplexes the physical uplink control channel onto all physical uplink shared channels within the OCC group that overlap with the physical uplink control channel, and enables inter-slot OCC as part of the OCC group, with the spreading length based on the configured OCC sequence length; wherein, the OCC group is a group composed of multiple consecutively transmitted physical uplink shared channels that enable OCC, and these physical uplink shared channels belong to the same user equipment.

[0317] In one or more embodiments of the present invention, the multiplexing rule includes: when a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, processing the overlapping portion based on priority rules, wherein the priority rules include: a predefined rule that control signals have higher priority than data signals; or priority parameters transmitted by the physical uplink control channel and the physical uplink shared channel configured through radio resource control, downlink control information, or media access control elements; or determining the priority based on the type of uplink control information carried by the physical uplink control channel.

[0318] In one or more embodiments of the present invention, when the priority of physical uplink control channel transmission is higher than the priority of physical uplink shared channel transmission, the user equipment prioritizes transmitting duplicate physical uplink control channels and discards overlapping OCC groups; when the priority of physical uplink control channel transmission is lower than the priority of physical uplink shared channel transmission, the user equipment directly discards duplicate physical uplink control channels, or discards physical uplink control channels overlapping with OCC groups and transmits non-overlapping physical uplink control channels on available time-frequency resources of non-OCC groups, or delays the transmission of duplicate physical uplink control channels to available time-frequency resources of non-OCC groups.

[0319] In one or more embodiments of the present invention, the multiplexing rules include: when a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel does not cross OCC groups, the user equipment delays the transmission of the physical uplink control channel to the position of the first physical uplink shared channel in the next OCC group, and continues to repeat the transmission until the length is the same as the length of the OCC group; or when a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel crosses OCC groups, the user equipment discards the physical uplink control channel that overlaps with the physical uplink shared channel within the OCC group, and multiplexes the remaining physical uplink control channels on available time-frequency resources.

[0320] In one or more embodiments of the present invention, the offset parameter is configured for all user equipment within a cell or OCC group by radio resource control, or by configuring an additional offset value in a time-domain resource allocation table by downlink control information, or by directly indicating a field in the downlink control information.

[0321] In one or more embodiments of the present invention, the multiplexing rules include: determining whether multiplexing between duplicate physical uplink control channels and physical uplink shared channels with OCC enabled is supported by configuration parameters or predefined rules, wherein when multiplexing is not supported, the user equipment directly discards duplicate physical uplink control channels or overlapping OCC groups; when multiplexing is supported and the length of the duplicated physical uplink control channels exceeds the length of the OCC group, the user equipment directly discards the duplicate physical uplink control channels.

[0322] In one or more embodiments of the present invention, the multiplexing rule includes: when the user equipment receives downlink control information that activates uplink control information multiplexing, it transmits uplink control information through a specific physical uplink shared channel in an available time slot, wherein the uplink control information multiplexed on the physical uplink shared channel can be multiplexed and transmitted together with uplink data or transmitted separately on the physical uplink shared channel.

[0323] Referring to FIG16, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0324] Step S301: The satellite base station 40 configures the uplink channel enable orthogonal coverage code (OCC) function of the user equipment (e.g., UE 50). The relevant information of the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, and OCC sequence index.

[0325] Step S302: The user equipment 50 receives information related to the uplink channel enabling orthogonal coverage code (OCC) function configured by the satellite base station (e.g., satellite base station 40). The OCC function related information includes at least one of the following: OCC scheme type, OCC sequence length, and OCC sequence index.

[0326] Step S303: The satellite base station 40 determines the multiplexing rules between the physical uplink control channel for single or multiple repeated transmissions and the physical uplink shared channel with OCC enabled in a predefined manner.

[0327] Step S304: The user equipment 50 uses the predefined multiplexing rules between the physical uplink control channel for single or multiple repeated transmissions and the physical uplink shared channel with OCC enabled.

[0328] Step S306: The user equipment 50 transmits uplink control information and uplink data to the satellite base station (e.g., satellite base station 40) through the physical uplink shared channel enabled by the OCC according to the multiplexing rules.

[0329] Step S307: The satellite base station 40 receives uplink control information and uplink data transmitted by the user equipment (e.g., UE 50) through the physical uplink shared channel enabled by the OCC, according to the multiplexing rules.

[0330] In one or more embodiments of the present invention, the multiplexing rules include: when multiple repeatedly transmitted physical uplink control channels overlap with an OCC group, and the priority of a single repeatedly transmitted physical uplink control channel multiplexing with an enabled OCC group is higher, the user equipment determines the repeated physical uplink control channels that need to be multiplexed based on the rules, wherein the rules include: based on the order in which the physical uplink control channels are transmitted, or based on the priority of the uplink control information carried by the physical uplink control channels.

[0331] In one or more embodiments of the present invention, when the rule is based on the order in which the physical uplink control channels are first transmitted, the user equipment preferentially reuses the earliest transmitted physical uplink control channel; when the rule is based on the priority of the uplink control information carried by the physical uplink control channel, the user equipment preferentially reuses the physical uplink control channel carrying uplink control information with higher priority, wherein the priority of HARQ-ACK is higher than that of CSI.

[0332] In one or more embodiments of the present invention, the multiplexing rules include: when multiple repeatedly transmitted physical uplink control channels overlap with an OCC group, and the multiplexing priority of the multiple repeatedly transmitted physical uplink control channels is higher, the user equipment retains the first multiplexed physical uplink control channel and discards the other physical uplink control channels; or the user equipment divides the multiplexed repeatedly transmitted physical uplink control channels into overlapping and non-overlapping parts, processes the non-overlapping part as a single repeatedly transmitted physical uplink control channel, and delays the overlapping part to be transmitted on available time-frequency resources.

[0333] In one or more embodiments of the present invention, the multiplexing rules include: when multiple repeatedly transmitted physical uplink control channels overlap with an OCC group, and the multiplexing priority of the multiple repeatedly transmitted physical uplink control channels is higher, the user equipment retains the overlapping portion of the physical uplink control channels in the multiplexed repeated transmission physical uplink control channels and processes them as a single repeated transmission physical uplink control channel; or the user equipment only retains the non-overlapping portion of the later transmitted repeated physical uplink control channels and processes them as a single repeated transmission physical uplink control channel.

[0334] In one or more embodiments of the present invention, the multiplexing rule includes: when the uplink control information levels carried by two repeatedly transmitted physical uplink control channels are different, the user equipment retains the first physical uplink control channel of the repeatedly transmitted physical uplink control channel obtained after multiplexing the two repeatedly transmitted physical uplink control channels, and discards the other physical uplink control channels.

[0335] In one or more embodiments of the present invention, the multiplexing rule includes: when multiple uplink control messages appear on different physical uplink shared channels within the same OCC span, the user equipment multiplexes the multiple physical uplink control channels to the first physical uplink shared channel position, mapping them sequentially on the first physical uplink shared channel according to the order in which the physical uplink control channels are sent, or mapping them on the first physical uplink shared channel based on the priority of the uplink control information carried from high to low.

[0336] In one or more embodiments of the present invention, the multiplexing rule includes: determining whether multiplexing between multiple duplicate physical uplink control channels and physical uplink shared channels with OCC enabled is supported by configuration parameters or predefined rules, wherein when multiplexing is not supported, the user equipment directly discards multiple duplicate physical uplink control channels or overlapping OCC groups.

[0337] In one or more embodiments of the present invention, the method further includes: configuring offset parameters to instruct the user equipment to reserve resources for transmitting multiplexed physical uplink control channels or physical uplink control channels of overlapping portions or physical uplink control channels of non-overlapping portions after multiplexing, wherein the offset parameters are configured for all user equipment within the cell or OCC group through radio resource control, or by configuring additional offset values ​​in the time domain resource allocation table through downlink control information, or by indicating new domains in the downlink control information.

[0338] Example 2-1: Reuse of a single repeating PUCCH:

[0339] In Embodiment 2-1 of the present invention, a multiplexing method for a single repeated transmission of the Physical Uplink Control Channel (PUCCH) is proposed, and the relevant parameters are described below:

[0340] Table 11

[0341] In this invention, when a repeatedly transmitted Physical Uplink Control Channel (PUCCH) overlaps with an Orthogonal Coverage Code Group (OCC group), specific multiplexing rules are required to ensure the effective transmission of Uplink Control Information (UCI) while maintaining the orthogonality of the OCC group. This invention proposes the following multiplexing scheme:

[0342] Case 1: The repeated PUCCH overlaps with the first physical uplink shared channel PUSCH within the OCC group.

[0343] When the first PUCCH in a repeatedly transmitted PUCCH overlaps with the first PUSCH of an OCC group, specific multiplexing rules are required to achieve UCI multiplexing without affecting the orthogonality of the OCC group. These multiplexing rules include, but are not limited to, the following situations:

[0344] Scenario 1: When the number of PUCCH repetitions is greater than or equal to the length of the OCC group. Referring to Figure 17, for example, when the PUCCH is configured to be repetitive 4 times and the OCC group length is 2, a special multiplexing mechanism is required. In this case, since the number of PUCCH repetitions exceeds the coverage of the OCC group, the system needs to ensure that important control information can be transmitted correctly while maintaining the orthogonality of the OCC group.

[0345] When the repeatedly transmitted Physical Uplink Control Channel (PUCCH) overlaps with the Orthogonal Coverage Code Group (OCC group), this invention proposes the following multiplexing processing methods:

[0346] Method 1: PUCCH and PUSCH multiplexing mechanism

[0347] In this method, each PUCCH can be multiplexed on all physical uplink shared channels (PUSCHs) that overlap with it within the OCC group, or the first overlapping PUCCH can be multiplexed on the overlapping PUSCHs to enable inter-slot OCC as part of the PUSCH. The spreading length is determined according to the configured OCC sequence length.

[0348] For non-overlapping PUCCH segments, one of the following processing methods can be adopted: 1. Directly discard the non-overlapping PUCCH segment. 2. Continue transmission on available time-frequency domain resources in non-OCC groups, since there is no overlap with OCC groups. 3. Configure the Uplink Control Information Request (UCI request) field in the Downlink Control Information (DCI) to activate the UCI multiplexing trigger state. After decoding the DCI, the user equipment (e.g., UE 50) transmits two UCIs in available time slots through the designated PUSCH. The UCI multiplexed on the PUSCH can be multiplexed and transmitted together with uplink data, or it can be transmitted separately on the PUSCH.

[0349] Method 2: Priority-based processing mechanism

[0350] This method handles overlap cases based on different priority rules:

[0351] Option 1: By default, control signals have higher priority than data signals. The entire OCC group is discarded, and duplicate PUCCHs are transmitted first. Non-overlapping PUCCHs can be processed using the method in Method 1.

[0352] Option 2: Indicate the priority of PUCCH and PUSCH transmissions based on priority parameters configured by the base station (e.g., satellite base station 40) or defined priority rules. This parameter can be indicated by Radio Resource Control (RRC) or DCI or Media Access Control (MAC) elements, or configured through a predefined method.

[0353] When the priority of PUCCH transmission is higher than that of PUSCH transmission, the processing method is the same as option 1.

[0354] When the priority of PUCCH transmission is lower than that of PUSCH transmission, the following processing methods are used: a. Directly discard duplicate PUCCH b. Discard PUCCH that overlaps with the OCC group. For non-overlapping PUCCH, you can: (1) discard directly (2) continue transmission on the available time-frequency domain resources of the non-OCC group (3) activate multiplexing through the UCI request field configured by DCI and transmit on the specified PUSCH c. Delay the transmission of duplicate PUCCH to the available time-frequency domain resources of the non-OCC group.

[0355] In one embodiment of the present invention, the system can configure an uplink control information request (UCI request) field in the downlink control information (DCI) to activate the uplink control information multiplexing trigger state. When the user equipment (e.g., UE 50) decodes the DCI containing this configuration, it will transmit two uplink control information UCIs through a specific physical uplink shared channel (PUSCH) in an available time slot. It is worth noting that the UCI transmission method multiplexed on the PUSCH is flexible; it can be multiplexed and transmitted together with uplink data or transmitted separately on the PUSCH, thereby improving system resource utilization efficiency and ensuring reliable transmission of control information.

[0356] Option 3: Determine the processing method based on the UCI type carried by the PUCCH: 1. If the UCI type is Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK), process according to Method 1. If the UCI type is not HARQ-ACK, process according to Option 1. 2. Determine the UCI types to be retained based on the UCI priority parameters or priority rules configured by the base station (e.g., satellite base station 40). This parameter can be indicated by RRC, DCI, or MAC CE, or configured through a predefined method. Retained UCI types are processed according to Method 1; non-retained UCI types are processed according to Option 1.

[0357] This invention further proposes the following two methods for handling the overlap of the Physical Uplink Control Channel (PUCCH) and the Physical Uplink Shared Channel (PUSCH) with OCC enabled:

[0358] Method 3: Reuse Prohibition Mechanism

[0359] With OCC enabled, the system can be configured to not support multiplexing between repeated PUCCHs and OCC-enabled PUSCHs, instead directly discarding repeated PUCCHs. The discarded PUCCH can be the portion overlapping with the OCC group, or it can be the entire repeated PUCCH transmission. The system can determine whether to support this type of multiplexing through configuration parameters or predefined rules, which can be indicated by Radio Resource Control (RRC), Downlink Control Information (DCI), or Media Access Control (MAC) elements, or configured in a predefined manner.

[0360] Method 4: Resource Reservation Mechanism

[0361] Referring to Figure 18, under the condition of meeting the processing time requirements, the system can reserve a portion of time-frequency resources specifically for PUCCH transmission. The configuration methods for reserving resources are as follows: 1. An offset parameter OCCoffset can be configured for all user equipment (e.g., UE 50) within the cell or OCC group via RRC to instruct the UE to reserve resources for PUCCH transmission. 2. An additional offset value OCCoffset can be configured in the Time Domain Resource Allocation (TDRA) table via DCI indication, or the offset parameter OCCoffset can be indicated via a new field. 3. Define a rule that the UE in time slot n+K2+Δ+2 μ *K cell,offset PUSCH is sent in +X, where X is an additional offset value for reserved resources.

[0362] It is important to note that if the reserved resources are insufficient to store all PUCCHs, the system will directly discard the PUCCH content exceeding the reserved resources to ensure the stability of system operation.

[0363] This invention further proposes the following method for handling the multiplexing relationship between the repeatedly transmitted Physical Uplink Control Channel (PUCCH) and the Physical Uplink Shared Channel (PUSCH) with OCC enabled:

[0364] Method 5: Conditional Discard Mechanism

[0365] With OCC enabled, the system can be configured to not support multiplexing between duplicate PUCCHs and OCC-enabled PUSCHs, directly discarding duplicate PUCCHs. Furthermore, even when multiplexing is supported, if the length of a duplicate PUCCH exceeds the length of the OCC group, the system can also be configured to directly discard the duplicate PUCCH. Whether this multiplexing mechanism is supported can be determined through configuration parameters or predefined rules. These parameters can be indicated by Radio Resource Control (RRC), Downlink Control Information (DCI), or Media Access Control (MAC) elements, or configured through predefined methods.

[0366] Scenario 2: Handling when the number of PUCCH repetitions is less than the length of the OCC group

[0367] This invention also considers the case where the number of PUCCH repetitions is less than the OCC group length. Referring to Figure 19, for example, when the PUCCH is configured to be repetitive twice, and the OCC group length is 4, a special processing mechanism is required. In this case, since the number of PUCCH repetitions is insufficient to cover the entire OCC group, the system needs to adopt an appropriate strategy to balance the reliability of control information transmission and the effective utilization of orthogonal resources. When the number of repetitions of the physical uplink control channel PUCCH is less than the orthogonal coverage code group (OCC group) length, this invention proposes the following processing method:

[0368] Method 1: Multiplexing transmission mechanism

[0369] In this method, each PUCCH is multiplexed on all physical uplink shared channels (PUSCHs) that overlap with it within the OCC group, or the first overlapping PUCCH is multiplexed on the overlapping PUSCH as part of the PUSCH to enable inter-slot OCC. The spreading length is determined according to the configured OCC sequence length.

[0370] Method 2: Priority-based processing mechanism

[0371] This method handles overlap cases based on different priority rules:

[0372] Option 1: By default, control signals have higher priority than data signals, the entire OCC group is discarded, and duplicate PUCCHs are transmitted first.

[0373] Option 2: Indicate the priority of PUCCH and PUSCH transmissions based on priority parameters configured by the base station (e.g., satellite base station 40) or determined priority rules. This parameter can be indicated by Radio Resource Control (RRC), Downlink Control Information (DCI), or Media Access Control (MAC) control element (MAC CE), or configured through a predefined method. 1. When the priority of PUCCH transmission is higher than that of PUSCH transmission, the processing method is the same as in Option 1. 2. When the priority of PUCCH transmission is lower than that of PUSCH transmission, the processing method is as follows: a. Directly discard duplicate PUCCHs; b. Delay the transmission of duplicate PUCCHs to available time-frequency domain resources in non-OCC groups for continued transmission.

[0374] Option 3: Determine the processing method based on the UCI type of the uplink control information carried by the PUCCH: 1. If the UCI type is Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK), process according to Method 1. If the UCI type is not HARQ-ACK, process according to Option 1. 2. Determine the UCI types to be retained based on the UCI priority parameters or priority rules configured by the base station (e.g., satellite base station 40). This parameter can be indicated by RRC, DCI, or MAC CE, or configured through a predefined method. Retained UCI types are processed according to Method 1; non-retained UCI types are processed according to Option 1.

[0375] In handling the overlap between the Physical Uplink Control Channel (PUCCH) and the Physical Uplink Shared Channel (PUSCH) with OCC enabled, the present invention also proposes the following method:

[0376] Method 3: Reuse Prohibition Mechanism

[0377] With OCC enabled, the system can be configured to not support duplicate PUCCHs or multiplexing between a PUCCH and an OCC-enabled PUSCH, and to directly discard duplicate PUCCHs. Whether such multiplexing is supported can be determined by configuration parameters or predefined rules. These parameters can be indicated by Radio Resource Control (RRC), Downlink Control Information (DCI), or Media Access Control (MAC) control element CE, or configured through predefined methods.

[0378] Method 4: Resource Reservation Mechanism

[0379] Under the condition of meeting the processing time requirements, the system can reserve a portion of time-frequency resources specifically for PUCCH transmission. The configuration methods for reserving resources are as follows: 1. An offset parameter OCCoffset can be configured for all user equipment (e.g., UE 50) within the cell or OCC group via RRC to instruct the UE to reserve resources for PUCCH transmission. 2. An additional offset value OCCoffset can be configured in the Time Domain Resource Allocation (TDRA) table via DCI indication, or the offset parameter OCCoffset can be indicated via a new domain. 3. Define a rule that the UE in time slot n+K2+Δ+2... μ *K cell,offset PUSCH is sent in +X, where X is an additional offset value for reserved resources.

[0380] If the reserved resources are insufficient to store all PUCCHs, the system will directly discard the PUCCH content exceeding the reserved resources.

[0381] Case 2: A repeated PUCCH overlaps with a non-first PUSCH within the OCC group.

[0382] When the first PUCCH in a repeatedly transmitted PUCCH overlaps with a non-first PUSCH in an OCC group, specific multiplexing rules are also required to maintain the orthogonality of the OCC groups while achieving uplink control information (UCI) multiplexing. This invention proposes several multiplexing rules for this situation, including but not limited to the following:

[0383] Scenario 1: Referring to Figure 20, repeated PUCCHs do not cross OCC groups. When repeated PUCCHs are completely contained within one OCC group and do not cross multiple OCC groups, a special processing mechanism is required to maintain the orthogonality and transmission efficiency of the system.

[0384] When a repeatedly transmitted Physical Uplink Control Channel (PUCCH) overlaps with a non-first Physical Uplink Shared Channel (PUSCH) within an Orthogonal Cover Code (OCC) group and does not cross OCC groups, the present invention proposes the following processing method:

[0385] Method 1: Alignment and Reuse Mechanism

[0386] If the timing processing conditions are met, the PUCCH can continue to be transmitted repeatedly, keeping its transmission length consistent with the length of the OCC group, and the PUCCH can be multiplexed starting from the first PUSCH position within the OCC group; or the first overlapping PUCCH can be multiplexed onto the first PUSCH within the OCC group and enabled as part of the PUSCH, with the spread spectrum length determined according to the configured OCC sequence length.

[0387] Method 2: Delayed Transmission Mechanism

[0388] The repeated PUCCH is delayed and transmitted to available time-frequency resources. Since the OCC sequence length is configured for the user equipment (e.g., UE 50), and the UE knows that the first PUCCH overlaps with the Nth PUSCH within an OCC span, the UE can calculate the required offset value as M-N+1 from the OCC sequence length M. For example, when the OCC sequence length is 4 and the first PUCCH overlaps with the second PUSCH within the OCC group, the PUCCH needs to be delayed by 3 time slots.

[0389] When multiple OCC groups exist in the system, the available time-frequency resource can be the first PUSCH of the next OCC group. In this case, the delayed PUCCH needs to continue to be transmitted repeatedly until its length is the same as the length of the OCC group. At this point, the number of PUCCH repetitions completely overlaps with the next OCC group, and the PUCCH is multiplexed onto each PUSCH. Alternatively, the first PUCCH after the delay can be multiplexed onto the corresponding PUSCH, enabling OCC as part of the PUSCH.

[0390] For example, when the total number of PUSCH repetitions is 8, the OCC sequence length is 4 (forming two OCC groups), the number of PUCCH repetitions is 2, and the first PUCCH overlaps with the second PUSCH in the first OCC group, the system will delay the PUCCH by 3 time slots to the position of the first PUSCH in the second OCC group, and continue to repeat the transmission 2 times, multiplexing it on each PUSCH.

[0391] When there is only one orthogonal coverage code group (OCC group) in the system, the available time-frequency resources are the non-OCC group time-frequency resources, and PUCCH can continue to be transmitted on this resource.

[0392] Method 3: Priority-based processing mechanism

[0393] This method handles overlap cases based on different priority rules:

[0394] Option 1: By default, control signals have higher priority than data signals, the entire OCC group is discarded, and duplicate PUCCHs are transmitted first.

[0395] Option 2: Indicate the priority of PUCCH and PUSCH transmissions based on the priority parameters configured by the base station (e.g., satellite base station 40) or the determined priority rules. This parameter can be indicated by Radio Resource Control (RRC), Downlink Control Information (DCI), or Media Access Control (MAC) Control Element (CE), or configured through a predefined method. 1. When the priority of PUCCH transmission is higher than that of PUSCH transmission, the processing method is the same as in Option 1. 2. When the priority of PUCCH transmission is lower than that of PUSCH transmission, the processing method is as follows: a. Directly discard duplicate PUCCHs; b. Delay the transmission of duplicate PUCCHs and send them to available time-frequency domain resources in non-OCC groups for continued transmission, the processing method is the same as in Method 2.

[0396] Option 3: Determine the processing method based on the UCI type of the uplink control information carried by the PUCCH: 1. If the UCI type is HARQ-ACK, process according to Method 1 and Method 2. 2. If the UCI type is not HARQ-ACK, process according to Option 1. 3. Determine the UCI types to be retained based on the UCI priority parameters or priority rules configured by the base station (e.g., satellite base station 40). This parameter can be indicated by RRC, DCI, or MAC CE, or configured through a predefined method. Retained UCI types are processed according to Method 1 and Method 2; non-retained UCI types are processed according to Option 1.

[0397] In one implementation, when a repeatedly transmitted PUCCH overlaps with a PUSCH within an OCC group, the system can handle such situations in several ways.

[0398] Method 4: Method 4 provides a simplified approach where, with OCC enabled, the system can be configured to multiplex PUCCHs that do not support repeated transmissions with PUSCHs that enable OCC. In this configuration, when an overlap between a repeated PUCCH and an OCC-enabled PUSCH is detected, the user equipment (e.g., UE 50) will directly discard the repeated PUCCH. The system can determine whether to support this type of multiplexing by configuring specific parameters or predefined rules. These configuration parameters can be indicated through Radio Resource Control (RRC) signaling, Downlink Control Information (DCI), Media Access Control (MAC) control element (CE), or set through predefined methods.

[0399] Method 5:

[0400] Method 5 considers the possibility of reserving some time-frequency resources specifically for PUCCH transmission, provided that processing time requirements are met. Regarding the configuration of reserved resources, one of the following methods can be used: 1. Configure the offset parameter OCCoffset uniformly for all user equipment (e.g., UE 50) within the cell or a specific OCC group via RRC signaling. This parameter indicates which resources the user equipment needs to reserve for PUCCH transmission; 2. Dynamically indicate this via DCI. An additional offset value OCCoffset can be configured in the Time Domain Resource Allocation (TDRA) table, or a dedicated field can be added to the DCI to indicate the offset parameter OCCoffset; 3. Define transmission rules, stipulating that user equipment (e.g., UE 50) adds an additional offset value X to the calculated time slot before sending PUSCH, thereby reserving time slot resources for PUCCH transmission. For example, the UE in time slot n+K2+Δ+2... μ *K cell,offset Send PUSCH in +X.

[0401] It should be noted that if the reserved resources are insufficient to accommodate all PUCCHs, the system will directly discard the PUCCH portion that exceeds the reserved resource capacity.

[0402] Scenario 2: Duplicate PUCCHs across OCC groups

[0403] The above method also applies to special cases, such as when repeated PUCCHs cross OCC group boundaries. The system will decide how to handle overlapping PUCCH and PUSCH resources based on the actual configuration. Figure 21 shows an example of repeated PUCCHs crossing OCC groups. In one implementation, when repeated PUCCHs overlap with PUSCHs in an OCC group and the repeated PUCCHs cross OCC groups, several processing methods can be used:

[0404] Method 1: Method 1 involves specific processing of retransmitted PUCCHs under certain time processing conditions. Specifically, although the retransmitted PUCCH only partially overlaps with a PUSCH in the OCC group, the system can allow the PUCCH to continue retransmitting, ensuring its transmission length matches the length of the OCC group, and multiplexing the PUCCH starting from the first PUSCH position within the OCC group. Alternatively, the first overlapping PUCCH can be multiplexed onto the first PUSCH in the OCC group, enabling inter-slot OCC as part of the PUSCH, where the spreading length is determined based on the configured OCC sequence length.

[0405] Method Two: Method Two provides a different processing strategy. When the repeatedly transmitted PUCCH portion overlaps with a PUSCH in an OCC group, the system chooses to discard the overlapping PUCCH portion and reuse the remaining PUCCH on available time-frequency resources. Regarding the determination of available time-frequency resources: 1. When multiple OCC groups exist in the system, the available time-frequency resource can be the first PUSCH position of the next OCC group. In this case, the remaining PUCCH needs to continue to be repeatedly transmitted until its length is the same as the OCC group length, thus ensuring that the number of PUCCH repetitions completely overlaps with the next OCC group, and multiplexing is performed on each PUSCH. Alternatively, the first PUCCH after delayed transmission can be multiplexed onto the corresponding PUSCH and enabled as part of the PUSCH for OCC. For example, when the total number of PUSCH repetitions is 8, the OCC sequence length is 4 (forming two OCC groups), the number of PUCCH repetitions is 2, and the first PUCCH overlaps with the second PUSCH in the first OCC group, the system will delay by 3 time slots to the position of the first PUSCH in the second OCC group and continue to repeat the transmission twice, multiplexing on each PUSCH. 2. When there is only one OCC group in the system, the available time-frequency resources are the time-frequency resources of the non-OCC group, and the remaining PUCCHs can continue to be transmitted on these resources.

[0406] Method 3: Method 3 proposes a delayed transmission mechanism, which delays the overall transmission of repeated PUCCHs to available time-frequency resources. Since the OCC sequence length is communicated to the user equipment (e.g., UE 50) through system configuration, and the user equipment can identify cases where the first PUCCH overlaps with the Nth PUSCH within the OCC span, the user equipment can calculate the required offset value as M-N+1 using the sequence length M. For example, when the OCC sequence length is 4, if the first PUCCH overlaps with the second PUSCH within the OCC group, a delay of 3 time slots is required to avoid overlap and maintain system orthogonality.

[0407] In this embodiment, when multiplexing is involved between PUCCH that is repeatedly transmitted and PUSCH that enables OCC, the system provides a variety of processing schemes, depending on the network configuration and resource availability.

[0408] When multiple OCC groups exist in the system, a delayed PUCCH can utilize the first PUSCH position of the next OCC group as available time-frequency resources. In this case, the delayed PUCCH needs to continue to be transmitted repeatedly until its transmission length is the same as the length of the OCC group, so that the number of PUCCH repetitions completely overlaps with the next OCC group, and it is multiplexed on each PUSCH. Alternatively, the system can choose to multiplex the first delayed PUCCH onto the corresponding PUSCH and enable OCC functionality as part of the PUSCH. For example, when the total number of PUSCH repetitions is 8, the OCC sequence length is 4 (forming two OCC groups), the number of PUCCH repetitions is 2, and the first PUCCH overlaps with the second PUSCH in the first OCC group, the system delays the PUCCH by 3 time slots to the first PUSCH position of the second OCC group and continues to transmit it twice, multiplexing it on each PUSCH.

[0409] When there is only one OCC group in the system, the available time and frequency resources are those of the non-OCC group, and delayed PUCCH can continue to be transmitted on these resources.

[0410] Method 4: Method 4 provides a simplified processing scheme. When OCC is enabled, the system can be configured to not support multiplexing between PUCCHs that do not transmit repeatedly and PUSCHs that enable OCC. Instead, it directly discards repeated PUCCHs or overlapping OCC groups. The system can determine whether to support this type of multiplexing through configuration parameters or predefined rules. These parameters can be indicated through Radio Resource Control (RRC) signaling, Downlink Control Information (DCI), Media Access Control (MAC) control element (CE), or set through predefined methods.

[0411] Method 5: Method 5 proposes a scheme to reserve some time-frequency resources specifically for PUCCH transmission, while meeting processing time requirements. Regarding the configuration of reserved resources, one of the following methods can be adopted: 1. Configure the offset parameter OCCoffset uniformly for all user equipment (e.g., UE 50) within the cell or a specific OCC group via RRC, to indicate that user equipment reserves resources for PUCCH transmission; 2. Configure an additional offset value OCCoffset in the Time Domain Resource Allocation (TDRA) table via DCI dynamic indication, or add a dedicated field in DCI to indicate the offset parameter OCCoffset; 3. Define a rule that stipulates that user equipment (e.g., UE 50) adds an additional offset value X to the calculated time slot before sending PUSCH. UE transmits PUSCH in time slot n+K2+Δ+2. μ *K cell,offset Send PUSCH in +X.

[0412] It should be noted that if the reserved resources are insufficient to accommodate all PUCCH data, the system will directly discard the excess portion.

[0413] Method Six: Method Six specifically proposes a different processing scheme for repeated PUCCH transmissions across OCC groups. Specifically, it discards PUSCHs within overlapping OCC groups, retaining only the first half of the PUCCH. For the second half of the PUCCH, when multiple OCC groups exist, the system adopts a similar processing method as described above, utilizing the resources of the next OCC group; when only one OCC group exists, it continues transmission using the time-frequency resources of the non-OCC group.

[0414] In one specific example of the implementation, when it is necessary to handle the overlap between repeatedly transmitted PUCCHs and PUSCHs that enable OCCs, the system will adopt different processing methods depending on the number of OCC groups.

[0415] When multiple OCC groups exist in the system, the available time-frequency resources are defined as the first PUSCH position of the next OCC group. In this case, the delayed PUCCH needs to continue to be repeatedly transmitted until its transmission length is the same as the length of the OCC group, so that the number of PUCCH repetitions can completely overlap with the next OCC group, and it is multiplexed on each PUSCH in that group. Alternatively, the first PUCCH after delay transmission can be multiplexed onto the corresponding PUSCH and used as part of the PUSCH to enable OCC functionality.

[0416] To illustrate with a specific example: when the total number of PUSCH repetitions is 8, the OCC sequence length is 4 (thus forming two OCC groups), and the number of PUCCH repetitions is 2, and the first PUCCH overlaps with the second PUSCH in the first OCC group, the system will delay the PUCCH by 3 time slots, so that its position corresponds to the first PUSCH position in the second OCC group, and then continue to repetition 2 times, and multiplex it on each PUSCH, thereby maintaining the orthogonality of the system.

[0417] When there is only one OCC group in the system, the available time-frequency resources are defined as the time-frequency resources of the non-OCC group. Delayed PUCCH can continue to be transmitted on these resources without affecting the orthogonality of the OCC group.

[0418] Example 2-2: Multiple repeating PUCCH overlap within the same OCC group

[0419] The parameters used in the following explanations and examples are as follows:

[0420] Table 12

[0421] Scenario 1: Figure 22 illustrates an example of multiple repeatedly transmitted PUCCHs overlapping with an OCC group. In this embodiment, when multiple repeatedly transmitted PUCCHs overlap with an OCC group, and the multiplexing priority is determined to be higher for a single repeatedly transmitted PUCCH than for a PUSCH enabling the OCC, the system needs to determine which PUCCH should be multiplexed. The advantage of this approach is that it eliminates the need to consider complex multiplexing scenarios among multiple PUCCHs, thereby reducing processing complexity. To determine the PUCCH that needs to be multiplexed, the system can use one of the following rules:

[0422] Method 1: Selection based on PUCCH transmission timing. The system will use the first symbol of the PUSCH that overlaps with the earliest transmitted PUCCH, or the last symbol of the corresponding PDCCH that schedules the first PUSCH, as the reference point. The user equipment (e.g., UE 50) will prioritize reusing the earliest transmitted PUCCH according to the start symbol time order of the PUCCH.

[0423] Method 2: Consider the importance of UCI type. Since repeated PUCCHs can only carry the same type of UCI, the system selects based on the priority of the carried UCI type. Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) has a higher priority than Channel State Information (CSI), so the system will prioritize reusing PUCCHs carrying HARQ-ACK. When two repeated PUCCHs carry the same UCI priority, the system will revert to the standard of Method 1, determining priority according to the order of transmission.

[0424] Method 3: A flexible configuration mechanism is introduced to determine the UCI types to be retained based on the UCI priority parameters configured by the base station (e.g., satellite base station 40) or predefined priority rules. These parameters can be indicated through Radio Resource Control (RRC) signaling, Downlink Control Information (DCI), Media Access Control (MAC) control elements (CE), or configured in a predefined manner. The system will reuse PUCCHs carrying high-priority UCIs. Similarly, when multiple repeatedly transmitted PUCCHs carry the same UCI priority, the system will determine the priority according to the transmission timing order described in Method 1.

[0425] Scenario 2: Figure 23 illustrates an example where the multiplexing priority between multiple duplicate PUCCHs is higher than that of multiplexing with an OCC group PUSCH. In this embodiment, when the multiplexing priority between multiple duplicate PUCCHs is higher than that of multiplexing with an OCC group PUSCH, the system handles the multiplexing between PUCCHs based on existing protocol rules. According to these rules, in overlapping time slots, the system adopts the following judgment criteria: if two PUCCHs carry different UCI priorities, the PUCCH carrying the higher priority UCI is sent first; if two PUCCHs carry the same UCI priority, the PUCCH with the earlier start time of the time slot set is sent first. The advantage of this processing scheme is that it is based on existing protocol rules, has less impact on existing protocols, and thus improves system compatibility.

[0426] The system employs different processing strategies for different situations:

[0427] Scenario 1: When two PUCCHs carry the same UCI priority, the system will process them according to the method of Scenario 1 above, that is, determine the priority according to the timing order of PUCCH transmission and reuse the earliest transmitted PUCCH first.

[0428] Scenario 2: When two PUCCHs carry UCI priorities different from each other, and the earlier PUCCH carries a lower UCI priority than the later PUCCH, the two PUCCHs overlap. Following existing rules would result in the multiplexed PUCCHs containing two different UCI priorities. This would cause PUCCHs overlapping with PUSCHs within the same OCC group to carry different UCI types, thus affecting the orthogonality performance of the OCCs. To address this situation, this embodiment proposes the following specialized processing method to maintain the orthogonality of the system and ensure the effective transmission of critical control information.

[0429] Method 1: This method aims to ensure the orthogonality of OCC groups. Its key strategy is to retain the first PUCCH from the multiplexed PUCCHs obtained by reusing two repeatedly transmitted PUCCHs, while discarding the remaining PUCCHs. In this case, the PUCCH multiplexed with the OCC group can be a repeated PUCCH or a single PUCCH; the specific multiplexing method follows the relevant rules in Example 2-1. This method effectively maintains the orthogonality of the system by simplifying the processing flow.

[0430] Method 2: Also focusing on ensuring the orthogonality of the OCC group, but employing a more refined processing strategy. This method divides the repeated PUCCH obtained after multiplexing two repeated PUCCHs into two parts: a non-overlapping part and an overlapping part. For the non-overlapping PUCCH, regardless of whether it is a repeated PUCCH or a single PUCCH, it is multiplexed according to the method in Example 2-1. For the overlapping PUCCH, it is delayed and transmitted to available time-frequency resources. The method for calculating the delayed transmission is based on the OCC sequence length configured for the user equipment (e.g., UE 50), and the position where the first PUCCH identified by the user equipment overlaps with the Nth PUSCH within the OCC span. The user equipment can calculate the required offset value as M-N+1 using the sequence length M. For example, when the OCC sequence length is 4, and the first PUCCH overlaps with the second PUSCH in the OCC group, a delay of 3 time slots is required.

[0431] For the processing of delayed PUCCHs, there are two cases depending on the number of OCC groups in the system: 1. When there are multiple OCC groups in the system, the available time-frequency resource is the position of the first PUSCH in the next OCC group. In this case, the delayed PUCCH needs to continue to be transmitted repeatedly until its length is the same as the length of the OCC group, so that the number of PUCCH repetitions completely overlaps with the next OCC group, and it is multiplexed on each PUSCH. Alternatively, the system can choose to multiplex the first PUCCH after delay to the corresponding PUSCH, enabling the OCC function as a component of the PUSCH. For example, when the total number of PUSCH repetitions is 8, the OCC sequence length is 4 (forming two OCC groups), the number of PUCCH repetitions is 2, and the first PUCCH overlaps with the second PUSCH in the first OCC group, the system will delay by 3 time slots to the position of the first PUSCH in the second OCC group, and continue to transmit repeatedly twice, multiplexing on each PUSCH. 2. When there is only one OCC group in the system, the available time-frequency resources are those of the non-OCC group. Delayed PUCCH can continue to be transmitted on these resources without affecting the orthogonality of the original OCC group.

[0432] Method 3: The design goal of Method 3 is to ensure the orthogonality of the OCC group while guaranteeing that the PUCCH in the overlapping part after multiplexing contains a higher-priority UCI. To achieve this, the system discards the non-overlapping parts of the repeated PUCCH obtained by multiplexing two repeated PUCCHs, retaining only the overlapping parts after multiplexing. In this case, the PUCCH multiplexed with the OCC group can be a repeated PUCCH or a single PUCCH, but the PUCCH in the overlapping part will not appear in the same PUSCH position, thus avoiding interference with orthogonality.

[0433] This method provides two specific implementations based on processing time conditions: When processing time requirements are met, the system can repeatedly transmit the PUCCH according to the length of the OCC group, ensuring it completely overlaps with the first OCC group, and multiplex it on each PUSCH; or, the PUCCH can be multiplexed onto the first PUSCH of the OCC group, enabling OCC functionality together with the PUSCH. When processing time is insufficient, the system can delay the transmission of the overlapping PUCCH on available time-frequency resources, with the specific delay method referring to the aforementioned Method Two.

[0434] Method Four: Method Four, under the premise of meeting processing time conditions, reserves some time-frequency resources specifically for transmitting multiplexed PUCCH, overlapping PUCCH, or non-overlapping multiplexed PUCCH. Several options are provided for configuring these reserved resources: 1. Configure the offset parameter OCCoffset uniformly for all user equipment (e.g., UE 50) within the cell or a specific OCC group via RRC signaling to indicate which resources the user equipment needs to reserve for PUCCH transmission; 2. Configure an additional offset value OCCoffset in the Time Domain Resource Allocation (TDRA) table via DCI dynamic indication, or add a dedicated field in the DCI to indicate the offset parameter OCCoffset; 3. Define transmission rules, stipulating that user equipment (e.g., UE 50) adds an additional offset value X to the calculated time slot before sending PUSCH, thereby reserving time slot resources for PUCCH transmission. The UE in time slot n+K2+Δ+2 μ *K cell,offset Send PUSCH in +X.

[0435] It is worth noting that if the reserved resources are insufficient to accommodate all PUCCH data, the system will directly discard the portion exceeding the reserved resource capacity in order to maintain the overall transmission efficiency and resource utilization of the system.

[0436] Method 5: Method 5 provides a simplified processing strategy under OCC-enabled conditions. The system can be configured to not support multiplexing between duplicate PUCCHs or duplicate PUCCHs and OCC-enabled PUSCHs, instead directly discarding duplicate PUCCHs or overlapping OCC groups. The system can determine whether to support such multiplexing by configuring specific parameters or predefined rules. These configurations can be indicated through Radio Resource Control (RRC) signaling, Downlink Control Information (DCI), Media Access Control (MAC) control elements (CE), or set in a predefined manner. This method simplifies the system processing logic and reduces implementation complexity by explicitly prohibiting specific multiplexing situations.

[0437] Method Six: Method Six proposes a selective retention strategy, which only retains the non-overlapping portions of the retransmitted PUCCHs. It's important to note that this portion of the PUCCH can be either a retransmitted PUCCH or a single PUCCH; the specific processing method follows the relevant rules in Example 2-1. This method ensures the transmission of critical control information while minimizing the impact on the orthogonality of the OCC group.

[0438] Scenario 3: In addition to the methods described above, this embodiment also proposes a special configuration scheme for the multiplexing of multiple duplicate PUCCHs. Specifically, with OCC enabled, the system can be specially configured to completely disable the multiplexing function of multiple duplicate PUCCHs. Under this configuration, the system does not support any form of multiplexing between multiple duplicate PUCCHs and PUSCHs with OCC enabled; instead, it directly discards all PUCCHs or overlapping OCC groups. Similarly, the system can determine whether to enable this configuration through configuration parameters or predefined rules. These parameters can be indicated through RRC signaling, DCI, MAC CE, or set in a predefined manner. This configuration scheme is suitable for application scenarios with high requirements for system simplification and relatively low requirements for uplink control information transmission reliability.

[0439] Examples 2-3: Multiple different PUCCHs overlap within one OCC group

[0440] The parameters used in the following explanations and examples are as follows:

[0441] Table 13

[0442] Figure 24 shows an example of multiple different PUCCHs overlapping within an OCC group.

[0443] In this embodiment, when multiple uplink control messages (UCIs) appear on different PUSCHs within the same OCC span, the system can adopt the following multiplexing rules:

[0444] Method 1: Method 1 is suitable for situations where time processing conditions are met. Its core idea is to multiplex multiple PUCCHs onto the first PUSCH position in the OCC group. Specifically, this can be implemented by mapping the PUCCHs sequentially to the first PUSCH according to their transmission order; or by mapping them from high to low priority based on the UCI they carry. Based on this, the system can continue to repeatedly transmit the PUCCHs until their transmission length matches the length of the OCC group, and then multiplex these PUCCHs starting from the first PUSCH position within the OCC group. Alternatively, the system can choose to multiplex the first overlapping PUCCH onto the first PUSCH within the OCC group and enable inter-slot OCC functionality as part of the PUSCH, where the spreading length is determined based on the configured OCC sequence length.

[0445] Method Two: Method Two, under the premise of meeting the processing time conditions, reserves a portion of time-frequency resources specifically for PUCCH transmission. Several options are provided for configuring these reserved resources: 1. Configure an offset parameter OCCoffset for all user equipment (e.g., UE 50) within the cell or a specific OCC group via RRC signaling to indicate the location of the reserved resources; 2. Dynamically indicate this in the DCI by configuring an additional offset value OCCoffset in the Time Domain Resource Allocation (TDRA) table, or by adding a dedicated field in the DCI to indicate this offset parameter; 3. Define transmission rules specifying that user equipment (e.g., UE 50) adds an additional offset value X to the calculated time slot before sending PUSCH, thereby reserving time slot resources for PUCCH transmission. For example, according to the defined rules, the UE in time slot n+K2+Δ+2... μ *K cell,offset Send PUSCH in +X.

[0446] It should be noted that if the reserved resources are insufficient to accommodate all PUCCH data, the system will discard the portion exceeding the reserved capacity.

[0447] Method 3: Method 3 introduces a priority-based flexible decision-making mechanism. It determines the PUCCH that should be reused, or the priority relationship between PUCCH and PUSCH transmissions, based on priority parameters configured in the base station (e.g., satellite base station 40) or predefined priority rules. These parameters can be indicated through RRC signaling, Downlink Control Information (DCI), Media Access Control (MAC) control elements (CE), or set through predefined methods, thereby achieving dynamic optimization of system resource allocation.

[0448] Example 3: Inconsistent OCC length and number of repeated transmissions. The parameters used in the following descriptions and examples are as follows:

[0449] Table 14

[0450] In this embodiment, when the uplink channel enables the OCC function, if the configured number of repeated transmissions is inconsistent with the OCC length, the system provides a variety of processing schemes, depending on the relative size of the OCC length and the number of repeated transmissions.

[0451] Referring to FIG25, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0452] Step S400a: When the OCC sequence length is less than the number of repeated transmissions of the physical uplink shared channel, the user equipment 50 enables OCC from the earliest physical uplink shared channel position, retains the part of the physical uplink shared channel repeated transmission that overlaps with the OCC sequence according to the OCC sequence length, and discards the part that exceeds the sequence length.

[0453] Step S402a: The user equipment 50 transmits the physical uplink shared channel enabled by the OCC sequence, including the portion of the reserved physical uplink shared channel that overlaps with the OCC sequence.

[0454] Step S403a: The satellite base station 40 receives the physical uplink shared channel enabled by the OCC sequence from the user equipment 50.

[0455] Referring to FIG26, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0456] Step S400b: When the OCC sequence length is less than the number of repeated transmissions of the physical uplink shared channel, the user equipment 50 continues to map the OCC sequence to the remaining physical uplink shared channels according to the OCC sequence length, forming a nominal OCC group.

[0457] Step S402b: The user equipment 50 transmits a physical uplink shared channel enabled by an OCC sequence, including the nominal OCC group.

[0458] Step S403b: The satellite base station 40 receives the physical uplink shared channel enabled by the OCC sequence from the user equipment 50.

[0459] Referring to FIG27, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0460] Step S400c: When the length of the OCC sequence is greater than the number of repeated transmissions of the physical uplink shared channel, the user equipment 50 forms a nominal OCC group, including the portion of the repeated transmissions of the physical uplink shared channel that overlaps with the OCC sequence.

[0461] Step S402c: The user equipment 50 transmits the physical uplink shared channel enabled by the OCC sequence, i.e., the nominal OCC group.

[0462] Step S403c: The satellite base station 40 receives the physical uplink shared channel enabled by the OCC sequence from the user equipment 50.

[0463] Referring to FIG28, an embodiment of the satellite communication method of the present invention is performed on the satellite base station 40 and the user equipment 50. The satellite communication method includes at least one of the following steps (the order of the following steps is not limited):

[0464] Step S400d: When the length of the OCC sequence is greater than the number of repeated transmissions of the physical uplink shared channel, the user equipment 50 forms a nominal OCC group and continues the repeated transmission of the physical uplink shared channel according to the length of the OCC sequence until it is aligned with the length of the OCC sequence. The nominal OCC group includes the repeated transmissions of the physical uplink shared channel.

[0465] Step S402d: The user equipment 50 transmits the physical uplink shared channel enabled by the OCC sequence, i.e., the nominal OCC group.

[0466] Step S403d: The satellite base station 40 receives the physical uplink shared channel enabled by the OCC sequence from the user equipment 50.

[0467] Scenario 1: OCC length is less than the number of repeated transmissions

[0468] Figure 29 illustrates an example where the OCC length is less than the number of repetitions. When the OCC length is less than the number of repetitions, the system can use one of the following two methods:

[0469] Method 1: Considering that the remaining PUSCH / NPUSCH length is insufficient to enable a complete OCC, to ensure normal reception between user equipment (e.g., UE 50), the system specifies that OCC is enabled starting from the earliest PUSCH / NPUSCH position. A corresponding number of duplicate transmissions are retained based on the OCC sequence length, and PUSCH / NPUSCH exceeding the sequence length are discarded. For example, when the configured duplicate transmission count is 3 and the OCC sequence length is 2, the system will retain the first two overlapping PUSCHs and discard the remaining PUSCHs, thereby ensuring the correct enabling and maintenance of the OCC function.

[0470] Method 2: A more flexible processing strategy is proposed, which involves continuing to map the remaining PUSCH / NPUSCH sequences to OCC sequences, thus forming a nominal OCC group. In practice, since the remaining repetition count is insufficient to map a complete OCC sequence, some sequences will have empty resources. However, the system can receive data in segments according to the OCC group, without affecting reception performance. For example, when the repetition count is configured to 3 and the OCC sequence length is 2, OCC will be enabled twice, and the resource corresponding to the last OCC sequence value will be empty, so the reception process will not be affected.

[0471] Scenario 2: OCC length is greater than the number of repeated transmissions

[0472] Figure 30 illustrates an example where the OCC length exceeds the number of repeated transmissions. When the OCC length exceeds the number of repeated transmissions, the system also provides two processing methods:

[0473] Method 1: Recognizing that repeated PUSCH / NPUSCH transmissions are insufficient to enable full OCC functionality, a strategy similar to Method 2 in Scenario 1 is adopted to form a nominal OCC group, receiving the overlapping portion during reception. For example, when the number of repeated transmissions is 3 and the OCC sequence length is 4, the resource corresponding to the last value of the OCC sequence will be empty, and the system will only receive the overlapping portion during reception, thus ensuring correct demodulation of the information.

[0474] Method 2: It is recommended to continue repeating the transmission based on the length of the OCC sequence until it is aligned with the OCC sequence length. During reception, the system reserves PUSCH / NPUSCH resources within the range of repeated transmissions. For any additional repeated transmissions, the system can choose to retain or discard them based on its configuration, thus providing greater system flexibility.

[0475] These methods enable the system to effectively handle situations where the OCC length and the number of repeated transmissions are inconsistent, ensuring the orthogonality and transmission efficiency of the uplink channel.

[0476] Example 4: Indication method for OCC sequence indexing

[0477] In some embodiments, the third information carried in the DCI includes a second field for indicating an OCC sequence. In some examples of this application, the third information is carried in the DCI carrying parameters related to the OCC sequence. For example, the ceil(log2(N)) bit in a field (as the second field) of the downlink control information DCI indicates an OCC sequence in the OCC sequence table, where N is the number of OCC scheme types and ceil is a rounding function. For example, an existing field in the DCI can be reinterpreted as a second field, such that the ceil(log2(N)) bit in that field is used to indicate an OCC sequence in the OCC sequence table.

[0478] Because the information rate of transmission in NTN scenarios is not very high, the demand for high-order modulation is not high. Furthermore, due to the long transmission distance and relatively poor signal quality, and because high-order modulation has a weaker anti-interference capability than low-order modulation, the demand for high-order modulation is not high. One bit can be extracted from the MCS domain to indicate the OCC sequence in the OCC sequence table.

[0479] In the prior art, the MCS field (as a second field) of the DCI has 5 bits to indicate 32 states. In some examples of this application, 2 bits of the MCS field of the DCI can be used to indicate the OCC sequence in the OCC sequence list, and the remaining 3 bits of the MCS field can be used to indicate 8 of the 32 states. For example, the 8 states can be 8 states corresponding to second-order modulation. Alternatively, the 8 states can include 2 states corresponding to second-order modulation, 2 states corresponding to fourth-order modulation, and 2 states corresponding to sixth-order modulation. In the above embodiments of this application, 1 bit of the MCS field of the DCI is used to indicate the OCC sequence in the OCC sequence list, but the number of bits used to indicate the OCC sequence in the OCC sequence list is not limited to this; 3 or more bits of the MCS field of the DCI can be used to indicate the OCC sequence in the OCC sequence list. The number of bits in the DCI field used to indicate the OCC sequence in the OCC sequence list in this application is not limited to this; it can be 1 bit or 3 or more bits. When 1 bit in the MCS field of the DCI is used to indicate the OCC sequence in the OCC sequence list, the remaining 4 bits in the MCS field indicate 16 of the 32 states. For example, the 16 states can be the first 16 states of the MCS index. Alternatively, the 8 states can include 8 states corresponding to 2nd-order modulation and 8 states corresponding to 4th-order modulation. Or, the 8 states can include 8 states corresponding to 2nd-order modulation, 4 states corresponding to 4th-order modulation, and 4 states corresponding to 6th-order modulation.

[0480] In some examples of this application, 1 bit of the HARQ process number field (as a second field) of the Hybrid Automatic Repeat Request (HARQ) of the DCI can be used to indicate the OCC sequence in the OCC sequence table. For example, in one example, for DCI format 0_0, the HARQ field has 4 bits. 1 bit of the DCI's HARQ field can be used to indicate the OCC sequence in the OCC sequence table, and the remaining 3 bits of the HARQ field are used to indicate a maximum supported HARQ number of 8. In one example, for DCI format 1_0, if the higher-level parameter harq-ProcessNumberSizeDCI-0-1 is configured, the HARQ field has 5 bits. 1 bit of the DCI's HARQ field can be used to indicate the OCC sequence, and the remaining 4 bits of the HARQ field are used to indicate a maximum supported HARQ number of 16. In one example, for DCI format 0_2, the high-level parameter harq-ProcessNumberSizeDCI-0-2-r17 can be configured with the HARQ field as 0, 1 bit, 2 bit, 3 bit, 4 bit, or 5 bits. Two bits from the DCI's HARQ field can be used to indicate the OCC sequence, leaving 0, 1, 2, 3, or 4 bits remaining in the HARQ field. The number of bits in the HARQ field used to indicate the OCC sequence in the OCC sequence table in this application is not limited to this; it can be 2 bits or more.

[0481] The above method applies to NR and IoT devices. To distinguish it from the usage of the MCS domain in the existing DCI, the above indication method is triggered when the OCC feature is enabled, the OCC scheme is configured, the OCC length is configured, or the threshold power for enabling OCC is reached.

[0482] Referring to Figure 31, user equipment 10a may be an example of user equipment 10 connected to the terrestrial network and user equipment 50 connected to the NTN. User equipment 10a may include a processor 11a, a memory 12a, and a transceiver 13a. The processor 11a may be configured to implement the steps, functions, procedures, and / or methods of the methods described in the user equipment. The various layers of the radio interface protocol may be implemented in the processor 11a. The transceiver 13a is operatively connected to the connected processor to transmit and / or receive radio signals or wired signals. The memory 12a stores various programs and information, and the processor 11a executes the steps, functions, procedures, and / or methods of the user equipment when executing the programs.

[0483] Referring to Figure 32, network device 20a may be an example of a network-side device, such as base station 20, satellite base station 40, NTN gateway 41, or NTN ground station 42. Network device 20a may include a processor 21a, a memory 22a, and a transceiver 23a. The processor 21a may be configured to implement the steps, functions, procedures, and / or methods of the methods described in the description on the network side. The various layers of the radio interface protocol may be implemented in the processor 21a. The transceiver 23a is operatively connected to the connected processor to transmit and / or receive radio signals or wired signals. The memory 22a stores various programs and information, and the processor 21a executes the network-side steps, functions, procedures, and / or methods when executing the programs.

[0484] The user equipment may be a mobile computing device, such as, but not limited to, a laptop, tablet, netbook, ultrabook, or smartphone. The base station may be an eNB or gNB.

[0485] Each of the processors 11a and 21a may include an application-specific integrated circuit (ASIC), a central processing unit (CPU), a graphics processing unit (GPU), other chipsets, logic circuits, and / or data processing devices.

[0486] Referring to Figure 33, this application embodiment also provides a chip 700, which may correspond to user equipment 10 and / or user equipment 50 in the embodiments of this application, and the chip 700 can implement the corresponding processes implemented by user equipment 10 and / or user equipment 50 in the various methods of the embodiments of this application. The chip 700 includes a processor 701, which can call and run computer programs from memory to implement the methods of the embodiments of this application.

[0487] Optionally, the chip 700 may further include memory 702. The processor 701 can retrieve and run computer programs from memory 702 to implement the methods described in this application.

[0488] The memory 702 can be a separate device independent of the processor 701, or it can be integrated into the processor 701.

[0489] Optionally, the chip 700 may also include an input interface 703. The processor 701 can control the input interface 703 to communicate with other devices or chips, specifically, to acquire messages or data sent by other devices or chips.

[0490] Optionally, the chip 700 may also include an output interface 704. The processor 701 can control the output interface 704 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0491] Referring to Figure 34, this application embodiment also provides another chip 800, which may correspond to the base station 20 and / or satellite base station 40 in the embodiments of this application, and the chip 800 can implement the corresponding processes implemented by the base station 20 and / or satellite base station 40 in the various methods of the embodiments of this application. The chip 800 includes a processor 801, which can call and run computer programs from memory 802 to implement the methods in the embodiments of this application.

[0492] Optionally, the chip 800 may further include memory 802. The processor 801 can retrieve and run computer programs from memory 802 to implement the methods described in this application.

[0493] The memory 802 can be a separate device independent of the processor 801, or it can be integrated into the processor 801.

[0494] Optionally, the chip 800 may also include an input interface 803. The processor 801 can control the input interface 803 to communicate with other devices or chips, specifically, to acquire messages or data sent by other devices or chips.

[0495] Optionally, the chip may also include an output interface 804. The processor 801 can control the output interface 804 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0496] This application also provides a computer program product, including computer program instructions.

[0497] Optionally, the computer program product can be applied to the base station 20 / or satellite base station 40 in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the base station 20 / or satellite base station 40 in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0498] Optionally, the computer program product can be applied to user equipment 10 and / or user equipment 50 in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by user equipment 10 and / or user equipment 50 in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0499] This application also provides a computer program.

[0500] Optionally, the computer program can be applied to the base station 20 / or satellite base station 40 in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the base station 20 / or satellite base station 40 in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0501] Optionally, the computer program can be applied to user equipment 10 and / or user equipment 50 in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by user equipment 10 and / or user equipment 50 in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0502] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0503] Those skilled in the art will understand that the above embodiments are specific implementations of this application, and in practical applications, various changes can be made in form and detail without departing from the spirit and scope of this application.

Claims

1. A satellite communication method applied to a satellite base station, characterized in that, Includes at least one of the following: The beam hopping pattern information is sent to the user equipment, wherein the beam hopping pattern information includes at least one of the following: beam hopping dwell time, beam hopping revisit time, or beam hopping start and end time information; and Sending downlink control signaling and data to the user equipment or receiving uplink control signaling and data according to the hopping beam pattern information; The hopping beam pattern information is used to indicate beam service time information and to notify the user equipment to send and receive control information or service data within a specified time.

2. The satellite communication method according to claim 1, characterized in that, The skip beam pattern information also includes at least one of the following: Index of hopping beam pattern, beam index, synchronization signal block index, ground beam position identifier ID or coverage area identifier list, physical cell identifier index, beam dwell information of adjacent beam positions or adjacent coverage areas, and beam index of adjacent beam positions or adjacent coverage areas.

3. The satellite communication method according to claim 1, characterized in that, The methods for sending the beam hopping pattern information include: The beam hopping pattern information is sent to the user equipment through at least one of the following methods: system message, downlink control information, media access control element, or predefined method.

4. The satellite communication method according to claim 1, characterized in that, The configuration methods for the hopping beam pattern information include: Update the pattern information of the service area each time a beam is switched; or The pattern information of the service area is associated with the synchronization signal block index; all synchronization signal block indices are polled to update the pattern information of the service area; or The pattern information of the service area is associated with the cell identifier; configure the pattern information under all cell identifiers. The pattern information of the service area is associated with the cell identifier, and the default beam hopping pattern is determined through a predefined method.

5. The satellite communication method according to claim 1, characterized in that, The configuration methods for the start and end time information of the hopping beam include: Configure beam hopping start service time information, single beam hopping start and end time information, beam dwell time, and revisit time, wherein the start service time information is aligned with system frame 0 or has a fixed time offset; or Configure the beam hopping start service time information, beam dwell time and return time, and implicitly indicate the start time information of each beam hopping by associating with the beam hopping identifier.

6. The satellite communication method according to claim 5, characterized in that, The hopping beam identifier includes: At least one of the following: service area number, waveform index, synchronization signal block index, or cell identifier.

7. The satellite communication method according to claim 5, characterized in that, The units for the beam hopping start service time information, the start and end time information of a single beam hopping, the beam dwell time, and the return visit time include: At least one of a wireless frame, subframe, time slot, symbol, millisecond, or second.

8. The satellite communication method according to claim 1, characterized in that, The method further includes: Determining a random access opportunity, wherein, based on the beam hopping pattern information, when the starting position of the random access opportunity falls within the beam hopping dwell time, it is determined to be an available random access opportunity; and When the starting position of a random access opportunity is within the non-beam-hopping dwell time, it is determined to be an unavailable random access opportunity.

9. The satellite communication method according to claim 8, characterized in that, For unavailable random access opportunities, the method further includes: The random access timing is postponed to the beginning of the next beam hopping dwell time.

10. The satellite communication method according to claim 1, characterized in that, The method further includes: Determine the random access response window and contention resolution window. When the random access response window or contention resolution window falls within a non-beam hopping dwell time, delay the starting position of the random access response window or contention resolution window to the starting subframe position of the next beam dwell time.

11. A satellite communication method applied to a satellite base station, characterized in that, The method includes at least one of the following: Configure multiple sets of hopping beam pattern information, including a default pattern and at least one set of candidate patterns. The hopping beam pattern information includes at least one of the following: hopping beam dwell time, hopping beam pattern information index, hopping beam revisit time, or hopping beam start and end time information. and When it is determined that the beam hopping pattern needs to be updated, a beam hopping pattern update instruction is sent to the user equipment. The update instruction is used to activate a set of candidate patterns among the multiple sets of beam hopping pattern information.

12. The satellite communication method according to claim 11, characterized in that, The triggering conditions that require updating the beam skipping pattern include: Dynamic changes in business services, resource adjustments, or user applications.

13. The satellite communication method according to claim 11, characterized in that, The methods for sending the beam hopping pattern update indication to the user equipment include: The beam hopping pattern update instruction is sent via radio resource control reconfiguration signaling; or The beam skipping pattern update instruction is sent via the media access control element; or The hopping beam pattern update instruction is sent via downlink control information.

14. The satellite communication method according to claim 13, characterized in that, Sending the hopping beam pattern update indication via downlink control information includes: The downlink control information now includes a new hopping beam pattern indication field to indicate candidate hopping beam patterns; or Encoding a portion of bits from a portion of the downlink control information as the beam hopping pattern update indication; or The candidate hop beam pattern indication is jointly encoded with a portion of the downlink control information; or Encode the reserved bits in the downlink control information as the beam hopping pattern update indication; or System message update indications are obtained through downlink control information.

15. The satellite communication method according to claim 11, characterized in that, The hopping beam pattern information includes a default pattern or candidate pattern configuration validity period parameter, which indicates the validity period of the hopping beam pattern configuration. The reference time point of the effective time is the start time information of the satellite's beam skipping, which is aligned with system frame 0 or has a time offset from system frame 0.

16. The satellite communication method according to claim 11, characterized in that, Based on the beam-hopping pattern timer, when the timer expires, the system switches to the candidate beam-hopping pattern configuration or waits for the pattern update request from the user equipment.

17. A satellite communication method applied to a satellite base station, characterized in that, The method includes at least one of the following: Receive beam hopping pattern update requests sent by user equipment; The beam hopping pattern information that needs to be updated is determined based on the update request; and The updated beam hopping pattern information is sent to the user equipment.

18. The satellite communication method according to claim 17, characterized in that, The methods for receiving the beam hopping pattern update request sent by the user equipment include: Receive hopping beam pattern update requests via uplink control information; Receive beam skipping pattern update requests via the media access control element; or Receive beam skipping pattern update requests via radio resource control signaling.

19. The satellite communication method according to claim 18, characterized in that, The hopping beam pattern update request includes at least: Index of skip beam patterns; and The user equipment is located in at least one of the following: the wave position information, the associated synchronization signal block index information, or the associated cell identification information.

20. The satellite communication method according to claim 17, characterized in that, The method further includes: The system sends an indication of whether the beam hopping pattern update was successful or failed to the user equipment via radio resource control signaling, downlink control information, or media access control elements.

21. A satellite communication method applied to a satellite base station, characterized in that, The method includes at least one of the following: Based on the received user equipment physical uplink control channel or the physical uplink shared channel enabling OCC or the physical uplink shared channel carrying uplink control information enabling OCC, the physical uplink control channel or the physical uplink shared channel enabling OCC or the physical uplink shared channel carrying uplink control information enabling OCC is based on the multiplexing rules between the repeatedly transmitted physical uplink control channel and the physical uplink shared channel enabling OCC.

22. The satellite communication method according to claim 21, characterized in that, The method includes: Configure the uplink channel enable orthogonal coverage code (OCC) function of the user equipment. The relevant information of the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, OCC enable indicator, or OCC sequence index.

23. The satellite communication method according to claim 21, characterized in that, The relevant information for the OCC function also includes at least one of the following: OCC offset value, delayed transmission offset value, and multiplexing priority information. The OCC offset value is used to indicate that the user equipment reserves resources for transmitting the physical uplink control channel, the physical uplink shared channel, or the physical uplink shared channel that reuses the physical uplink control channel. The delayed transmission offset value is used to indicate the time offset value of the user equipment for delaying the transmission of a single physical uplink control channel or the repeated transmission of a physical uplink control channel.

24. The satellite communication method according to claim 21, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, the user equipment multiplexes the physical uplink control channel onto all physical uplink shared channels within the OCC group that overlap with the physical uplink control channel, and enables inter-slot OCC as part of the OCC group, with the spreading length based on the configured OCC sequence length. The OCC group is a group consisting of multiple continuously transmitted physical uplink shared channels that enable OCC, and these physical uplink shared channels belong to the same user equipment.

25. The satellite communication method according to claim 21, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, the overlapping portion is processed based on priority rules. The priority rules include: A predefined rule states that control signals have a higher priority than data signals; or Priority parameters for transmission of the physical uplink control channel and the physical uplink shared channel, configured through radio resource control, downlink control information, or media access control elements; or Priority is determined based on the type of uplink control information carried by the physical uplink control channel.

26. The satellite communication method according to claim 25, characterized in that, When the priority of physical uplink control channel transmission is higher than that of physical uplink shared channel transmission, the user equipment shall prioritize the transmission of duplicate physical uplink control channels and discard overlapping OCC groups. When the priority of physical uplink control channel transmission is lower than that of physical uplink shared channel transmission, the user equipment directly discards duplicate physical uplink control channels, or discards physical uplink control channels that overlap with the OCC group and transmits the non-overlapping portion of the physical uplink control channels on the available time-frequency resources of the non-OCC group, or delays the transmission of duplicate physical uplink control channels to the available time-frequency resources of the non-OCC group.

27. The satellite communication method according to claim 21, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel does not cross OCC groups, the user equipment delays the transmission of the physical uplink control channel to the position of the first physical uplink shared channel in the next OCC group, and continues to repeat the transmission until its length is the same as the length of the OCC group; or When a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel spans across OCC groups, the user equipment discards the physical uplink control channel that overlaps with the physical uplink shared channel within the OCC group and reuses the remaining physical uplink control channels on available time-frequency resources.

28. The satellite communication method according to claim 23, characterized in that, The method also include: The offset parameter is configured for all user equipment within the cell or OCC group through radio resource control, or an additional offset value is configured in the time domain resource allocation table through downlink control information, or it is directly indicated by a field in the downlink control information.

29. The satellite communication method according to claim 21, characterized in that, The reuse rules include: Whether to support multiplexing between repeated physical uplink control channels and physical uplink shared channels with OCC enabled can be determined by configuring parameters or predefined rules. When multiplexing is not supported, the user equipment directly discards duplicate physical uplink control channels or overlapping OCC groups; when multiplexing is supported and the length of the repeatedly transmitted physical uplink control channel exceeds the length of the OCC group, the user equipment directly discards duplicate physical uplink control channels.

30. The satellite communication method according to claim 21, characterized in that, The reuse rules include: When the user equipment receives downlink control information that activates uplink control information multiplexing, it transmits the uplink control information through a specific physical uplink shared channel in the available time slot. The uplink control information multiplexed on the physical uplink shared channel can be multiplexed and transmitted together with the uplink data or transmitted separately on the physical uplink shared channel.

31. A satellite communication method applied to a satellite base station, characterized in that, The method includes at least one of the following: Configure the user equipment uplink channel to enable the orthogonal coverage code (OCC) function. The relevant information of the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, and OCC sequence index. The multiplexing rules between the physical uplink control channel for multiple repeated transmissions and the physical uplink shared channel with OCC enabled are determined in a predefined manner; and According to the multiplexing rules, the user equipment receives uplink control information and uplink data transmitted through the physical uplink shared channel enabled by the OCC.

32. The satellite communication method according to claim 31, characterized in that, The reuse rules include: When multiple retransmitted physical uplink control channels overlap with an OCC group, and a single retransmitted physical uplink control channel has a higher priority than an enabled OCC group, the user equipment determines the retransmitted physical uplink control channels that need to be multiplexed based on rules. The rules include: the order in which the physical uplink control channel is transmitted, or the priority of the uplink control information carried by the physical uplink control channel.

33. The satellite communication method according to claim 32, characterized in that, When the rule is based on the order in which the physical uplink control channels are first transmitted, the user equipment shall preferentially reuse the earliest transmitted physical uplink control channel; When the rule is based on the priority of uplink control information carried by the physical uplink control channel, the user equipment shall preferentially reuse the physical uplink control channel carrying uplink control information with higher priority, wherein HARQ-ACK has a higher priority than CSI.

34. The satellite communication method according to claim 31, characterized in that, The reuse rules include: When multiple repeatedly transmitted physical uplink control channels overlap with an OCC group, and the multiplexing priority of the multiple repeatedly transmitted physical uplink control channels is higher, the user equipment retains the first multiplexed physical uplink control channel and discards the other physical uplink control channels; or The user equipment divides the multiplexed physical uplink control channel into overlapping and non-overlapping parts, processes the non-overlapping part as a single repeated physical uplink control channel, and delays the overlapping part to be transmitted on available time-frequency resources.

35. The satellite communication method according to claim 31, characterized in that, The reuse rules include: When multiple retransmitted physical uplink control channels overlap with an OCC group, and the multiple retransmitted physical uplink control channels have a higher multiplexing priority, the user equipment retains the overlapping portion of the multiplexed retransmitted physical uplink control channels and processes them as a single retransmitted physical uplink control channel; or The user equipment retains only the non-overlapping portion of the subsequently transmitted repeated physical uplink control channels and processes them as a single repeated transmission of the physical uplink control channel.

36. The satellite communication method according to claim 31, characterized in that, The reuse rules include: When two repeatedly transmitted physical uplink control channels carry uplink control information at different levels, the user equipment retains the first physical uplink control channel of the repeatedly transmitted physical uplink control channel obtained by multiplexing the two repeatedly transmitted physical uplink control channels, and discards the other physical uplink control channels.

37. The satellite communication method according to claim 31, characterized in that, The reuse rules include: When multiple uplink control messages appear on different physical uplink shared channels within the same OCC span, the user equipment multiplexes the multiple physical uplink control channels to the first physical uplink shared channel position, mapping them sequentially on the first physical uplink shared channel according to the order in which the physical uplink control channels are sent, or mapping them on the first physical uplink shared channel based on the priority of the uplink control information carried, from high to low.

38. The satellite communication method according to claim 31, characterized in that, The reuse rules include: Whether multiplexing of repeated physical uplink control channels and the physical uplink shared channel with OCC enabled is supported can be determined by configuring parameters or predefined rules. When multiplexing is not supported, the user equipment directly discards multiple duplicate physical uplink control channels or overlapping OCC groups.

39. The satellite communication method according to claim 31, characterized in that, The method further includes: Configure offset parameters to indicate that the user equipment reserves resources for transmitting the multiplexed physical uplink control channel, the overlapping portion of the physical uplink control channel, or the multiplexed non-overlapping portion of the physical uplink control channel. The offset parameter is configured for all user equipment within the cell or OCC group through radio resource control, or configured with an additional offset value in the time domain resource allocation table through downlink control information, or indicated by a new domain in the downlink control information.

40. A satellite device, characterized in that, include: A processor is configured to invoke and execute a computer program stored in memory to cause a device equipped with the processor to perform the methods described in any one of claims 1 to 39.

41. A chip, characterized in that, include: A processor is configured to invoke and execute a computer program stored in memory to cause a device equipped with the processor to perform the methods described in any one of claims 1 to 39.

42. A non-volatile computer-readable storage medium, characterized in that, It contains a computer program that causes a computer to perform the method described in any one of claims 1 to 39.

43. A computer program product, characterized in that, It includes a computer program, wherein the computer program causes a computer to perform the method described in any one of claims 1 to 39.

44. A satellite communication method applied to user equipment, characterized in that, Includes at least one of the following: The system receives beam hopping pattern information transmitted by a satellite base station, wherein the beam hopping pattern information includes at least one of the following: beam hopping dwell time, beam hopping revisit time, and beam hopping start and end time information; and Receive downlink control signaling and data sent by the satellite base station according to the hopping beam pattern information, or send uplink control signaling and data to the satellite base station; The hopping beam pattern information is used to indicate beam service time information and to notify the user equipment to send and receive control information or service data within a specified time.

45. The satellite communication method according to claim 44, characterized in that, The skip beam pattern information also includes at least one of the following: Index of hopping beam pattern, beam index, synchronization signal block index, ground beam position identifier ID or coverage area identifier list, physical cell identifier index, beam dwell information of adjacent beam positions or adjacent coverage areas, and beam index of adjacent beam positions or adjacent coverage areas.

46. ​​The satellite communication method according to claim 44, characterized in that, The recipients of the hopping beam pattern information include: The beam hopping pattern information is received through at least one of the following methods: system messages, downlink control information, media access control elements, or predefined methods.

47. The satellite communication method according to claim 44, characterized in that, The configuration of the hopping beam pattern information includes: Update the pattern information of the service area each time a beam is switched; or The pattern information of the service area is associated with the synchronization signal block index; all synchronization signal block indices are polled to update the pattern information of the service area; or The pattern information of the service area is associated with the cell identifier; configure the pattern information under all cell identifiers. The pattern information of the service area is associated with the cell identifier, and the default beam hopping pattern is determined through a predefined method.

48. The satellite communication method according to claim 44, characterized in that, The configuration of the start and end time information of the hopping beam includes: Beam hopping start service time information, start and end time information for a single beam hopping, beam dwell time, and revisit time, wherein the start service time information is aligned with system frame 0 or has a fixed time offset; or The beam hopping start service time information, beam dwell time, and return time are implicitly indicated by associating the beam hopping identifier with the beam hopping start time information.

49. The satellite communication method according to claim 48, characterized in that, The hopping beam identifier includes: At least one of the following: service area number, waveform index, synchronization signal block index, or cell identifier.

50. The satellite communication method according to claim 48, characterized in that, The units for the beam hopping start service time information, the start and end time information of a single beam hopping, the beam dwell time, and the return visit time include: At least one of a wireless frame, subframe, time slot, symbol, millisecond, or second.

51. The satellite communication method according to claim 44, characterized in that, The method further includes: Determining a random access opportunity, wherein, based on the beam hopping pattern information, when the starting position of the random access opportunity falls within the beam hopping dwell time, it is determined to be an available random access opportunity; and When the starting position of a random access opportunity is within the non-beam-hopping dwell time, it is determined to be an unavailable random access opportunity.

52. The satellite communication method according to claim 51, characterized in that, For unavailable random access opportunities, the method further includes: The random access timing is postponed to the beginning of the next beam hopping dwell time.

53. The satellite communication method according to claim 44, characterized in that, The method further includes: Determine the random access response window and contention resolution window. When the random access response window or contention resolution window falls within a non-beam hopping dwell time, delay the starting position of the random access response window or contention resolution window to the starting subframe position of the next beam dwell time.

54. A satellite communication method, applied to user equipment, characterized in that, The method includes at least one of the following: The system receives a beam hopping pattern update instruction sent by a satellite base station. The update instruction is used to activate a candidate pattern from multiple sets of beam hopping pattern information. The multiple sets of beam hopping pattern information include a default pattern and at least one set of candidate patterns. The beam hopping pattern information includes at least one of the following: beam hopping dwell time, beam hopping pattern information index, beam hopping revisit time, or beam hopping start and end time information. Based on the activated candidate pattern, communication is conducted with the satellite base station during the corresponding hopping beam dwell time.

55. The satellite communication method according to claim 54, characterized in that, The triggering conditions for updating the beam skipping pattern include: Dynamic changes in business services, resource adjustments, or user applications.

56. The satellite communication method according to claim 54, characterized in that, The methods for receiving the beam hopping pattern update instruction include: Receive the beam hopping pattern update instruction via radio resource control reconfiguration signaling; or Receive the beam skipping pattern update instruction via the media access control element; or The beam skipping pattern update instruction is received via downlink control information.

57. The satellite communication method according to claim 56, characterized in that, Receiving the hopping beam pattern update indication via downlink control information includes: Decoding adds a hopping beam pattern indication field to the downlink control information to indicate candidate hopping beam patterns; or Decoding a portion of bits from a portion of the downlink control information as a beam hopping pattern update indication; or Jointly decode the candidate hop beam pattern indication with a portion of the downlink control information; or Decode the reserved bits in the downlink control information as the beam hopping pattern update indicator; or System message update indications are obtained through downlink control information.

58. The satellite communication method according to claim 54, characterized in that, The hopping beam pattern information includes a default pattern or candidate pattern configuration validity period parameter, which indicates the validity period of the hopping beam pattern configuration. The reference time point of the effective time is the start time information of the satellite's beam skipping, which is aligned with system frame 0 or has a time offset from system frame 0.

59. The satellite communication method according to claim 54, characterized in that, Based on the beam hopping pattern timer, when the timer expires, the system switches to the candidate beam hopping pattern configuration or sends a pattern update request to the user equipment.

60. A satellite communication method, applied to user equipment, characterized in that, The method includes at least one of the following: Send a beam skipping pattern update request to the satellite base station; Receive the updated beam hopping pattern information sent by the satellite base station; and Based on the updated beam hopping pattern information, communication is conducted with the satellite base station during the corresponding beam hopping dwell time.

61. The satellite communication method according to claim 60, characterized in that, The methods for sending the beam hopping pattern update request include: Send a hopping beam pattern update request via uplink control information; Send a beam skipping pattern update request via the media access control element; or Send a beam skipping pattern update request via radio resource control signaling.

62. The satellite communication method according to claim 61, characterized in that, The hopping beam pattern update request includes at least: Index of skip beam patterns; and The user equipment is located in at least one of the following: the wave position information, the associated synchronization signal block index information, or the associated cell identification information.

63. The satellite communication method according to claim 60, characterized in that, The method further includes: The satellite base station receives indications of successful or failed beam hopping pattern updates via radio resource control signaling, downlink control information, or media access control elements.

64. A satellite communication method, applied to user equipment, characterized in that, The method includes at least one of the following: The physical uplink control channel or the physical uplink shared channel enabling OCC or the physical uplink shared channel carrying uplink control information enabling OCC is transmitted to the satellite base station. The physical uplink control channel or the physical uplink shared channel enabling OCC or the physical uplink shared channel carrying uplink control information enabling OCC is based on the multiplexing rules between the repeatedly transmitted physical uplink control channel and the physical uplink shared channel enabling OCC.

65. The satellite communication method according to claim 64, characterized in that, The method includes: The system receives information related to enabling the orthogonal coverage code (OCC) function of the uplink channel. The information related to the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, OCC enable indication, or OCC sequence index.

66. The satellite communication method according to claim 64, characterized in that, The relevant information for the OCC function also includes at least one of the following: OCC offset value, delayed transmission offset value, and multiplexing priority information. The OCC offset value is used to indicate that the user equipment reserves resources for transmitting the physical uplink control channel, the physical uplink shared channel, or the physical uplink shared channel that reuses the physical uplink control channel. The delayed transmission offset value is used to indicate the time offset value of the user equipment for delaying the transmission of a single physical uplink control channel or the repeated transmission of a physical uplink control channel.

67. The satellite communication method according to claim 64, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, the user equipment multiplexes the physical uplink control channel onto all physical uplink shared channels within the OCC group that overlap with the physical uplink control channel, and enables inter-slot OCC as part of the OCC group, with the spreading length based on the configured OCC sequence length. The OCC group is a group consisting of multiple continuously transmitted physical uplink shared channels that enable OCC, and these physical uplink shared channels belong to the same user equipment.

68. The satellite communication method according to claim 64, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with the first physical uplink shared channel within an OCC group, the overlapping portion is processed based on priority rules. The priority rules include: A predefined rule states that control signals have a higher priority than data signals; or Priority parameters for transmission of the physical uplink control channel and the physical uplink shared channel, configured through radio resource control, downlink control information, or media access control elements; or Priority is determined based on the type of uplink control information carried by the physical uplink control channel.

69. The satellite communication method according to claim 68, characterized in that, When the priority of physical uplink control channel transmission is higher than that of physical uplink shared channel transmission, the user equipment shall prioritize the transmission of duplicate physical uplink control channels and discard overlapping OCC groups. When the priority of physical uplink control channel transmission is lower than that of physical uplink shared channel transmission, the user equipment directly discards duplicate physical uplink control channels, or discards physical uplink control channels that overlap with the OCC group and transmits the non-overlapping portion of the physical uplink control channels on the available time-frequency resources of the non-OCC group, or delays the transmission of duplicate physical uplink control channels to the available time-frequency resources of the non-OCC group.

70. The satellite communication method according to claim 64, characterized in that, The reuse rules include: When a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel does not cross OCC groups, the user equipment delays the transmission of the physical uplink control channel to the position of the first physical uplink shared channel in the next OCC group, and continues to repeat the transmission until its length is the same as the length of the OCC group; or When a repeatedly transmitted physical uplink control channel overlaps with a non-first physical uplink shared channel within an OCC group, and the repeated physical uplink control channel spans across OCC groups, the user equipment discards the physical uplink control channel that overlaps with the physical uplink shared channel within the OCC group and reuses the remaining physical uplink control channels on available time-frequency resources.

71. The satellite communication method according to claim 66, characterized in that, The method also include: The offset parameter is configured for all user equipment within the cell or OCC group through radio resource control, or an additional offset value is configured in the time domain resource allocation table through downlink control information, or it is directly indicated by a field in the downlink control information.

72. The satellite communication method according to claim 64, characterized in that, The reuse rules include: Whether to support multiplexing between repeated physical uplink control channels and physical uplink shared channels with OCC enabled can be determined by configuring parameters or predefined rules. When multiplexing is not supported, the user equipment directly discards duplicate physical uplink control channels or overlapping OCC groups; when multiplexing is supported and the length of the repeatedly transmitted physical uplink control channel exceeds the length of the OCC group, the user equipment directly discards duplicate physical uplink control channels.

73. The satellite communication method according to claim 64, characterized in that, The reuse rules include: When the user equipment receives downlink control information that activates uplink control information multiplexing, it transmits the uplink control information through a specific physical uplink shared channel in the available time slot. The uplink control information multiplexed on the physical uplink shared channel can be multiplexed and transmitted together with the uplink data or transmitted separately on the physical uplink shared channel.

74. A satellite communication method applied to a satellite base station, characterized in that, The method includes at least one of the following: This refers to the information related to enabling the orthogonal coverage code (OCC) function on the uplink channel configured by the satellite base station. The information related to the OCC function includes at least one of the following: OCC scheme type, OCC sequence length, and OCC sequence index. Based on predefined multiplexing rules between the physical uplink control channel for multiple repeated transmissions and the physical uplink shared channel with OCC enabled; and According to the multiplexing rules, uplink control information and uplink data are transmitted to the satellite base station through the physical uplink shared channel enabled by the OCC.

75. The satellite communication method according to claim 74, characterized in that, The reuse rules include: When multiple retransmitted physical uplink control channels overlap with an OCC group, and a single retransmitted physical uplink control channel has a higher priority than an enabled OCC group, the user equipment determines the retransmitted physical uplink control channels that need to be multiplexed based on rules. The rules include: the order in which the physical uplink control channel is transmitted, or the priority of the uplink control information carried by the physical uplink control channel.

76. The satellite communication method according to claim 75, characterized in that, When the rule is based on the order in which the physical uplink control channels are first transmitted, the user equipment shall preferentially reuse the earliest transmitted physical uplink control channel; When the rule is based on the priority of uplink control information carried by the physical uplink control channel, the user equipment shall preferentially reuse the physical uplink control channel carrying uplink control information with higher priority, wherein HARQ-ACK has a higher priority than CSI.

77. The satellite communication method according to claim 74, characterized in that, The reuse rules include: When multiple repeatedly transmitted physical uplink control channels overlap with an OCC group, and the multiplexing priority of the multiple repeatedly transmitted physical uplink control channels is higher, the user equipment retains the first multiplexed physical uplink control channel and discards the other physical uplink control channels; or The user equipment divides the multiplexed physical uplink control channel into overlapping and non-overlapping parts, processes the non-overlapping part as a single repeated physical uplink control channel, and delays the overlapping part to be transmitted on available time-frequency resources.

78. The satellite communication method according to claim 74, characterized in that, The reuse rules include: When multiple retransmitted physical uplink control channels overlap with an OCC group, and the multiple retransmitted physical uplink control channels have a higher multiplexing priority, the user equipment retains the overlapping portion of the multiplexed retransmitted physical uplink control channels and processes them as a single retransmitted physical uplink control channel; or The user equipment retains only the non-overlapping portion of the subsequently transmitted repeated physical uplink control channels and processes them as a single repeated transmission of the physical uplink control channel.

79. The satellite communication method according to claim 74, characterized in that, The reuse rules include: When two repeatedly transmitted physical uplink control channels carry uplink control information at different levels, the user equipment retains the first physical uplink control channel of the repeatedly transmitted physical uplink control channel obtained by multiplexing the two repeatedly transmitted physical uplink control channels, and discards the other physical uplink control channels.

80. The satellite communication method according to claim 74, characterized in that, The reuse rules include: When multiple uplink control messages appear on different physical uplink shared channels within the same OCC span, the user equipment multiplexes the multiple physical uplink control channels to the first physical uplink shared channel position, mapping them sequentially on the first physical uplink shared channel according to the order in which the physical uplink control channels are sent, or mapping them on the first physical uplink shared channel based on the priority of the uplink control information carried, from high to low.

81. The satellite communication method according to claim 74, characterized in that, The reuse rules include: Whether multiplexing of repeated physical uplink control channels and the physical uplink shared channel with OCC enabled is supported can be determined by configuring parameters or predefined rules. When multiplexing is not supported, the user equipment directly discards multiple duplicate physical uplink control channels or overlapping OCC groups.

82. The satellite communication method according to claim 74, characterized in that, The offset parameter is used to indicate the resources reserved by the user equipment for transmitting the multiplexed physical uplink control channel, the overlapping portion of the physical uplink control channel, or the multiplexed non-overlapping portion of the physical uplink control channel. The offset parameter is configured for all user equipment within the cell or OCC group through radio resource control, or configured with an additional offset value in the time domain resource allocation table through downlink control information, or indicated by a new domain in the downlink control information.

83. A satellite communication method, applied to user equipment, characterized in that, The method includes at least one of the following: When the OCC sequence length is less than the number of repeated transmissions on the physical uplink shared channel, OCC is enabled from the earliest physical uplink shared channel position. The portion of the physical uplink shared channel retransmission that overlaps with the OCC sequence is retained based on the OCC sequence length, and the portion exceeding the sequence length is discarded; or the remaining physical uplink shared channel is further mapped with OCC sequences to form a nominal OCC group. When the length of the OCC sequence is greater than the number of repeated transmissions of the physical uplink shared channel, a nominal OCC group is formed, including the portion of the repeated transmissions of the physical uplink shared channel that overlaps with the OCC sequence; or the repeated transmissions of the physical uplink shared channel continue according to the length of the OCC sequence until they are aligned with the length of the OCC sequence.

84. A user equipment, characterized in that, include: A processor configured to invoke and execute a computer program stored in memory to cause a device equipped with the processor to perform the methods described in any one of claims 44 to 83.

85. A chip, characterized in that, include: A processor configured to invoke and execute a computer program stored in memory to cause a device equipped with the processor to perform the methods described in any one of claims 44 to 83.

86. A non-volatile computer-readable storage medium, characterized in that, It contains a computer program that causes a computer to perform the method described in any one of claims 44 to 83.

87. A computer program product, characterized in that, It includes a computer program, wherein the computer program causes a computer to perform the method described in any one of claims 44 to 83.

Images