Random access method, communication apparatus, communication system, storage medium and chip system

Abstract

The application discloses a random access method, a communication device, a communication system, a storage medium and a chip system, and belongs to the technical field of communication. The method comprises the following steps: a terminal device sends a random access request message through n beams according to the transmission power corresponding to a power count value, wherein n is an integer greater than or equal to 2; and in the case that the random access request message needs to be retransmitted, the power count value is adjusted according to the difference between the n beams required for this time of retransmission and the n beams used for the last transmission. By associating the beam usage history with the power control, the application can realize a differentiated retransmission strategy according to possible transmission failure reasons, so that the adaptation to the multi-beam transmission scene can be realized with low complexity, and the balance between the transmission success rate and the terminal device power consumption in the multi-beam transmission scene can be realized.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a random access method, communication device, communication system, storage medium, and chip system. Background Technology

[0002] Before establishing a wireless link between a terminal device and a network device, random access is required. During random access, the terminal device transmits Msg1 based on a power ramping rule. The current power ramping rule is relatively simple and designed for single-beam transmission scenarios. With the increasing prevalence of multi-beam transmission scenarios, the old rule is no longer suitable, leading to inconsistent power adjustment performance among different terminal devices during multi-beam transmission. Summary of the Invention

[0003] This application provides a random access method, communication device, communication system, storage medium, and chip system, which can achieve a balance between transmission success rate and terminal device power consumption in multi-beam transmission scenarios. The technical solution is as follows:

[0004] Firstly, a random access method is provided. This method can be executed by a terminal device, or by a component (such as a circuit, chip, or chip system) configured in the terminal device, or by a logic module or software capable of implementing all or part of the functions of the terminal device. This application does not limit the scope of this method. The following description uses a terminal device as an example.

[0005] The terminal device sends a random access request message through n beams based on the transmit power corresponding to the power count value, where n is an integer greater than or equal to 2; if a retransmission of the random access request message is required, the power count value is adjusted according to the difference between the n beams required for this retransmission and the n beams used in the previous transmission.

[0006] In this application, by associating beam usage history with power control, differentiated retransmission strategies can be implemented based on possible transmission failure reasons. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in multi-beam transmission scenarios.

[0007] In one possible approach, before sending a random access request message through n beams based on the transmit power corresponding to the power count value, the terminal device can create n beam sets if it needs to access network devices; initialize n power count values, with each of the n power count values ​​corresponding to one of the n beam sets; and add the beam identifiers of the n beams required for the initial transmission to the n beam sets respectively. In this case, the operation of the terminal device sending a random access request message through n beams based on the transmit power corresponding to the power count value can be as follows: for any one of the n beams, based on the transmit power corresponding to the power count value of the beam set to which the beam identifier belongs, send a random access request message through that beam.

[0008] In this application, the terminal device can create n beam sets and associate each beam set with a power count value. Subsequent adjustments to each power count value can be made based on changes in its corresponding beam set, thus enabling precise on-demand adjustment of the transmission power of different beam sets.

[0009] In one possible approach, before sending a random access request message via n beams based on the transmit power corresponding to the power count value, the terminal device can initialize a pseudo-count value if network access is required. This pseudo-count value indicates the number of times the random access request message transmission has failed. In this case, the terminal device adjusts the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission. If the pseudo-count value is less than a preset value, the power count value is adjusted accordingly. Alternatively, if a retransmission of the random access request message is required and the pseudo-count value is greater than or equal to the preset value, all n power count values ​​are incremented by 1.

[0010] This application proposes a dynamic power control scheme based on the collaboration of n power count values ​​and pseudo-count values. This scheme can not only accurately adjust the transmit power of different beam sets as needed, but also enable power-saving probing when the number of transmission failures is low and timely power replenishment when the number of transmission failures is high for each beam set. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in multi-beam transmission scenarios.

[0011] In one possible approach, the terminal device adjusts the power count value based on the difference between the n beams required for the current retransmission and the n beams used in the previous transmission. This adjustment can be as follows: if the current retransmission requires switching the first beam used in the previous transmission to the second beam, adjust the power count value corresponding to the first beam set based on whether the beam identifier of the second beam belongs to the first beam set. The first beam set is the beam set to which the beam identifier of the first beam belongs. If one of the beams required for the current retransmission is the same as the third beam used in the previous transmission, increment the power count value corresponding to the second beam set by 1. The second beam set is the beam set to which the beam identifier of the third beam belongs.

[0012] In this application, the power count value can be adjusted differently according to the beam switching situation. In this way, while ensuring transmission reliability, invalid transmission power increases can be avoided to a large extent, achieving a balance between random access efficiency and terminal equipment power consumption.

[0013] In one possible approach, the terminal device adjusts the power count value corresponding to the first beam set based on whether the beam identifier of the second beam belongs to the first beam set. This can be done as follows: if the beam identifier of the second beam does not belong to the first beam set, add the beam identifier of the second beam to the first beam set while keeping the power count value corresponding to the first beam set unchanged; if the beam identifier of the second beam belongs to the first beam set, increment the power count value corresponding to the first beam set by 1.

[0014] In this application, if the beam identifier of the second beam does not belong to the first beam set, it indicates that the retransmission attempt has switched to a new beam that has not been used before. In this case, the previous transmission failure is more likely due to beam misalignment rather than insufficient transmit power. By maintaining the power count value unchanged (instead of incrementing it), the terminal device will retransmit the random access request message on the new beam using the same transmit power as before. This avoids unnecessary power consumption increases caused by blindly increasing transmit power, thus effectively saving power consumption of the terminal device while trying a new beam to improve the transmission success rate.

[0015] If the beam identifier of the second beam belongs to the first beam set, it means that the terminal device is still retrying on a beam that has already been used. In this case, the previous transmission failure was more likely due to insufficient transmit power. By incrementing the power count value, the terminal device can retransmit with a higher transmit power to overcome path loss or interference, thereby increasing the probability of successful transmission on the second beam.

[0016] In one possible approach, before sending a random access request message via n beams based on the transmit power corresponding to the power count value, the terminal device can initialize the power count value and a pseudo-count value if network access is required. The pseudo-count value indicates the number of times the random access request message transmission has failed. In this case, the terminal device adjusts the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission. If the pseudo-count value is less than a preset value, the power count value is adjusted accordingly. Additionally, if a retransmission of the random access request message is required and the pseudo-count value is greater than or equal to the preset value, the power count value is incremented by 1.

[0017] This application proposes a dynamic power control scheme based on the coordination of global power count and pseudo-count values. This scheme enables power-saving probing when the number of transmission failures is low and timely power replenishment when the number of transmission failures is high. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in such scenarios. Furthermore, by determining the adjustment method of the power count value based on the magnitude of the pseudo-count value, power consumption of the terminal device can be saved in strong coverage scenarios, while ensuring transmission success rate in weak coverage scenarios, offering high flexibility.

[0018] In one possible approach, the terminal device can adjust the power count value based on the difference between the n beams required for the current retransmission and the n beams used in the previous transmission. This adjustment can be achieved by: maintaining the power count value unchanged when the n beams required for the current retransmission are at least partially different from the n beams used in the previous transmission; and incrementing the power count value by 1 when the n beams required for the current retransmission are the same as the n beams used in the previous transmission.

[0019] In this application, if the n beams required for the current retransmission are at least partially different from the n beams used in the previous transmission, it indicates that the current retransmission attempt has switched to a new beam that was not used previously. Therefore, the previous transmission failure was more likely due to beam misalignment than insufficient transmit power. In this case, by maintaining the power count value unchanged (rather than incrementing it), the terminal device will retransmit the random access request message on the new beam using the same transmit power as before. This avoids unnecessary power consumption increases caused by blindly increasing transmit power, thus effectively saving power consumption of the terminal device while attempting a new beam to improve the transmission success rate.

