A communication method and related apparatus

Abstract

The application provides a communication method and related communication device, comprising: a terminal receiving DRX configuration information from a network device, the DRX configuration information being used for configuring parameters of a DRX timer. Then, according to fault-tolerant information or indication information from the network device, a running state of the DRX timer is set. The fault-tolerant information comprises at least one of fault-tolerant capability information, fault-tolerant threshold information or fault-tolerant mode information, the fault-tolerant capability information indicating that data transmission has fault-tolerant capability, the fault-tolerant threshold information indicating an allowed data amount of error transmission, the fault-tolerant mode information indicating an allowed data mode of error transmission, and the indication information sent by the network device being related to the fault-tolerant information. In this way, the terminal can set the running state of the DRX timer according to the data fault-tolerant information, and when the terminal does not need to retransmit error data or does not need to transmit redundant data, the corresponding DRX timer is set to a non-running state, so that the terminal does not need to continue to detect PDCCH, and the power consumption of the terminal is reduced.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a communication method, communication device, computer storage medium, and computer program product. Background Technology

[0002] With the continuous development of communication technology, the requirements for power consumption control of terminals are becoming increasingly stringent. Taking a user equipment (UE) as an example, to reduce UE power consumption and achieve power saving, a discontinuous reception (DRX) mechanism can be enabled. Specifically, DRX causes the UE, such as its receiver, to periodically enter a sleep state. If data transmission is needed, the UE is woken up from the sleep state. Connected DRX (CDRX) can be enabled when the UE has established a connection with the network equipment.

[0003] Meanwhile, in recent years, next-generation communication technologies, represented by semantic communications, have endowed communication systems with a certain degree of fault tolerance. Compared to traditional Shannon communication, fault-tolerant semantic communication technologies do not require precise recovery at the bit level, but rather pursue accurate semantic transmission, thus greatly improving communication efficiency. In other words, fault-tolerant communication systems can maintain system performance well even when some features or data transmission errors occur.

[0004] However, the traditional DRX mechanism does not take into account the fault tolerance capability of the communication system, which causes the UE to increase unnecessary power consumption during data transmission. Summary of the Invention

[0005] This application proposes a communication method and related apparatus to solve the problem of high power consumption in the fault-tolerant data transmission process of the UE.

[0006] Firstly, embodiments of this application propose a communication method that can be applied to the terminal side, such as a terminal or a communication module and / or computing module within the terminal, or circuits or chips in the terminal responsible for communication functions (such as a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip containing a modem core, or a system-in-package (SIP) chip), or circuits or chips in the terminal responsible for communication and / or computing functions (such as a graphics processing unit (GPU), an artificial intelligence (AI) processor, or an application-specific integrated circuit (ASIC)), or logical nodes, logical modules, or software capable of implementing all or part of the terminal's functions. Taking the application of this method to a terminal as an example, the method includes:

[0007] The terminal receives DRX configuration information from the network device, which is used to configure the parameters of the DRX timer. Then, based on fault tolerance information or indication information from the network device, the terminal sets the operating state of the DRX timer. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. Fault tolerance capability information indicates that data transmission has fault tolerance capability; fault tolerance threshold information indicates the amount of data allowed to be transmitted incorrectly; fault tolerance mode information indicates the data mode allowed to be transmitted incorrectly; and the indication information sent by the network device is related to the fault tolerance information.

[0008] In this method, the terminal can set the running state of the DRX timer based on the fault tolerance information of the data transmission. This allows the DRX timer to be set to a non-running state when the terminal does not need to retransmit erroneous data or transmit redundant data, thus eliminating the need for the terminal to continue monitoring the PDCCH and reducing the terminal's power consumption.

[0009] In some possible implementations, the DRX timer includes a DRX retransmission timer (drx-RetransmissionTimer) and / or a DRX hybrid automatic repeat request round-trip timer (drx-HARQ-RTT-Timer). Fault tolerance threshold information indicates a first fault tolerance threshold and / or fault tolerance mode information indicates a first fault tolerance mode. The terminal can set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state if one or more of the following first conditions are met: the transmitted erroneous data does not reach the first fault tolerance threshold, or the transmitted erroneous data conforms to the first fault tolerance mode.

[0010] In this way, the relevant timers can be set to a non-running state when erroneous data does not need to be retransmitted, so that the terminal does not continue to detect PDCCH and reduces the power consumption of the terminal.

[0011] In some possible implementations, the fault tolerance information also indicates a first fault tolerance interval, and the terminal can set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state if at least one or more of the following first conditions are met: the data transmitted in error in the first fault tolerance interval does not reach the first fault tolerance threshold, or the data transmitted in error in the first fault tolerance interval conforms to the first fault tolerance mode.

[0012] In this way, the data transmission status can be detected periodically according to the transmission interval, and the running status of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer can be automatically determined and set, thereby improving communication efficiency.

[0013] In some possible implementations, the DRX timer includes a DRX inactivity timer (drx-InactivityTimer), fault tolerance threshold information indicating a second fault tolerance threshold and / or fault tolerance mode information indicating a second fault tolerance mode. The terminal can set the drx-InactivityTimer to a non-running state if at least one or more of the following second conditions are met: the transmission of correct data reaches the second fault tolerance threshold, or the transmission of correct data conforms to the second fault tolerance mode.

[0014] This reduces unnecessary data transmission, allowing the terminal to avoid detecting the PDCCH if requirements are met, thus reducing the transmission burden and lowering terminal power consumption.

[0015] In some possible implementations, the fault tolerance information also indicates a second fault tolerance interval, and the terminal can set drx-InactivityTimer to a non-running state if at least one or more of the following second conditions are met: the transmission of correct data in the second fault tolerance interval reaches the second fault tolerance threshold, and the transmission of correct data in the second fault tolerance interval conforms to the second fault tolerance mode.

[0016] In this way, the data transmission status can be detected periodically according to the transmission interval, and the running status of drx-InactivityTimer can be automatically determined and set, thereby improving communication efficiency.

[0017] In some possible implementations, the terminal can also send error information to the network device, or receive fault tolerance information from the server or network device.

[0018] In this way, the terminal side and the network side can synchronize fault tolerance information, enabling the devices on both sides to align their judgments on data transmission status and corresponding processing strategies, thereby improving the accuracy and efficiency of transmission.

[0019] Secondly, this method can be applied to the network side, such as access network devices, modules (e.g., circuits, chips, or chip systems) within these devices, or logical nodes, modules, or software that can implement all or part of the functions of the access network devices, or circuits or chips (e.g., GPUs, AI processors, or ASICs) responsible for communication and / or computing functions within the access network devices. Taking the application of this method to access network devices (or network equipment) as an example, in this method, the network device can send DRX configuration information to the terminal. This DRX configuration information is used to configure the parameters of the DRX timer. Then, the network device can send indication information to the terminal based on fault tolerance information. This indication information is used to set the operating state of the DRX timer. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that the data transmission has fault tolerance capability; the fault tolerance threshold information indicates the amount of data allowed to be transmitted incorrectly; and the fault tolerance mode information indicates the data mode allowed to be transmitted incorrectly.

[0020] In some possible implementations, the DRX timer includes drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer, fault tolerance threshold information indicates a first fault tolerance threshold and / or fault tolerance mode information indicates a first fault tolerance mode. The network device can send indication information to the terminal, instructing the terminal to set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-operating state, provided that at least one or more of the following first conditions are met: the transmitted erroneous data has not reached the first fault tolerance threshold, or the transmitted erroneous data conforms to the first fault tolerance mode.

[0021] In some possible implementations, the fault tolerance information also indicates a first fault tolerance interval. The network device may send an indication to the terminal, instructing the terminal to set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state, provided that at least one or more of the following first conditions are met: the data transmitted in error in the first fault tolerance interval has not reached the first fault tolerance threshold, or the data transmitted in error in the first fault tolerance interval conforms to the first fault tolerance mode.

[0022] In some possible implementations, the DRX timer includes a drx-InactivityTimer, fault tolerance threshold information indicating a second fault tolerance threshold and / or fault tolerance mode information indicating a second fault tolerance mode. The network device can send indication information to the terminal, instructing the terminal to set the drx-InactivityTimer to a non-running state, provided that at least one or more of the following first conditions are met: the transmission of correct data reaches the second fault tolerance threshold, or the transmission of correct data conforms to the second fault tolerance mode.

[0023] In some possible implementations, the fault tolerance information also indicates a second fault tolerance interval. The network device can send an indication to the terminal, instructing the terminal to set drx-InactivityTimer to a non-running state, provided that at least one or more of the following first conditions are met: the transmission of correct data in the second fault tolerance interval reaches the second fault tolerance threshold, and the transmission of correct data in the second fault tolerance interval conforms to the second fault tolerance mode.

[0024] In some possible implementations, network devices can also receive fault tolerance information from servers or terminals, or send fault tolerance information to terminals.

[0025] Thirdly, this application provides a communication device that has the functions of the first aspect described above. For example, the communication device includes modules, units, or means that perform the operations involved in the first aspect. These modules, units, or means can be implemented by software, hardware, or a combination of software and hardware.

[0026] Fourthly, this application provides a communication device that has the functions of the second aspect above. For example, the communication device includes modules, units, or means that perform the operations involved in the second aspect above. These modules, units, or means can be implemented by software, hardware, or a combination of software and hardware.

[0027] Fifthly, this application provides a communication device including an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer program or instructions for implementing the functions described in the first aspect. The one or more processors can execute the computer program or instructions, causing the communication device to implement the methods in any possible design or implementation of the first aspect. The interface circuit is used to implement the communication functions within the communication device and / or the communication functions between the communication device and other devices or components.

[0028] In some possible implementations, the processor is used to communicate with other devices or components through the interface circuit.

[0029] In some possible implementations, the communication device may also include the memory.

[0030] The aforementioned communication device may be a terminal, or a communication and / or computing module in a terminal, or a chip in a terminal responsible for communication functions such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module, or a circuit or chip in a terminal responsible for communication and / or computing functions (such as a GPU, AI processor, or ASIC), or a logical node or logical module capable of implementing all or part of the terminal functions.

[0031] Sixthly, this application provides a communication device including an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer program or instructions for implementing the functions described in the second aspect above. The one or more processors are executable to carry out the computer program or instructions, causing the communication device to implement the methods in any possible design or implementation of the second aspect above. The interface circuit is used to implement the communication functions within the communication device and / or the communication functions between the communication device and other devices or components.

[0032] In some possible implementations, the processor is used to communicate with other devices or components through the interface circuit.

[0033] In one possible implementation, the communication device may also include the memory.

[0034] The aforementioned communication device may be an access network device, or a module (e.g., a circuit, chip, or chip system) within an access network device, or a circuit or chip (e.g., a GPU, AI processor, or ASIC) within an access network device responsible for communication and / or computing functions, or a logical node or logical module capable of implementing all or part of the functions of the access network device.

[0035] In a seventh aspect, this application provides a communication system, which includes a first communication device and a second communication device, wherein the first communication device is used to implement the functions described in the first aspect, and the second communication device is used to implement the functions described in the second aspect.

[0036] Eighthly, this application provides a computer-readable storage medium storing computer-readable instructions that, when read and executed by a computer, cause the computer to perform any of the possible designs in the first to second aspects described above.

[0037] Ninthly, this application provides a computer program product that, when read and executed by a computer, causes the computer to perform any of the possible designs in the first to second aspects described above.

[0038] The effects of the solutions provided in any of the second to ninth aspects above can be referenced in the corresponding descriptions in the first aspect.

[0039] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0040] Figure 1 A schematic diagram of the architecture of a communication system provided for an embodiment of this application;

[0041] Figure 2 A schematic diagram of an open RAN architecture provided for embodiments of this application;

[0042] Figure 3 A schematic diagram of a CDRX operating mechanism provided for an embodiment of this application;

[0043] Figure 4 A schematic diagram of a timer operation mechanism provided for an embodiment of this application;

[0044] Figure 5A and Figure 5B A schematic diagram of the DRX timer operation mechanism provided for embodiments of this application;

[0045] Figure 6 A schematic diagram of a semantic communication system architecture provided for embodiments of this application;

[0046] Figure 7 A flowchart illustrating a communication method provided for an embodiment of this application;

[0047] Figure 8 and Figure 9 A schematic diagram illustrating the operation of the DRX timer as provided in an embodiment of this application;

[0048] Figure 10 A schematic diagram of the structure of a communication device provided for an embodiment of this application;

[0049] Figure 11 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. Detailed Implementation

[0050] References to "one embodiment" or "some embodiments" as described in this application mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0051] 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 alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c. Where a, b, and c can be single or multiple.

[0052] In this application, "sending information" can be understood as one device sending information to another device, or it can also be understood as one logical module within a device sending information to another logical module. For example, "access network device sending information" can be understood as the access network device sending information to another device (such as a terminal), or it can be understood as logical module 1 in the access network device sending information to logical module 2 in the access network device.

[0053] In this application, "receiving information" can be understood as one device receiving information from another device, or it can also be understood as a logical module within a device receiving information from another logical module. For example, "access network device receiving information" can be understood as the access network device receiving information from another device (such as a terminal), or it can be understood as logical module 1 in the access network device receiving information from logical module 2 in the access network device.

[0054] In this application, phrases such as "sending information to... (e.g., a terminal)" or related illustrations in the accompanying drawings can be understood as indicating that the destination of the information is a terminal. This can include sending information directly or indirectly to a terminal. Similarly, phrases such as "receiving information from... (e.g., a terminal)," "receiving information from... (e.g., a terminal)," or "receiving information sent by (e.g., a terminal)," or related illustrations in the accompanying drawings, can be understood as indicating that the source of the information is a terminal. This can include receiving information directly or indirectly from a terminal. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be interpreted similarly and will not be elaborated further here.

[0055] The terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. The terms "first" and "second" in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance, chronological order of operations, or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0056] First, the communication system involved in the embodiments of this application is introduced. This application can be applied to long-term evolution (LTE) systems, new radio (NR) systems, or future communication systems after 5G. This communication system includes at least one access network device and / or at least one terminal device. The access network device is sometimes also referred to as a network device in the following text.