[0020] If the n beams required for this retransmission are the same as those used in the previous transmission, it means the terminal device is still retrying on beams that have already been used. In this case, the previous transmission failure was more likely due to insufficient transmission power. By incrementing the power count value, the terminal device can retransmit with greater transmission power to overcome path loss or interference, thereby improving the transmission success rate.

[0021] Secondly, a communication device is provided, comprising a processing module and a communication module. The communication module is used to transmit a random access request message through n beams based on the transmit power corresponding to the power count value, where n is an integer greater than or equal to 2. The processing module is used to: adjust the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission when a retransmission of the random access request message is required.

[0022] The second aspect is the implementation on the device side, which corresponds to the first aspect. The explanations, supplements, and descriptions of the beneficial effects of the first aspect also apply to the second aspect, and will not be repeated here.

[0023] Thirdly, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the methods in any possible implementation of any of the above aspects. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0024] In one implementation, the communication interface can be a transceiver, or an input / output interface.

[0025] In another implementation, the communication device is a chip configured in a terminal device or network device. When the communication device is a chip configured in a terminal device or network device, the communication interface can be an input / output interface.

[0026] Fourthly, a computer program product is provided, comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the method in any possible implementation of any of the above aspects.

[0027] Fifthly, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when run on a computer, causes the computer to perform the methods in any possible implementation of any of the above aspects.

[0028] Sixthly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the possible implementations of the above aspects to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0029] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0030] In a seventh aspect, a communication system is provided, including the aforementioned terminal equipment and / or network equipment. Optionally, the communication system may further include other devices that communicate with the terminal equipment and / or network equipment. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of a communication system provided in an embodiment of this application;

[0032] Figure 2 This is a flowchart of a random access method provided in an embodiment of this application;

[0033] Figure 3 This is a flowchart of another random access method provided in the embodiments of this application;

[0034] Figure 4 This is a flowchart of another random access method provided in the embodiments of this application;

[0035] Figure 5 This is a schematic diagram of a beam set and power count value provided in an embodiment of this application;

[0036] Figure 6 This is a flowchart of another random access method provided in the embodiments of this application;

[0037] Figure 7 This is a flowchart of another random access method provided in the embodiments of this application;

[0038] Figure 8 This is a schematic diagram of a power count value and a pseudo count value provided in an embodiment of this application;

[0039] Figure 9 This is a flowchart of another random access method provided in the embodiments of this application;

[0040] Figure 10 This is a flowchart of another random access method provided in the embodiments of this application;

[0041] Figure 11 This is a schematic block diagram of a communication device provided in an embodiment of this application;

[0042] Figure 12 This is a schematic block diagram of another communication device provided in the embodiments of this application. Detailed Implementation

[0043] In the following description, specific details such as particular system architectures and technologies are set forth for illustrative purposes and not for limiting purposes, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details.

[0044] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0045] It should be understood that "one or more" as used in this application refers to one, two, or more, and "multiple" as used in this application refers to two or more. In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0046] To facilitate a clear description of the technical solutions of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0047] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0048] The embodiments of this application can be applied to various communication systems. For example, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS) systems, Wireless Local Area Network (WLAN) systems (such as Wireless Fidelity (Wi-Fi) systems), Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink communication systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, non-terrestrial network (NTN) communication systems, 4th generation (4G) mobile communication systems, 5th generation (5G) mobile communication systems, or new radio access technology (NR) systems, 6th generation (6G) mobile communication systems, etc. The 5G mobile communication system may include non-standalone (NSA) and / or standalone (SA) networking. It is understood that the embodiments of this application can also be applied to future communication systems, and the embodiments of this application do not limit this application.

[0049] Figure 1 This is a schematic diagram of a communication system 100 provided in an embodiment of this application. The communication system 100 may include network (NW) devices, such as... Figure 1 The network device 110 shown. The communication system 100 may also include terminal devices, such as... Figure 1 The terminal device 120 shown can communicate with the network device via a wireless link. Figure 1 An exemplary network device 110 and a terminal device 120 are shown. Optionally, the communication system 100 may also include multiple network devices and / or multiple terminal devices.

[0050] The network device in this application embodiment can be a network-side device such as an access network device or a core network device.

[0051] Access network equipment is sometimes also called access node. Access network equipment has wireless transceiver capabilities and can communicate with terminal devices. For example, access network equipment can be a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), next-generation radio access network (NG-RAN) equipment (such as a next-generation NodeB (gNB)) in a 5G mobile communication system, access network equipment or modules of access network equipment in an open RAN (ORAN) system, satellites in an NTN communication system, base stations in a future mobile communication system, or access points (APs) in a Wi-Fi system. Access network equipment can also be modules or units capable of implementing some of the functions of a base station, such as macro base stations, micro base stations, indoor stations, relay nodes, or donor nodes, or wireless controllers in cloud radio access network (CRAN) scenarios. Multiple access network devices in the communication system 100 can be of the same type or different types. This application does not limit the specific technology or device form used in the access network equipment.

[0052] Core network equipment possesses functions such as data processing, session management, network interconnection, operation administration and maintenance (OAM), and location management function (LMF). Core network equipment can perform user access authentication, service bearer establishment, and data interaction with external networks. Through OAM, it completes network configuration monitoring, resource scheduling optimization, and fault maintenance tasks. Through LMF, it provides terminal location calculation, trajectory tracking, and spatial data analysis. For example, core network equipment can be network elements such as the mobility management entity (MME), serving gateway (SGW), and packet data network gateway (PGW) in a 4G mobile communication system. Alternatively, core network equipment can be network elements such as the access and mobility management function (AMF), session management function (SMF), user plane function (UPF), and LMF in a 5G mobile communication system. Or, core network equipment can be a functional entity specifically providing operation and maintenance services or location services, such as an independent server closely cooperating with the core network. Alternatively, the core network equipment can be a virtualized network element integrating OAM or LMF capabilities within a Network Functions Virtualization (NFV) architecture. The core network equipment can also be a novel core network entity in future communication systems. Multiple core network equipment in communication system 100 can be deployed in a centralized or distributed architecture, with each core network equipment undertaking the same or different types of network functions. This application does not limit the specific technologies or equipment forms used in the core network equipment.

[0053] In this application embodiment, the apparatus for implementing the functions of a network device can be a network device itself, or an apparatus capable of supporting the network device in implementing those functions, such as a processor, circuit, chip, or chip system. This apparatus can be installed in the network device or connected to and used with the network device. In this application embodiment, taking a network device as an example to illustrate the technical solution provided by this application, we will describe it accordingly.

[0054] The terminal device in this application embodiment can be a wireless terminal device capable of receiving network device scheduling and instructions. The wireless terminal device can be a device providing voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. For example, the terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN). The terminal device can also be referred to as a terminal, user equipment (UE), mobile terminal (MT), mobile station (MS), mobile unit (MU), radio unit, remote unit, user agent, mobile client, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ultra-reliable low-latency communication (URLLC), virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical surgery, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, or satellite communication. Terminal devices can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, aircraft (such as drones, helicopters, and airplanes), hot air balloons, ships, robots, robotic arms, or smart home devices. This application does not limit the form of the terminal device.

[0055] In this application embodiment, the device for implementing the functions of the terminal device can be the terminal device itself, or any device capable of supporting the terminal device in implementing the functions, such as a processor, circuit, chip, or chip system. This device can be installed in the terminal device or connected to and used with the terminal device. In this application embodiment, taking the terminal device as an example to illustrate the technical solution provided by this application, we will describe it accordingly.

[0056] To facilitate understanding of the embodiments of this application, the technical terms involved in the embodiments of this application are first briefly explained. Optionally, the explanation of some terms can also refer to the explanation in the 3rd Generation Partnership Project (3GPP) standard protocol. It should be understood that the terminology in the embodiments of this application is only illustrative and not limiting. As technology evolves, the terminology will also change; where the technical meaning is the same, other terms should also be applicable to the embodiments of this application.