[0057] Figure 1 This is a schematic diagram of the architecture of the communication system used in the embodiments of this application. Figure 1 As shown, the communication system 10 includes a radio access network (RAN) 100 and a core network (CN) 200. RAN 100 includes at least one RAN node (e.g., ...). Figure 1 110a and 110b (collectively referred to as 110) and at least one terminal (such as Figure 1 RAN 100, denoted as RAN 120a-120j, is collectively referred to as RAN 120. RAN 100 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment. Figure 1(Not shown in the image). Terminal 120 is connected to RAN node 110 wirelessly. RAN node 110 is connected to core network 200 wirelessly or via wired connection. The core network equipment in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.

[0058] RAN100 can be a cellular system related to the 3rd Generation Partnership Project (3GPP), such as 4G, 5G mobile communication systems, or future-oriented evolution systems. RAN100 can also be an open RAN (O-RAN or ORAN), cloud RAN (CRAN), virtualized RAN (vRAN), artificial intelligence radio access network (AI RAN), or wireless fidelity (WiFi) system. RAN100 can also be a communication system that integrates two or more of the above systems.

[0059] RAN node 110, sometimes also referred to as access network equipment, RAN entity, or access node, constitutes part of the communication system and is used to help terminals achieve wireless access. Multiple RAN nodes 110 in communication system 10 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal 120 are relative, for example... Figure 1 Network element 120i can be a helicopter or a drone, and it can be configured as a mobile base station. For terminals 120j that access RAN 100 through network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal. RAN node 110 and terminal 120 are sometimes referred to as communication devices, for example... Figure 1 Network elements 110a and 110b can be understood as communication devices with base station functions, while network elements 120a-120j can be understood as communication devices with terminal functions.

[0060] In one possible scenario, a RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future mobile communication system, or an access node in a WiFi system, etc. Figure 1 110a), micro base stations or indoor stations (such as Figure 1 The RAN node can be a relay node or donor node (as described in section 110b), or a wireless controller in a CRAN scenario. Optionally, the RAN node can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The RAN node can also be equipped with communication modules, circuits, or chips that perform corresponding communication functions. The RAN node can also be configured with program instructions for performing corresponding communication functions and corresponding program instructions. The RAN node in this application can also be a logical node, logical module, or software that can implement all or part of the functions of the access node, or a circuit or chip (such as a graphics processing unit (GPU), artificial intelligence (AI) processor, or application-specific integrated circuit (ASIC)) responsible for communication and / or computing functions in the access node.

[0061] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, with different RAN nodes each performing some of the functions of the base station. For example... Figure 2The diagram illustrates an open RAN architecture where RAN nodes can be centralized units (CUs), distributed units (DUs), CU-control planes (CPs), CU-user planes (UPs), or radio units (RUs), etc. CUs and DUs can be separate entities or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs). Furthermore, RAN nodes can also be computing units, providing computational power for tasks (such as model inference and / or model training), and can also be used to implement one or more of the following: task partitioning, scheduling, and orchestration. The functionality of the computing unit can be implemented by a separate module independent of other units (e.g., CUs, DUs, RUs), or by one or more other units (e.g., one or more of CUs, DUs, RUs).

[0062] In different systems, CU (or CU-CP and CU-UP), DU, computing unit, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, computing unit, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, computing unit, and RU in this application can be implemented through software modules, hardware modules, or a combination of software modules and hardware modules.

[0063] A terminal can be a device or module that accesses the aforementioned communication system and has corresponding communication functions. A terminal can also be called a terminal device, user equipment (UE), mobile station, mobile terminal, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, transportation vehicles with wireless communication capabilities, communication modules, etc. The embodiments of this application do not limit the device form of the terminal. The terminal typically contains communication modules, circuits, or chips that perform corresponding communication functions. Furthermore, it may also contain modules, circuits, or chips (such as GPUs, AI processors, or ASICs) that perform corresponding communication and / or computing functions. The terminal can also be configured with program instructions for performing these communication and / or computing functions.

[0064] To save power, UEs and other terminals can enable discontinuous reception (DRX). DRX allows the UE, such as its receiver, to periodically enter sleep mode. In sleep mode, the UE does not monitor the physical downlink control channel (PDCCH). When monitoring is required, the UE wakes up from sleep mode. The PDCCH can carry downlink control information (DCI).

[0065] The DRX mechanism is implemented differently in idle and connected states. The connected DRX (CDRX) mechanism is as follows: Figure 3 As shown. In Figure 3In a DRX cycle, the UE is divided into a sleep state and a wake-up state. When the UE is in the wake-up state, or during the active duration of the DRX cycle, the UE will detect the PDCCH. When the UE enters the sleep state to save power, or during the sleep opportunity for DRX cycle, the UE will not detect the PDCCH. It should be noted that the UE in the sleep state does not receive the PDCCH, but in some cases (such as semi-persistent scheduling (SPS)), the UE in the sleep state can receive (e.g., periodically receive) data from other physical channels (e.g., the physical downlink shared channel (PDSCH)).

[0066] To ensure normal data transmission, the DRX mechanism can be configured with various timers, such as the discontinuous reception continuous timer (drx-onDurationTimer) and the discontinuous reception inactivity timer (drx-InactivityTimer). Figure 4 This is a schematic diagram of a timer operation mechanism provided in an embodiment of this application, such as... Figure 4 As shown, `drx-onDurationTimer` is used to configure the length of the UE's "on duration" period in the DRX cycle, that is, the duration the UE is in the wake-up state. If data transmission is not complete after `drx-onDurationTimer` expires, it must wait until the next "on duration" period to continue transmission, affecting data transmission efficiency. Therefore, `drx-InactivityTimer` can be configured to instruct the UE to continue detecting the PDCCH for the duration that the DRX cycle's active duration has ended. Even if the active duration of the DRX cycle has ended, `drx-InactivityTimer` will continue to run until it times out, thus ensuring the UE's initial data transmission is completed.

[0067] For example, when a data transmission error requires retransmission, the UE can initiate a hybrid automatic repeat request (HARQ) process. The HARQ process requests retransmission of erroneous data that cannot be corrected by forward error correction (FEC) based on ACK / NACK feedback, ensuring the accuracy and efficiency of data transmission. During retransmission, the HARQ process can configure a discontinuous reception HARQ-RTT-Timer and a discontinuous reception retransmission timer. The drx-HARQ-RTT-Timer indicates the time the UE should wait before receiving the expected retransmission data. When the drx-HARQ-RTT-Timer is running, the UE does not need to detect the PDCCH. During downlink data transmission, when the UE detects a transmission error, it can send a NACK to the network device. When the drx-HARQ-RTT-Timer expires, the UE can start a drx-RetransmissionTimer for the corresponding HARQ process, indicating the maximum time the UE can wait for retransmission, to monitor the PDCCH used for HARQ retransmission. During uplink data transmission, since the UE cannot immediately determine whether the network device has successfully decoded the data, it can start the drx-RetransmissionTimer immediately after the drx-HARQ-RTT-Timer expires. This indicates the maximum time the UE can wait for data retransmission. That is, if the drx-RetransmissionTimer does not expire, the UE will continue to monitor the PDCCH, thus ensuring that erroneous data can be retransmitted within the current DRX cycle.

[0068] Figure 5A and Figure 5B This is a schematic diagram illustrating the DRX timer operation mechanism provided in an embodiment of this application. Figure 5A In the process, when drx-InactivityTimer times out and drx-RetransmissionTimer is not enabled, the UE will briefly enter a sleep state and will not detect the PDCCH until drx-HARQ-RTT-Timer times out and drx-RetransmissionTimer starts. At this point, the UE will switch to a wake-up state and detect the PDCCH again. Figure 5BIn the process, when drx-HARQ-RTT-Timer times out and drx-RetransmissionTimer starts, but drx-InactivityTimer has not yet timed out, the UE will continue to detect PDCCH until both drx-InactivityTimer and drx-RetransmissionTimer time out.

[0069] In recent years, a new generation of communication technologies, represented by semantic communications, has enabled communication systems to possess a certain degree of fault tolerance. Compared to traditional Shannon communication, fault-tolerant semantic communication technologies do not require precise recovery at the bit level, but rather pursue accurate semantic transmission, thus greatly improving communication efficiency. That is, fault-tolerant communication systems can maintain system performance well even when some features or data transmission errors occur. Figure 6 As illustrated in the schematic diagram of a semantic communication system architecture, such systems typically employ AI-based semantic encoders to extract key semantic features relevant to the task from input data. These features, after channel coding and modulation, are transmitted to the receiving end via a wireless channel. Correspondingly, at the receiving end, after demodulation and channel decoding, a semantic decoder can execute intelligent tasks based on the semantic features. Because semantic communication systems usually possess a certain degree of fault tolerance, intelligent tasks can still be executed normally, maintaining system performance even when only a portion of the features are successfully received at the receiving end.