[0057] 1. Beam

[0058] A beam is a directional energy radiation pattern formed when electromagnetic waves propagate in space. Its energy is concentrated in the target direction, with energy attenuation in non-target directions. The beam described in the embodiments of this application can also be referred to as a beam direction; the two terms can be used interchangeably.

[0059] It should be noted that one beam can correspond to one reference signal (RS). That is, when a network device transmits a reference signal on a certain beam, the reference signal corresponds to the beam identifier of that beam. For example, the beam identifier can be a beam number, beam index, or channel state information-reference signal resource indicator (CRI), etc., and this application embodiment does not limit this.

[0060] 2. Reference signal

[0061] A reference signal is a known signal used in a communication system for channel estimation or channel sounding. Its core function is to provide channel state information to the receiver, assisting in efficient resource scheduling and data transmission.

[0062] Optionally, the reference signal described in the embodiments of this application may include a channel state information-reference signal (CSI-RS), a synchronization signal / physical broadcast channel block (SSB) reference signal, etc., and the embodiments of this application do not limit this.

[0063] 3. Power count value

[0064] The power count value is used to determine the transmission power. A larger power count value indicates a higher transmission power; a smaller power count value indicates a lower transmission power. In this embodiment, the power count value is used to determine the transmission power of the terminal device when sending a random access request message via beamforming. Optionally, the power count value can be the value of a first counter (such as a power counter).

[0065] It should be noted that, in the embodiments of this application, the terminal device sending a random access request message through a certain beam means that the terminal device sends the random access request message on the physical random access channel (PRACH) resource (such as random access channel occasion (RO)) associated with that beam.

[0066] 4. Pseudo-count values

[0067] The pseudo-count value is used to indicate the number of times the random access request message transmission has failed. For example, if a terminal device does not receive a returned random access response message after sending a random access request message within a timeout period, it can be determined that the random access request message transmission has failed. In this case, the pseudo-count value can be incremented by 1. Optionally, the pseudo-count value can be the value of a second counter (such as a pseudo-counter).

[0068] 5. Random Access

[0069] Before establishing a wireless link between a terminal device and a network device, random access needs to be completed. Random access is used to achieve the following three key objectives: achieving uplink synchronization; requesting uplink resources; and resolving contention conflicts. Random access includes contention-based random access and contention-free random access, which are explained below:

[0070] I. Competition-based random access

[0071] Figure 2 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 2 The method includes the following steps:

[0072] Step 201: When the terminal device needs to access the network device, it initializes the power counter.

[0073] When a terminal device needs to access a network device, it initiates a random access process, at which point the power counter can be initialized.

[0074] Step 202: The terminal device determines the transmission power based on the value of the power counter.

[0075] There is a corresponding relationship between the power counter value and the transmission power. For example, when the power counter value is 0, the transmission power level is 0; when the power counter value is 1, the transmission power level is 1. And so on, the larger the power counter value, the higher the transmission power level, and the greater the corresponding transmission power.

[0076] Step 203: The terminal device sends Msg1 to the network device through a specified beam according to the transmission power.

[0077] Msg1 is a random access request message. Terminal devices can send Msg1 on PRACH.

[0078] For example, Msg1 may include a random access preamble (RAP), etc. A random access preamble can also be simply referred to as a preamble.

[0079] Step 204: If the terminal device does not receive Msg2 within the timeout period, it increments the value of the power counter by 1, and then re-executes steps 202 to 203 above to retransmit Msg1.

[0080] If the terminal device does not receive Msg2 within the timeout period, it can determine that Msg1 transmission failed. Each time Msg1 transmission fails, the terminal device can increase the transmission power during retransmission by incrementing the power counter. This continues until Msg2 is received, at which point subsequent steps can continue, or until the maximum number of retransmissions is reached, at which point random access is determined to have failed.

[0081] Step 205: The terminal device receives Msg2 sent by the network device.

[0082] Msg2 is a random access response message. Network devices can send Msg2 on the physical downlink shared channel (PDSCH).

[0083] For example, Msg2 may include one or more of the following: random access preamble identifier (RAPID), timing advance command (TAC), uplink grant (UL grant), temporary cell radio network temporary identifier (TC-RNTI), etc., and this application embodiment does not limit this.

[0084] Step 206: The terminal device sends Msg3 to the network device.

[0085] The terminal device can send Msg3 using the specified physical uplink shared channel (PUSCH) resource, as instructed by the UL grant. For example, Msg3 may include the terminal device identifier, etc.

[0086] Step 207: The terminal device receives Msg4 sent by the network device.

[0087] Msg4 is a contention resolution message, which includes the end device identifier, etc. Network devices can send Msg4 on the PDSCH.

[0088] If the terminal device identifier in Msg4 is the same as its own terminal device identifier, then random access can be confirmed as successful.

[0089] II. Random Access Based on Non-Contentment

[0090] Non-contention-based random access uses dedicated random access resources and random access preambles, eliminating contention and conflict. Therefore, it can be completed through steps 201 to 205, without the need for subsequent steps 206 and 207.

[0091] During the aforementioned random access process, the terminal device transmits Msg1 based on a power ramping rule. However, this power ramping rule is relatively simple and is designed for single-beam transmission scenarios. With the increasing prevalence of multi-beam transmission scenarios, the old rule is no longer suitable, leading to inconsistent power adjustment performance among different terminal devices during multi-beam transmission.

[0092] In view of this, embodiments of this application design a new power ramp-up rule for multi-beam transmission scenarios. This rule adjusts the power counter value based on the differences between the multiple beams required for the current retransmission and those used in the previous transmission. Thus, by associating beam usage history with power control, differentiated retransmission strategies can be implemented based on possible transmission failure causes. This allows for adaptation to multi-beam transmission scenarios with lower complexity, achieving a balance between transmission success rate and terminal device power consumption in multi-beam transmission scenarios.

[0093] The random access method provided in this application embodiment will be described in detail below with reference to the corresponding flowcharts. It is understood that the illustrative flowcharts provided in this application embodiment mainly use different devices (such as network devices and terminal devices) as examples of the execution subjects for the interactive illustration of the random access method, but this application embodiment does not limit the execution subjects of the interactive illustration. For example, the devices (such as network devices and terminal devices) in the illustrative flowcharts can also be chips, chip systems, or processors that support the implementation of the random access method on the device, or logic modules or software that can implement all or part of the functions of the device.

[0094] As a general statement, the message or signaling interactions involved in the interaction process of this application embodiment can be standard messages or signaling or newly introduced messages or signaling. This application embodiment does not limit this.

[0095] Understandable, the following text Figures 3 to 10 The network device described in the implementation method can be the one mentioned above. Figure 1 Any of the network devices described in the embodiments can also be devices within a network device (such as processors, chips, or chip systems). (The following...) Figures 3 to 10 The terminal device described in the implementation method can be as described above. Figure 1 Any of the terminal devices described in the embodiments can also be devices within the terminal device (such as processors, chips, or chip systems).

[0096] Figure 3 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 3 The method may include the following steps:

[0097] Step 301: When the terminal device needs to access the network device, it determines the n beams required for the initial transmission, creates n beam sets, initializes the n power count values ​​corresponding one-to-one with the n beam sets, and adds the beam identifiers of the n beams to the n beam sets respectively.

[0098] n can be preset. n is an integer greater than or equal to 2. In multi-beam transmission scenarios, the terminal device can send a random access request message to the network device through multiple beams each time, in order to improve random access efficiency. In this embodiment, the number of beams used by the terminal device when sending the random access request message is set to n.

[0099] Terminal equipment can determine the n beams required for the initial transmission in a variety of ways.

[0100] For example, a network device can configure a PRACH candidate beam set in its broadcast system messages (such as system information blocks (SIBs)). This PRACH candidate beam set may include multiple beam identifiers and the priority of each beam identifier; optionally, it may also include the PRACH resources associated with each beam identifier. The terminal device can select the beams corresponding to the n highest-priority beam identifiers from these multiple beam identifiers as the n beams used for the initial transmission.