[0070] Therefore, for these fault-tolerant communication systems, when the erroneously transmitted data is within acceptable limits, the erroneous data may not need to be retransmitted, thus eliminating the need to activate the drx-RetransmissionTimer and check the PDCCH. Alternatively, once the receiving end receives and decodes the correct data that meets the conditions, it will no longer need to receive more data, so it can stop activating the drx-InactivityTimer and checking the PDCCH. In this way, the wake-up time of communication devices such as terminals can be reduced while ensuring system performance, thereby reducing power consumption. Current communication methods do not consider the fault tolerance of the communication system, which may lead to unnecessary power consumption by the terminal during data transmission.

[0071] In view of this, this application provides a communication method. Specifically, a terminal receives DRX configuration information from a network device, the DRX configuration information being used to configure parameters of a DRX timer. Then, based on fault tolerance information or indication information from the network device, the operating state of the DRX timer is set. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that data transmission has fault tolerance capability; the fault tolerance threshold information indicates the amount of data allowed to be transmitted incorrectly; the fault tolerance mode information indicates the data mode allowed to be transmitted incorrectly; and the indication information sent by the network device is related to the fault tolerance information.

[0072] In this method, the terminal can set the running state of the DRX timer based on the fault tolerance information of the data transmission. This allows the DRX timer to be set to a non-running state when the terminal does not need to retransmit erroneous data or transmit remaining data, thus eliminating the need for the terminal to continue monitoring the PDCCH and reducing the terminal's power consumption.

[0073] To make the technical solution of this application clearer and easier to understand, the communication method and apparatus provided in this application will be further described below with reference to the accompanying drawings. It is understood that this application uses network devices and terminals as examples of the execution subjects in the interactive illustration, but this application does not limit the execution subjects of the interactive illustration. For example, the method executed by the network device in this application can also be implemented by modules (e.g., circuits, chips, or chip systems) in the network device, or by logical nodes, logical modules, or software that can implement all or part of the functions of the network device, or by circuits or chips (e.g., GPUs, AI processors, or ASICs) in the network device responsible for communication and / or computing functions. The method executed by the terminal in this application can also be implemented by communication and / or computing modules in the terminal, or by circuits or chips (e.g., modem chips (also known as baseband chips), or SoC chips / SIP chips containing modem cores, or GPUs / AI processors / ASICs) in the terminal responsible for communication and / or computing functions, or by logical nodes, logical modules, or software that can implement all or part of the terminal functions. See also Figure 7 The flowchart shown illustrates a communication method, which includes the following steps:

[0074] S702: The network device sends DRX configuration information, and the terminal receives the DRX configuration information from the network device. The DRX configuration information is used to configure the parameters of the DRX timer.

[0075] Network devices can configure DRX parameters to the Media Access Control (MAC) layer via the RRC layer. This can be achieved by instructing the UE to configure DRX and its parameters through ConnectionReconfiguration, RRCConnectionSetup, or RRCConnectionReestablishment messages. Upon receiving the DRX configuration (DRX-Config), the terminal sends the DRX configuration parameters to the MAC layer. The UE can check information elements (IEs) in the RRC messages, such as the MAC-MainConfig information element, to see if it includes the DRX-Config field. If so, the UE-side MAC layer can configure DRX parameters based on the DRX-Config field. The MAC layer then configures the relevant DRX parameters according to the DRX-Config. These parameters include the DRX period, DRX timer parameters, and packet information configured by the terminal based on the DRX configuration.

[0076] For ease of understanding, this application also provides an example. In this example, the network device can configure the parameters of the DRX timers for multiple terminals, as shown below:

[0077] DRX-Config::=SEQUENCE{

[0078]

[0079] Here, `drx-onDurationTimer` represents the duration of continuous activity after the terminal wakes up within a DRX cycle (or CDRX cycle). `drx-InactivityTimer` represents the duration after the terminal successfully decodes a downlink PDCCH, requiring continued monitoring. It is typically enabled during the initial data transmission to ensure complete data transmission within the current DRX cycle. `drx-HARQ-RTT-Timer` represents the time the terminal needs to wait before receiving the expected retransmitted data. That is, if the HARQ process fails to decode the transport block (TB), the terminal will not send or receive retransmitted data until at least `drx-HARQ-RTT-Timer` times out. Therefore, when `drx-HARQ-RTT-Timer` is running, the terminal does not need to monitor the PDCCH. `drx-HARQ-RTT-TimerDL` and `drx-HARQ-RTT-TimerUL` are configured based on downlink or uplink data transmission, respectively. The drx-RetransmissionTimer starts at the next symbol after the drx-HARQ-RTT-Timer times out. Specifically, during downlink data transmission, the terminal only starts a drx-RetransmissionTimerDL when it sends a NACK and the drx-HARQ-RTT-TimerDL times out. During uplink data transmission, since the terminal cannot immediately determine whether the network device has successfully decoded the data, the drx-RetransmissionTimerUL can be started immediately after the drx-HARQ-RTT-TimerUL times out. This time can be represented by the number of subframes or by other time unit granularities (such as the number of time slots or symbols).

[0080] S704: The terminal sets the running state of the DRX timer based on fault tolerance information or on indication information from the network device. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information, and the indication information is related to the fault tolerance information.

[0081] In communication systems, transmission errors are inevitable during the transmission of large amounts of data. These errors can occur due to factors such as noise, interference, or attenuation as the signal passes through the channel, data packets being lost during transmission, or data failing to be correctly identified or converted back to its original form during modulation or demodulation. With the development of communication technology, communication systems have gradually acquired a degree of fault tolerance, such as semantic communication systems. Compared to traditional Shannon communication, fault-tolerant semantic communication systems do not require precise lossless recovery at the bit level but rather pursue accurate semantic transmission, thus greatly improving communication efficiency. In other words, fault-tolerant communication systems can maintain system performance well even when some features or data transmission errors occur. Of course, the fault tolerance of a communication system is not unlimited. Therefore, the fault tolerance status during data transmission can be used as fault tolerance information to inform both the sender and receiver of the data, thereby improving communication efficiency.

[0082] Fault tolerance information indicates the conditions under which data errors are permissible during transmission between terminals and network devices. It can include at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. Fault tolerance capability information indicates that data transmission has fault tolerance capabilities, for example, it can be represented by a transmission identifier or a special field. Fault tolerance threshold information indicates the amount of data that is allowed to be transmitted erroneously, such as the ratio of correctly transmitted data to erroneously transmitted data in a certain data transmission interval, the specific number of erroneously transmitted data in a certain data transmission interval, or the proportion of erroneously transmitted data to the total data volume in the transmission interval. Fault tolerance mode information indicates the pattern of erroneously transmitted data, such as odd / even numbers, specific data, etc.

[0083] In some possible implementations, fault tolerance information can be synchronized between the terminal and the network device. Specifically, during uplink data transmission, the server can send fault tolerance information to both the terminal and the network device, or the terminal can send the fault tolerance information to the network device via signaling fields. For example, the terminal can send the fault tolerance information to the network device via RRC / MAC control elements (CE) / uplink control information (UCI). During downlink data transmission, the fault tolerance information can be sent from the server to the network device, and then the network device can send it to the UE via additional signaling fields such as RRC / MAC CE / DCI.

[0084] In some possible implementations, network devices can also predict fault tolerance information using historical transmission data. Specifically, network devices can summarize and deduce fault tolerance information based on the data transmission situation and system performance in the previous data transmission interval, and then verify it in the current data transmission interval. For example, when an artificial intelligence (AI) model is deployed on the network device side, the network device can train and infer based on the AI ​​model and historical transmission data to obtain predicted fault tolerance information, and then verify and confirm it in subsequent transmission processes.

[0085] The indication information, related to fault tolerance information, is sent by the network device to the terminal to instruct the terminal on the running status of the DRX timer. During uplink data transmission, the terminal may not immediately know whether the data has been transmitted correctly; therefore, the network device can send indication information to instruct the terminal on the running status of the DRX timer. During downlink data transmission, the terminal can determine the data transmission status itself and set the DRX timer's running status based on the fault tolerance information, or it can set the DRX timer's running status based on the indication information sent by the network device. Specifically, during uplink data transmission, the indication information can be determined based on the fault tolerance information and the uplink data transmission status; during downlink data transmission, the indication information can be determined based on the fault tolerance information and the downlink data transmission status contained in the feedback information sent by the terminal to the network device.

[0086] It should be noted that the information indicated by the indication information can be called the information to be indicated. In this embodiment, the information to be indicated is the operating state of the terminal-side DRX timer. In specific implementations, there are many ways to indicate the operating state of the terminal-side DRX timer. For example, but not limited to, the operating state of the terminal-side DRX timer can be directly indicated, such as the information to be indicated itself or its index. Alternatively, the operating state of the terminal-side DRX timer can be indirectly indicated by indicating other information, where there is a correlation between the other information and the operating state of the terminal-side DRX timer. It is also possible to indicate only a part of the operating state of the terminal-side DRX timer, while the other parts are known or pre-agreed upon. For example, the indication of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement order of various pieces of information, thereby reducing the indication overhead to some extent.

[0087] In some possible implementations, the terminal can stop the retransmission of erroneous data by setting the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer based on fault tolerance information or indication information. This reduces the number of erroneous data retransmissions, thereby reducing the time the terminal spends detecting the PDCCH and the time it is in the wake-up state, and lowering the terminal's power consumption. Specifically, the fault tolerance information may include a first fault tolerance threshold, which can indicate the amount of data that can be transmitted erroneously, such as the ratio of correctly transmitted data to erroneously transmitted data, the specific number of erroneously transmitted data allowed, etc. If the fault tolerance information can also indicate a first fault tolerance interval, that is, the transmission interval for judging the fault tolerance status of data, the first fault tolerance threshold can be the amount of data that can be transmitted erroneously within the first fault tolerance interval, such as the ratio of correctly transmitted data to erroneously transmitted data within the first fault tolerance interval, the specific number of erroneously transmitted data allowed within the first fault tolerance interval, the proportion of erroneously transmitted data to the total amount of data within the first fault tolerance interval, etc. As an example, the fault tolerance information may include the following: ErrorCapability=1, ErrorRange=10, ErrorBound=20%, indicating that a maximum of 20% of the data transmission errors are allowed out of every 10 data points, which is equivalent to 2 data points. When the number of erroneous data transmissions does not reach the first fault tolerance threshold, the terminal can set the running status of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to non-running.

[0088] It should be noted that setting the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state can be achieved in several ways. For example, when the transmitted erroneous data does not reach the first fault tolerance threshold, the terminal can disable or not start the timers even when drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer are configured, thus putting them in a non-running state. Another example is that when data transmission is periodic or regular, the terminal can not configure drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer in the next transmission cycle or interval, achieving the effect of the timers being in a non-running state. In some possible implementations, the terminal can disable the timers or invalidate the original configuration through special fields or identifiers in DRX-Config; this application does not limit this in any way.

[0089] In other possible implementations, fault tolerance information may include a first fault tolerance mode. This first fault tolerance mode can be a mode that allows the transmission of erroneous data. For example, if data is transmitted in the form of data packets, the first fault tolerance mode may specify that packets with odd numbers are allowed to be transmitted incorrectly, while packets with even numbers are not. Therefore, when data transmission conforms to the first fault tolerance mode, the terminal can refrain from retransmission when a packet with an odd number is transmitted incorrectly. It can set the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state, refrain from PDCCH detection, and reduce the terminal's power consumption. For example, semantic communication typically transmits key semantic features extracted from large amounts of data, or code blocks (CBs), code block groups (CBGs), or transport blocks (TBs) formed from one or more features. The first fault-tolerance mode can directly indicate the features, CBs, CBGs, or TBs that are allowed to transmit incorrectly, setting the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to non-running when an error occurs. Furthermore, fault-tolerance information can also indicate the first fault-tolerance interval, i.e., the transmission interval for judging the fault tolerance of data, thereby periodically judging the data transmission status.

[0090] To more clearly demonstrate the implementation methods and effects of the embodiments of this application, please refer to [link / reference]. Figure 8 This is a schematic diagram illustrating the operation of a DRX timer as provided in an embodiment of this application. Figure 8 If, during transmission, the erroneous data does not reach the first fault tolerance threshold and / or the transmission data meets at least one of the following conditions (i.e., the erroneous data does not reach the first fault tolerance threshold and / or the erroneous data meets the first fault tolerance mode), the terminal will set the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state, thereby not enabling PDCCH detection during this period, allowing the terminal to enter a sleep state and reducing power consumption. It should be noted that when erroneous data has not yet been retransmitted, for example, if the erroneous data in the transmitted data has not reached the first fault tolerance threshold, the terminal can... Figure 8 As shown in the upper half, within a DRX cycle, the device enters a sleep state after the drx-InactivityTimer times out. When erroneous data is partially retransmitted and meets the fault tolerance conditions (e.g., the proportion of erroneous data retransmitted does not reach the first fault tolerance threshold, or erroneous data outside the first fault tolerance mode is retransmitted), the terminal can... Figure 8The lower part shows how the running state of drx-RetransmissionTimer is switched to non-running state, prematurely ending the detection of PDCCH.

[0091] It should be noted that setting the running state of drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to non-running state is a necessary condition for the terminal to not detect PDCCH and to be in sleep mode. That is, if there is another timer running mechanism that requires the terminal to be in wake-up state during this period, the terminal will continue to detect PDCCH. This application does not discuss the relevant situations, nor does it impose any limitations.

[0092] In some possible implementations, the terminal can stop data transmission by setting the running state of drx-InactivityTimer based on fault tolerance information or indication information, thereby reducing the terminal's PDCCH detection time and wake-up time, and lowering the terminal's power consumption. Specifically, the fault tolerance information may include a second fault tolerance threshold, which can be the amount of correctly transmitted data, such as the ratio of correctly transmitted data to incorrectly transmitted data, or the specific amount of correctly transmitted data required. If the fault tolerance information can also indicate a second fault tolerance interval, i.e., the transmission interval for judging the fault tolerance status of data, the second fault tolerance threshold can indicate the amount of correctly transmitted data in the second fault tolerance interval, such as the ratio of correctly transmitted data to incorrectly transmitted data, the specific amount of correctly transmitted data required in the second fault tolerance interval, or the proportion of correctly transmitted data to the total data amount in the second fault tolerance interval. When the amount of correctly transmitted data reaches the second fault tolerance threshold, the terminal can set the running state of drx-InactivityTimer to a non-running state to stop PDCCH detection.

[0093] It should be noted that setting the running state of drx-InactivityTimer to a non-running state can be achieved in several ways. For example, when the correctly transmitted data reaches the second fault tolerance threshold, the terminal can disable or not start the timer when drx-InactivityTimer is configured, thus putting it in a non-running state. Another example is that when data transmission is periodic or regular, the terminal can not configure drx-InactivityTimer in the next transmission cycle or interval, achieving the effect of the timer being in a non-running state. In some possible implementations, the terminal can disable the timer or invalidate the original configuration through special fields or identifiers in DRX-Config; this application does not limit this approach.

[0094] In other possible implementations, fault tolerance information may include a second fault tolerance mode. This second fault tolerance mode may be the specific data that needs to be transmitted correctly. For example, in the transmission of audio data, an audio frame typically contains a series of information needed to reconstruct the original audio signal. The most important part is usually located in the audio frame header, including frame synchronization information to identify the start position, such as a framesync code or frame header, and possible error detection codes or error correction codes, as well as timestamps, sequence numbers, etc. Therefore, when specific data transmissions in the audio frame are correct, such as the audio frame header and the critical payload data transmissions being correct, the receiving end can recover the audio data without correctly decoding the remaining data. Thus, the data transmission process can be terminated early to reduce the transmission burden. The terminal can set the running state of the drx-InactivityTimer to a non-running state, not performing PDCCH detection, thereby reducing the terminal's power consumption. In addition, the fault tolerance information can also indicate the second fault tolerance interval, that is, the transmission interval for judging the fault tolerance status of the data, thereby periodically judging the data transmission status.

[0095] To more clearly demonstrate the implementation methods and effects of the embodiments of this application, please refer to [link / reference]. Figure 9 This is a schematic diagram illustrating the operation of a DRX timer as provided in an embodiment of this application. Figure 9 If the transmitted data meets at least one of the second fault tolerance threshold and / or the second fault tolerance mode, that is, the transmitted erroneous data reaches the second fault tolerance threshold and / or the transmitted erroneous data conforms to the second fault tolerance mode, the terminal will set the running state of drx-InactivityTimer to non-running state, so that the detection of PDCCH will not be enabled during this period, allowing the terminal to be in sleep state and reducing the power consumption of the terminal.

[0096] It should be noted that setting the running state of drx-InactivityTimer to non-running state is a necessary condition for the terminal to not detect PDCCH and to be in a sleep state. That is, if there is another timer running mechanism that requires the terminal to be in a wake-up state during this period, the terminal will continue to detect PDCCH. This application does not discuss related situations, nor does it impose any limitations.

[0097] In some possible implementations, the network device can send an indication message to the terminal when the terminal is instructed to change the running state of the DRX timer based on the data transmission status and fault tolerance information. In this case, the terminal needs to synchronize with the network device to a pre-agreed default timer running state. For example, if the terminal and network device synchronize the period during which the drx-InactivityTimer is set to the running state within a DRX cycle, and the network device determines, based on fault tolerance information and data transmission status, that the transmitted correct data has reached the second fault tolerance threshold, the network device can send an indication message to the terminal, instructing the terminal to set the drx-InactivityTimer to the non-running state. In this way, the indication message can be sent only when the timer's running state changes, reducing indication overhead and transmission burden to some extent.

[0098] In some possible implementations, during uplink data transmission, the terminal can also determine the retransmission method for erroneous data based on fault tolerance information. Specifically, when the fault tolerance information indicates the aforementioned first fault tolerance threshold and the data transmission has reached the first fault tolerance threshold, the terminal can retransmit the already erroneously transmitted data, or retransmit the erroneously transmitted data from the remaining data if a transmission error occurs. If the terminal chooses to retransmit the erroneously transmitted data from the remaining data only when a transmission error occurs, the terminal can set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state before the first fault tolerance threshold is reached, thereby reducing the terminal's power consumption. If the terminal chooses to retransmit the already erroneously transmitted data when the erroneously transmitted data reaches the first fault tolerance threshold, the terminal can partially retransmit the already erroneously transmitted data. After determining that the erroneously transmitted data after retransmission has not reached the first fault tolerance threshold, the terminal can still set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state again until the erroneously transmitted data reaches the first fault tolerance threshold again.

[0099] Based on the above description, this application provides a communication method, which specifically includes: a terminal receiving DRX configuration information from a network device, the DRX configuration information being used to configure parameters of a DRX timer. Then, based on fault tolerance information or indication information from the network device, the operating state of the DRX timer is set. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that data transmission has fault tolerance capability; the fault tolerance threshold information indicates the amount of data allowed to be transmitted incorrectly; the fault tolerance mode information indicates the data mode allowed to be transmitted incorrectly; and the indication information sent by the network device is related to the fault tolerance information.

[0100] In this method, the terminal can set the running state of the DRX timer based on the fault tolerance information of the data transmission. This allows the corresponding DRX timer to be set to a non-running state when the terminal does not need to retransmit erroneous data or transmit redundant data, thus eliminating the need for the terminal to continue monitoring the PDCCH and reducing the terminal's power consumption.

[0101] The apparatus provided in the embodiments of this application will now be described. Please refer to... Figure 10 , Figure 10 A possible exemplary block diagram of the communication device involved in an embodiment of this application is shown. For example... Figure 10 As shown, the communication device 1000 may include modules or units for implementing the methods described in the embodiments above. In one possible design, the communication device 1000 includes a processing unit 1002 and a communication unit 1003. Optionally, the communication device 1000 may further include a storage unit 1001 for storing device program code and / or data.

[0102] The communication device 1000 can be a terminal-side device as described in the above embodiments, such as a terminal or a communication module in a terminal, or a circuit or chip in a terminal that is responsible for communication functions.

[0103] For example, in one embodiment, the processing unit 1002 is configured to: set the operating state of the DRX timer according to fault tolerance information or according to indication information from the network device. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that the data transmission has fault tolerance capability; the fault tolerance threshold information indicates the amount of data allowed to be transmitted incorrectly; the fault tolerance mode information indicates the data mode allowed to be transmitted incorrectly; and the indication information is related to the fault tolerance information.

[0104] In one possible design, the DRX timer includes a drx-RetransmissionTimer and / or a drx-HARQ-RTT-Timer, with fault tolerance threshold information indicating a first fault tolerance threshold and / or fault tolerance mode information indicating a first fault tolerance mode. The processing unit 1002 is specifically configured to: set the drx-RetransmissionTimer and / or the drx-HARQ-RTT-Timer to a non-running state when at least one or more of the following first conditions are met: the transmitted erroneous data does not reach the first fault tolerance threshold, or the transmitted erroneous data conforms to the first fault tolerance mode.

[0105] In one possible design, the fault tolerance information also indicates a first fault tolerance interval, and the processing unit 1002 is specifically used to: set drx-RetransmissionTimer and / or drx-HARQ-RTT-Timer to a non-running state when at least one or more of the following first conditions are met: the data transmitted in error in the first fault tolerance interval has not reached the first fault tolerance threshold, and the data transmitted in error in the first fault tolerance interval conforms to the first fault tolerance mode.

[0106] In one possible design, the DRX timer includes a drx-InactivityTimer, fault tolerance threshold information indicating a second fault tolerance threshold and / or fault tolerance mode information indicating a second fault tolerance mode. The processing unit 1002 is specifically used to: set the drx-InactivityTimer to a non-running state when at least one or more of the following second conditions are met: the transmission of correct data reaches the second fault tolerance threshold, and the transmission of correct data conforms to the second fault tolerance mode.

[0107] In one possible design, the fault tolerance information also indicates a second fault tolerance interval, and the processing unit 1002 is specifically used to: set drx-InactivityTimer to a non-running state when at least one or more of the following second conditions are met: the transmission of correct data in the second fault tolerance interval reaches a second fault tolerance threshold, and the transmission of correct data in the second fault tolerance interval conforms to the second fault tolerance mode.

[0108] In one possible design, the communication unit 1003 is used to: receive DRX configuration information from the network device, the DRX configuration information being used to configure parameters of the DRX timer.

[0109] In one possible design, the communication unit 1003 is also used to: send error information to a network device, or receive fault-tolerant information from a server or network device.

[0110] In one possible design, when the communication device 1000 is a terminal or a communication module within a terminal, the function of the processing unit 1002 can be implemented by one or more processors. Specifically, the processor may include a modem chip, or a system-on-a-chip (SoC) chip or a SIP chip containing a modem core. The function of the communication unit 1003 can be implemented by transceiver circuitry.

[0111] In one possible design, when the communication device 1000 is a circuit or chip in a terminal responsible for communication functions, such as a modem chip or a system-on-a-chip (SoC) or SIP chip containing a modem core, the function of the processing unit 1002 can be implemented by a circuit system in the aforementioned chip that includes one or more processors or processor cores. The function of the communication unit 1003 can be implemented by the interface circuitry or data transceiver circuitry on the aforementioned chip.

[0112] In one possible design, when the communication device 1000 is a terminal or a communication and / or computing module within a terminal, the functionality of the processing unit 1002 can be implemented by one or more processors. Specifically, the processor may include a GPU, or a system-on-a-chip (SoC) or SIP chip containing a GPU. Alternatively, the processor may include an AI processor, or a SoC or SIP chip containing an AI processor. Or, the processor may include an ASIC, or a SoC or SIP chip containing an ASIC. The functionality of the communication unit 1003 can be implemented by transceiver circuitry.

[0113] In one possible design, when the communication device 1000 is a circuit or chip in a terminal responsible for communication and / or computing functions, such as a GPU or a system-on-a-chip (SoC) or SIP chip containing a GPU, an AI processor or a SoC or SIP chip containing an AI processor, or an ASIC or a SoC or SIP chip containing an ASIC, the function of the processing unit 1002 can be implemented by a circuit system in the aforementioned chip that includes one or more processors or processor cores. The function of the communication unit 1003 can be implemented by interface circuits or data transceiver circuits on the aforementioned chip.

[0114] The communication device 1000 can be a network-side device as described in the above embodiments. For example, it can be a communication module in a network device, or a circuit or chip in a network device that is responsible for communication functions.

[0115] For example, in one embodiment, the processing unit 1002 is used to determine indication information based on fault tolerance information, and the indication information is used to set the running state of the DRX timer.

[0116] In one possible design, the communication unit 1003 is used to: send DRX configuration information to the terminal, the DRX configuration information being used to configure the parameters of the DRX timer.

[0117] In one possible design, the communication unit 1003 is also used to: send indication information to the terminal, the indication information being used to set the running state of the DRX timer.

[0118] In one possible design, the communication unit 1003 is also used to: receive fault-tolerant information from a server or terminal, or send fault-tolerant information to a terminal.

[0119] In one possible design, when the communication device 1000 is a network device or a communication module within a network device, the function of the processing unit 1002 can be implemented by one or more processors. Specifically, the processor may include a modem chip, or a system-on-a-chip (SoC) chip or a SIP chip containing a modem core. The function of the communication unit 1003 can be implemented by transceiver circuitry.

[0120] In one possible design, when the communication device 1000 is a circuit or chip responsible for communication functions in a network device, such as a modem chip or a system-on-a-chip (SoC) or SIP chip containing a modem core, the function of the processing unit 1002 can be implemented by a circuit system in the aforementioned chip that includes one or more processors or processor cores. The function of the communication unit 1003 can be implemented by interface circuits or data transceiver circuits on the aforementioned chip.

[0121] In one possible design, when the communication device 1000 is a network device or a communication and / or computing module within a network device, the functionality of the processing unit 1002 can be implemented by one or more processors. Specifically, the processor may include a GPU, or a system-on-a-chip (SoC) or SIP chip containing a GPU. Alternatively, the processor may include an AI processor, or a SoC or SIP chip containing an AI processor. Or, the processor may include an ASIC, or a SoC or SIP chip containing an ASIC. The functionality of the communication unit 1003 can be implemented by transceiver circuitry.

[0122] In one possible design, when the communication device 1000 is a circuit or chip in a network device responsible for communication and / or computing functions, such as a GPU or a system-on-a-chip (SoC) or SIP chip containing a GPU, an AI processor or a SoC or SIP chip containing an AI processor, or an ASIC or a SoC or SIP chip containing an ASIC, the function of the processing unit 1002 can be implemented by a circuit system in the aforementioned chip that includes one or more processors or processor cores. The function of the communication unit 1003 can be implemented by interface circuits or data transceiver circuits on the aforementioned chip.

[0123] It is understandable that the division of units in the above-mentioned device is merely a logical functional division. One function can correspond to one functional unit, or two or more functions can be integrated into one functional unit. In actual implementation, all or some units can be integrated into one physical entity, or they can be distributed across different physical entities. Furthermore, the above-mentioned functional units can be implemented in hardware, software, or a combination of both.

[0124] In one example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as: one or more application-specific integrated circuits (ASICs), or one or more central processing units (CPUs), one or more microcontroller units (MCUs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.

[0125] In one example, storage unit 1001 may include random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory and / or registers, etc.

[0126] See Figure 11 This is a schematic diagram of the structure of a terminal 1100 provided in an embodiment of this application. The terminal 1100 can correspond to... Figure 1 or Figure 7 The terminal shown is used to implement the operations of the terminal in the above embodiments. Figure 11 As shown, the terminal includes: one or more antennas 1110, a radio frequency processing system 1120, and a processor system 1130.

[0127] In the downlink or sidelink direction, the RF processing system 1120 receives RF signals through the antenna 1110 and sends the RF-processed signals to the processor system 1130 for further processing. In the uplink or sidelink direction, the processor system 1130 processes the terminal-side information and sends it to the RF processing system 1120, which then processes the signal and transmits it through the antenna 1110.

[0128] In one example, the radio frequency (RF) processing system 1120 serves as the communication interface for external communication of the terminal and may include an RF front end (RFFE) 1121 and an RF transceiver 1022. The RFFE 1121 is primarily used for one or more processing operations, such as shaping, passband selection, or gain adjustment, on the RF signals received by the antenna or those to be transmitted through the antenna. It may include one or more components such as RF switches, duplexers, filters, power amplifiers, antenna tuners, and low-noise amplifiers. The RFFE 1121 can be a circuit system composed of multiple discrete devices or integrated into one or more chips. The RF transceiver 1122 processes the RF signals received by the RFFE into baseband / IF signals for further processing by the processor system 1130, and processes the baseband / IF signals provided by the processor system 1130 into RF signals for transmission to the RFFE 1121. The baseband / IF signals transmitted between the RF transceiver 1122 and the processor system 1130 can be digital or analog signals. The radio frequency transceiver 1122 can be implemented by one or more chips, which are commonly referred to as radio frequency chips (RFICs).

[0129] In one example, processor system 1130 may include one or more processors for processing signals and executing one or more communication protocols. Optionally, processor system 1130 may also include memory 1136. In one example, the one or more processors include at least one baseband processor 1131 (also known as a modem processor). Memory 1136 is used to store data and / or computer program instructions. Optionally, processor system 1130 may also include one or more application processors 1132 for implementing processing of the terminal operating system and application layer. Application processor 1132 may include, for example, a GPU, AI processor, or ASIC. Optionally, processor system 1130 may also include one or more of a voice subsystem 1133, a multimedia subsystem 1134, or an interface circuit 1135. The voice subsystem 1133 is used to process voice signals, the multimedia subsystem 1134 is used to handle multimedia-related operations, such as video encoding / decoding, image processing, etc., and the interface circuit 1135 is used to implement communication with other terminal components, such as a display 1140, an input device 1150, memory 1160, etc. The aforementioned components in the processor system 1130 can communicate with each other via a bus or communication interface circuit.

[0130] In one example, processor system 1130 can be packaged as a single processor chip, such as a SoC chip or a SIP chip. In another example, processor system 1130 can be a system of multiple chips, for example, the baseband processor 1131 can be packaged as a single chip, or packaged with part or all of the circuitry of the radio frequency processing system into a single chip.

[0131] In one example, memory 1136 can be on-chip memory, i.e., located on the processor system 1130 chip. In another example, memory 1160 can be off-chip memory, i.e. located outside the processor system 1130 chip.

[0132] In one example, the baseband processor 1131 may include one or more processor cores 11311 and interface circuitry 11314. The one or more processor cores 11311 are used to process signals and execute one or more communication protocols. Optionally, the baseband processor 1131 may also include a memory 11312 for storing at least a portion of the corresponding computer program instructions and / or data. In one example, the one or more processor cores 11311 execute the computer program instructions stored in the memory 11312 to implement the relevant operations in the above method embodiments (such as setting the operating state of the DRX timer according to fault tolerance information or according to indication information from the network device). In this disclosure, memory 11312 is used to store corresponding computer program instructions and / or data. This can mean that memory 11312 stores all corresponding computer program instructions and / or data for execution by processor core 11311; or it can mean that memory 11312 stores a portion of corresponding computer program instructions and / or data, including the computer program instructions and / or data currently required to be executed by processor core 11311. Memory 11312 can store different portions of computer program instructions and / or data multiple times for execution by processor core 11311 to implement the relevant operations in the above method embodiments. Interface circuit 11314 serves as a communication interface for communication with other components, such as transmitting signals with radio frequency processing system 1120, communicating with other subsystems and related components of processor system 1130 via a bus, such as transmitting data control signals with application processor 1132, and transmitting data or computer program instructions with memory 1136 or memory 1160. Optionally, in order to reduce the load on the processor core, a baseband signal processing circuit 11313 can be set to perform at least some baseband signal processing, including one or more of signal demodulation, modulation, encoding or decoding.

[0133] In one example, the communication device provided in this application may be a terminal 1100, a communication module including a processor system 1130 and a radio frequency system 1120, or a baseband processor 1131.

[0134] The processor, processor system, application processor, baseband processor, processor circuit, or processor core mentioned above can be collectively referred to as a processor. The processor may include one or more of the following: central processing unit (CPU), digital signal processor (DSP), microprocessor unit (MPU), microcontroller unit (MCU), graphics processing unit (GPU), field programmable gate array (FPGA), application-specific integrated circuit (ASIC), artificial intelligence processor (AI processor), or neural processing unit (NPU).

[0135] The aforementioned memory may include one or more of the following storage media: random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), phase-change memory (PCM), resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), cache, register, read-only memory (ROM), flash memory, erasable programmable read-only memory (EPROM), hard disk, etc. In one example, computer program instructions for executing the above embodiments may be stored on non-volatile memory, such as at least a portion of the aforementioned memory 1160 (e.g., one or more of ROM, flash memory, EPROM, or hard disk). When the terminal is running, the corresponding computer program instructions may be partially or wholly loaded onto a memory with a faster transfer speed than the processor, such as at least a portion of memory 1136 and / or memory 11312 (e.g., one or more of RAM, SRAM, DRAM, PCM, RERAM, MRAM, FRAM, cache, or register), for the processor to execute in order to implement the steps in the above method embodiments.