[0101] For example, network devices can transmit multiple reference signals on different beams. Terminal devices can measure the signal quality of all the reference signals they can receive and select the beams corresponding to the n reference signals with the strongest signal quality as the n beams for the initial transmission.

[0102] Of course, this is not the only way. The terminal device may also determine the n beams required for the initial transmission in other ways. This application does not limit this.

[0103] In this embodiment, the terminal device can create n beam sets (also known as inheritance chains) and associate each beam set with a power count value. For example, the initial value of each power count value can be 0 or 1, etc. Subsequent adjustments to each power count value can be based on changes in its corresponding beam set.

[0104] For example, if a terminal device selects two initial beams (such as beam A and beam B), then beam A can be added to beam set 1, and beam B can be added to beam set 2. Furthermore, power count value 1 is associated with beam set 1, and power count value 2 is associated with beam set 2. If it is necessary to expand to more beams, it can be added according to the rule of "1 initial beam → 1 beam set → 1 power count value," such as 3 initial beams corresponding to 3 beam sets and 3 power count values.

[0105] The beam set in this application embodiment is a set of "beam-chain" associations maintained locally on the terminal device. The core is to group the "initial beam → subsequent switched (or replaced) beams" into the same logical group / chain, and all beams in the group share the same power count value.

[0106] Step 302: For any one of the n beams, the terminal device sends a random access request message through the beam according to the transmit power corresponding to the power count value of the beam set to which the beam identifier belongs.

[0107] The terminal device can determine the transmission power based on this power count value. For example, the terminal device can determine the transmission power based on this power count value using the following formula:

[0108] P_PRACH=min{P_max,P_target+PL+Counter*Step_Size}

[0109] Wherein, P_PRACH is the transmit power, i.e., the power used by the terminal device to send the random access request message. P_max is the maximum allowed transmit power of the terminal device, determined by the terminal device's power level, and is the upper limit of the transmit power. P_target is the target receive power, which refers to the power level that the network device expects to achieve at its own receiving end, and can be broadcast by the network device through system messages. PL is the path loss, which is the downlink path loss estimated by the terminal device. Counter is the power count value. Step_Size is the power ramp step size, which is the amount of additional power added in addition to the base power during each retransmission, and can be broadcast by the network device through system messages.

[0110] Of course, this is not the only way. Terminal devices can also determine the transmission power through other means based on the power count value. This application does not limit this.

[0111] After determining the transmit power based on the power count value corresponding to the beam set to which the beam identifier belongs, the terminal device can send a random access request message through the beam at that transmit power. Afterward, the terminal device can wait to receive a random access response message from the network device.

[0112] The terminal device sends n random access request messages to the network device through these n beams. If the terminal device does not receive a random access response message for each random access request message within a timeout period, the transmission of the random access request message can be considered a failure. In this case, the terminal device can adjust the transmit power when retransmitting the random access request message by adjusting the power counter value, as described below:

[0113] Step 303: When the terminal device needs to retransmit the random access request message, it determines the n beams required for this retransmission.

[0114] The n beams required for this retransmission can be exactly the same as the n beams used in the previous transmission, or they can be at least partially different from the n beams used in the previous transmission, that is, they can be completely different or partially different from the n beams used in the previous transmission.

[0115] The terminal device can determine the n beams required for this retransmission based on some preset rules. For example, it can select the n beams with the highest priority after the n beams used in the previous transmission, in descending order of priority, as the n beams used for this retransmission. Alternatively, it can select the n beams with the highest signal quality after the n beams used in the previous transmission, in descending order of signal quality, as the n beams used for this retransmission. Of course, this is not limited to these methods; the terminal device can also determine the n beams required for this retransmission in other ways, and this embodiment does not limit this approach.

[0116] Step 304: If the terminal device needs to switch the first beam used in the previous transmission to the second beam in this retransmission, it adjusts the power count value corresponding to the first beam set according to whether the beam identifier of the second beam belongs to the first beam set. The first beam set is the beam set to which the beam identifier of the first beam belongs.

[0117] If the retransmission switches the first beam to the second beam, the power count value corresponding to the first beam set to which the beam identifier of the first beam belongs needs to be adjusted. In this case, the power count value can be adjusted based on whether the second beam is a new beam that has not been used before (i.e., whether the beam identifier of the second beam belongs to the first beam set).

[0118] In some implementations, the operation of adjusting the power count value corresponding to the first beam set based on whether the beam identifier of the second beam belongs to the first beam set can be as follows: if the beam identifier of the second beam does not belong to the first beam set, add the beam identifier of the second beam to the first beam set and keep the power count value corresponding to the first beam set unchanged; if the beam identifier of the second beam belongs to the first beam set, increment the power count value corresponding to the first beam set by 1.

[0119] If the beam identifier of the second beam does not belong to the first beam set, it means that this retransmission attempt has switched to a new beam that has not been used before. In this case, the previous transmission failure is more likely due to beam misalignment rather than insufficient transmit power. By maintaining the power count value unchanged (instead of incrementing it), the terminal device will retransmit the random access request message on the new beam using the same transmit power as before. This avoids unnecessary power consumption increases caused by blindly increasing transmit power, thus effectively saving power consumption of the terminal device while attempting a new beam to improve the transmission success rate.

[0120] If the beam identifier of the second beam belongs to the first beam set, it means that the terminal device is still retrying on a beam that has already been used. In this case, the previous transmission failure was more likely due to insufficient transmit power. By incrementing the power count value, the terminal device can retransmit with a higher transmit power to overcome path loss or interference, thereby increasing the probability of successful transmission on the second beam.

[0121] Step 305: If the beam required for this retransmission is the same as the third beam used in the previous transmission, the terminal device increments the power count value corresponding to the second beam set by 1. The second beam set is the beam set to which the beam identifier of the third beam belongs.

[0122] If the beam required for this retransmission is the same as the third beam used in the previous transmission, it means that the terminal device is still retrying on a previously used beam. In this case, the previous transmission failure was more likely due to insufficient transmit power. By incrementing the power count value, the terminal device can retransmit with greater transmit power to overcome path loss or interference, thereby increasing the probability of successful transmission on the third beam.

[0123] This application's embodiments, by associating beam usage history with power control, can implement differentiated retransmission strategies based on possible transmission failure causes. In this way, while ensuring transmission reliability, ineffective transmission power increases can be avoided to a large extent, achieving a balance between random access efficiency and terminal device power consumption.

[0124] For each of the n power count values, after the terminal device maintains the power count value unchanged or increments the power count value through the above steps 304 or 305, it can execute step 302 again to send a random access request message through the corresponding beam according to the transmit power corresponding to each of the n power count values, thereby realizing the retransmission of the random access request message.

[0125] In some implementations, if a terminal device receives a random access response message from a network device after sending a random access request message, it can determine that the random access request message was successfully transmitted, and subsequent processes can continue. For example, in a contention-based random access process, after receiving the random access response message, the terminal device can send Msg3 to the network device; in a non-contention-based random access process, after receiving the random access response message, the terminal device can determine that random access was successful.

[0126] In other implementations, if the terminal device does not receive a random access response message from the network device after sending a random access request message within a timeout period, it can retransmit the random access request message if all n power count values ​​are less than a first value; if there is a power count value among the n power count values ​​equal to the first value, the random access is considered to have failed. The first value can be preset. The first value can be the maximum value that the power count value can reach, and correspondingly, when the power count value is the first value, the transmission power corresponding to the power count value can be the maximum allowed transmission power of the terminal device.

[0127] Optionally, the terminal device may reset the n power count values ​​if it determines that the random access request message was successfully transmitted or that the random access failed.

[0128] The following is combined with Figure 4 and Figure 5 Regarding the above Figure 3 The random access method provided in the implementation method is illustrated by example:

[0129] Figure 4 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 4 The method may include the following steps:

[0130] Step 401: The terminal device selects two initial beams (beam A and beam B) and creates beam set 1 and beam set 2; adds the beam identifier of beam A to beam set 1 and adds the beam identifier of beam B to beam set 2; initializes power count value 1 and power count value 2 to 0, with power count value 1 corresponding to beam set 1 and power count value 2 corresponding to beam set 2.

[0131] In this case, such as Figure 5 As shown in (a), beam set 1: [A], power count value 1: 0; beam set 2: [B], power count value 2: 0.

[0132] Step 402: The terminal device sends a random access request message through beam A according to the transmit power corresponding to power count value 1; and sends a random access request message through beam B according to the transmit power corresponding to power count value 2.

[0133] Step 403: If the random access request message transmission fails, the terminal device switches beam A to beam C, while keeping beam B unchanged; adds the beam identifier of beam C to beam set 1, keeps the power count value 1 unchanged; and increments the power count value 2 by 1.

[0134] In this case, such as Figure 5As shown in (b), beam set 1: [A, C], power count value 1: 0; beam set 2: [B], power count value 2: 1.

[0135] Step 404: The terminal device sends a random access request message through beam C according to the transmit power corresponding to power count value 1; and sends a random access request message through beam B according to the transmit power corresponding to power count value 2.

[0136] Step 405: If the terminal device fails to transmit the random access request message, beam C remains unchanged, beam B is switched to beam D; the power count value 1 is incremented by 1; the beam identifier of beam D is added to beam set 2, and the power count value 2 remains unchanged.

[0137] In this case, such as Figure 5 As shown in (c), beam set 1: [A, C], power count value 1:1; beam set 2: [B, D], power count value 2:1.

[0138] Step 406: The terminal device sends a random access request message through beam C according to the transmit power corresponding to power count value 1; and sends a random access request message through beam D according to the transmit power corresponding to power count value 2.

[0139] Step 407: If the random access request message transmission fails, the terminal device switches beam C to beam A, while keeping beam D unchanged; increments the power count value 1 by 1; and increments the power count value 2 by 1.

[0140] In this case, such as Figure 5 As shown in (d), beam set 1: [A, C], power count value 1:2; beam set 2: [B, D], power count value 2:2.

[0141] Step 408: The terminal device sends a random access request message through beam A according to the transmit power corresponding to power count value 1; and sends a random access request message through beam D according to the transmit power corresponding to power count value 2.

[0142] Step 409: If the random access request message transmission fails, both beam A and beam D remain unchanged; power count value 1 is incremented by 1; power count value 2 is incremented by 1.

[0143] In this case, such as Figure 5 As shown in (e), beam set 1: [A, C], power count value 1:3; beam set 2: [B, D], power count value 2:3.

[0144] Step 410: The terminal device sends a random access request message through beam A according to the transmit power corresponding to power count value 1; and sends a random access request message through beam D according to the transmit power corresponding to power count value 2.

[0145] Step 411: The terminal device receives the random access response message.

[0146] Once the terminal device receives the random access response message, it can confirm that the random access request message was successfully transmitted and can then continue with the subsequent process.

[0147] In this embodiment, by creating n beam sets and a corresponding power count value for each beam set, the transmit power of different beam sets can be precisely adjusted on demand. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in such scenarios. Furthermore, this embodiment can minimize the increase in transmit power for beam sets with more beam identifiers (i.e., those frequently switching to new beams) and maximize the increase in transmit power for beam sets with fewer beam identifiers (i.e., those frequently retries on the same beam). This significantly reduces terminal device power consumption without lowering transmission success rate. Thus, by differentially adjusting the power of different beam sets, it can adapt to scenarios such as terminal device movement and dynamic channel changes, offering high flexibility.

[0148] Furthermore, in this embodiment, the terminal device can autonomously adjust power locally without network device signaling intervention, complying with PRACH open-loop power control requirements. Moreover, the terminal device only needs to record n ​​beam sets and n power count values ​​to quickly achieve power adjustment, resulting in low storage and computational overhead and low management complexity. Additionally, this embodiment does not require modification of the power calculation formula or the network device communication logic, thus ensuring good compatibility with existing protocols.

[0149] Figure 6 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 6 The method may include the following steps:

[0150] Step 601: When the terminal device needs to access the network device, it determines the n beams required for the initial transmission, initializes the power count value and the pseudo count value, and the pseudo count value is used to indicate the number of times the random access request message transmission failed.

[0151] The initial value of the power count can be 0 or 1, etc. The initial value of the pseudo count can be 0.

[0152] n can be preset. n is an integer greater than or equal to 2. In multi-beam transmission scenarios, the terminal device can send a random access request message to the network device through multiple beams each time, in order to improve random access efficiency. In this embodiment, the number of beams used by the terminal device when sending the random access request message is set to n.

[0153] The operation of the terminal device determining the n beams required for the initial transmission is similar to the operation of the terminal device determining the n beams required for the initial transmission in step 301 above, and will not be described again in this embodiment.

[0154] Step 602: The terminal device sends a random access request message through n beams based on the transmit power corresponding to the power count value.

[0155] In this embodiment, the terminal device transmits random access request messages through n beams with the same power, which is the transmission power corresponding to the power count value.

[0156] The terminal device can determine the transmission power based on the power count value. The operation of the terminal device determining the transmission power based on the power count value is similar to the operation of the terminal device determining the transmission power based on the power count value in step 302 above, and will not be described again in this embodiment.

[0157] After the terminal device sends a random access request message through n beams at this transmission power, it can wait to receive a random access response message from the network device.

[0158] The terminal device sends n random access request messages to the network device through these n beams. If the terminal device does not receive a random access response message for each random access request message within the timeout period, it can be determined that the random access request message transmission has failed.

[0159] If the terminal device determines that the random access request message transmission has failed, it can increment the pseudo-count value by 1. Subsequently, the terminal device can adjust the transmit power when retransmitting the random access request message by adjusting this power counter value, as described below:

[0160] Step 603: When the terminal device needs to retransmit the random access request message, it determines the n beams required for this retransmission.

[0161] The operation of step 603 is similar to that of step 303 above, and will not be described again in this embodiment.

[0162] Step 604: If the pseudo count value is less than the preset value, the terminal device adjusts the power count value according to the difference between the n beams required for this retransmission and the n beams used in the previous transmission.

[0163] The preset value can be set in advance. For example, the preset value can be 3, 4, etc., but this application embodiment does not limit this.

[0164] If the pseudo count value is less than the preset value, it means that the number of times the random access request message transmission failed is relatively small. Therefore, the power count value can be adjusted as needed based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission, so as to achieve a balance between the transmission success rate and the power consumption of the terminal device.

[0165] In some implementations, the operation of adjusting the power count value based on the difference between the n beams required for the current retransmission and the n beams used in the previous transmission can be as follows: if the n beams required for the current retransmission are at least partially different from the n beams used in the previous transmission, the power count value is kept unchanged; if the n beams required for the current retransmission are the same as the n beams used in the previous transmission, the power count value is incremented by 1.

[0166] If the n beams required for this retransmission are at least partially different from the n beams used in the previous transmission, it indicates that the retransmission attempt has switched to a new beam that was not used previously. Therefore, the previous transmission failure was more likely due to beam misalignment than insufficient transmit power. In this case, by maintaining the power count value unchanged (rather than incrementing it), the terminal device will retransmit the random access request message on the new beam using the same transmit power as before. This avoids unnecessary power consumption increases caused by blindly increasing transmit power, effectively saving power for the terminal device while attempting a new beam to improve the transmission success rate.

[0167] If the n beams required for this retransmission are the same as those used in the previous transmission, it means the terminal device is still retrying on beams that have already been used. In this case, the previous transmission failure was more likely due to insufficient transmission power. By incrementing the power count value, the terminal device can retransmit with greater transmission power to overcome path loss or interference, thereby improving the transmission success rate.