[0136] In one example, the RF transceiver 1122 and the RF front-end 1121 can also be packaged in a single chip. In another example, the RF transceiver 1122, the RF front-end 1121, and the baseband processor 1131 can also be packaged in a single chip.

[0137] The processor mentioned above can be a general-purpose central processing unit, a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of a program for controlling the method provided in any of the above embodiments. The memory mentioned above can be read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, such as random access memory (RAM).

[0138] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the explanations and beneficial effects of the relevant contents in any of the above-mentioned devices can be referred to the corresponding method embodiments provided above, and will not be repeated here.

[0139] 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 an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

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

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

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

[0144] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0145] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

Claims

1. A communication method, characterized in that, The method includes: Receive discontinuous reception DRX configuration information from network devices, wherein the DRX configuration information is used to configure parameters of the DRX timer; The operating state of the DRX timer is set according to fault tolerance information or according to indication information from the network device. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that the data transmission has fault tolerance capability. The fault tolerance threshold information indicates the amount of data that can be transmitted incorrectly. The fault tolerance mode information indicates the data mode that can be transmitted incorrectly. The indication information is related to the fault tolerance information.

2. The method according to claim 1, characterized in that, The DRX timer includes a DRX retransmission timer and / or a DRX hybrid automatic repeat request (HARQ) round-trip timer (RTT) timer. The fault tolerance threshold information indicates a first fault tolerance threshold and / or the fault tolerance mode information indicates a first fault tolerance mode. The DRX retransmission timer and / or the DRX HARQ RTT timer are set to a non-running state when at least one or more of the following first conditions are met: The erroneous data transmitted did not reach the first fault tolerance threshold, and the erroneous data transmitted conformed to the first fault tolerance mode.