[0168] This application's embodiments, by associating beam usage history with power control, can implement differentiated retransmission strategies based on possible transmission failure causes. In this way, while ensuring transmission reliability, ineffective transmission power increases can be avoided to a large extent, achieving a balance between random access efficiency and terminal device power consumption.

[0169] Step 605: If the pseudo count value is greater than or equal to the preset value, the terminal device increments the power count value by 1.

[0170] If the pseudo-count value is greater than or equal to the preset value, it indicates that the random access request message transmission has failed a lot. In this case, to improve the transmission success rate, the power count value needs to be continuously increased to continuously increase the transmission power.

[0171] In this embodiment, the pseudo-count value can monitor the degree of continuous global transmission failure to quickly determine the power adaptation status. The global power count value is dynamically adjusted according to "transmission failure degree + beam switching status," thereby helping to achieve on-demand adjustment of the transmission power.

[0172] After the terminal device maintains the power count value unchanged or increments the power count value through the above steps 604 or 605, it can execute step 602 again to send a random access request message through the n beams according to the transmit power corresponding to the power count value, thereby realizing the retransmission of the random access request message.

[0173] In some implementations, if a terminal device receives a random access response message from a network device after sending a random access request message, it can determine that the random access request message was successfully transmitted, and subsequent processes can continue. For example, in a contention-based random access process, after receiving the random access response message, the terminal device can send Msg3 to the network device; in a non-contention-based random access process, after receiving the random access response message, the terminal device can determine that random access was successful.

[0174] In other implementations, if the terminal device does not receive a random access response message from the network device after sending a random access request message within a timeout period, it can retransmit the random access request message if the power count value is less than a second value; if the power count value is equal to the second value, random access can be determined to have failed. The second value can be preset. The second value can be the maximum value that the power count value can reach, and correspondingly, when the power count value is the second value, the transmission power corresponding to that power count value can be the maximum allowed transmission power of the terminal device.

[0175] Optionally, the terminal device may reset the power count value and the pseudo count value if it determines that the random access request message transmission was successful or that the random access failed.

[0176] The following is combined with Figure 7 and Figure 8 Regarding the above Figure 6 The random access method provided in the implementation method is illustrated by example:

[0177] Figure 7 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 7The method may include the following steps:

[0178] Step 701: The terminal device selects three initial beams (beam A, beam B, and beam C), initializes the power count value and pseudo count value to 0, and assumes the preset value is 4.

[0179] In this case, such as Figure 8 As shown in (a), the power count value is 0 and the pseudo count value is 0.

[0180] Step 702: The terminal device sends a random access request message through beams A, B, and C based on the transmit power corresponding to the power count value.

[0181] Step 703: If the random access request message transmission fails, the terminal device increments the pseudo count value by 1, switches beam A to beam D, and keeps beams B and C unchanged; if the pseudo count value is less than 4, the power count value remains unchanged.

[0182] In this case, such as Figure 8 As shown in (b), the power count value is 0 and the pseudo count value is 1.

[0183] Step 704: The terminal device sends a random access request message through beams D, B, and C based on the transmit power corresponding to the power count value.

[0184] Step 705: If the terminal device fails to transmit the random access request message, it increments the pseudo count value by 1, keeps beam D unchanged, switches beam B to beam E, and switches beam C to beam F; if the pseudo count value is less than 4, it keeps the power count value unchanged.

[0185] In this case, such as Figure 8 As shown in (c), the power count value is 0 and the pseudo count value is 2.

[0186] Step 706: The terminal device sends a random access request message through beams D, E and F according to the transmit power corresponding to the power count value.

[0187] Step 707: If the random access request message transmission fails, the terminal device increments the pseudo count value by 1, while beams D, E, and F remain unchanged; if the pseudo count value is less than 4, the power count value is incremented by 1.

[0188] In this case, such as Figure 8 As shown in (d), the power count value is 1 and the pseudo count value is 3.

[0189] Step 708: The terminal device sends a random access request message through beams D, E and F based on the transmit power corresponding to the power count value.

[0190] Step 709: If the terminal device fails to transmit the random access request message, it increments the pseudo count value by 1, switches beam D to beam G, and keeps beams E and F unchanged; if the pseudo count value is equal to 4, it increments the power count value by 1.

[0191] In this case, such as Figure 8 As shown in (e), the power count value is 2, and the pseudo count value is 4.

[0192] Step 710: The terminal device sends a random access request message through beams G, E and F based on the transmit power corresponding to the power count value.

[0193] Step 711: If the random access request message transmission fails, the terminal device increments the pseudo count value by 1, switches beam G to beam A, beam E to beam B, and beam F to beam H; if the pseudo count value is greater than 4, increments the power count value by 1.

[0194] In this case, such as Figure 8 As shown in (f), the power count value is 3 and the pseudo count value is 5.

[0195] Step 712: The terminal device sends a random access request message through beams A, B, and H based on the transmit power corresponding to the power count value.

[0196] Step 713: The terminal device receives the random access response message.

[0197] Once the terminal device receives the random access response message, it can confirm that the random access request message was successfully transmitted and can then continue with the subsequent process.

[0198] This application proposes a dynamic power control scheme based on the coordination of global power count and pseudo-count values. This scheme enables power-saving probing when the number of transmission failures is low and timely power replenishment when the number of failures is high. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in such scenarios. Furthermore, by using the magnitude of the pseudo-count value to determine the adjustment method of the power count value, it can adapt to scenarios such as terminal device movement and dynamic channel changes, offering high flexibility. Thus, it can save terminal device power consumption in strong coverage scenarios and ensure transmission success rate in weak coverage scenarios.

[0199] Furthermore, in this embodiment, the terminal device can autonomously adjust power locally without network device signaling intervention, complying with PRACH open-loop power control requirements. Moreover, the terminal device only needs to record one power count value and one pseudo-count value to quickly achieve power adjustment, resulting in low storage and computational overhead and low management complexity. Additionally, this embodiment does not require modification of the power calculation formula or the network device communication logic, thus ensuring good compatibility with existing protocols.

[0200] Figure 9 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 9 The method may include the following steps:

[0201] Step 901: When the terminal device needs to access the network device, it determines the n beams required for the initial transmission, creates n beam sets, initializes the n power count values ​​corresponding to the n beam sets, adds the beam identifiers of the n beams to the n beam sets respectively, and initializes the pseudo count values.

[0202] In step 901, the terminal device determines the n beams required for the initial transmission, creates n beam sets, initializes the n power count values ​​corresponding to the n beam sets, and adds the beam identifiers of the n beams to the n beam sets respectively. The operation is similar to the operation in step 301, and will not be described again in this embodiment.

[0203] This pseudo-count value indicates the number of times a random access request message transmission has failed. The initial value of this pseudo-count value can be 0.

[0204] Step 902: For any one of the n beams, the terminal device sends a random access request message through the beam according to the transmit power corresponding to the power count value of the beam set to which the beam identifier belongs.

[0205] The operation of step 902 is similar to that of step 302, and will not be described again in this embodiment.

[0206] If the terminal device determines that the random access request message transmission has failed, it can increment the pseudo-count value by 1. Afterwards, the terminal device can adjust the transmit power when retransmitting the random access request message by adjusting the power counter value, as described below:

[0207] Step 903: When the terminal device needs to retransmit the random access request message, it determines the n beams required for this retransmission.

[0208] The operation of step 903 is similar to that of step 303, and will not be described again in this embodiment.

[0209] Step 904: If the pseudo count value is less than the preset value, the terminal device adjusts the n power count values ​​according to the difference between the n beams required for this retransmission and the n beams used in the previous transmission.

[0210] The preset value can be set in advance. For example, the preset value can be 3, 4, etc., but this application embodiment does not limit this.

[0211] If the pseudo count value is less than the preset value, it means that the number of times the random access request message transmission failed is relatively small. Therefore, the n power count values ​​can be adjusted as needed based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission, so as to achieve a balance between the transmission success rate and the power consumption of the terminal device.

[0212] This application's embodiments, by associating beam usage history with power control, can implement differentiated retransmission strategies based on possible transmission failure causes. In this way, while ensuring transmission reliability, ineffective transmission power increases can be avoided to a large extent, achieving a balance between random access efficiency and terminal device power consumption.

[0213] In step 904, the terminal device adjusts the n power count values ​​based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission. This operation is similar to the operations in steps 304 and 305 above, and will not be described again in this embodiment.

[0214] Step 905: If the pseudo count value is greater than or equal to the preset value, the terminal device increments all n power count values ​​by 1.

[0215] If the pseudo-count value is greater than or equal to the preset value, it indicates that the random access request message transmission has failed a lot. In this case, to improve the transmission success rate, it is necessary to continuously increase the n power count values ​​to continuously increase the transmission power.

[0216] In this embodiment, the pseudo-count value can monitor the degree of global continuous transmission failure to quickly determine the power adaptation status. The n power count values ​​are dynamically adjusted according to "transmission failure degree + beam switching status," thereby facilitating on-demand adjustment of the transmission power.

[0217] For each of the n power count values, after the terminal device maintains the power count value unchanged or increments the power count value through the above steps 904 or 905, it can execute step 902 again to send a random access request message through the corresponding beam according to the transmit power corresponding to each of the n power count values, thereby realizing the retransmission of the random access request message.

[0218] In some implementations, after the terminal device sends a random access request message, it can determine whether the random access request message was successfully transmitted based on the reception status of the random access response message. If the random access request message transmission fails, it can also determine whether to continue retransmitting the random access request message or to confirm that random access has failed based on the magnitude of the n power count values. The specific operations have been described in detail above and will not be repeated here.

[0219] Optionally, the terminal device may reset the n power count values ​​and the pseudo count value if it determines that the random access request message transmission was successful or that the random access failed.

[0220] In this embodiment, a dynamic power control scheme based on the collaboration of n power count values ​​and pseudo-count values ​​is proposed. This scheme can not only accurately adjust the transmit power of different beam sets as needed, but also, for each beam set, enable power-saving probing when the number of transmission failures is low and timely power replenishment when the number of transmission failures is high. This allows for adaptation to multi-beam transmission scenarios with low complexity, achieving a balance between transmission success rate and terminal device power consumption in multi-beam transmission scenarios.

[0221] Figure 10 This is a flowchart of a random access method provided in an embodiment of this application. See also... Figure 10 The method may include the following steps:

[0222] Step 1001: When the terminal device needs to access the network device, it determines the n beams required for the initial transmission and initializes the power count value.

[0223] In one possible approach, step 1001 can be implemented by step 301, step 601, or step 901 as described above.

[0224] In another possible approach, step 1001 sets only one power count value and does not set a pseudo count value. Step 1001 only initializes this power count value. For example, the initial value of this power count value can be 0 or 1, etc., and this embodiment of the application does not limit this.

[0225] Step 1002: The terminal device sends a random access request message through n beams based on the transmit power corresponding to the power count value.

[0226] In one possible manner, if step 1001 is implemented through step 301, step 1002 can be implemented through step 302; if step 1001 is implemented through step 601, step 1002 can be implemented through step 602; if step 1001 is implemented through step 901, step 1002 can be implemented through step 902.

[0227] In another possible approach, if only one power count value is set in step 1001 and no pseudo count value is set, then in step 1002, a random access request message is sent through n beams with the transmit power corresponding to the power count value.

[0228] If a terminal device determines that the transmission of a random access request message has failed, it can adjust the transmit power when retransmitting the random access request message by adjusting the power counter value, as detailed below:

[0229] Step 1003: When the terminal device needs to retransmit the random access request message, it determines the n beams required for this retransmission.

[0230] The operation of step 1003 is similar to that of step 303, and will not be described again in this embodiment.

[0231] Step 1004: The terminal device adjusts the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission.

[0232] In one possible approach, if step 1001 is implemented through step 301, step 1004 can be implemented through steps 304 and 305; if step 1001 is implemented through step 601, step 1002 can be implemented through steps 604 and 605; if step 1001 is implemented through step 901, step 1002 can be implemented through steps 904 and 905.

[0233] In another possible approach, if only one power count value is set in step 1001 and no pseudo count value is set, the operation of step 1004 can be as follows: if the n beams required for this retransmission are at least partially different from the n beams used in the previous transmission, the power count value is kept unchanged; if the n beams required for this retransmission are the same as the n beams used in the previous transmission, the power count value is incremented by 1.

[0234] After the terminal device adjusts the power count value through step 1004, it can execute step 1002 again to send a random access request message through n beams according to the transmit power corresponding to the power count value, thereby realizing the retransmission of the random access request message.

[0235] In some implementations, after the terminal device sends a random access request message, it can determine whether the random access request message was successfully transmitted based on the reception status of the random access response message. If the random access request message transmission fails, it can also determine whether to retransmit the random access request message or confirm that random access has failed based on the magnitude of the power count value. The specific operations have been described in detail above and will not be repeated here.

[0236] Optionally, the terminal device may reset the power count value if it determines that the random access request message transmission was successful or that random access has failed.

[0237] In this embodiment, by associating beam usage history with power control, differentiated retransmission strategies can be implemented based on possible causes of transmission failure. This ensures transmission reliability while minimizing unnecessary power increases, achieving a balance between random access efficiency and terminal device power consumption.

[0238] It should be understood that Figures 1 to 10 The flowcharts or scene diagrams shown are for illustrative purposes only and are not intended to limit the embodiments of this application to the examples illustrated. In fact, those skilled in the art can interpret the embodiments based on... Figures 1 to 10 The examples in the document can be transformed into equivalent ways to obtain more implementations.

[0239] The above text combined Figures 1 to 10 This document describes in detail the random access method provided in the embodiments of this application. The following will combine... Figures 11 to 12 The apparatus embodiments of this application are described in detail below. It should be understood that the communication apparatus of this application embodiments can execute the various random access methods described in the foregoing embodiments of this application. That is, the specific working processes of the various products described below can be referred to the corresponding processes in the foregoing method embodiments.

[0240] In the embodiments described above, the network device may execute some or all of the steps in each embodiment; the terminal device may execute some or all of the steps in each embodiment. These steps or operations are merely examples, and other operations or variations thereof may also be performed in the embodiments of this application. Furthermore, the steps may be executed in different orders as presented in the embodiments, and it is not necessary to execute all the operations in the embodiments of this application. The sequence number of each step does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0241] Figure 11 This is a schematic block diagram of a communication device provided in an embodiment of this application. Figure 11 As shown, the communication device 1100 may include a communication module 1120. The communication module 1120 can implement corresponding communication functions, which can be internal communication functions of the communication device 1100 or communication functions between the communication device 1100 and other devices. Optionally, the communication module 1120 may also be referred to as a communication interface or transceiver module. Optionally, the communication device 1100 also includes a processing module 1110. The processing module 1110 can implement corresponding processing functions.

[0242] Optionally, the communication device 1100 further includes a storage module, which can be used to store instructions and / or data; the processing module 1110 can read the instructions and / or data in the storage module so that the communication device 1100 can implement the aforementioned method embodiments.

[0243] In one possible design, the communication device 1100 may correspond to the terminal device in the above method embodiments, or a component (such as a circuit, chip, or chip system) configured in the terminal device. The communication device 1100 may be used to perform the steps or processes performed by the terminal device in any of the above method embodiments.

[0244] For example, the communication module 1120 is used to: send a random access request message through n beams according to the transmit power corresponding to the power count value, where n is an integer greater than or equal to 2. The processing module 1110 is used to: adjust the power count value according to the difference between the n beams required for this retransmission and the n beams used in the previous transmission when a retransmission of the random access request message is required.