3. The method according to claim 2, characterized in that, The fault tolerance information also indicates a first fault tolerance interval, wherein the first condition includes: The erroneous data transmitted in the first fault tolerance interval does not reach the first fault tolerance threshold, and the erroneous data transmitted in the first fault tolerance interval conforms to the first fault tolerance mode.

4. The method according to any one of claims 1 to 3, characterized in that, The DRX timer includes a DRX inactive timer, the fault tolerance threshold information indicates a second fault tolerance threshold and / or the fault tolerance mode information indicates a second fault tolerance mode, and the DRX inactive timer is set to a non-running state when at least one or more of the following second conditions are met: The transmission of correct data reaches the second fault tolerance threshold, and the transmission of correct data conforms to the second fault tolerance mode.

5. The method according to claim 4, characterized in that, The fault tolerance information also indicates a second fault tolerance interval, the second condition including: The transmission of correct data in the second fault tolerance interval reaches the second fault tolerance threshold, and the transmission of correct data in the second fault tolerance interval conforms to the second fault tolerance mode.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Send the fault tolerance information to the network device, or receive the fault tolerance information from the server or the network device.

7. A communication method, characterized in that, The method includes: Send discontinuous reception DRX configuration information to the terminal, wherein the DRX configuration information is used to configure the parameters of the DRX timer; Based on the fault tolerance information, an indication information is sent to the terminal. The indication information is used to set the running state of the DRX timer. The fault tolerance information includes at least one of fault tolerance capability information, fault tolerance threshold information, or fault tolerance mode information. The fault tolerance capability information indicates that the data transmission has fault tolerance capability. The fault tolerance threshold information indicates the amount of data that can be transmitted incorrectly. The fault tolerance mode information indicates the data mode that can be transmitted incorrectly.