[0245] For example, processing module 1110 is used to: create n beam sets when network access is required; initialize n power count values, with each of the n power count values ​​corresponding to one of the n beam sets; and add the beam identifiers of the n beams required for the initial transmission to the n beam sets respectively. Communication module 1120 is used to: for any one of the n beams, send a random access request message through that beam according to the transmit power corresponding to the power count value of the beam set to which the beam identifier belongs.

[0246] For example, processing module 1110 is configured to: initialize a pseudo-count value when network access is required, the pseudo-count value indicating the number of times random access request message transmission has failed. Processing module 1110 is also configured to: adjust the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission when the pseudo-count value is less than a preset value.

[0247] For example, the processing module 1110 is used to: when the retransmission requires switching the first beam used in the previous transmission to the second beam, adjust the power count value corresponding to the first beam set according to whether the beam identifier of the second beam belongs to the first beam set, wherein the first beam set is the beam set to which the beam identifier of the first beam belongs; when the beam required for the retransmission is the same as the third beam used in the previous transmission, increment the power count value corresponding to the second beam set by 1, wherein the second beam set is the beam set to which the beam identifier of the third beam belongs.

[0248] For example, the processing module 1110 is configured to: add the beam identifier of the second beam to the first beam set when the beam identifier of the second beam does not belong to the first beam set, while keeping the power count value corresponding to the first beam set unchanged; and increment the power count value corresponding to the first beam set by 1 when the beam identifier of the second beam belongs to the first beam set.

[0249] For example, the processing module 1110 is used to: increment all n power count values ​​by 1 when it is necessary to retransmit the random access request message and the pseudo count value is greater than or equal to a preset value.

[0250] For example, processing module 1110 is used to: initialize a power count value and a pseudo count value when network device access is required, wherein the pseudo count value is used to indicate the number of times the random access request message transmission failed. Processing module 1110 is also used to: adjust the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission if the pseudo count value is less than a preset value.

[0251] For example, the processing module 1110 is configured to: maintain the power count value unchanged when the n beams required for this retransmission are at least partially different from the n beams used in the previous transmission; and increment the power count value by 1 when the n beams required for this retransmission are the same as the n beams used in the previous transmission.

[0252] For example, the processing module 1110 is used to: increment the power count value by 1 when it is necessary to retransmit the random access request message and the pseudo count value is greater than or equal to a preset value.

[0253] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0254] Figure 12 This is a schematic block diagram of a communication device 1200 provided in an embodiment of this application. The communication device 1200 may be a network device, a terminal device, or a circuit, chip, chip system, or processor for implementing the above methods. The communication device 1200 can be used to implement the methods described in the above method embodiments, and for details, please refer to the description in the above method embodiments.

[0255] like Figure 12 As shown, the communication device 1200 may include one or more processors 1210, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 1210 may be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device 1200 (e.g., a base station, baseband chip, user equipment, user chip), execute software programs, and process data from the software programs.

[0256] In an alternative design, the processor 1210 may also store instructions and / or data that can be executed by the processor 1210 to cause the communication device 1200 to perform the methods described in the above method embodiments.

[0257] In another alternative design, the communication device 1200 may include a communication interface 1220 for implementing receiving and transmitting functions. For example, the communication interface 1220 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0258] Optionally, the communication device 1200 may include one or more memories 1230, which may store instructions that can be executed on the processor 1210, causing the communication device 1200 to perform the methods described in the above method embodiments. Optionally, the memories 1230 may also store data. Optionally, the processor 1210 may also store instructions and / or data. The processor 1210 and the memories 1230 may be provided separately or integrated together.

[0259] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0260] In one implementation, the communication device 1200 may correspond to the network device in the above method embodiments and may be used to execute the various steps and / or processes executed by the network device in the above method embodiments. The processor 1210 may be used to execute instructions stored in the memory 1230, and when the processor 1210 executes the instructions stored in the memory, the processor 1210 is used to execute the various steps and / or processes of the above method embodiments corresponding to the network device.

[0261] In another implementation, the communication device 1200 may correspond to the terminal device in the above method embodiments, and may be used to execute the various steps and / or processes executed by the terminal device in the above method embodiments. The processor 1210 may be used to execute the instructions stored in the memory 1230, and when the processor 1210 executes the instructions stored in the memory, the processor 1210 is used to execute the various steps and / or processes of the above method embodiments corresponding to the terminal device.

[0262] It should be understood that the aforementioned processing device can be one or more chips. For example, the processing device can be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0263] 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. The 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. The 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 dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (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.

[0264] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0265] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0266] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned network device and terminal device.

[0267] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0268] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0269] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0270] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0271] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

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

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

[0274] In summary, the above descriptions are merely optional embodiments of the technical solutions of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A random access method, characterized in that, Applied to a terminal device, the method includes: When network access is required, a pseudo-count value is initialized, which is used to indicate the number of times random access request message transmission failed; Based on the transmit power corresponding to the power count value, the random access request message is sent through n beams, where n is an integer greater than or equal to 2; If the random access request message needs to be retransmitted and the pseudo count value is less than a preset value, the power count value is adjusted according to the difference between the n beams required for this retransmission and the n beams used in the previous transmission; if the random access request message needs to be retransmitted and the pseudo count value is greater than or equal to the preset value, the power count value is incremented by 1.

2. The method as described in claim 1, characterized in that, Before sending the random access request message through n beams based on the transmit power corresponding to the power count value, the method further includes: When network access is required, create n beam sets; Initialize n power count values, each of which corresponds one-to-one with one of the n beam sets; Add the beam identifiers of the n beams required for the initial transmission to the n beam sets respectively; The step of sending the random access request message through n beams based on the transmit power corresponding to the power count value includes: For any one of the n beams, the random access request message is sent through the beam according to the transmit power corresponding to the power count value of the beam set to which the beam identifier belongs.

3. The method as described in claim 2, characterized in that, The step of adjusting the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission includes: If the first beam used in the previous transmission needs to be switched to the second beam in this retransmission, the power count value corresponding to the first beam set is adjusted according to whether the beam identifier of the second beam belongs to the first beam set. The first beam set is the beam set to which the beam identifier of the first beam belongs. If the beam required for this retransmission is the same as the third beam used in the previous transmission, the power count value corresponding to the second beam set is incremented by 1. The second beam set is the beam set to which the beam identifier of the third beam belongs.

4. The method as described in claim 3, characterized in that, The step of adjusting the power count value corresponding to the first beam set based on whether the beam identifier of the second beam belongs to the first beam set includes: If the beam identifier of the second beam does not belong to the first beam set, the beam identifier of the second beam is added to the first beam set, while keeping the power count value corresponding to the first beam set unchanged. If the beam identifier of the second beam belongs to the first beam set, the power count value corresponding to the first beam set is incremented by 1.

5. The method as described in claim 1, characterized in that, Before sending the random access request message through n beams based on the transmit power corresponding to the power count value, the method further includes: When access to the network device is required, initialize the power count value.

6. The method as described in claim 1 or 5, characterized in that, The step of adjusting the power count value based on the difference between the n beams required for this retransmission and the n beams used in the previous transmission includes: If the n beams required for this retransmission are at least partially different from the n beams used in the previous transmission, the power count value shall remain unchanged. If the n beams required for this retransmission are the same as the n beams used in the previous transmission, the power count value is incremented by 1.

7. A communication device, characterized in that, The communication device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the communication device to perform the method as described in any one of claims 1 to 6.

8. A communication system, characterized in that, The communication system includes the communication device as described in claim 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed, cause a computer to perform the method as described in any one of claims 1 to 6.

10. A chip system, characterized in that, The chip system includes one or more processors, which are configured to retrieve and execute instructions stored in a memory, such that the method as described in any one of claims 1 to 6 is performed.

Images