8. The method according to claim 7, characterized in that, The DRX timer includes a DRX retransmission timer and / or a DRX hybrid automatic repeat request (HARQ) round-trip timer (RTT). The fault tolerance threshold information indicates a first fault tolerance threshold and / or the fault tolerance mode information indicates a first fault tolerance mode. Under at least one or more of the following first conditions, the indication information indicates that the DRX retransmission timer and / or the DRX HARQ RTT timer need to be set to a non-running state: The erroneous data transmitted did not reach the first fault tolerance threshold, and the erroneous data transmitted conformed to the first fault tolerance mode.

9. The method according to claim 8, characterized in that, The fault tolerance information also indicates a first fault tolerance interval, wherein the first condition includes: The erroneous data transmitted in the first fault tolerance interval does not reach the first fault tolerance threshold, and the erroneous data transmitted in the first fault tolerance interval conforms to the first fault tolerance mode.

10. The method according to any one of claims 7 to 9, characterized in that, The DRX timer includes a DRX inactive timer, the fault tolerance threshold information indicates a second fault tolerance threshold and / or the fault tolerance mode information indicates a second fault tolerance mode, and the indication information indicates that the DRX inactive timer needs to be set to a non-running state if at least one or more of the following second conditions are met: The transmission of correct data reaches the second fault tolerance threshold, and the transmission of correct data conforms to the second fault tolerance mode.

11. The method according to claim 10, characterized in that, The fault tolerance information also indicates a second fault tolerance interval, the second condition including: The transmission of correct data in the second fault tolerance interval reaches the second fault tolerance threshold, and the transmission of correct data in the second fault tolerance interval conforms to the second fault tolerance mode.

12. A communication device, characterized in that, The device includes: A unit for performing the method as described in any one of claims 1 to 6.

13. A communication device, characterized in that, The device includes: A unit for performing the method as described in any one of claims 7 to 11.

14. A computer storage medium, characterized in that, The computer storage medium is used to store computer programs or instructions, which, when executed, cause the method as described in any one of claims 1 to 6 to be implemented, or cause the method as described in any one of claims 7 to 11 to be implemented.

15. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the method as described in any one of claims 1 to 6 to be implemented, or causes the method as described in any one of claims 7 to 11 to be implemented.

Images